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
| ||
|
Message-Id: <1181568598.4043.250.camel@localhost> Date: Mon, 11 Jun 2007 09:29:58 -0400 From: jamal <hadi@...erus.ca> To: Patrick McHardy <kaber@...sh.net> Cc: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>, davem@...emloft.net, netdev@...r.kernel.org, jeff@...zik.org, "Kok, Auke-jan H" <auke-jan.h.kok@...el.com> Subject: Re: [PATCH] NET: Multiqueue network device support. On Mon, 2007-11-06 at 15:03 +0200, Patrick McHardy wrote: > jamal wrote: > Well, its not. I dont wanna go into those old style debates again; so lets drop this point. > > Take a step back: > > When you put a packet on the DMA ring, are you ever going to take it > > away at some point before it goes to the wire? > > > No, > but its nevertheless not on the wire yet and the HW scheduler > controls when it will get there. > > It might in theory even never get > there if higher priority queues are continously active. Sure - but what is wrong with that? What would be wrong is in the case of contention for a resource like a wire between a less important packet and a more important packet, the more important packet gets favored. Nothing like that ever happens in what i described. Remember there is no issue if there is no congestion or contention for local resources. > > And if there is contention, the qdisc scheduler will do the right thing. > > > That ignores a few points that were raised in this thread, > > - you can treat each HW queue as an indivdual network device You can treat a pair of tx/rx as a netdev. In which case none of this is important. You instantiate a different netdev and it only holds the appropriate locks. > - you can avoid synchronizing on a single queue lock for > multiple TX queues Unneeded if you do what i described. Zero changes to the qdisc code. > - it is desirable to keep all queues full It is desirable to keep resources fully utilized. Sometimes that is achieved by keeping _all_ queues full. If i fill up a single queue full and transmit at wire rate, there is no issue. cheers, jamal - 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