[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D5C1322C3E673F459512FB59E0DDC32904700E40@orsmsx414.amr.corp.intel.com>
Date: Thu, 31 Jan 2008 10:47:05 -0800
From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To: "Andi Kleen" <andi@...stfloor.org>,
"Patrick McHardy" <kaber@...sh.net>
Cc: "Stephen Hemminger" <shemminger@...ux-foundation.org>,
<netdev@...r.kernel.org>
Subject: RE: [PATCH] Disable TSO for non standard qdiscs
> My point was that without TSO different submitters will
> interleave their streams (because they compete about the
> qdisc submission) and then you end up with a smooth rate over
> time for all of them.
>
> If you submit in large chunks only (as TSO does) it will
> always be more bursty and that works against the TBF goal.
>
> For a single submitter you would be correct.
>
> -Andi
TSO by nature is bursty. But disabling TSO without the option of having
it on or off to me seems to aggressive. If someone is using a qdisc
that TSO is interfering with the effectiveness of the traffic shaping,
then they should turn off TSO via ethtool on the target device. Some
people may want TSO with certain rate limiter settings. That way (as
Stephen said) you can even allow the stack to GSO, then segment before
calling hard_start_xmit(), which still saves a number of cycles.
I'd rather not see this, but a documented recommendation why TSO could
be bad for some traffic shaping qdiscs. Give the power to the user to
either shoot themselves in the foot or disable TSO when needed.
-PJ Waskiewicz
<peter.p.waskiewicz.jr@...el.com>
--
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