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: <1339688046.20038.3.camel@lb-tlvb-meravs.il.broadcom.com>
Date:	Thu, 14 Jun 2012 18:34:06 +0300
From:	"Merav Sicron" <meravs@...adcom.com>
To:	"David Miller" <davem@...emloft.net>
cc:	eilong@...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 Wed, 2012-06-13 at 15:35 -0700, David Miller wrote:
> From: "Eilon Greenstein" <eilong@...adcom.com>
> Date: Wed, 13 Jun 2012 16:53:29 +0300
> 
> > Just to emphasis, since this is the patch series that enable the users
> > to control the number of queues, we can reduce the default number and
> > allow the user to increase it if he has a setup that needs more than 8
> > parallel CPUs to receive the traffic. When using a new FW on the board,
> > the number can be increased up to 64, so using the maximal number can be
> > an overkill (even if the machine has 64 CPUs, it does not mean that the
> > user would like us to consume 64 MSI-X vectors and all the memory to set
> > up 64 queues) - so a lower default value can be used to satisfy most
> > users while allowing them to increase the number if they wish.
> 
> I think you should look at other drivers for guidance in this area.
> 
> There is zero value in each and every driver author deciding what
> is a good default strategy, because this means the user gets a
> very inconsistent experience based purely upon the driver author's
> whims.
> 

We looked at few other drivers - their current behavior is similar to
what bnx2x had before this change: Minimum between the number of CPU and
a defined maximum (probably the HW limit).
bnx2x HW limit is 64 (in most other drivers it is smaller, but this can
change). The number of CPUs in new systems becomes bigger and bigger,
and allocaintg so many RSS queues seems like a waste. With the
relatively new ethtool -L feature the user can change the number of
queues. 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?

Thanks,
Merav





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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ