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]

Message-Id: <1181870826.4092.29.camel@debian.sh.intel.com>
Date:	Fri, 15 Jun 2007 09:27:06 +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 Thu, 2007-06-14 at 07:48 -0400, jamal wrote:
> I dont have much time to followup for sometime to come. I have left my
> answer above. To clarify, incase i wasnt clear, I am saying:
> a) It is better to have the driver change via some strategy of when to
> open the tx path than trying to be generic. This shifts the burden to
> the driver.
> b) given the behavior of wireless media (which is very different from
> wired ethernet media), you need a different strategy. In response to
> Guy's question, I gave the example of being able to use management
> frames to open up the tx path for VO (even when you dont know VO
> packets
> are sitting on the qdisc); alternatively you could use a timer etc.
> Theres many ways to skin the cat (with apologies to cat
> lovers/owners).
> i.e you need to look at the media and be creative.
> Peters DCE for example could also be handled by having a specific
> strategy. 

OK. You tried so much to guess the traffic flow pattern in the low level
driver, which could be implemented straightforward in the Qdisc. The pro
is the Qdisc API is untouched. But the cons are:

1. driver becomes complicated (as it is too elaborate in the queue
wakeup strategies design)
2. duplicated code among drivers (otherwise you put all the queue
management logics in a new layer?)
3. it's not 100% accurate. there has to be some overhead, more or less
depends on the queue wakeup strategy the driver selected.

Time for voting?

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