[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080201225627.GB3071@ami.dom.local>
Date: Fri, 1 Feb 2008 23:56:27 +0100
From: Jarek Poplawski <jarkao2@...il.com>
To: hadi@...erus.ca
Cc: Patrick McHardy <kaber@...sh.net>,
"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
Andi Kleen <andi@...stfloor.org>, Glen Turner <gdt@....id.au>,
Stephen Hemminger <shemminger@...ux-foundation.org>,
netdev@...r.kernel.org
Subject: Re: [PATCH] Disable TSO for non standard qdiscs
jamal wrote, On 02/01/2008 01:06 PM:
> On Fri, 2008-01-02 at 10:56 +0100, Patrick McHardy wrote:
>
>> We don't want to disable TSO for cases where it makes sense, but
>> who is using TBF on 10GbE? The point is that most users of qdiscs
>> which are incapable of dealing with TSO without hacks or special
>> configuration probably don't care, and 10GbE users know about
>> ethtool *and* don't use TBF or HTB (which are probably the only
>> qdiscs which actually have problems, maybe also CBQ).
>
> Right - Essentially it is a usability issue:
> People who know how to use TSO (Peter for example) will be clueful
> enough to turn it on. Which means the default should be to protect the
> clueless and turn it off.
> On Andis approach:
> Turning TSO off at netdev registration time with a warning will be a
> cleaner IMO. Or alternatively introducing a kernel-config "I know what
> TSO is" option which is then used at netdev registration. From a
> usability perspective it would make more sense to just keep ethtool as
> the only way to configure TSO.
>
> [I recently spent a few days helping someone debug a problem with IFB
> because he was redirecting packets from an TSO netdevice and occasionaly
> some multi-packet will be missed in the calculation; my answer was "turn
> off TSO"; so there are more use cases for this TSO issue].
I totally disagree with these POVs:
- 10G cards should be treated by default as 10G cards - not DSL modems,
and common users shouldn't have to read any warnings or configs to
see this.
- tc with TBF or HTB are professional tools; there should be added some
warnings to manuals. But trying to change the way they work because
we think we know better what users want, and changing BTW some other
things (making debugging this later a hell), is simply disrespectful
for target users of these tools. There are some wrappers or "creators"
invented for this. And, BTW, I think I've seen somewhere a system
which does this this other way - with creators for professionals. So,
you could be right with this too...
Cheers,
Jarek P.
--
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