[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: |
Jared Grubb |
Subject: |
[lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY |
Date: |
Tue, 31 Jul 2007 17:21:03 +0000 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 |
Follow-up Comment #11, task #6735 (project lwip):
> It's possible that zero copy can work if you happen to have fast enough
ethernet hardware, and depending on the driver design (e.g. how much it can
queue), and the application. But there are no guarantees in general. It's
likely that the more Frederic and Simon improve the sockets.c performance :-),
the more likely it is that this problem will show up. It should already be
fairly easy for it to show up with the netconn API.
In an embedded environment, I would think "copy only when necessary" is the
right behavior -- you have limited CPU time and limited RAM. Since we agree a
copy has to happen somehere the question is: Where should the copy happen?
If the driver always copies data, then it will be copying every IP, ARP,
ICMP, UDP, and TCP packet it has to send -- even when an upper layer's next
step is pbuf_free(). That is a lot of wasted memory and a lot of wasted
space.
Alternatively, you can have the driver scan through the pbuf chain and
conditionally copy some pbuf's and not others... but this is added complexity
and requires the transmit portion of the driver to be able to allocate memory
for transmission. This might be ok, since the RX part of the driver must have
allocation capability, so borrowing a bit of the RX buffer pool could be ok.
In my opinion, though, a good design has the RX & TX chains completely
decoupled and complementary, with the RX chain only doing pbuf_alloc (the free
happens elsewhere) and the TX chain only doing pbuf_ref and pbuf_free (and
allocation happens elsewhere).
The only protocol that may specifically need some copy mechanism is TCP
(because of retransmissions), but that's already built in.
What do we lose by saying: "driver is zero-copy; application must not reuse a
buffer after sending"? This seems to be the simpler design choice across the
board -- and the most efficient from an embedded standpoint.
_______________________________________________________
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, Simon Goldschmidt, 2007/07/03
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jonathan Larmour, 2007/07/30
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jared Grubb, 2007/07/30
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Frédéric Bernon, 2007/07/30
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jonathan Larmour, 2007/07/30
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY,
Jared Grubb <=
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jared Grubb, 2007/07/31
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jonathan Larmour, 2007/07/31
- [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY, Jared Grubb, 2007/07/31