[Tinyos-devel] Current status of the message buffer discussion
Stephen Dawson-Haggerty
stevedh at eecs.berkeley.edu
Tue May 19 10:18:33 PDT 2009
This is a good discussion-- a few extra points
- I use gather within blip to implement IP header processing, and
many things about it are very convenient. The memory overhead is only
about 4 bytes per header for iovec-style header processing However,
I'm not sure I see a real advantage over these proposals in this case.
The reason is because unless you are dynamically allocating memory,
the regions pointed to from the iovec must be inside the static
message_t. Therefore, the only new thing this would allow you to do
is to insert headers at arbitrary places in the message, which seems
to be of limited value to me.
- I think one real issue with proposal (2) is not knowing how much
payload is available until you send(). In (1) presumably once the
headers are reserved, you can call getMaxPayload() and learn how much
room is available in the packet.
- Has there been any discussion of standardizing header processing?
TLVs, to improve interop?
Thanks,
Steve
On Mon, May 11, 2009 at 1:46 AM, Miklos Maroti <mmaroti at math.u-szeged.hu> wrote:
> On Mon, May 11, 2009 at 6:34 AM, culler <culler at cs.berkeley.edu> wrote:
>> Classically, on the inbound path you have a contiguous packet with the
>> telescoping layers of encapsulation. The trick is the outbound path, since
>> each layer does not know what the layers around it want to wrap around it.
>> Classically, you build a list of these (mbufs) as you go down and perform a
>> gather as it goes out. Or, you need to determine from the layers below what
>> they need. All of addresses and header fields aree just encapsulating
>> information. Given that our processors are really fast compared to these
>> paltry radios, it is not obvious that gather is a problem. Very retro, but
>> there is a reason that it was done in the old days.
>
> Gather would be very nice and flexible, but probably it would waste memory.
>
> David, could you please shed some light on what is the final goal?
> What exactly do people want to archive that requires variable size
> headers? It is not enough for me to say that 16 and 64-bit addresses,
> because I also want to know what interfaces you want to use. Do people
> have two interfaces in mind, one AMPacket to access 16-bit and another
> for 64-bit, or we want to have two AMSend interfaces, one with 16-bit
> and one for 64-bit, or we want one interfaces to be able access both
> 16 and 64-bit addresses, or we want to always use 64bit addresses in
> software but would like to be able to receive 16-bit addresses too and
> cast them to 64-bit?
>
> My real question is: how application developers want to interact with
> the message buffer? I would like to see use cases.
>
> Miklos
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
More information about the Tinyos-devel
mailing list