On Fri, Aug 16, 2024 at 08:52:41AM -0700, Jakub Kicinski wrote: > 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); Due to hyper-threading, #of physical cores = online CPUs/2. Therefore, netif_get_num_default_rss_queues() returns #of physical cores/2 = online CPUs/4. In my testing, the throughput performance was similar for both the configurations even for higher SKUs.To utilize lesser CPU resources, will be using netif_get_num_default_rss_queues() for the next version of the patch.
