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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1181714168.4758.57.camel@debian.sh.intel.com>
Date:	Wed, 13 Jun 2007 13:56:08 +0800
From:	Zhu Yi <yi.zhu@...el.com>
To:	Patrick McHardy <kaber@...sh.net>
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.

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.

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

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