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: <466FD638.4070907@trash.net>
Date:	Wed, 13 Jun 2007 13:34:16 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Zhu Yi <yi.zhu@...el.com>
CC:	David Miller <davem@...emloft.net>, hadi@...erus.ca,
	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.

Zhu Yi wrote:
> On Tue, 2007-06-12 at 23:17 +0200, Patrick McHardy wrote:
> 
>>I've hacked up a
>>small multiqueue simulator device and to my big surprise my testing
>>showed that Jamal's suggestion of using a single queue state seems to
>>work better than I expected. But I've been doing mostly testing of
>>the device itself up to now with very simple traffic patterns (mostly
>>just "flood all queues"), so I'll try to get some real results
>>tomorrow. 
> 
> 
> The key argument for Jamal's solution is the NIC will send out 32
> packets in the full PHL in a reasonably short time (a few microsecs per
> Jamal's calculation). But for wireless, the PHL hardware has low
> probability to seize the wireless medium when there are full of high
> priority frames in the air. That is, the chance for transmission in PHL
> and PHH is not equal. Queuing packets in software will starve high
> priority packets than putting them to PHH as early as possible.


Well, the key result of our discussion was that it makes no difference
wrt. queuing behaviour if the queue wakeup strategy is suitable chosen
for the specific queueing discipline, but it might add some overhead.

> Patrick, I don't think your testing considered about above scenario,
> right?


No, as stated my testing so far has been very limited. I'll try to
get some better results later.

-
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