lwip-devel
[Top][All Lists]
Advanced

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

Re: [lwip-devel] Packet queues (was Re: [bug #11400] ARP multi-packet-qu


From: Kieran Mansley
Subject: Re: [lwip-devel] Packet queues (was Re: [bug #11400] ARP multi-packet-queue modifies TCP ...)
Date: Tue, 10 Apr 2007 14:17:51 +0100

On Tue, 2007-04-10 at 13:55 +0100, Jonathan Larmour wrote:
> 
> >  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.

I'd like to avoid special cases if I can, so if it could sensibly be
generalised to all pbuf types, that would be nice.  That way it would
just become an additional flag on the pbuf->flags variable that was
independent of type.  Doing so wouldn't add any additional code over
your proposal I think - might even make it simpler - and would make it
easier to use this feature from other places (e.g. the TCP side of
things) if we find it necessary in the future.

Perhaps we should add a this as a task to the savannah tracker.  Would
you be willing to take ownership of this for the time being?  I'm in no
hurry for a solution, but I think it would definitely be an improvement
and shouldn't get forgotten.

Kieran





reply via email to

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