Re: [PATCH v3] nvme-tcp: allow setting per-queue io_cpu through sysfs

[Saravanan D]

On Thu, 10 Sep 2026 13:55:59 +0530 Nilay Shroff <nilay@xxxxxxxxxxxxx> wrote:
> I wonder if we should avoid introducing a transport-specific tcp_queues
> hierarchy here. io_cpu describes CPU placement of an NVMe I/O queue
> rather than something inherently specific to TCP, and other transports
> may have similar queue-level attributes in the future. Could we instead
> introduce a generic "queues/<qid>/" hierarchy under each NVMe
> controller, e.g.
>
>       /sys/class/nvme/nvmeX/queues/<qid>/
>
> and have transports expose queue-specific attributes there?

Thanks for your review.

A controller is backed by exactly one transport, so we can adopt the
transport-neutral /sys/class/nvme/nvmeX/queues/<qid>/ path with the
creation staying outside of core in nvme-tcp, which owns the queue
lifecycle. The core only knows ctrl->queue_count and never sees
individual queue lifecycle.

No other transport has queue attributes today, so a controller backed
by rdma will have no queues directory at all. The path appears only
where a transport populates it, and if another transport grows queue
attributes later, the creation can move into the core without any
ABI change.

> So could we expose this state through an additional read-only
> attribute alongside io_cpu, for example:
>
>      /sys/class/nvme/nvmeX/queues/<qid>/io_cpu
>      /sys/class/nvme/nvmeX/queues/<qid>/managed
>
> where "managed" indicates who currently owns the CPU placement. For
> example, "1" could indicate that io_cpu is driver-managed and "0"
> indicates it is managed by the control plane or user.

Agreed, I can add the read-only managed attribute, 1 when the io_cpu is
driver managed and 0 when the user assigned it in the next version.

Both suggestions look good to me. I will wait for Sagi or Keith to
weigh in before spinning v4.

Saravanan D.