[lwip-devel] [bug #11400] ARP multi-packet-queue modifies TCP unsent/unacked segment packet pbuf chain into packet queue

[Kieran Mansley]

Follow-up Comment #43, bug #11400 (project lwip):

>From the changelog when this feature was introduced:
(0.6.1)

  ++ New features:

  * The packet buffer implementation has been enhanced to support
    zero-copy and copy-on-demand for packet buffers which have their
    payloads in application-managed memory.
    Implemented by David Haas.

    Use PBUF_REF to make a pbuf refer to RAM. lwIP will use zero-copy
    if an outgoing packet can be directly sent on the link, or perform
    a copy-on-demand when necessary.

    The application can safely assume the packet is sent, and the RAM
    is available to the application directly after calling udp_send()
    or similar function.


An external application shouldn't be using PBUF_RAM buffers to refer to its
own memory; it should instead use PBUF_REF (if the memory contents can
change) or PBUF_ROM (if it can guarantee it will be preserved as long as lwip
needs it).  PBUF_RAM should only be used to refer to buffers whose payload
points to a region of memory allocated by lwIP.  However, this might not be
relevant because on return the API does currently seem to give the
application the right to do what it likes with the pbuf, so I think we will
have to copy if we can't send it immediately.  

We could add complexity/efficiency by working out if it's a TCP or UDP
packet, and then not doing as much copying in the TCP case, but for the first
pass I think that is unnecessary.  Let's get it working first.

Another alternative would be to extend the API to add the copy/no-copy flag
for UDP so that we can tell if the application is going to try and reuse the
buffer when the udp_send() call returns, but again I think we should get it
working first and worry about making it more efficient later.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?11400>

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