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

["Michal Koutný" <mkoutny@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]

On Wed, Sep 23, 2026 at 09:34:48PM -0700, peng yu <yupeng0921@gmail.com> 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.)

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 [*].)

Thanks,
Michal

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]