[martingxx]

I've always thought that Nagle's algorithm is putting policy in the kernel where it doesn't really belong.

If userspace applications want to make latency/throughput tradeoffs they can already do that with full awareness and control using their own buffers, which will also often mean fewer syscalls too.

[klempner]

The actual algorithm (which is pretty sensible in the absence of delayed ack) is fundamentally a feature of the TCP stack, which in most cases lives in the kernel. To implement the direct equivalent in userspace against the sockets API would require an API to find out about unacked data and would be clumsy at best.

With that said, I'm pretty sure it is a feature of the TCP stack only because the TCP stack is the layer they were trying to solve this problem at, and it isn't clear at all that "unacked data" is particularly better than a timer -- and of course if you actually do want to implement application layer Nagle directly, delayed acks mean that application level acking is a lot less likely to require an extra packet.

[j16sdiz]

If your application need that level of control, you probably want to use UDP and have something like QUIC over it.

BTW, Hardware based TCP offloads engine exists... Don't think they are widely used nowadays though

[nly]

Hardware TCP offloads usually deal with the happy fast path - no gaps or out of order inbound packets - and fallback to software when shit gets messy.

Widely used in low latency fields like trading

[ghshephard]

It's kind of in User Space though - right? When an application opens a socket - it decides whether to open it with TCP_NODELAY or not. There isn't any kernel/os setting - it's done on a socket by socket basis, no?

[naught00]

TCP_NODELAY is implemented within the kernel. A socket can decide whether to use it or not.

[PunchyHamster]

Technically yes, practically userspace apps are written by mostly people that either don't, or don't want to care about lower levels. There is plenty of badly written userspace code that will stay badly written.

And it would be right choice if it worked. Hell, simple 20ms flush timer would've made it work just fine.

[kvemkon]

The tradeoff on one program can influence the other program needing perhaps the opposite decision of such tradeoff. Thus we need the arbiter in the kernel to be able to control what is more important for the whole system. So my guess.