netdev - Re: [RFC] bnx2x: Insane RX rings

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] [day] [month] [year] [list]

Message-Id: <20100910.094220.220056217.davem@davemloft.net>
Date:	Fri, 10 Sep 2010 09:42:20 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	eilong@...adcom.com
Cc:	rick.jones2@...com, ole@....pl, eric.dumazet@...il.com,
	netdev@...r.kernel.org
Subject: Re: [RFC] bnx2x: Insane RX rings

From: "Eilon Greenstein" <eilong@...adcom.com>
Date: Fri, 10 Sep 2010 14:16:14 +0300

> There are few factors that can be considered when scaling the ring
> sizes:
> - Number of queues per device
> - Number of devices
> - Available amount of memory
> - Others...
> 
> I'm thinking about adding a factor only according to the number of
> queues - this will still cause issues for systems with many ports. Does
> that sound reasonable or not enough? Do you think the number of devices
> or even the amount of free memory should be considered?

I think scaling based upon the number of queues is a good place
to start.

Multi-port is less of an issue.  The problem we really care about is
stemming from the fact that the same exact port will require more
memory than another one simply because it has more queues active.

I would even argue that this is a zero sum thing to do, because
since the traffic ought to be distributed, you have enough buffers
to handle the load.

Of course I understand that a certain level of buffering is necessary
even on a per-queue level with many queues active, so if you scale
based upon the number of queues but then enforce a minimum (something
like 128 entries) that would be a reasonable thing to do.

Thanks for looking into this 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