* David S. Miller <[EMAIL PROTECTED]> 2005-07-24 18:08 > The key is what should happen when the ring for prio X fills > up? netif_stop_queue() in it's current form is the wrong > thing to do, because it prevents lower priority packets from > being queued which is exactly what we want to do if those > queues have space. The higher-prio packets will still go out > first, of course, but queueing to lower prio rings should > still be possible.
I agree but it is not a requirement for strict prio because the lower prio queues would not be used anyway. Problems arise if the hardware needs to know the queue length of the lower prios as it is probably the case for 802.11e. My point on this is solely that the current system is sufficient for multiple TX rings being read in strict prio order. > So we need some kind of netif_stop_queue_prio(dev, prio_nr) > or similar. Exactly. > The next issue is how to demultiplex from the number of prios > we want, to what the hardware actually supports if the latter > is smaller. That's what I meant with the non 1:1 mapping. I'm currently looking into this, the easiest way is to have some callback for the driver to report the number of tx rings. We can then extend the prio qdisc to support bands=auto to automatically get the same number of bands as rings and bands=N to get a proportional mapping. As soon as I finished the patch to make the prio qdisc do DRR we get some more flexibility for all this. - 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
