Re: [PATCH v3] nvmet: add cgroup_path to charge namespace I/O to a cgroup

[peng yu]

On Fri, Sep 25, 2026 at 2:59 AM Michal Koutný <mkoutny@xxxxxxxx> wrote:
>
> On Wed, Sep 23, 2026 at 09:34:48PM -0700, peng yu <yupeng0921@xxxxxxxxx> wrote:
> > The LVMs are close to my real use case, so I mentioned them to explain why
> > I need this feature.
> > When I write the testing code, I try to demonstrate the usage in a
> > simpler way, so
> > I use RAM devices.
> > Sorry for the inconsistency.
>
> Understood.
>
> > > > * The subsystems are exported to different users.
> > > > * We should provide each user a specific iops/bps quota, thus a noisy
> > > >   neighbor won't impact the performance of other logical volumes.
> > >
> > > Why cannot you place users into respective cgroups and configure
> > > appropriate per-device limits?
> >
> > I export the devices to nvme target. Per my understanding, the IOs are
> > controlled by kernel threads. The users are remote users, so I can't find
> > a way to put them in a local cgroup.
>
> I see, so the core of the issue is that local storage is exported
> remotely as NVME (over TCP) and you want to regulate IO on the local
> storage.
>
> 1) resembles loopback devices where original task's blkcg is transferred
>    to the kthread issuing actual IO. Is there any userspace component
>    fronting the clients? (whose cgroup the IO could be associated with.)

I'm using tcp-nvmeof. Per my understanding, there is no local userspace
component. The tcp-nvmeof listens on a tcp port in kernel space and
sends the IOs to the kernel block layer. So I can't find a userspace process
and assign a cgroup to it.


> 2) it also resembles FC app ids (blkcg_set_fc_appid()/blkcg_get_fc_appid())
>    Could you look at that whether a common concept could be used? (I
>    haven't looked into detail how the client side is handled [*].)

The FC app ids export the host side cgroup. But I want to not rely on the
host side information, limit the iops/bps on the target side. I'm not sure
what I can use about it. If I miss-understand anything, please let me know.

> Thanks,
> Michal
>
> [*] And now when I'm thinking about it, I'm not sure one can trust any
>     app ID that is sent over...