Re: [PATCH] nvme-tcp: pin io_cpu to submitter cpu

[Saravanan D]

On Mon, 17 Aug 2026 09:57:44 +0200 Christoph Hellwig <hch@xxxxxx> wrote:

> On Wed, Aug 05, 2026 at 07:39:44PM -0700, Saravanan D wrote:
> > Adopt the submitting CPU of non passthrough requests as io_cpu. The
> > submitter is a member of the map group by construction, and the
> > nvme_tcp_cpu_queues accounting moves with each adoption. Passthrough
> > commands do not participate since the io queue Connect arrives from an
> > arbitrary group CPU via blk_mq_alloc_request_hctx(), so the first real
> > read or write decides.
>
> connect isn't the only passthrough command.  All your above reasoning
> would apply to at least user passthrough commands as well.  Maybe
> special casing connect is the better idea here?
>
Agreed. User passthrough commands are submitted from a real task on the
submitting CPU, so they should adopt like any other read or write.
Connect is the only passthrough command on an I/O queue that should
be skipped, since it is injected on an arbitrary CPU by
blk_mq_alloc_request_hctx().

For v2 I will drop the blk_rq_is_passthrough() guard and special case
connect.

        cmd = nvme_req(rq)->cmd;
        if (nvme_is_fabrics(cmd) &&
            cmd->fabrics.fctype == nvme_fabrics_type_connect)
                return;

so user passthrough I/O adopts normally.

> >
> > Queues outlive the workloads that submit through them, so adoption
> > re-arms after 30 seconds of queue quiet. An idle queue is reclaimed by
> > its next submitter, while a busy queue keeps a stable io_cpu and
> > cannot ping pong between two live submitters. Concurrent writers
> > on different CPUs serialize on a cmpxchg on io_cpu.
> >
> > The behavior is opt in via the new wq_adopt module parameter, default
> > off and runtime writable. wq_unbound takes precedence when both are
> > set.
>
> I think you want this as an option at queue connect time.  Any specific
> reason you picked the global module parameter?
>
>
No strong reason. I followed the wq_unbound precedent and the parameter
was handy to toggle at runtime while testing. An option at connect
time is the better fit as this falls under controller policy, so for
v2 I will add an NVMF_OPT_ fabrics option and gate on queue->ctrl->opts.
With this pivot, we can avoid flipping the policy on a live connection.

Thanks for the review.