netdev - Re: [PATCH 10/13] bnx2x: Set default value of num

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]

Message-ID: <1271657181.27125.20.camel@lb-tlvb-eilong.il.broadcom.com>
Date:	Mon, 19 Apr 2010 09:06:21 +0300
From:	"Eilon Greenstein" <eilong@...adcom.com>
To:	"David Miller" <davem@...emloft.net>
cc:	"Vladislav Zolotarov" <vladz@...adcom.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Dmitry Kravkov" <dmitry@...adcom.com>
Subject: Re: [PATCH 10/13] bnx2x: Set default value of num_queues to 1
 on 32-bit platforms

On Sun, 2010-04-18 at 21:10 -0700, David Miller wrote:
> From: "Vladislav Zolotarov" <vladz@...adcom.com>
> Date: Sun, 18 Apr 2010 17:50:24 +0300
> 
> > The default was changed to save memory on 32bits systems.
> > 
> > Author: Dmitry Kravkov <dmitry@...adcom.com>
> > Signed-off-by: Dmitry Kravkov <dmitry@...adcom.com>
> > Signed-off-by: Vladislav Zolotarov <vladz@...adcom.com>
> > Signed-off-by: Eilon Greenstein <eilong@...adcom.com>
> 
> This is absolutely rediculious.
> 
> There is no reason in the world to restrict multiqueue to only 64-bit
> systems.
> 
> If there is a memory allocation issue, fix that!  Is it vmalloc() space
> usage?

Yes - running low on vmalloc is the reason. This patch does not restrict
the usage of multi queue on 32bits - it is just changing the default
queues values from the number of available CPUs to 1. If the user will
use another value, it will work as before.

We encounter few issues were a 32bit kernel was installed on a
multi-core platform and the driver allocated "too many" queues. One way
to go is to limit the queue size and the other is the number of queues -
leaving it as is caused issues due to running low on kernel virtual
memory so a change was needed.

Dave, what is your preference:
- re-submitting this patch with a proper description?
- limit the size of each queue?
- other?

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