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:	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

Powered by blists - more mailing lists