lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 11 Apr 2007 09:52:50 -0700 From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com> To: "Patrick McHardy" <kaber@...sh.net> Cc: <davem@...emloft.net>, <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <jgarzik@...ox.com>, "cramerj" <cramerj@...el.com>, "Kok, Auke-jan H" <auke-jan.h.kok@...el.com>, "Leech, Christopher" <christopher.leech@...el.com> Subject: RE: [PATCH] NET: [UPDATED] Multiqueue network device support implementation. > 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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists