Messages in this thread | | | Date | Fri, 26 Jun 1998 09:11:24 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Thread implementations... |
| |
On Fri, 26 Jun 1998, Linus Torvalds wrote: > > Is nagle _really_ that big a deal?
[ 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.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |