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

[Surabhi Gogte (she/her)]

On Sat, Sep 5, 2026 at 3:30 PM Sagi Grimberg <sagi@xxxxxxxxxxx> wrote:
>
> >>>                qid, queue->io_cpu);
> >>> @@ -1846,7 +1856,7 @@ static int nvme_tcp_alloc_queue(struct nvme_ctrl *nctrl, int qid,
> >>>                queue->cmnd_capsule_len = sizeof(struct nvme_command) +
> >>>                                                NVME_TCP_ADMIN_CCSZ;
> >>>
> >>> -     ret = sock_create_kern(current->nsproxy->net_ns,
> >>> +     ret = sock_create_kern(&init_net,
> >> I don't think we can just change this...
> > Passing init_net explicitly does change behavior on the synchronous connect
> > path. However, with queue allocation now moved into an async worker,
> > current->nsproxy->net_ns resolves to init_net in that context anyway, so
> > the initial connect path already loses the caller's netns regardless of
> > which argument is passed.
> >
> > If the goal is to actually preserve the caller's netns through the full
> > ctrl lifecycle - initial connect, reconnect, and error recovery; it can
> > be pinned at ctrl creation like:
> >
> >      nvme_tcp_alloc_ctrl():
> >              to_tcp_ctrl(ctrl)->net = get_net(current->nsproxy->net_ns);
> >
> >      nvme_tcp_free_ctrl():
> >              put_net(to_tcp_ctrl(ctrl)->net);
> >
> >      nvme_tcp_alloc_queue():
> >              sock_create_kern(to_tcp_ctrl(ctrl)->net, ...);
> >
> > This captures the caller's netns while still in userspace context, then
> > carries it through all async paths — so reconnect and error recovery
> > also honor the original netns rather than falling back to the kworker's
> > init_net.
> >
> > Is this approach preferred?
>
> Yes I think so

Alright, sent the patch with the implementation in v3