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

[Nilay Shroff]

On 8/20/26 2:06 PM, Saravanan D wrote:
> nvme_tcp_set_queue_io_cpu() picks each queue's io_cpu at connect time,
> before any I/O exists, as the least loaded CPU in the queue's blk-mq
> map group, and all socket work then runs there for the connection's
> lifetime. On hosts that partition CPUs between pinned workloads a map
> group can straddle a partition boundary, so the pick can land one
> workload's socket processing on CPUs owned by another. On a 384 cpu
> multi tenant host with one VM driving ~1.1 GB/s of writes, 9% of
> nvme_tcp_io_work executions ran outside the submitting VM's cpuset,
> all on io_cpus of boundary straddling map groups, observed by the
> neighbor as steal time it did not cause.

It seems that here multi tenants shares the same NVMe/TCP controller.
Sp if the concern is CPU isolation between tenants, why are multiple
tenants sharing the same NVMe/TCP controller? Wouldn't a per-tenant
controller/connection provide better isolation and allow each controller's
queues to be mapped to the tenant's CPU set? If sharing a controller is
required, it would be useful to understand why.

Thanks,
--Nilay