From: Jarek Poplawski <jarkao2@gmail.com>
To: hadi@cyberus.ca
Cc: Patrick McHardy <kaber@trash.net>,
"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>,
Andi Kleen <andi@firstfloor.org>, Glen Turner <gdt@gdt.id.au>,
Stephen Hemminger <shemminger@linux-foundation.org>,
netdev@vger.kernel.org
Subject: Re: [PATCH] Disable TSO for non standard qdiscs
Date: Fri, 1 Feb 2008 23:56:27 +0100 [thread overview]
Message-ID: <20080201225627.GB3071@ami.dom.local> (raw)
In-Reply-To: <1201867609.4465.50.camel@localhost>
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.
next prev parent reply other threads:[~2008-02-01 22:52 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-31 12:46 [PATCH] Disable TSO for non standard qdiscs Andi Kleen
2008-01-31 17:23 ` Stephen Hemminger
2008-01-31 18:33 ` Andi Kleen
2008-01-31 18:01 ` Patrick McHardy
2008-01-31 18:37 ` Andi Kleen
2008-01-31 18:08 ` Stephen Hemminger
2008-01-31 18:11 ` Patrick McHardy
2008-01-31 18:53 ` Andi Kleen
2008-01-31 18:21 ` Patrick McHardy
2008-01-31 19:01 ` Andi Kleen
2008-01-31 18:47 ` Waskiewicz Jr, Peter P
2008-01-31 19:34 ` Andi Kleen
2008-01-31 19:39 ` Waskiewicz Jr, Peter P
2008-01-31 23:10 ` Arnaldo Carvalho de Melo
2008-01-31 23:42 ` Waskiewicz Jr, Peter P
2008-02-01 4:26 ` Patrick McHardy
2008-02-01 4:35 ` Andi Kleen
2008-02-01 4:36 ` Andi Kleen
2008-01-31 20:33 ` Jarek Poplawski
2008-01-31 23:04 ` Jarek Poplawski
2008-02-01 7:42 ` Jarek Poplawski
2008-02-01 9:28 ` Waskiewicz Jr, Peter P
2008-02-01 21:47 ` Jarek Poplawski
2008-02-01 5:01 ` Andi Kleen
2008-02-01 6:35 ` Glen Turner
2008-02-01 6:46 ` Patrick McHardy
2008-02-01 7:46 ` Andi Kleen
2008-02-01 7:25 ` Patrick McHardy
2008-02-01 9:37 ` Waskiewicz Jr, Peter P
2008-02-01 9:56 ` Patrick McHardy
2008-02-01 12:06 ` jamal
2008-02-01 19:02 ` Waskiewicz Jr, Peter P
2008-02-01 22:56 ` Jarek Poplawski [this message]
2008-02-02 1:51 ` Waskiewicz Jr, Peter P
2008-02-02 5:20 ` Andi Kleen
2008-02-01 14:34 ` Andi Kleen
2008-02-01 17:24 ` Stephen Hemminger
2008-01-31 18:48 ` Patrick McHardy
2008-02-02 22:57 ` Herbert Xu
2008-02-03 9:35 ` Andi Kleen
2008-01-31 18:26 ` Rick Jones
2008-01-31 19:03 ` Andi Kleen
2008-01-31 18:35 ` Rick Jones
2008-01-31 19:25 ` Andi Kleen
2008-01-31 19:14 ` Rick Jones
2008-02-01 1:04 ` Andy Furniss
2008-02-01 4:31 ` Andi Kleen
2008-02-02 22:59 ` Herbert Xu
2008-02-01 21:58 ` Rick Jones
2008-02-02 4:10 ` Andi Kleen
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=20080201225627.GB3071@ami.dom.local \
--to=jarkao2@gmail.com \
--cc=andi@firstfloor.org \
--cc=gdt@gdt.id.au \
--cc=hadi@cyberus.ca \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=peter.p.waskiewicz.jr@intel.com \
--cc=shemminger@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.