On Wed, 2007-06-13 at 08:32 -0400, jamal wrote: > The key arguement i make (from day one actually) is to leave the > majority of the work to the driver.
But it seems not feasible the Qdisc needs to know nothing about the hardware rings. > My view of wireless WMM etc is it is a different media behavior > (compared to wired ethernet) which means a different view of strategy > for when it opens the valve to allow in more packets. 802.11 media has > embedded signalling which is usable. Guy Cohen gave a good use case > which i responded to. Do you wanna look at that and respond? The key to support multi-ring hardware for software is to put packets into hardware as much/early as possible. Guy gave a good VO vs. BK example. To achieve this in your model, you have to keep the TX ring running (in the case of PHL full) and requeue. But when there are only BK packets coming, you do want to stop the ring, right? AFAICS, the driver is not the best place to make the decision (it only knows the current and previous packets, but not the _next_), the Qdisc is the best place. Thanks, -yi - 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
