On Sat, Sep 23, 2023 at 12:52 AM Tejun Heo <tj@xxxxxxxxxx> wrote: > > Hello, > > On Fri, Sep 22, 2023 at 11:28:38AM +0000, Yafang Shao wrote: > > - bpf_cgroup_id_from_task_within_controller > > Retrieves the cgroup ID from a task within a specific cgroup controller. > > - bpf_cgroup_acquire_from_id_within_controller > > Acquires the cgroup from a cgroup ID within a specific cgroup controller. > > - bpf_cgroup_ancestor_id_from_task_within_controller > > Retrieves the ancestor cgroup ID from a task within a specific cgroup > > controller. > > > > The advantage of these new BPF kfuncs is their ability to abstract away the > > complexities of cgroup hierarchies, irrespective of whether they involve > > cgroup1 or cgroup2. > > I'm afraid this is more likely to bring the unnecessary complexities of > cgroup1 into cgroup2. I concur with the idea that we should avoid introducing the complexities of cgroup1 into cgroup2. Which specific change do you believe might introduce these complexities into cgroup2? Is it the modification within task_under_cgroup_hierarchy() or cgroup_get_from_id()? In fact, we have the option to utilize bpf_cgroup_ancestor_id_from_task_within_controller() as a substitute for bpf_task_under_cgroup(), which allows us to sidestep the need for changes within task_under_cgroup_hierarchy() altogether. > > > In the future, we may expand controller-based support to other BPF > > functionalities, such as bpf_cgrp_storage, the attachment and detachment > > of cgroups, skb_under_cgroup, and more. > > I'm okay with minor / trivial quality of life improvements to cgroup1 but > this goes much beyond that and is starting to complications to cgroup2 > users, which I think is a pretty bad idea long term. I'm afraid I'm gonna > have to nack this approach. > > Thanks. > > -- > tejun -- Regards Yafang
