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

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

Date:	Wed, 13 Jun 2012 16:53:29 +0300
From:	"Eilon Greenstein" <eilong@...adcom.com>
To:	"Eric Dumazet" <eric.dumazet@...il.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 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.

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