lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY


From: Jonathan Larmour
Subject: [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY
Date: Wed, 01 Aug 2007 14:26:00 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070530 Fedora/1.5.0.12-1.fc5 Firefox/1.5.0.12

Follow-up Comment #16, task #6735 (project lwip):

Kieran Mansley wrote:
> 
> In my opinion, if the application was going to use the buffers
> in that way (i.e. never modify the contents, just free it after
> sending) they could just use the PBUF_ROM type (or the
> suggested new PBUF_RAM_NOCOPY if the stack should do the free)
> and the stack would have the guarantees it needs.

That's true. It may then be the case that if the most common use at present
is for people to just free pbufs after transmission, then in practice users
will mostly want to use PBUF_RAM_NOCOPY instead of PBUF_RAM in future
(although we may want to provide a way in the sequential API to indicate this
since netbuf_alloc() only allocates a normal PBUF_RAM).

And hopefully in future we can consider reworking TCP so that copied data in
tcp_enqueue goes into a PBUF_RAM_NOCOPY instead of PBUF_RAM. If so, maybe we
can get to the position where most data isn't copied by the driver after all.

> Also, just preventing users from re-using PBUFs doesn't really
> solve the problem.  If they free it, then allocate another one
> for the next send, they might get the same one back and so it
> be identical to re-use.

The driver would have to have pbuf_ref()'d it, so a pbuf_free() wouldn't have
really freed it anyway.

> lwIP can support zero-copy *if* the application allows it.

At present I'm not sure we can safely even do single copy at present. If a
driver at present doesn't copy all data, there are problems if the user reuses
a PBUF_RAM sent by UDP, or changes its payload after send. If a driver does
copy all data, then overall there will be unnecessary multiple copies e.g. for
TCP.

> Either way, this will be a 1.4 not 1.3 problem.

Ack. I'll keep going with PBUF_RAM_NOCOPY then, but wait till after 1.3.


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?6735>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/





reply via email to

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