From: Patrick McHardy <kaber@trash.net>
To: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>
Cc: 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, 01 Feb 2008 10:56:57 +0100 [thread overview]
Message-ID: <47A2ECE9.5000103@trash.net> (raw)
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC32904737A42@orsmsx414.amr.corp.intel.com>
Waskiewicz Jr, Peter P wrote:
>> Indeed. As an example of an unknowing user, this discussion
>> made me check whether my cablemodem device (on which I'm
>> using HFSC) uses TSO :)
>
> The TSO defer logic is based on your congestion window and current
> window size. So the actual frame sizes hitting your NIC attached to
> your DSL probably aren't anywhere near 64KB, but probably more in line
> with whatever your window size is for DSL.
>
> The bottom line is TSO saves CPU cycles. If we want to make it go away
> because of a traffic shaping qdisc interfering, then that's fine. I
> just don't think a TSO option should be added to the scheduler layer,
> since it already exists in the ethtool layer. Asking a user to type
> 'ethtool -k <devicename> tso off' is probably going to be much easier
> than setting an option on your qdisc through tc to turn TSO back on.
>
> I think we're having more of a disagreement of what is considered the
> "normal case" user. If you are on a slow link, such as a DSL/cable
> line, your TCP window/congestion window aren't going to be big enough to
> generate large TSO's, so what is the issue? But disabling TSO, say on a
> 10 GbE link, can cut throughput by half (I have data on 8-core machines
> with 10 GbE with/without TSO if you're interested). Even on a
> single-core machine with a 1GbE link can have bad performance hits. So
> this is why I'm so concerned about a proposal to turn off TSO outside of
> the current established methods of using ethtool. Rather than educating
> the user about how to turn TSO back on using tc if they want it, educate
> them why they may want to consider turning TSO off in certain
> configurations. And I don't consider any user effectively using a TBF
> qdisc someone incapable of understanding how to use ethtool.
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).
next prev parent reply other threads:[~2008-02-01 9:57 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 [this message]
2008-02-01 12:06 ` jamal
2008-02-01 19:02 ` Waskiewicz Jr, Peter P
2008-02-01 22:56 ` Jarek Poplawski
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=47A2ECE9.5000103@trash.net \
--to=kaber@trash.net \
--cc=andi@firstfloor.org \
--cc=gdt@gdt.id.au \
--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 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).