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

[Waskiewicz Jr, Peter P]

> 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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/