[Top][All Lists]
[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/
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Kieran Mansley, 2007/08/01
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY,
Jonathan Larmour <=
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Simon Goldschmidt, 2007/08/09
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jonathan Larmour, 2007/08/09
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jared Grubb, 2007/08/09
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Simon Goldschmidt, 2007/08/10
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jonathan Larmour, 2007/08/10
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jared Grubb, 2007/08/10
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jonathan Larmour, 2007/08/10
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jared Grubb, 2007/08/10
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jonathan Larmour, 2007/08/10
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jared Grubb, 2007/08/10