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:	Tue, 20 Nov 2007 17:03:12 +0300
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Andrew Gallatin <gallatin@...i.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	ossthema@...ibm.com
Subject: Re: [PATCH] LRO ack aggregation

On Tue, Nov 20, 2007 at 09:50:56PM +0800, Herbert Xu (herbert@...dor.apana.org.au) wrote:
> On Tue, Nov 20, 2007 at 04:35:09PM +0300, Evgeniy Polyakov wrote:
> > 
> > On Tue, Nov 20, 2007 at 08:27:05AM -0500, Andrew Gallatin (gallatin@...i.com) wrote:
> > > Hmm.. rather than a global tunable, what if it was a
> > > network driver managed tunable which toggled a flag in the
> > > lro_mgr features?  Would that be better?
> > 
> > What about ethtool control to set LRO_simple and LRO_ACK_aggregation?
> 
> I have two concerns about this:
> 
> 1) That same option can still be turned on by distros.

FC and Debian turn on hardware checksumm offloading in e1000 and I have
a card where this results in more than 10% performance _decrease_.
I do not know why, but Im able to run script which disables it via
ethtool.

> 2) This doesn't make sense because the code is actually in the
>    core networking stack.

It depends. Software lro can be controlled by simple procfs switch, but
hardware one? I recall it was number of times pointed that hardware LRO
is possible and likely being implemented in some asics.

> I'm particular unhappy about 2) because I don't want be in a
> situation down the track where every driver is going to add this
> option so that they're not left behind in the arms race.

For software lro I agree, but this looks exactly like gso/tso case and
additional tweak for software gso. Having it per-system is fine, and I
believe no one should ever care that some distro will do bad/good things
with it. Actually we do have so much tricky options in procfs already
which can kill performance...

-- 
	Evgeniy Polyakov
-
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