netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Andrew Gallatin <gallatin@myri.com>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, ossthema@de.ibm.com
Subject: Re: [PATCH] LRO ack aggregation
Date: Tue, 20 Nov 2007 17:03:12 +0300	[thread overview]
Message-ID: <20071120140312.GA6695@2ka.mipt.ru> (raw)
In-Reply-To: <20071120135056.GA18266@gondor.apana.org.au>

On Tue, Nov 20, 2007 at 09:50:56PM +0800, Herbert Xu (herbert@gondor.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@myri.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

  reply	other threads:[~2007-11-20 14:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-23 15:11 [PATCH] LRO ack aggregation Andrew Gallatin
2007-11-20  5:09 ` David Miller
2007-11-20  6:09   ` Herbert Xu
2007-11-20  6:22     ` David Miller
2007-11-20 11:47       ` Andrew Gallatin
2007-11-20 11:55         ` David Miller
2007-11-20 13:27           ` Andrew Gallatin
2007-11-20 13:35             ` Evgeniy Polyakov
2007-11-20 13:50               ` Herbert Xu
2007-11-20 14:03                 ` Evgeniy Polyakov [this message]
2007-11-20 14:08                   ` Herbert Xu
2007-11-20 14:37                     ` Evgeniy Polyakov
2007-11-21  6:15             ` Bill Fink
2007-11-20 19:45   ` Rick Jones
2007-11-20 22:27     ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071120140312.GA6695@2ka.mipt.ru \
    --to=johnpol@2ka.mipt.ru \
    --cc=davem@davemloft.net \
    --cc=gallatin@myri.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    --cc=ossthema@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).