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

[Saravanan D]

On Sat, 12 Sep 2026 00:11:18 +0300 Sagi Grimberg <sagi@xxxxxxxxxxx> wrote:
> No need for NVME_TCP_Q_IO_CPU_USER flag and restoring to the original
> connect time selection. -1 would mean WORK_CPU_UNBOUND. In fact lets
> allow this file to access "unbound" string (same as -1). I don't think
> we need to restore the connect time selection, the user who touches
> these settings is obviously interested to be in control.

Noted. The next version will accept a cpu number, -1 or the string "unbound",
with -1 and "unbound" setting io_cpu to WORK_CPU_UNBOUND.

> I think that the queue accounting is something we'd do anyways,
> regardless of how the queue is set. It just represents the io_cpu
> spread across cpu cores.

Agreed, the accounting applies regardless of whether the io_cpu came from
the driver's selection or from the control plane.

> I am wandering if it is time to introduce the core nvme queue:
> struct nvme_queue {
>          struct kobject        kobj;
>          unsigned int          qid;
>          u64                          flags;
> };
>
> And have the transport queue embed it:
> struct nvme_tcp_queue {
>          struct nvme_queue        nvmeq;
>          ....
> };
>
> I suspect it will allow for better abstractions.

This works for me, and it settles where the queues/<qid>/ kobject
lives. As Nilay pointed out the nvme_queue name is taken by the PCI
driver, so the common struct needs another name.

One clarification for the reconnect path. You suggested earlier that a
user assigned io_cpu should not change across reconnects. Without a
flag the driver cannot tell a user assigned io_cpu from its own pick
when it reconnects, since both are just a cpu number. If the
assignment should still persist, would you consider tracking it as a bit
in the flags of core nvme queue struct ?

I will wait for Keith and Christoph before spinning the next version.

Thanks,
Saravanan D.