[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Packet Transfer?
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Packet Transfer? |
Date: |
Thu, 9 Feb 2006 14:29:44 -0800 |
User-agent: |
Mutt/1.5.9i |
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
Re: [Discuss-gnuradio] Packet Transfer?, Joshua Lackey, 2006/02/09