> My point was that without TSO different submitters willTSO 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
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds | [LGUEST] Look in object dir for .config |
git: | |
| Brian Downing | Re: Git in a Nutshell guide |
| John Benes | Re: master has some toys |
| Matthias Lederhofer | [PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree |
| Alexander Sulfrian |
