Now I have read RFC 1122 and understood that the existing CONFIG_NET_TCP_SPLIT algorithm can not help.
RFC 1122 (4.2.3.2) says: > ... > A TCP SHOULD implement a delayed ACK, but an ACK should not > be excessively delayed; in particular, the delay MUST be > less than 0.5 seconds, and in a stream of full-sized > segments there SHOULD be an ACK for at least every second > segment. The important word there is "full-sized". Full-sized means equal to MSS. Then splitting a segment into two segments is useless. E.g. MSS = 512. - If a user sends 200 bytes, then CONFIG_NET_TCP_SPLIT will create two segments: 100 and 100 bytes. They are not full-sized. Then the remote TCP receiver will not send ACK for up to 0.5 seconds. - If a user sends 1500 bytes, then CONFIG_NET_TCP_SPLIT will create 4 segments: 512, 512, 238 and 238 bytes. The two last segments are not full-sized. The same issue. On Thu, 2021-10-14 at 15:45 -0600, Gregory Nutt wrote: > > Concerning buffered send mode yes, however I asked about unbuffered > > send mode with a large user buffer. > > > > > > Sorry, I misread that. > > > Do I understand correctly, that if I use unbuffered mode with a > > large > > > > user buffer (say 64 KB), then RFC 1122 still may pause NuttX > > > > TCP stack > > > > if an odd number of TCP segments are constructed based on the > > > > 64 KB > > > > buffer? Thus 0.5 second delay may occur at the end of 64 KB > > > > buffer > > > > during the last segment > > I haven't looked or thought much about the unbuffered case in a long > time. > I suppose that for very large user buffers provided in the send, what > you > are saying is correct. There would be no ACK delays until the last > segment > is sent and if there is an odd number of segments, you should get the > delay > (assuming that CONFIG_NET_TCP_SPLIT is not selected and that the size > of > the last segment is at least CONFIG_NET_TCP_SPLIT_SIZE). > > But if you send the same 64 KB of data using a small user buffer, > then you > would experience that half second delay on every packet. That is the > case > where performance is terrible and CONFIG_NET_TCP_SPLIT should improve > that.
