[lwip-devel] [task #7040] Work on tcp_enqueue

[Jakob Stoklund Olesen]

Follow-up Comment #8, task #7040 (project lwip):

First of all: I am sorry for posting comments directly to the lwip-devel
list. For any new listeners out there, there is some discussion about this
task in the January 2009 archives of lwip-devel.

I have attached a patch for tcp_enqueue that fixes the issue discussed here.
It was not as simple as I had hoped. The tcp_enqueue function is quite scary.
I have tested this patch, but please try to test it on different systems.
There are many things that can go wrong.

The code to extend the last unsent segment is separate from the code that
creates new segments. This has a couple of advantages: 1. pbufs are allocated
with PBUF_RAW, so no memory is wasted on a header that is never prepended. 2.
The old code would allocate a segment only to free it again immediately. In
the no-copy case, we can also avoid allocating an extra pbuf for the header.

The downside is that the pbuf allocation code is duplicated. Twice as many
bugs!

I think it would be a good idea to split tcp_enqueue into two separate
functions:

tcp_enqueue_data to be called from tcp_write and
tcp_enqueue_options for everybody else.

The logic trying to handle data or options has become rather convoluted.

I think the user should be able to call tcp_write with small data chunks
without worrying too much about performance. My own user code does that.
Currently small writes cause very long pbuf chains because each write creates
at least one pbuf. With no-copy tcp_write this is inevitable. With copying
tcp_write it is really not necessary.

tcp_enqueue_data could allocate a pbuf with room for a full segment (or some
smaller chunk size). Following tcp_writes could append data to the same pbuf.
This would use more memory, so it must be considered carefully.

This is perhaps related to the zero-copy driver discussion on lwip-devel?
Maybe the driver could have a say in how outgoing pbufs are allocated?

My own Ethernet driver cannot directly DMA the long pbuf chains created by
small writes. I have to copy them into continuous memory first. This means
that data is copied both by tcp_enqueue AND the driver.


(file #17364)
    _______________________________________________________

Additional Item Attachment:

File name: tcp-enqueue-concat             Size:7 KB


    _______________________________________________________

Reply to this item at:

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

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