Re: [PATCH v3 2/2] nvme-rdma: parallelize I/O queue allocation and startup
From: Christoph Hellwig
Date: Fri Jun 26 2026 - 03:40:20 EST
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.