netdev - RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior

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:	Fri, 11 May 2007 09:58:01 +0800
From:	Zhu Yi <yi.zhu@...el.com>
To:	hadi@...erus.ca
Cc:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	Johannes Berg <johannes@...solutions.net>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org,
	jgarzik@...ox.com, cramerj <cramerj@...el.com>,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
	"Leech, Christopher" <christopher.leech@...el.com>,
	davem@...emloft.net
Subject: RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior

On Thu, 2007-05-10 at 08:35 -0400, jamal wrote:
> So we may be agreeing then?
> In other words, if you had both low prio and high prio in WMM
> scheduler
> (in wireless hardware) then the station favors a higher priority
> packet
> over at low priority packet at ALL times.
> IOW:
> Given the default 802.11e AIFS, CWmin/max and PF (and TXOP) parameters
> used for the different WMM queues there is no way that a lower prio
> packet will ever be allowed to leave when it is competing with a
> higher
> prio packet. 
> This approach is what the strict prio qdisc already does. The slight
> difference is the prio qdisc is deterministic and the WMM is
> statistical
> (strict prio) in nature -  i.e there is a statiscal "luck" possibility
> (not design intent) for an lower prio packet to go out.
> 
> Does this make sense? 

Good, we agree on this. Now let's solve the problem.

When the low priority ring buffer is full in the hardware, will you
suppose the driver call netif_stop_queue() or not? In old ethernet, I
think the answer is yes because the packets in the ring buffer have to
be sent out anyway before there is room for the new packets. But in
wireless (or multiqueue devices), the high priority packets can be sent
out thru high ring buffer although the low ring buffer is full. This is
how wireless MAC differs where we agreed above.

To enable this, we need to manage the device queues separately, i.e.
netif_stop_subqueue() and the Qdisc dequeue methold is able to feed the
device with only high priority packets in the low ring full case.

I think it's possible to do all these changes in a specific Qdisc and
leave all the Qdisc APIs, netif_{start,stop}_queue(), etc untouched. But
it turns out to be what mac80211 QoS is right now. You also call it a
hack, right? I think Peter's patch resovle the problem in a generic way.
This avoids every multiqueue device creates its own Qdisc for doing its
work. Besides, it also duplicates a lot of common code.

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