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

[Sagi Grimberg <sagi@grimberg.me>]

On 11/09/2026 9:03, Saravanan D wrote:
> On Thu, 10 Sep 2026 13:55:59 +0530 Nilay Shroff <nilay@linux.ibm.com> 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.

I agree with this approach.

I think that making nvme-core more "aware" of individual controller queues
is a good thing.