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:	Wed, 13 Jun 2012 15:59:15 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	eilong@...adcom.com
Cc:	Merav Sicron <meravs@...adcom.com>, davem@...emloft.net,
	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 16:53 +0300, Eilon Greenstein wrote:
> On Wed, 2012-06-13 at 18:14 +0300, Merav Sicron wrote:
> > Hi Eric,
> > 
> > On Wed, 2012-06-13 at 11:52 +0200, Eric Dumazet wrote:
> > > On Wed, 2012-06-13 at 15:44 +0300, Merav Sicron wrote:
> > > > This patch removed the limitation in the code for 16 RSS queues. The default
> > > > (without other instruction from the user) number of queues is determined
> > > > according to the number of MSI-X vectors supported for that function, the number
> > > > of CPUs in the system, and a maximum of 8 queues.
> > > 
> > > Thats a very confusing changelog
> > > 
> > > You meant : " a minimum of 8 queues" ?
> > > 
> > No, I meant maximum...for example in a system with 16 CPUs we will
> > allocate 8 RSS queues. We saw that in most scenarios we tested there was
> > no need for more than 8 queues to get the maximal throughput, and by
> > limiting to 8 by default we reduce the allocated memory. We do provide
> > ethtool -L support so that the user could request more RSS queues if
> > desired.
> > 
> > > You should give more explanations, because its a sensible area for
> > > performances.
> > > 
> 
> 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 am all for a reduction of default number of queues.

Even a laptop has now 8 cpus, so on servers, using one queue per cpu is
overkill for most uses.

Thanks


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