netdev - Re: [PATCH v2] net: netvsc: Update default VMBus channels

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: <20240816085241.326978a6@kernel.org>
Date: Fri, 16 Aug 2024 08:52:41 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Haiyang Zhang <haiyangz@...rosoft.com>
Cc: Erni Sri Satya Vennela <ernis@...ux.microsoft.com>, Erni Sri Satya
 Vennela <ernis@...rosoft.com>, KY Srinivasan <kys@...rosoft.com>,
 "wei.liu@...nel.org" <wei.liu@...nel.org>, Dexuan Cui
 <decui@...rosoft.com>, "davem@...emloft.net" <davem@...emloft.net>,
 "edumazet@...gle.com" <edumazet@...gle.com>, "pabeni@...hat.com"
 <pabeni@...hat.com>, "linux-hyperv@...r.kernel.org"
 <linux-hyperv@...r.kernel.org>, "netdev@...r.kernel.org"
 <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] net: netvsc: Update default VMBus channels

On Thu, 15 Aug 2024 19:23:50 +0000 Haiyang Zhang wrote:
> Your suggestion on netif_get_num_default_rss_queues() is not ignored.
> We discussed internally on the formula we used for the num_chn, and
> chose a similar formula for higher number of vCPUs as in 
> netif_get_num_default_rss_queues().
> For lower number of vCPUs, we use the same default as Windows guests,
> because we don't want any potential regression.

Ideally you'd just use netif_get_num_default_rss_queues()
but the code is close enough to that, and I don't have enough
experience with the question of online CPUs vs physical CPUs.

I would definitely advise you to try this on real workloads.
While "iperf" looks great with a lot of rings, real workloads
suffer measurably from having more channels eating up memory
and generating interrupts.

But if you're confident with the online_cpus() / 2, that's fine.
You may be better off coding it up using max:

	dev_info->num_chn = max(DIV_ROUND_UP(num_online_cpus(), 2),
				VRSS_CHANNEL_DEFAULT);