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

[Christoph Hellwig <hch@lst.de>]

On Thu, Jun 25, 2026 at 03:27:22PM -0600, Surabhi Gogte wrote:
> -static int nvme_rdma_alloc_io_queues(struct nvme_rdma_ctrl *ctrl)
> +static int nvme_rdma_setup_io_queues(struct nvme_rdma_ctrl *ctrl, unsigned int first,

Overly long line.

> +		unsigned int last, size_t queue_size)
>  {
> +	ASYNC_DOMAIN_EXCLUSIVE(queue_domain);
> +	struct nvme_rdma_setup_ctx *ctxs;
> +	int nr_queues = last - first;
> +	int err = 0, i, ret;
>  
> +	ctxs = kmalloc_array(nr_queues, sizeof(*ctxs), GFP_KERNEL);

This should use kmalloc_objs in the brave new world.

> +	if (!ctxs)
>  		return -ENOMEM;
>  
> +	for (i = 0; i < nr_queues; i++) {
> +		struct nvme_rdma_queue *queue = &ctrl->queues[first + i];
> +
> +		queue->ctrl = ctrl;
> +		queue->queue_size = queue_size;
> +
> +		ctxs[i].queue = queue;
> +		ctxs[i].err = &err;
> +		async_schedule_domain(nvme_rdma_setup_queue_async, &ctxs[i],
> +				&queue_domain);
>  	}
>  
> +	async_synchronize_full_domain(&queue_domain);
> +	kfree(ctxs);

It would nice if the async domain had a way to do the error propagation.
Well, that would be a nice follow on if you're interested.

Talking about follow ons:  do you plan to do a similar change
to nvme-tcp?  It would be great to keep the setup path for
both in sync.