> 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 <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
