I think that we should not provide broken features unless they are experimental
-----Original Message----- From: Xiang Xiao <xiaoxiang781...@gmail.com> Sent: den 14 oktober 2021 10:49 To: dev@nuttx.apache.org Subject: Re: NET_TCP_SPLIT removal 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://urldefense.com/v3/__https://en.wikipedia.org/wiki/TCP_delaye > > d_acknowledgment__;!!JmoZiZGBv3RvKRSx!tialRaWS8SoruDjFpeabVMLOKhTRX0ZmTGHapT0vQAy6pb66jXy7suu4AR6CokSoPw$ > > . 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://urldefense.com/v3/__https://github.com/apache/incubator-nut > >> tx/pull/4660__;!!JmoZiZGBv3RvKRSx!tialRaWS8SoruDjFpeabVMLOKhTRX0ZmT > >> GHapT0vQAy6pb66jXy7suu4AR6OGCrEqw$ > >> > >> 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. > >> > > >
