From: Andrew Gallatin <gallatin@myri.com>
To: David Miller <davem@davemloft.net>
Cc: herbert@gondor.apana.org.au, netdev@vger.kernel.org, ossthema@de.ibm.com
Subject: Re: [PATCH] LRO ack aggregation
Date: Tue, 20 Nov 2007 08:27:05 -0500 [thread overview]
Message-ID: <4742E0A9.2070205@myri.com> (raw)
In-Reply-To: <20071120.035558.214794900.davem@davemloft.net>
David Miller wrote:
> From: Andrew Gallatin <gallatin@myri.com>
> Date: Tue, 20 Nov 2007 06:47:57 -0500
>
>> David Miller wrote:
>> > From: Herbert Xu <herbert@gondor.apana.org.au>
>> > Date: Tue, 20 Nov 2007 14:09:18 +0800
>> >
>> >> David Miller <davem@davemloft.net> wrote:
>> >>> Fundamentally, I really don't like this change, it batches to the
>> >>> point where it begins to erode the natural ACK clocking of TCP,
and I
>> >>> therefore am very likely to revert it before merging to Linus.
>> >> Perhaps make it a tunable that defaults to off?
>> >
>> > That's one idea.
>>
>> I'd certainly prefer the option to have a tunable to having our
>> customers see performance regressions when they switch to
>> the kernel's LRO.
>
> Please qualify this because by itself it's an inaccurate statement.
>
> It would cause a performance regression in situations where the is
> nearly no packet loss, no packet reordering, and the receiver has
> strong enough cpu power.
Yes, a regression of nearly 1Gb/s in some cases as I mentioned
when I submitted the patch.
<....>
> Show me something over real backbones, talking to hundres or thousands
> of clients scattered all over the world. That's what people will be
> using these high end NICs for front facing services, and that's where
> loss happens and stretch ACKs hurt performance.
>
I can't. I think most 10GbE on endstations is used either in the
sever room, or on dedicated links. My experience with 10GbE users is
limited to my interactions with people using our NICs who contact our
support. Of those, I can recall only a tiny handful who were using
10GbE on a normal internet facing connection (and the ones I dealt
with were actually running a different OS). The vast majority were in
a well controlled, lossless environment. It is quite ironic. The
very fact that I cannot provide you with examples of internet facing
people using LRO (w/ack aggr) in more normal applications tends to
support my point that most 10GbE users seem to be in lossless
environments.
> ACK stretching is bad bad bad for everything outside of some well
> controlled test network bubble.
I just want those in the bubble to continue have the best performance
possible in their situation. If it is a tunable the defaults to off,
that is great.
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?
Drew
next prev parent reply other threads:[~2007-11-20 13:27 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 [this message]
2007-11-20 13:35 ` Evgeniy Polyakov
2007-11-20 13:50 ` Herbert Xu
2007-11-20 14:03 ` Evgeniy Polyakov
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=4742E0A9.2070205@myri.com \
--to=gallatin@myri.com \
--cc=davem@davemloft.net \
--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).