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: <1182129521.4092.77.camel@debian.sh.intel.com>
Date:	Mon, 18 Jun 2007 09:18:41 +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 Fri, 2007-06-15 at 06:49 -0400, jamal wrote:
> Hello Yi,
> 
> On Fri, 2007-15-06 at 09:27 +0800, Zhu Yi wrote:
> 
> > 1. driver becomes complicated (as it is too elaborate in the queue
> > wakeup strategies design)
> 
> I am not sure i see the complexity in the wireless driver's wakeup
> strategy. I just gave some suggestions to use management frames - they
> dont have to be literally that way.
> 
> > 2. duplicated code among drivers (otherwise you put all the queue
> > management logics in a new layer?)
> 
> There will be some shared code on drivers of same media on the
> netif_stop/wake strategy perhaps, but not related to queue management. 
> 
> > 3. it's not 100% accurate. there has to be some overhead, more or less
> > depends on the queue wakeup strategy the driver selected.
> 
> Why is it not accurate for wireless? I can see the corner case Patrick
> mentioned in wired ethernet but then wired ethernet doesnt have other
> events such as management frames (actually DCE does) to help. 

Would you respond the question I asked early, in your model how to
define the queue wakeup strategy in the driver to deal with the PHL full
situation? Consider about 1) both high prio and low prio packets could
come (you cannot predict it beforehand) 2) the time for PHL to send out
a packet to the wireless medium is relative long (given the medium is
congested). If you can resolve it in an elegant way, I'm all ears.

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