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

[Sagi Grimberg]

On 11/09/2026 9:03, Saravanan D wrote:
> 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.

I agree with this approach.

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