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:	Tue, 12 Jun 2007 17:04:19 +0300
From:	"Cohen, Guy" <guy.cohen@...el.com>
To:	<hadi@...erus.ca>
Cc:	"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.

Hi Jamal,

Here is a simple scenario (nothing here is rare of extreme case):
- Busy wireless environment
- FTP TX on BE queue (low priority)
- Skype TX on VO queue (high priority)

The channel is busy with high priority packets hence the BE packets are
transmitted to the air rarely so the DMA/HW queue of the BE access
category gets full and the qdisc is stopped.
Now periodic VO-tagged Skype packets arrive. I would expect that they
get the priority (and pass) in all stages of the stack and reach the HW
ASAP and compete there on the medium with the other access categories
and the other clients on the channel.
Now this packet will be stuck in the qdisc and wait there until a BE
packet is transmitted, which can take a long time. This is a real
problem.

There is also a problem with the queues that will be dedicated to TX
aggregation in 11n (currently implemented) - the packets will be
classified to queues by the destination MAC address and not only by the
priority class, but I don't want to get into that now. I think that
there are enough arguments now why the patch that started this thread is
needed...

Please see below some replies to your questions.

Regards,
Guy.

jamal wrote:
> It could be estimated well by the host sw; but lets defer that to
later
> in case i am clueless on something or you misunderstood something i
> said.

It cannot be estimated well by the host SW. This is one of the main
issues - we can't put it aside...

> I understand.  Please correct me if am wrong:
> The only reason AC_BK packet will go out instead of AC_VO when
> contending in hardware is because of a statistical opportunity not the
> firmware intentionaly trying to allow AC_BK out
> i.e it is influenced by the three variables:
> 1) The contention window 2) the backoff timer and 3)the tx opportunity
> And if you look at the default IEEE parameters as in that url slide
43,
> the only time AC_BK will win is luck.

In most scenarios BK packets will be transmitted and will win the medium
against VO packets (thought, in some non-favored ratio).

> Heres a really dated paper before the standard was ratified:
> http://www.mwnl.snu.ac.kr/~schoi/publication/Conferences/02-EW.pdf

Sorry, I'm really overloaded - I won't be able to review the docs you
sent (really apologize for that).

> So essentially the test you mention changes priorities in real time.
> What is the purpose of this test? Is WMM expected to change its
> priorities in real time?

The WMM parameters of the AC are set and controlled by the network/BSS
(access point) administrator and can be used in anyway. There are the
default parameters but they can be changed.

Regards,
Guy.
-
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