Similarly, I have also advocated the option to disable READ AHEAD buffering. A stack that cannot buffer a packet is not reliable: If the read operation is not in place and waiting for an incoming packet, then the packet will be dropped dropped in that case. Pretty hard to design a reliable stack with that kind of behavior.
Again, the counter argument for retaining the option to disable READ AHEAD buffering (as with WRITE buffering) is only because it would prevent minimum systems that cannot afford a pool of IOBs. Is it better to have a quality network stack? Or a small but unreliable stack? On Tue, Oct 12, 2021 at 8:35 PM Gregory Nutt <spudan...@gmail.com> wrote: > For people that need some background, this Wikipedia article may be > helpful: https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment. The > SPLIT packet change is intended to work around issues when the unbuffered > send is used with a peer that supports RFC 1122. > > In the unbuffered send case, the send operation blocks until the packet is > sent and ACKed. Per RFC 1122, the peer may delay sending the ACK for up to > 500 Msec. So the performance of the unbuffered send is abysmal when > sending to an RFC 1122 client. > > The split basically breaks each TCP send into two packets. RFC 1122 does > *require* that an ACK be sent after two packets are received. If you are > seeing different behavior, then those peers are not conforming to RFC > 1122. Perhaps there is some other standard. > > I think that the unbuffered send logic is generally very bad and I have > suggested removing it in the past. The buffered send performance is much > better. We decided to retain the unbuffered send only because it does use > less memory since no write buffering is required. > > I am not 100% sure of this, but I still think that it would be better to > remove the unbuffered TCP send logic rather than remove the packet split > logic. I don't see how removing the split makes the unbuffered send > better. It does not fix anything and certainly breaks the RFC 1122 case. > The unbuffered TCP send behavior is bad without the split and, according to > your PR, it is also bad with the split. But my feeling is not strong so > just take that as my 2 cents worth. > > Greg > > On Tue, Oct 12, 2021 at 8:10 PM Takashi Yamamoto > <yamam...@midokura.com.invalid> wrote: > >> hi, >> >> i submitted a PR to remove NET_TCP_SPLIT. >> https://github.com/apache/incubator-nuttx/pull/4660 >> >> i'm posting this here because a feature removal should be reviewed by >> wider audience. >> especially, if you are relying on it, please speak up. >> >
