Re: [Discuss-gnuradio] Packet Transfer?

[Eric Blossom]

On Thu, Feb 09, 2006 at 04:10:46PM -0500, Michael Dickens wrote:
> Eric - Where is the scheduler code located?  I'll take a look at it  
> when I get a chance, and see if there's anything which pops out at me  
> as an obvious way to make this idea work. - MLD

Part of the setup is in python, the runtime part is in C++.

gnuradio-core/src/python/gnuradio/gr:

   basic_flow_graph.py
   flow_graph.py
   scheduler.py

gnuradio-core/src/lib/runtime:

   gr_single_threaded_scheduler.{h,cc}          # the runtime scheduler

      you'll also want to look at

   gr_block.{h,cc} and gr_block_detail.{h,cc}


> NOTE: This is all wishful; not necessarily reality:

  "You may say I'm a dreamer, but I'm not the only one..."

> >What I'd really like is to send packets as structured chunks of data,
> >using "connect()" in a graph.
> 
> "structured chunks of data" --> The buffer structure would define the  
> packet(s).  Somewhere in that structure would be the total packet  
> length (including header), the payload length, whatever else is  
> wanted ... but for the sake of GR-internals, keep this to a minimum.   
> Given that multiple packets might be appended, I would suggest a meta- 
> structure describing how many packets are to be found.  e.g. In the  
> simplest case, the data would be structured to look like (the  
> "dummy_passing" are in case a packet needs to be on a particular  
> memory boundary):
> 
> struct buffer {
>   ulong num_packets;
>   packet[0] = {
>     ulong total_packet_length;
>     char payload[total_packet_length - sizeof(ulong)];
>   };
>   char dummy_padding_0[xxx];
>   ...
>   packet[num_packets-1] = {
>     ulong total_packet_length;
>     char payload[total_packet_length - sizeof(ulong)];
>   };
>   char dummy_padding_N[yyy];
> };
> 
> The scheduler would need to "know" that these are packets, not
> streams.  This could be done, maybe, via an enum (or bool; e.g.  
> "DATA_STREAM" or "DATA_PACKET").  For the "STREAM" case, the schedule  
> knows it can append and split data as needed depending on the data  
> size provided by the I/O signature, just as it does now.  For the  
> "PACKET" case, the scheduler knows it must keep individual packets in  
> continuous memory, but (with appropriate structuring) can split or  
> append packets depending on need.  It's really a matter deciding "how  
> much" data can be appended or split, and "knowing how" to structure  
> accordingly ... the "PACKET" class is really a sub-class of the  
> "STREAM" class, but with more programming to handle the variable  
> packet structure.
> 
> This model is a little trickier than the basic stream model w/r.t.  
> memory usage.  But I think that the "forecast()" method (or  
> equivalent, in the sub-class) could be used to get the correct I/O  
> sizes and make sure memory was allocated correctly.
> 
> The data I/O model already provided in C++, combined with an upgraded  
> scheduler to handle stream and packet types, would allow for your  
> example of appending 8 zeros (or a CRC) to the packet stream by  
> copying the structure and changing the 'length' parameter to reflect  
> the addition.

Eric