netdev - RE: [PATCH] NET: Multiqueue network device support.

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Jun 2007 15:30:39 -0700
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	<hadi@...erus.ca>, "Patrick McHardy" <kaber@...sh.net>
Cc:	<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.

> [Which of course leads to the complexity (and not optimizing 
> for the common - which is single ring NICs)].

The common for 100 Mbit and older 1Gbit is single ring NICs.  Newer
PCI-X and PCIe NICs from 1Gbit to 10Gbit support multiple rings in the
hardware, and it's all headed in that direction, so it's becoming the
common case.

> Infact for the wired case i see little value (there is some) 
> in using multiple rings. In the case of wireless (which is 
> strict prio based) it provides more value.

There is value, hence why NIC manufacturers are building wired parts
that support multiple rings today.  And wireless may not want strict
prio in software, and may just want round-robin from the stack.  Either
way, Yi Zhu has represented the wireless side in this discussion
agreeing with these per-queue control patches.  Is wireless not a common
case to be considered?

> > I would love to see your alternative patches.
> 
> >From the above you can see they are simple.

The description above won't provide what I'm trying to solve and what
wireless has stated they want.

> Iam actually not against the subqueue control - i know Peter 
> needs it for certain hardware; i am just against the mucking 
> around of the common case (single ring NIC) just to get that working. 

Single-ring NICs see no difference here.  Please explain why using my
patches with pfifo_fast, sch_prio, or any other existing qdisc will
change the behavior for single-ring NICs?  If the driver doesn't call
alloc_etherdev_mq() explicity, or use the new sch_rr qdisc, then the Tx
path is identical to the kernel today.  What am I mucking around with?
And these patches are not for specific hardware; rather they're for all
the NICs today that have multiple rings, and want to control them in the
OS instead of the driver, which is most of wireless and a handful of
NICs from Intel and Neterion afaik.

-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