On Mon, Oct 26, 2015 at 2:35 PM, Andreas Petlund <apetl...@simula.no> wrote: > > > > On 26 Oct 2015, at 15:50, Neal Cardwell <ncardw...@google.com> wrote: > > > > On Fri, Oct 23, 2015 at 4:50 PM, Bendik Rønning Opstad > > <bro.de...@gmail.com> wrote: > >> @@ -2409,6 +2412,15 @@ static int do_tcp_setsockopt(struct sock *sk, int > >> level, > > ... > >> + case TCP_RDB: > >> + if (val < 0 || val > 1) { > >> + err = -EINVAL; > >> + } else { > >> + tp->rdb = val; > >> + tp->nonagle = val; > > > > The semantics of the tp->nonagle bits are already a bit complex. My > > sense is that having a setsockopt of TCP_RDB transparently modify the > > nagle behavior is going to add more extra complexity and unanticipated > > behavior than is warranted given the slight possible gain in > > convenience to the app writer. What about a model where the > > application user just needs to remember to call > > setsockopt(TCP_NODELAY) if they want the TCP_RDB behavior to be > > sensible? I see your nice tests at > > > > > > https://github.com/bendikro/packetdrill/commit/9916b6c53e33dd04329d29b7d8baf703b2c2ac1b > > > > are already doing that. And my sense is that likewise most > > well-engineered "thin stream" apps will already be using > > setsockopt(TCP_NODELAY). Is that workable? > > We have been discussing this a bit back and forth. Your suggestion would be > the right thing to keep the nagle semantics less complex and to educate > developers in the intrinsics of the transport. > > We ended up choosing to implicitly disable nagle since it > 1) is incompatible with the logic of RDB. > 2) leaving it up to the developer to read the documentation and register the > line saying that "failing to set TCP_NODELAY will void the RDB latency gain" > will increase the chance of misconfigurations leading to deployment with no > effect. > > The hope was to help both the well-engineered thin-stream apps and the ones > deployed by developers with less detailed knowledge of the transport. but would RDB be voided if this developer turns on RDB then turns on Nagle later?
> > -Andreas > -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html