lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] low_level_output question


From: Simon Goldschmidt
Subject: Re: [lwip-users] low_level_output question
Date: Tue, 07 Apr 2009 09:50:54 +0200

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]