netdev - Re: [PATCH 2.6.37-rc1] net-next: Add multiqueue support to vmxnet3 driver v3

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] [day] [month] [year] [list]

Message-Id: <20101117.092722.193716325.davem@davemloft.net>
Date:	Wed, 17 Nov 2010 09:27:22 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	bhutchings@...arflare.com
Cc:	sbhatewara@...are.com, shemminger@...tta.com,
	netdev@...r.kernel.org, pv-drivers@...are.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.37-rc1] net-next: Add multiqueue support to vmxnet3
 driver v3

From: Ben Hutchings <bhutchings@...arflare.com>
Date: Wed, 17 Nov 2010 17:23:38 +0000

> On Tue, 2010-11-16 at 21:14 -0800, Shreyas Bhatewara wrote:
> [...]
>> Okay. I am resending the patch with no module params what-so-ever. The default
>> is no-multiqueue though. Single queue code has matured and is optimized for
>> performance. Multiqueue code has got relatively lesser performance tuning. Since
>> there is no way to switch between the two modes as of now, it only makes sense
>> to keep the best known as default. When configuration knobs are introduced 
>> later, multiqueue can be made default.
> 
> But so far as I can see there is currently *no* way to enable multiqueue
> without editing the code.  Perhaps there could be an experimental config
> option that people can use to enable and test it now, before we sort out
> the proper API?

It should be turned on by default, otherwise don't add the code until
it's "ready."

We had slight performance regressions in the past when various drivers
added multiqueue support, but the aggregate performance increased for
multi-flow cases, and this was deemed a fine tradeoff.  I was hoping
you'd use similar logic.

Otherwise, send this stuff when it's ready, and no sooner.
--
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