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:	Mon, 11 Jun 2007 11:14:50 -0400
From:	jamal <hadi@...erus.ca>
To:	Tomas Winkler <tomasw@...il.com>
Cc:	"Cohen, Guy" <guy.cohen@...el.com>,
	Patrick McHardy <kaber@...sh.net>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	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.

On Mon, 2007-11-06 at 18:00 +0300, Tomas Winkler wrote:
> On 6/11/07, jamal <hadi@...erus.ca> wrote:
> > On Mon, 2007-11-06 at 17:30 +0300, Cohen, Guy wrote:
> >
> > >
> > > For WiFi devices the HW often implements the scheduling, especially when
> > > QoS (WMM/11e/11n) is implemented. There are few traffic queues defined
> > > by the specs and the selection of the next queue to transmit a packet
> > > from, is determined in real time, just when there is a tx opportunity.
> > > This cannot be predicted in advance since it depends on the medium usage
> > > of other stations.
> >
> > WMM is a strict prio mechanism.
> > The parametrization very much favors the high prio packets when the
> > tx opportunity to send shows up.
> >
> 
> This is not true, there is no simple priority order from 1 to 4 ,
> rather set of parameters that dermises access to medium.  You have to
> emulate medium behavior to schedule packets in correct order. That's
> why this pushed to HW, otherwise nobody would invest money in this
> part of silicon :)
> 

I dont have the specs neither am i arguing the value of having the
scheduler in hardware. (I think the over radio contention clearly
needs the scheduler in hardware).

But i have read a couple of papers on people simulating this in s/ware.
And have seen people describe the parametrization that is default,
example Slide 43 on:
http://madwifi.org/attachment/wiki/ChipsetFeatures/WMM/qos11e.pdf?format=raw
seems to indicate the default parameters for the different timers
is clearly strictly in favor of you if you have higher prio.
If the info quoted is correct, it doesnt change anything i have said so
far.
i.e it is strict prio scheduling with some statistical chance a low prio
packet will make it. 

cheers,
jamal

-
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