> My point was that without TSO different submitters will
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@intel.com>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html