> On Mon, 23 Mar 2026 12:49:25 -0700 Long Li wrote: > > Set the default number of queues per vPort to MANA_DEF_NUM_QUEUES > > (16), as 16 queues can achieve optimal throughput for typical > > workloads. The actual number of queues may be lower if it exceeds the > > hardware reported limit. Users can increase the number of queues up to > > max_queues via ethtool if needed. > > Sorry we are a bit backlogged I didn't spot this in time (read: I'm planning > to > revert this unless proper explanation is provided) > > Could you explain why not use netif_get_num_default_rss_queues() ? > Having local driver innovations is a major PITA for users who deal with > heterogeneous envs.
Hi Jakub, We considered netif_get_num_default_rss_queues() but chose a fixed default based on our performance testing. On Azure VMs, typical workloads plateau at around 16 queues - adding more queues beyond that doesn't improve throughput but increases memory usage and interrupt overhead. netif_get_num_default_rss_queues() would return 32-64 on large VMs (64-128 vCPUs), which wastes resources without benefit. That said, I agree that completely ignoring the core-based heuristic isn't ideal for consistency. One option is to use netif_get_num_default_rss_queues() but clamp it to a maximum of MANA_DEF_NUM_QUEUES (16), so small VMs still get enough queues and large VMs don't over-allocate. Something like: apc->num_queues = min(netif_get_num_default_rss_queues(), MANA_DEF_NUM_QUEUES); apc->num_queues = min(apc->num_queues, gc->max_num_queues); For reference, it seems mlx4 does something similar - it caps at DEF_RX_RINGS (16) regardless of core count. Do you want me to send a v2? Thanks, Long
