[PATCH RFC] nvme-tcp: allow multiple queues per hctx

[Keith Busch]

On Sun, Sep 06, 2026 at 03:04:42AM +0300, Sagi Grimberg wrote:
> I'm wandering if you guys can do the same --duplicate-connect and setting
> mpath with round-robin/queue-depth would get you the same result? Perhaps
> we can add this flag to nvme discover/connect-all for simplicity?

Thanks, I'll give that suggestion a try. I think I also need to tie the
"duplicate_connect" option to the module's wq_unbound option too.
 
> BTW, how many cpus/queues do you have in your test keith?

This experiment had 144 aarch64 CPUs (both host and target) and 128 IO
queues. I don't think I'll get to use those machines again anytime soon,
so any future experiments I run will be on less capable hardware.

> Moreover, I suspect that this is not a problem that is specific for
> nvme-tcp...

Yeah, that's a good thought. Generally I can saturate a link with one
IO queue on PCIe and RDMA transports, but I've tested some DPU vended
NVMe devices that need similar spreading to hit peak throughput.

If we need to make such things generic to support multiple users, I can
get a proposal ready to handle this in blk-mq. But if the multipath
duplicate connection option works out for the tcp transport, then I'm
not sure we'd have multiple users anymore.