On Thu, Jan 31, 2008 at 03:42:54PM -0800, Waskiewicz Jr, Peter P wrote: > > Well, it could be just that when using such qdiscs TSO would be > > disabled, but the user could override this by using ethtool after > > loading the qdiscs. > > I still disagree with this. The qdisc should not cause anything to happen to > feature flags on the device. It's the scheduling layer and really shouldn't > care about what features the device supports or not. If someone has an issue > with a feature hurting performance or causing odd behavior when using a > qdisc, then they should disable the feature on the device using the > appropriate tools provided. If it's the qdisc causing issues, then either > the qdisc needs to be fixed, or it should be documented what features are > recommended to be on and off with the qdisc. I don't agree that the > scheduling layer should affect features on an underlying device.
You seem to only look at this from a high level theoretical standpoint. But more down to earth: do you have a useful scenario where it makes sense to do shaping or another qdisc on GSO packets? My take is that when you decide to do any packet scheduling you really want to do it on wire packets, not some internal stack implementation implementation detail units. -Andi -- 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
