lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 23 Aug 2010 17:10:19 -0400
From:	Chris Snook <chris.snook@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Hagen Paul Pfeifer <hagen@...u.net>, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
	acme@...hat.com, Stephen Hemminger <shemminger@...tta.com>
Subject: Re: [PATCH] tcp: make TCP quick ACK behavior modifiable

Answering two of you...

On Mon, Aug 23, 2010 at 4:44 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:

> Le lundi 23 août 2010 à 21:00 +0200, Hagen Paul Pfeifer a écrit :

>> This patch provides a sysctl interface for the administrator to globally
>> enable or disable TCP quick ACKs. Short lived protocols like HTTP will
>> save a non unimportant portion of packets!

A year and a half ago, we merged a patch to tune the delayed ack
behavior.  While the proof of concept was a sysctl interface that a
relative novice to the TCP code like myself could write, the consensus
was that we already had a glut of TCP sysctls, and there was a
potential benefit to doing it on a per-route basis, so we could both
make the feature more flexible and avoid sysctl pollution by making it
a per-route tunable.  I think all of the same arguments apply to this
feature, as well as the argument that it surely makes sense to be
tuning delayed ack and quick ack in the same place.  I'm CCing acme,
because he wrote the final patch.

> What about dccp using this function ?

Also probably of interest to acme.

> I thought setsockopt(TCP_QUICKACK) was already available for this
> optimization ?

As with the delayed ack patch, modifying the application is not always
practical.  It's extremely helpful for an administrator to be able to
turn this on with a few keystrokes when performance starts suffering,
since patching the app (or multiple apps), validating the changes,
etc. could take months or years.

-- Chris
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ