[PATCH net-next v2] net: mana: Set default number of queues to 16

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.

Signed-off-by: Long Li <longli@microsoft.com>
---
v2:
  - Updated commit message to clarify that the actual number of queues
    may be lower if it exceeds the hardware reported limit.

 drivers/net/ethernet/microsoft/mana/mana_en.c | 3 ++-
 include/net/mana/mana.h                       | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index 49c65cc1697c..b39e8b920791 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c

@@ -3357,7 +3357,8 @@ static int mana_probe_port(struct mana_context *ac, int port_idx,
 	apc->ac = ac;
 	apc->ndev = ndev;
 	apc->max_queues = gc->max_num_queues;
-	apc->num_queues = gc->max_num_queues;
+	/* Use MANA_DEF_NUM_QUEUES as default, still honoring the HW limit */
+	apc->num_queues = min(gc->max_num_queues, MANA_DEF_NUM_QUEUES);
 	apc->tx_queue_size = DEF_TX_BUFFERS_PER_QUEUE;
 	apc->rx_queue_size = DEF_RX_BUFFERS_PER_QUEUE;
 	apc->port_handle = INVALID_MANA_HANDLE;

diff --git a/include/net/mana/mana.h b/include/net/mana/mana.h
index 3336688fed5e..96d21cbbdee2 100644
--- a/include/net/mana/mana.h
+++ b/include/net/mana/mana.h

@@ -1007,6 +1007,7 @@ struct mana_deregister_filter_resp {
 #define STATISTICS_FLAGS_TX_ERRORS_GDMA_ERROR		0x0000000004000000
 
 #define MANA_MAX_NUM_QUEUES 64
+#define MANA_DEF_NUM_QUEUES 16
 
 #define MANA_SHORT_VPORT_OFFSET_MAX ((1U << 8) - 1)
 

-- 
2.43.0

Hello:

This patch was applied to netdev/net-next.git (main)
by Paolo Abeni [off-list ref]:

On Mon, 23 Mar 2026 12:49:25 -0700 you 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.

Signed-off-by: Long Li <longli@microsoft.com>

[...]

Here is the summary with links:
  - [net-next,v2] net: mana: Set default number of queues to 16
    https://git.kernel.org/netdev/net-next/c/45b2b84ac6fd

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

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.

On Mon, 23 Mar 2026 12:49:25 -0700 Long Li wrote:

quoted

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

On Fri, 27 Mar 2026 04:00:31 +0000 Long Li wrote:

  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.

mlx4 is a bit ancient. And mlx5 does the wrong thing, which is why 
I'm so sensitive to this issue :(

  Do you want me to send a v2?

Please send a follow up, let's leave this patch be and make an
incremental change. 

Thanks!

On Fri, 27 Mar 2026 04:00:31 +0000 Long Li wrote:

quoted

  We considered netif_get_num_default_rss_queues() but chose a fixed

default based on our performance testing. On Azure VMs, typical

quoted

  workloads plateau at around 16 queues - adding more queues beyond that

doesn't improve throughput but increases memory usage and

quoted

  interrupt overhead.

  netif_get_num_default_rss_queues() would return 32-64 on large VMs

(64-128 vCPUs), which wastes resources without benefit.

quoted

  That said, I agree that completely ignoring the core-based heuristic isn't

ideal for consistency. One option is to use

quoted

  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

quoted

  large VMs don't over-allocate. Something like:

   apc->num_queues = min(netif_get_num_default_rss_queues(),

MANA_DEF_NUM_QUEUES);

quoted

   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.

mlx4 is a bit ancient. And mlx5 does the wrong thing, which is why I'm so
sensitive to this issue :(

quoted

  Do you want me to send a v2?

Please send a follow up, let's leave this patch be and make an incremental
change.

Thanks!

I will send a follow-up patch.

Thanks,
Long