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

On Sat, 22 Aug 2026 17:48:17 +0530 Nilay Shroff <[email protected]> wrote:
> My point was if we could instead make the queue-to-CPU mapping aware of
> the tenant's CPU partition when the controller is created [...] pass a
> CPU-placement hint/cpuset as part of the fabric connection setup [...]

Appreciate your time reviewing this patch and offering your suggestions.

You are right that a stable queue to CPU mapping has real advantages. It
is easier to reason about for NIC side steering and cache locality, and
where the CPU partition is known and fixed at connect time that is the
better design.

Our controllers do not fall under that category. They are host wide
and shared, the tenant VMs are namespaces under one multipath subsystem,
and the control plane creates, destroys and bin packs VMs continuously,
so a cpuset passed at connect would be stale as soon as the tenant mix
changes and could only be re-applied by reconnecting a controller many
live tenants depend on. Adoption needs no per tenant hint and follows that
churn on its own. I posted the concrete topology, 128 io queues over 384
CPUs with the straddling cpu_list groups and two live VM cpusets, in the
reply to Sagi.

The fleet operators who care about steal time already steer the NIC IRQs
and NAPI to a housekeeping CPU pool off the tenant cpusets, so network
processing does not land on tenant CPUs. That leaves the shared queue's
socket work, which this change pins to the submitting CPU so it stays
within the tenant's cpuset.

Thanks,
Saravanan D.