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

[Jonathan Larmour]

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

In comment #11, Jared Grubb wrote:
> 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?

And making sure the copy only happens at most once.

> 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.

Well, not entirely: if copying a PBUF_RAM or a PBUF_REF, then an upper layer
could then copy it into a PBUF_RAM_NOCOPY, so a lower level driver knows it
does not need to copy it another time. So we ensure that a copy only happens
once.

> 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).

Well, ideally pbuf_ref for TX, but that's the issue at hand!
 
> 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.

I agree, and I think I did say this at one point. However see comment #43 of
bug #11400. I would be very much in favour of going back on that and just
decreeing that you can't alter PBUF_RAM payloads or the struct pbuf of any of
the sorts of pbufs after transmission, except to pbuf_free it. That would
simplify a lot of things. I think with modern hardware there are going to be
very few cases which we could exploit as described in that comment #43 of bug
#14400 - sending can and should happen in the background which means it will
be rare that something can be considered sent immediately.

This doesn't help PBUF_REFs much - we have no control over external data, and
the user would never have any sensible way to know when they would be allowed
to change it. So for example, lwip_sendto would essentially always cause a
copy, but at least there's hope for raw or sequential API users.

Kieran, since we're in "don't mind breaking things for 1.3" mode, could we
reconsider the API behaviour as described in #43 of bug #11400?

Even if we don't want to include any changes for 1.3, it would be good to
have something written to tell users that reusing pbufs after transmission is
deprecated and will be unsupported in 1.4. So it's worth resolving this soon.

I'm just keen to get a solution, because what's there now doesn't allow safe
zero-copy.


    _______________________________________________________

Reply to this item at:

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

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