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

[Jonathan Larmour]

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

>From what Kieran both quoted and said himself, step 2 is certainly right. And
steps 4 & 5 are allowed - hence "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."

I'm not sure quite what you mean by "a copy flag is not needed" because it
would be needed for UDP if we wanted to do anything in future to avoid a copy
using the existing pbuf types. In fact with TCP it's even more silly - the
user may have set the copy flag to tcp_write() so we know the payload data is
not going to change - however the ARP layer doesn't know this as it doesn't
get passed that information, so when queuing, the ARP layer will copy the
data regardless.

Although Kieran says we should set aside the issue of optimising this for
now, I'll just mention that I think a solution to this would be my suggestion
on lwip-devel of a PBUF_RAM_NOCOPY pbuf type - TCP data to be copied could be
created as this type instead of PBUF_RAM as it is at present in
tcp_enqueue(). And pbuf_ref() called on it in tcp_output() before ip_output()
so subsequent lower layers don't really release the memory when they
pbuf_free() it.

Anyway, that's an idea for the future, not now - Kieran recommended solving
the current issue first, and then work on optimisations later. I just wanted
to raise the possibility of that as a medium term solution, but it's probably
best not to further discuss its merits in this bug now to avoid confusing the
issue.


    _______________________________________________________

Reply to this item at:

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

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