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

On Thu, 20 Aug 2026 17:39:48 +0200 Daniel Wagner <[email protected]> wrote:
> FWIW, from past experience if this gets accepted, it is most likely not
> the last policy controlling knob which is needed. I see this somewhat
> orthogonal to io_policy options. Thus my question should this user
> interface be just a bool or should we have something more future proof
> here?

I agree with you, wq_unbound already exists as a boolean and this
patch introduces io_cpu_adopt as a second one, which is why I had
to introduce a precedence rule so that wq_unbound wins when both
are set. Adding more such behaviors as separate bools would only
multiply these precedence rules.

So rather than a bool, we can consider io_cpu to be its own policy
knob which is orthogonal to io_policy which primarily decides
which path the I/O takes. io_cpu=<policy> decides for a given
connection's queue which host cpu will perform the socket work,
with values such as default, adopt and unbound.

On the same theme, the one heuristic in this v2 patch is the re-arm
idle time, which could be surfaced as io_cpu_readopt_idle=<sec> to
become configurable.

I am very new to nvme-tcp and I dont have any strong opinions on
how to make the contribution future proof and reduce burden for
nvme maintainers.

Christoph asked me in v1 to move the knob from a module parameter
to a per controller connect option, so if you and other nvme
maintainers have a preference, I am willing to consider the
interface before v3.

Thanks for your review.

Saravanan D.