Messages in this thread | | | Date | Fri, 20 May 2022 17:58:47 -0700 | Subject | Re: [PATCH bpf-next v1 3/5] bpf: Introduce cgroup iter | From | Yonghong Song <> |
| |
On 5/20/22 2:49 PM, Hao Luo wrote: > Hi Tejun and Yonghong, > > On Fri, May 20, 2022 at 12:42 PM Hao Luo <haoluo@google.com> wrote: >> >> Hi Tejun and Yonghong, >> >> On Fri, May 20, 2022 at 9:45 AM Tejun Heo <tj@kernel.org> wrote: >>> On Fri, May 20, 2022 at 09:29:43AM -0700, Yonghong Song wrote: >>>> <various stats interested by the user> >>>> >>>> This way, user space can easily construct the cgroup hierarchy stat like >>>> cpu mem cpu pressure mem pressure ... >>>> cgroup1 ... >>>> child1 ... >>>> grandchild1 ... >>>> child2 ... >>>> cgroup 2 ... >>>> child 3 ... >>>> ... ... >>>> >>>> the bpf iterator can have additional parameter like >>>> cgroup_id = ... to only call bpf program once with that >>>> cgroup_id if specified. >> >> Yep, this should work. We just need to make the cgroup_id parameter >> optional. If it is specified when creating bpf_iter_link, we print for >> that cgroup only. If it is not specified, we iterate over all cgroups. >> If I understand correctly, sounds doable. >> > > Yonghong, I realized that seek() which Tejun has been calling out, can > be used to specify the target cgroup, rather than adding a new > parameter. Maybe, we can pass cgroup_id to seek() on cgroup bpf_iter, > which will instruct read() to return the corresponding cgroup's stats. > On the other hand, reading without calling seek() beforehand will > return all the cgroups.
Currently, seek is not supported for bpf_iter.
const struct file_operations bpf_iter_fops = { .open = iter_open, .llseek = no_llseek, .read = bpf_seq_read, .release = iter_release, };
But if seek() works, I don't mind to remove this restriction. But not sure what to seek. Do you mean to provide a cgroup_fd/cgroup_id as the seek() syscall parameter? This may work.
But considering we have parameterized example (map_fd) and in the future, we may have other parameterized bpf_iter (e.g., for one task). Maybe parameter-based approach is better.
> > WDYT?
| |