RE: [lwip-users] low_level_output question

[Bill Auerbach]

Incrementing the reference count is the way to move the freeing of the pbuf
from the stack to the Ethernet driver.  It's been done by several
implementers successfully.  A comment in low_level_output to increment the
ref count if the packet isn't being physically sent before the function
returns and to free it at a later time when it has is sufficient.  What
hasn't been clear to me is the safety of handling pbufs in interrupt service
routines.  Can a TX dma complete ISR call pbuf_free?

Bill

>-----Original Message-----
>From: address@hidden
>[mailto:address@hidden On
>Behalf Of Simon Goldschmidt
>Sent: Tuesday, April 07, 2009 3:51 AM
>To: Mailing list for lwIP users
>Subject: Re: [lwip-users] low_level_output question
>
>There's a task on savannah on this (#7896 ):
>https://savannah.nongnu.org/task/?7896
>
>Basically, the scheme will work on _POOL and _RAM pbufs, but not on
>_ROM/_REF pbufs, which is why usage of these types would have to be
>adjusted (including a copy-on-delayed-usage flag or something like
>that).
>
>However, as sad as it is, this won't be included in 1.3.1 as we first
>have to agree on one solution.
>
>Simon
>
>
>> > Hi,
>> > I'm porting lwip (using an RTOS and the socket API) and I have a
>> > question regarding the low_level_output function.
>> > If I can't send the pbuf immediately (netif busy), to avoid copying
>> > the pbuf, I'd like to do the following:
>> > *       Increment the reference count to prevent lwip from re-using
>> > or freeing the pbuf.
>> > *       Put the pbuf on my output queue and try to send it later.
>> > *       Return ERR_OK.
>> > Later when the netif is not busy...
>> > *       Remove the pbuf from my output queue.
>> > *       Send the pbuf.
>> > *       Free the pbuf.
>> >
>> > Will this scheme work with lwip?
>>
>> This is a very valid discussion point for the Stack, IMHO.
>> It is not really explicitly documented that the Stack will free the
>pbufs
>> for a packet after it handed it over to the driver layer.
>> If the Driver is sending asynchronously and the data is not memcpy'd
>by
>> the driver, the datablock might be allocated by someone else and
>> overwritten with other data. This might be an explaination for
>> mysteriously lost or changed packets.
>> Also given the fact that LwIP is a zero-copy stack, people might not
>> expect to memcpy stuff on the driver layer?
>>
>> I propose we do either of the following:
>>
>> 1) In the ethernetif-skeleton explicitly document the behavior and
>tell
>> the developer to memcpy the data if their transmission is async.
>> 2) See 1), but tell the developer to increment the reference count and
>> pbuf_free() themselves (probably faster than memcpy)
>> 3) Remove the freeing of the pbuf after handing it over to the driver
>> layer and document that and leave it to the driver developer to
>> pbuf_free() after the xmit is really done
>>
>> comments?
>>
>> regards,
>> Fabian
>
>--
>Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate +
>Telefonanschluss für nur 17,95 Euro/mtl.!*
>http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
>
>
>_______________________________________________
>lwip-users mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/lwip-users