Re: [PATCH v2 2/2] nvme-tcp: parallelize I/O queue allocation and startup

On Mon, Aug 24, 2026 at 3:57 PM Surabhi Gogte <[email protected]> wrote:
>
> Similar to commit 2a8513091d2f ("nvme-rdma: parallelize I/O queue
> allocation and startup"), refactor nvme tcp I/O queue setup to use async
> API, combining allocation and startup into a single parallel operation
> per queue. This reduces connection and reconnection setup time when
> there are delays in establishing connections, which is especially
> important for high-core-count hosts.
>
> Key changes:
> - Use async API to facilitate parallel calls for io queue setup.
> - Add nvme_tcp_setup_ctx for propagating errors from async workers.
> - Remove nvme_tcp_start_io_queues() and __nvme_tcp_alloc_io_queues();
>   their logic is folded into nvme_tcp_setup_io_queues() and
>   nvme_tcp_configure_io_queues().
> - Allocate the io tag set before the queues so that the queue range is
>   known, and only set up the reconnect grow case if the queue count
>   actually increased.
> - Serialize the cpu scan and claim in nvme_tcp_set_queue_io_cpu() with a
>   spinlock, as concurrent callers would otherwise select the same cpu.
>   The per-cpu counters no longer need to be atomics.
> - Use init_net in nvme_tcp_alloc_queue() instead of the namespace of
>   current, which is no longer the connecting task once the allocation
>   runs from a worker. A controller is not guaranteed to be tied to a
>   namespace, as the reconnect and error recovery paths already run from
>   a workqueue in init_net.
>
> Testing on a 64-core host with 64 IO-queues shows nvme-tcp connection
> time reduced from 61ms to 11ms.
>
> Signed-off-by: Surabhi Gogte <[email protected]>
:~$
Reviewed-by: Randy Jennings <[email protected]>