RE: [lwip-users] low_level_output question

[John Kennedy]

Since pbuf_free decrements the pbuf reference count and only frees the pbuf 
when the reference count goes to zero I assumed that by incrementing the 
reference count in the Ethernet driver it would prevent the stack from freeing 
or reusing the pbuf, and that the Ethernet driver should then call pbuf_free 
when done with the pbuf.  My original question was to verify this assumption.

Also pbuf_free guards decrementing the pbuf reference count by surrounding it 
with SYS_ARCH_PROTECT and SYS_ARCH_UNPROTECT.    If the pbuf is type PBUF_POOL, 
PBUF_ROM, or PBUF_REF then memp_free gets called, otherwise mem_free gets 
called.  The function memp_free is also guarded with SYS_ARCH_PROTECT and 
SYS_ARCH_UNPROTECT.  In my implementation these macros simply disable and 
re-enable interrupts so it's not a good idea to call pbuf_free from an ISR.  In 
general I think these macros are intended to be invoked outside an interrupt 
context, but I suppose this depends on the port.  In my implementation for pbuf 
type PBUF_RAM, pbufs are ultimately allocated off the heap with malloc and 
freed with free, so for my implementation pbufs of type PBUF_RAM shouldn't be 
allocated or freed from an ISR either.

John


 
________________________________________
John Kennedy


Idaho Technology Inc.
390 Wakara Way
Salt Lake City, UT 84108, USA

USA: 1-800-735-6544
Bus:+1 (801)736-6354 x448
Fax:+1 (801)588-0507

http://www.idahotech.com/
-----Original Message-----
From: Bill Auerbach [mailto:address@hidden
Sent: Tuesday, April 07, 2009 6:31 AM
To: 'Mailing list for lwIP users'
Subject: RE: [lwip-users] low_level_output question


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



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users

________________________________________
CONFIDENTIALITY NOTICE: This E-mail and any attachments are confidential 
information of the sender and are for the exclusive use of the intended 
recipient. If you are not the intended recipient, be aware that any disclosure, 
copying, distribution, or use of this E-mail or any attachment is prohibited. 
If you have received this E-mail in error, please notify us immediately by 
returning it to the sender and delete this copy from your system. Thank you for 
your cooperation.