RE: [PATCH] NET: [UPDATED] Multiqueue network device support implementation.

Waskiewicz Jr, Peter P
2007-04-11T16:52:54Z

> 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