On Fri, 2005-22-07 at 15:52 -0700, David S. Miller wrote: > Sounds OK. What happens if the top-level queue pulls out > a packet with a certain priority, and that priority's queue > in the device is stopped? Will it look for lower-priority > packets and try to send those? All of this kind of logic could > result in some ugly loops :)
I am actually not fond of making any such change as i said yesterday to Thomas/Patrick. Experience may prove me wrong. Most of these pieces of h/ware have different approaches to how those underlying rings are used sending out to the wire. As an example, it is clear the wireless folks have time slots + prios as the desired qos scheme. This will map nicely to a top qdisc that is based on deficit roundrobin or even simple weighted roundrobin i.e you map the time slots to weights and priorities on the rings to the s/ware queue priorities. Hopefully Thomas can get that qdisc done. Some of the other NICs have different schemes than the wireless people need. Example the freescale people have a strict priority as well as a weighted round robin scheme. Depending on how the administrator configures such a NIC (maybe via ethttool), they have also to attach to it a specific root qdisc that maps correctly to the underlying rings. And yet another example is the newer upcoming e1000 which is based on just strict prio. Setting the skb->prio to be used by the driver sounds reasonable. Another alternative would be what was already mentioned to change the call to hardware_start_transmit() to take a prio option. The driver should take care of what that all means given that we have views that differ depending on the h/ware. cheers, jamal - 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
