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

[Christoph Hellwig <hch@lst.de>]

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?

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