> Thanks. > > > However, the PRIO qdisc still uses the priority in the bands for > > dequeueing priority, and will feed the queues on the NIC. > > The e1000, and any other multiqueue NIC, will schedule Tx > based on how > > the PRIO qdisc feeds the queues. So the only priority here is the > > dequeuing priority from the kernel. The e1000 will use the new API > > for starting/stopping the individual queues based on the > descriptors > > available, much like it does today for the global queue. > > > Packets will only be dequeued from a band if the associated > subqueue is active, which moves the decision from prio to the > driver, no? > What policy does e1000 use for scheduling its internal queues? >
E1000 is handed the skb's from PRIO to whichever queue the PRIO flows dictate (based on band2queue mapping, tc filters, or TOS to skb->priority filtering). Once the skb hits the e1000, the internal policy is round-robin on the hardware queues to dequeue and transmit on the wire. I agree the NIC does influence the decision of which band an skb will be dequeued from based on available descriptors, etc., but that's one of the goals of multiqueue: don't allow another traffic flow in one queue stop or impact another separate flow. Once NICs start using hardware-based priority scheduling (wireless?), we can use a round-robin type qdisc in the kernel to dequeue, and let the hardware directly decide how important one flow is over another. Hope this answers your question. Cheers, -PJ Waskiewicz - 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
