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

[Sagi Grimberg <sagi@grimberg.me>]

>>>                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