From: Bendik Rønning Opstad

Sent: 29 October 2015 22:54

...

quoted

quoted

quoted

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