[ I'm back. Had to go placate a small one.. ]
Anyway, what I meant to say that if nagle _is_ such a big deal, it's
actually trivially easy to add a "nonagle" flag.
We obviously have "nonagle" already, but there are actually two kinds of
"nonagle", and the normal nonagle that everybody already supports is
actually exactly the wrong kind of nonagle for this kind of thing.
You really want three cases:
- nagle. This is normal behaviour, and gives reasonable latency of
packets with reasonable throughput.
- "normal" nonagle. This is something almost nobody ever uses, but is
meant to give lowest possible latency for TCP "packets". However, it
only makes sense if you think of TCP as a stream of packets.
You can think of this as "nagle without ever a packet in flight", which
forces new data to always be packetized.
- "new" nonagle. This is actually a much more useful form of nonagle, I
wonder why nobody does it. It always coalesces into a full packet until
it times out.
You can think of this as "nagle with a packet in flight constantly".
The only thing with the new nagle is that you want some kind of software
interface for the final push. Obviously closing the socket would do it,
but you want to do a push even without closing the socket.
In short, it just sounds extremely silly to try to fight nagle with the
wrong kinds of interfaces when we can _control_ nagle instead. Nagle is
just a heuristic - it's not something that is fundamentally important to
TCP (the _effects_ of nagle, ie trying to make big packets, is obviously
fairly fundamental to any high bandwidth). It needs to be the _default_
heuristic, because it works reasonably without any user intervention, but
there is nothing to say that it has to be the only choice.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org