This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 432875 - need run time tunable to control nagle algorithm per interface or system wide
need run time tunable to control nagle algorithm per interface or system wide
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: glibc (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Chris Snook
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2008-02-14 16:23 EST by Matthew Coffey
Modified: 2008-05-08 18:02 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-08 09:54:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matthew Coffey 2008-02-14 16:23:38 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080201 Firefox/

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):

How reproducible:

Steps to Reproduce:
1.deploy application without tcp_nodelay set in the socket options

Actual Results:
Saw unacceptable latencies.

Expected Results:
This could be avoided with per interface Nagling control.

Additional info:
Comment 1 Chris Snook 2008-02-19 19:16:36 EST
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.

Note You need to log in before you can comment on or make changes to this bug.