I agreed with Greg that it's bad to give the user a broken feature, especially for a complex feature like networking.
On Wed, Oct 13, 2021 at 10:51 AM Gregory Nutt <spudan...@gmail.com> wrote: > 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. > >> > > >
