Re: [PATCH 0/3] nvme-cli: NIC topology aware I/O queue scaling

On 21/08/2026 17:43, Nilay Shroff wrote:
> Hi,
>
> This series is a rework of the earlier patchset[1]. The main
> difference is that --nr-io-queues is now calculated in nvme-cli
> instead of in the kernel when establishing an NVMe/TCP connection.
>
> This rework is based on the feedback received[2] from the netdev
> maintainers.
>
> The original patchset determined the number of NVMe/TCP I/O queues
> based on the number of online CPUs and the number of hardware queues
> available on the NIC in kernel driver. This series moves that logic
> to nvme-cli.
>
> When --nr-io-queues is not explicitly specified, nvme-cli determines
> the egress netdev for the NVMe/TCP connection, retrieves its current
> hardware queue count, and calculates the default as:
>
> 	min(nr_hw_queues, num_online_cpus)

This looks reasonable Nilay.

I am wandering tho if we want to place some lower limit here.
For example, my laptop has a virtio device with 4 cpu cores and
a single combined ring:
--
$ lscpu | grep NUMA
NUMA node(s):                            1
NUMA node0 CPU(s):                       0-3
$ ethtool -l enp7s0
Channel parameters for enp7s0:
Pre-set maximums:
RX:        n/a
TX:        n/a
Other:        n/a
Combined:    1
Current hardware settings:
RX:        n/a
TX:        n/a
Other:        n/a
Combined:    1
--

It would be kinda annoying for me to now explicitly pass the nr-io-queues...
I am wandering if some sort of threshold make sense as what you are 
aiming for
is reducing the amount of queues for large cpu counts...