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

[Jared Grubb]

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/