netdev - Re: [net-next patch 8/12] bnx2x: Allow up to 63 RSS queues default 8 queues

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:	Sun, 17 Jun 2012 09:53:51 +0300
From:	"Eilon Greenstein" <eilong@...adcom.com>
To:	"David Miller" <davem@...emloft.net>
cc:	meravs@...adcom.com, eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: [net-next patch 8/12] bnx2x: Allow up to 63 RSS queues
 default 8 queues

On Thu, 2012-06-14 at 13:36 -0700, David Miller wrote:
> From: "Merav Sicron" <meravs@...adcom.com>
> Date: Thu, 14 Jun 2012 18:34:06 +0300
> 
> > That's why we think (and so does Eric Dumazet) that it is better
> > to have a smaller default number which is good for most cases.
> > Do you agree with that?
> 
> What I think is that the thing which is more important than the
> default we choose, is that it is consistently followed by all
> multiqueue drivers.
> 
> By blazing your own unique path here, that is nearly guaranteed not to
> happen.
> 
> I'd much rather have a bad default that every driver adheres to.
> 

The increasing number of CPUs together with the increasing number of
supported MSI-X vectors per device, is causing a lot of memory to be
allocated for the networking channels. This is a problem on low memory
platforms such as 32bits installations. 64 queues per device (and in
most cases, there are few devices) is a becoming a real problem.

If the device does not implement the ethtool .set_channels operation,
then the default is practically the only way to go, and there is no such
thing as a good default - it really depends on the use case. This is the
reason why we are only setting the default in the series that adds
support for this operation.

So what do you say about setting a new default only for devices that
supports .set_channels? There are only 2 of those right now (qlcnic,
bnx2 and hopefully bnx2x soon). Is it acceptable to keep the default
hard coded value or do you want it to be configurable? If the latter, is
a kernel parameter a valid option?

Please note that today, on a system with enough CPUs, you cannot really
tell how many channels will be created per device - each vendor is
allocating up to its HW limit - usually 8 or 16, but there is no easy
way to determine it beside reading the code. So adding a kernel
parameter to limit the number can actually increase the consistency.

Thanks,
Eilon

--
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