Re: [lwip-devel] Packet queues (was Re: [bug #11400] ARP multi-packet-queue modifies TCP ...)

[Jonathan Larmour]

Kieran Mansley wrote:
> On Thu, 2007-04-05 at 16:44 +0100, Jonathan Larmour wrote:
>
> > A new pbuf type seems the most backwardly compatible approach as no 
> > external APIs change, and drivers don't even have to support it: the user 
> > can ensure they only use it if they know the driver supports it. The notion 
> > of whether that pbuf needs copying or not stays with the pbuf all the way 
> > through the stack with no further changes. This approach is also amenable 
> > to being a configurable option since it should be well contained. Pretty 
> > much the only special treatment for PBUF_RAM_NOCOPY would be in the low 
> > level drivers themselves, which would call pbuf_free() on tx completion for 
> > this type of pbuf.

I would say here though that I'd prefer if it wasn't an option - the impact 
for drivers is so minimal I think it would be good if this would just be 
the way that drivers are now expected to work. But if people want it as an 
option, that's okay.

> > Note that tcp_write is already asymmetric with udp_send: the former takes a 
> > character array and length, the latter takes a pbuf instead of those args. 
> > This change would only mean the pbuf also subsumes the 'copy' property as well.
>
> You make a compelling case!  I find the change in ownership of the pbuf
> depending on its type a little disconcerting though - I prefer APIs to
> have few special cases like this, unless they are really obvious.

Hopefully that's what the use of the _NOCOPY suffix should do. This 
behaviour can't be invoked by users without their direct request. (Or if we 
do decide to use these internally in the stack, then we'll know what we're 
doing!).

>  Would
> we also need to introduce ROM_NOCOPY and POOL_NOCOPY equivalents to
> protect against the pbuf structure being reused?  i.e. Is it just the
> payload region we're trying to protect, or the whole pbuf structure?

Although I don't think this is formally documented, I don't think they can 
really expect to reuse POOL type pbufs: pool pbufs are managed by lwip, for 
incoming packets (or at least internal to the stack) - users shouldn't be 
creating their own pbufs of this type.

One might be able to argue it for ROM pbufs, but it's really the payload we 
want to avoid copying, not so much the pbuf itself, and with ROM pbufs we 
know the payload is immutable, so there's no problem creating a duplicate 
RAM pbuf and pointing the payload at the same area as the original. If we 
need to.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
  **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv> **
  **  April 3-5 2007, Booth 1922, San Jose McEnery Convention Center  **
------["The best things in life aren't things."]------      Opinions==mine