[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4742C96D.3050203@myri.com>
Date: Tue, 20 Nov 2007 06:47:57 -0500
From: Andrew Gallatin <gallatin@...i.com>
To: David Miller <davem@...emloft.net>
CC: herbert@...dor.apana.org.au, netdev@...r.kernel.org,
ossthema@...ibm.com
Subject: Re: [PATCH] LRO ack aggregation
David Miller wrote:
> From: Herbert Xu <herbert@...dor.apana.org.au>
> Date: Tue, 20 Nov 2007 14:09:18 +0800
>
>> David Miller <davem@...emloft.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.
> But if it's there the risk it to have it end up being turned on
> always by distribution vendors, making our off-default pointless
> and the internet gets crapped up with misbehaving Linux TCP
> stacks anyways.
If vendors are going to pick this up, there is the risk of them just
applying this patch (which currently has no tunable to disable it),
leaving their users stuck with it enabled. At least with a tunable,
it would be easy for them to turn it off. And the comments surrounding
it could make it clear why it should default to off.
FWIW, we've seen TCP perform well in a WAN setting using our NICs and
our LRO which does this ack aggregation. For example, the last 2
Supercomputing "Bandwidth Challenges" (making the most of a 10Gb/s
WAN connection) were won by teams using our NICs, with drivers that
did this sort of ack aggregation.
Drew
-
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