Re: [Discuss-gnuradio] Packet Transfer?

[Michael Dickens]

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

NOTE: This is all wishful; not necessarily reality:

> 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.