From: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx> Sent: Thursday, August 15, 2024 7:51 AM > > > From: Michael Kelley <mhklinux@xxxxxxxxxxx> Sent: Wednesday, August 14, 2024 7:57 PM > > > > From: Erni Sri Satya Vennela <ernis@xxxxxxxxxxxxxxxxxxx> Sent: Wednesday, August 14, 2024 9:59 AM > > > > > > Change VMBus channels macro (VRSS_CHANNEL_DEFAULT) in > > > Linux netvsc from 8 to 16 to align with Azure Windows VM > > > and improve networking throughput. > > > > > > For VMs having less than 16 vCPUS, the channels depend > > > on number of vCPUs. Between 16 to 32 vCPUs, the channels > > > default to VRSS_CHANNEL_DEFAULT. For greater than 32 vCPUs, > > > set the channels to number of physical cores / 2 as a way > > > to optimize CPU resource utilization and scale for high-end > > > processors with many cores. > > > Maximum number of channels are by default set to 64. > > > > Where in the code is this enforced? It's not part of this patch. It > > might be in rndis_set_subchannel(), where a value larger than > > 64 could be sent to the Hyper-V host, expecting that the Hyper-V > > host will limit it to 64. But netvsc driver code is declaring an array > > of size VRSS_CHANNEL_MAX, and there's nothing that guarantees > > that Hyper-V will always limit the channel count to 64. But maybe > > the netvsc driver enforces the limit of VRSS_CHANNEL_MAX in a > > place that I didn't immediately see in a quick look at the code. > > Yes, netvsc driver limits the num_chn to be <=64: > > #define VRSS_CHANNEL_MAX 64 > > /* This guarantees that num_possible_rss_qs <= num_online_cpus */ > num_possible_rss_qs = min_t(u32, num_online_cpus(), > rsscap.num_recv_que); > > net_device->max_chn = min_t(u32, VRSS_CHANNEL_MAX, num_possible_rss_qs); > > /* We will use the given number of channels if available. */ > net_device->num_chn = min(net_device->max_chn, device_info->num_chn); > OK, right. Thanks for the identifying the code for me. :-) Michael
