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: [email protected] >[mailto:[email protected]] 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 >[email protected] >http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
