From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 Description of problem: We have lots of applications that require low latency network communication, and we occasionally get caught by apps that do not control Nagling on sockets that they create. If feasible, we would like to move the OS Nagling control from a kernel compile time parameter to a network stack parameter that could be set per network interface or system wide. We know that this request could cause other problems on our network, but low latency traffic is the dominant form for us and a per interface setting would enable us to turn off Nagling on just select interfaces. Version-Release number of selected component (if applicable): kernel-2.6.18-53.el5 How reproducible: Always Steps to Reproduce: 1.deploy application without tcp_nodelay set in the socket options 2. 3. Actual Results: Saw unacceptable latencies. Expected Results: This could be avoided with per interface Nagling control. Additional info:
Doing this on a per-interface basis would introduce some very nasty layering problems. Working around application bugs is not sufficient justification for making invasive changes to a critical kernel subsystem. Doing this globally is a less troubling notion, but if it's going to be done, it should be done in userspace, not in the kernel. Since the applications themselves aren't doing the tuning, the only other straightforward option is a library. This is precisely how Solaris implements similar features, with its userspace socket library. Linux implements the socket API with system calls, which is simpler, more portable, and benefits well-written applications at the expense of allowing stupid applications to be stupid. It may be possible to retrofit existing dynamically-linked binaries with a tuning library that intercepts glibc's handling of system calls, using LD_PRELOAD. That's a question for tools developers, not kernel developers.