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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 14 Jun 2007 10:44:24 +0800
From:	Zhu Yi <yi.zhu@...el.com>
To:	hadi@...erus.ca
Cc:	Patrick McHardy <kaber@...sh.net>,
	David Miller <davem@...emloft.net>,
	peter.p.waskiewicz.jr@...el.com, netdev@...r.kernel.org,
	jeff@...zik.org, auke-jan.h.kok@...el.com
Subject: Re: [PATCH] NET: Multiqueue network device support.

On Wed, 2007-06-13 at 08:32 -0400, jamal wrote:
> The key arguement i make (from day one actually) is to leave the
> majority of the work to the driver.

But it seems not feasible the Qdisc needs to know nothing about the
hardware rings.

> My view of wireless WMM etc is it is a different media behavior
> (compared to wired ethernet) which means a different view of strategy
> for when it opens the valve to allow in more packets. 802.11 media has
> embedded signalling which is usable. Guy Cohen gave a good use case
> which i responded to. Do you wanna look at that and respond? 

The key to support multi-ring hardware for software is to put packets
into hardware as much/early as possible. Guy gave a good VO vs. BK
example. To achieve this in your model, you have to keep the TX ring
running (in the case of PHL full) and requeue. But when there are only
BK packets coming, you do want to stop the ring, right? AFAICS, the
driver is not the best place to make the decision (it only knows the
current and previous packets, but not the _next_), the Qdisc is the best
place.

Thanks,
-yi
-
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