Re: [PATCH v5 2/2] nvme-tcp: allow setting per-queue io_cpu through sysfs

[Saravanan D]

On Wed, Oct 21, 2026 at 10:19:37AM +0200, Daniel Wagner wrote:
[...]
> There was a lot of discussion during Linux Plumbers on how to configure
> a system for the isolcpus case at runtime. From what I understand, the
> preferred interface for this is cgroups. Hence, pinning the CPU for this
> work is likely a target for it, though I don't think there is a need to
> figure it out right now. I just wanted to highlight this point.

Thanks for the pointer. I see the two as layers. cgroups decide which
CPUs a tenant owns. io_cpu then places a queue's socket work inside
that set. Today our control plane writes it, and a cgroup aware tool
could write it later. So io_cpu would not need to change if the
isolcpus configuration moves to cgroups.

On your earlier isolcpus point, the store only requires the cpu to be
online, so a queue can be pinned to an isolated cpu at runtime, for
example one that belongs to the VM issuing the I/O, even though blk-mq
leaves isolated cpus out of the hardware context masks.

> However, to make this truly user-friendly, I think nvme-cli should be
> extended so it is aware of this and can configure it directly. I've
> merged Nilay's --nr-io-queues patches, so this is the natural next
> feature nvme-cli should support; see commit:
>
> e170d6985797 ("news: document the use of --nr-io-queues during nvme connect")

Agreed. Once the ABI settles I'll add nvme-cli support to show and set
io_cpu per queue, following the --nr-io-queues work you merged.

> I would also really like to have a blktest for this as well.

I'll write one and post it alongside v6. It will use nvmet tcp over
loopback and check that

  - io_cpu reads and writes work and invalid values are rejected
  - an assignment survives a controller reset
  - the queue directories follow the queue count as it shrinks and grows
  - deleting the controller while io_cpu is written is safe

Thanks,
Saravanan D.