From: Bendik Rønning Opstad > Sent: 29 October 2015 22:54 ... > > > > 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/9916b6c53e33dd04329d29b > > > > 7d8baf703b2c2ac1b> > > > > > 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? > > This is definitely workable. I agree that it may not be an ideal solution to > have TCP_RDB disable Nagle, however, it would be useful with a way to easily > enable RDB and disable Nagle. If enabling RDB disables Nagle, then what happens when you turn RDB back off? David -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
