[Tinyos Core WG] Fwd: [Tinyos-devel] message_t

Tue May 5 23:12:23 PDT 2009

Begin forwarded message:

> From: Jan Hauer <hauer at tkn.tu-berlin.de>
> Date: March 12, 2009 12:34:11 PM PDT
> To: tinyos-devel at millennium.berkeley.edu
> Subject: Re: [Tinyos-devel] message_t
>
> I have updated the proposal, it now uses the same message buffer
> abstraction for the send and receive path and supports buffer swapping
> on receive. It's based on a circular buffer and forwarding typically
> doesn't require copying, but on the send-path protocols would have to
> access the buffer via special accessor functions. To be compatible
> with AM we *would* have to copy the PDU. The metadata approach has not
> changed. I've not included any examples yet.
>
> Jan
>
> On Thu, Mar 12, 2009 at 4:41 PM, Andreas Köpke
> <andreas.koepke at tu-berlin.de> wrote:
>> One should not overemphasize the "do not copy" mantra. BaseStation  
>> for example
>> makes an explicit copy, although in a strange fashion. In addition,  
>> we can
>> copy a packet of 128 bytes length in about 64us -- switching from  
>> rx to tx, or
>> computing the CRC takes longer than that.
>>
>> Best, Andreas
>>
>>
>> On Donnerstag 12 März 2009 Jan Hauer wrote:
>>> This proposal didn't support buffer swapping, so you'd have to copy
>>> the payload before forwarding. To be compatible with AM you'd also
>>> have to copy into message_t (we always thought a single copy would  
>>> be
>>> ok). But if the proposal was adapted to use a ring buffer instead of
>>> the (still) fixed message buffer layout then copying might not be
>>> necessary... I'll adapt the proposal and distribute an updated  
>>> version
>>> in the next email.
>>>
>>> Jan
>>>
>>>
>>> On Wed, Mar 11, 2009 at 9:00 PM, Janos Sallai
>>>
>>> <sallai at isis.vanderbilt.edu> wrote:
>>>> Jan,
>>>>
>>>> I just quickly skimmed through the writeup. I have two questions:
>>>>
>>>> 1. If there are different message structures on the transmit and
>>>> receive paths, how can we do bridging without buffer copying?
>>>>
>>>> 2. How would it be possible, with the proposed message  
>>>> abstraction, to
>>>> provide an AM compatibility layer?
>>>>
>>>> Janos
>>>>
>>>> On Wed, Mar 11, 2009 at 2:36 PM, Jan Hauer <hauer at tkn.tu- 
>>>> berlin.de> wrote:
>>>>> Attached is a proposal for an alternative message buffer  
>>>>> abstraction
>>>>> that allows variable-sized protocol headers/footers, but still  
>>>>> uses
>>>>> static allocation of the message buffer. We have not discussed  
>>>>> this in
>>>>> detail, so ... go on and take it apart :)
>>>>>
>>>>> Jan
>>>>>
>>>>> On Wed, Mar 11, 2009 at 6:53 PM, Philip Levis  
>>>>> <pal at cs.stanford.edu>
>> wrote:
>>>>>> As developers have started implementing standards on TinyOS,  
>>>>>> message_t
>>>>>> has started to show some limitations. The goal of message_t was  
>>>>>> to
>>>>>> allow software to pass messages between different AM link layers
>>>>>> without copying, and this involved several simplifying  
>>>>>> assumptions. As
>>>>>> systems need more complex link layers (e.g., more than one 15.4
>>>>>> addressing mode, security support, IPv6 on top of 15.4), some  
>>>>>> of the
>>>>>> design decisions have started to become problematic.
>>>>>>
>>>>>> For example, message_t requires that the header, data, and  
>>>>>> footer be
>>>>>> allocated separately. Depending on your 15.4 addressing and other
>>>>>> options, the header can be anywhere from 3 to 30 bytes or so.
>>>>>> Correspondingly, the payload can be anywhere from 120 to 95  
>>>>>> bytes or
>>>>>> so. While the two of them have, in combination, a maximum length
>>>>>> (125), you have to allocate the maximum of each of them  
>>>>>> separately,
>>>>>> leading to about a 20% waste (150 bytes).
>>>>>>
>>>>>> This has led core to start looking at other message  
>>>>>> abstractions. It's
>>>>>> important to note that changing the underlying buffer  
>>>>>> abstraction used
>>>>>> by radio drivers does not mean we have to break AM-based software
>>>>>> compatibility: many of these issues are arising exactly because  
>>>>>> TinyOS
>>>>>> needs more than just AM. At the worst case, you just make a  
>>>>>> single
>>>>>> copy between the AM layer (message_t) and other buffer  
>>>>>> abstraction
>>>>>> that drivers and other stacks use.
>>>>>>
>>>>>> Jan (TU Berlin) is going to send out one proposal he's come up  
>>>>>> with.
>>>>>> Stephen (Berkeley) also has some thoughts, and I encourage  
>>>>>> everyone to
>>>>>> examine the proposals. This is hopefully something that will  
>>>>>> change
>>>>>> for 2.1.1, or if more involved than anticipated, maybe a later  
>>>>>> version.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Phil
>>>>>> _______________________________________________
>>>>>> Tinyos-devel mailing list
>>>>>> Tinyos-devel at millennium.berkeley.edu
>>>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-dev
>>>>>> el
>>>>>
>>>>> _______________________________________________
>>>>> Tinyos-devel mailing list
>>>>> Tinyos-devel at millennium.berkeley.edu
>>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-deve
>>>>> l
>>>>
>>>> _______________________________________________
>>>> Tinyos-devel mailing list
>>>> Tinyos-devel at millennium.berkeley.edu
>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>>
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at millennium.berkeley.edu
>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: T2_packet_proposal_v2.txt
Url: https://www.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20090505/274ce4a1/attachment-0001.txt 
-------------- next part --------------
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel