Re: [RESEND PATCH v2 2/4] nvme-tcp: limit I/O queue count based on NIC queue count

[Jakub Kicinski <kuba@kernel.org>]

On Sat, 1 Aug 2026 19:08:05 +0530 Nilay Shroff wrote:
> > Looks like the userspace can already pass the preferred number of queues,
> > so in this case, why not do all this netdev resolution and queue
> > estimation in the userspace? Presumably most or the users you care
> > about always go through nvme-cli, right?  
> 
> Yes, userspace can already specify the preferred number of I/O queues, and nvme-cli
> provides an option to do so when creating an NVMe/TCP connection. However, choosing
> an appropriate value requires userspace to know both the number of online CPUs and
> the number of active TX/RX queues on the NIC used for the connection. Determining
> the latter also requires identifying the correct netdevice. That may involve a route
> lookup to determine the egress interface, particularly when the NVMe/TCP host and
> target are not on the same subnet.
> 
> So while this could be implemented in nvme-cli, it would require userspace to duplicate
> the logic needed to determine the actual netdevice and its current queue configuration.
> The intent of this change is to make the default queue selection automatic and avoid
> requiring users to determine and specify this topology manually.

In another message you said you add ntuple filters. So you _are_ doing
what you describe here as a problem. User space will know something we
don't know sooner or later, so you should just add the uAPI instead of
guessing in the kernel. BTW the queue count is likely to change after
all of user space boots, so if you run before whatever configures
queues for the machine in userspace you'll be using wrong counts.

> An explicitly specified "nr_io_queues" would still take precedence, so userspace can
> override the default when desired.
> 
> Just for the note, this change also follows the general approach used by nvme-pci, where
> the default number of I/O queues is constrained by both the number of possible CPUs and the
> queue resources available from the controller.

Not sure that maps well to networking. For TCP at least there will be 
a protocol stack that runs between the device queues and your queues. 
I guess that will depend on the network and the details of the
benchmark. But again, better to let the user tune to their workload
and machine.

Consider patch 1 nacked.