Messages in this thread | | | From | David Laight <> | Subject | RE: [PATCH RFC net-next 2/2] tcp: Add Redundant Data Bundling (RDB) | Date | Mon, 2 Nov 2015 09:18:20 +0000 |
| |
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
| |