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

[Jakob Stoklund Olesen]

Bill Auerbach <address@hidden> writes:

> Can we revisit this?  I don't think this has to do with Nagle. Or it also
> occurs without Nagle.  On large transfers (RAW_API) I see it not send a full
> payload about 1 in 40 packets.  True, this isn't a huge problem.  I would
> expect if sending e.g. 300kB that all but the last packet would have a full
> payload.

True, it is not Nagle doing this. Of course, setting SO_NDELAY causes
many small segments to be sent by design.

> Do we know why it sends a partial packet?  In my tcp_sent, if I have more
> than MTU bytes to send, should I wait for tcp_sndbuf to have MTU free?  Is
> this what was meant by solving it at the application level?

To solve it at the application level, you must call tcp_write() with
data lengths that are a multiple of the mss.

Here is what happens in tcp_enqueue():

if write-length > mss then
  break into mss-sized segments
end

if last-unsent-segment + first-write-segment <= mss
  concat onto last unsent segment
else
  start new segment
end

This means that every tcp_write() with more than mss bytes will always
start a new segment.

For many small writes, this is OK: Small writes are concatenated as long
as they fit in the last unsent segment.

For large writes this is also OK: Each write creates a number of full
segments + one partial. This leads to a small overhead, nothing to worry
about.

For just-over-mss sized writes this is really bad: Repeated writes of
1461 bytes leads to alternating segments 1460 , 1, 1460, 1, ...

A quick fix to tcp_enqueue() is relatively easy: When breaking the write
data into segments, the first segment should be made small enough to fit
at the end of the last unsent segment. The remaining segments should
still be mss-sized.

/stoklund