[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Packet Transfer?

From: Michael Dickens
Subject: Re: [Discuss-gnuradio] Packet Transfer?
Date: Thu, 9 Feb 2006 16:10:46 -0500

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]