public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: Chuyi Zhou <zhouchuyi@bytedance.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
	andrii@kernel.org, martin.lau@kernel.org, tj@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 4/6] bpf: Introduce css_descendant open-coded iterator kfuncs
Date: Fri, 15 Sep 2023 19:57:46 +0800	[thread overview]
Message-ID: <8f27e07e-e23c-af80-90eb-b1123e1f68cd@bytedance.com> (raw)
In-Reply-To: <CAEf4BzY4qabpk3SD-GA5n5++REcXCxTtA4ythsR9HKHtGi33xA@mail.gmail.com>

Hello.

在 2023/9/15 07:26, Andrii Nakryiko 写道:
> On Tue, Sep 12, 2023 at 12:02 AM Chuyi Zhou <zhouchuyi@bytedance.com> wrote:
>>
>> This Patch adds kfuncs bpf_iter_css_{pre,post}_{new,next,destroy} which
>> allow creation and manipulation of struct bpf_iter_css in open-coded
>> iterator style. These kfuncs actually wrapps css_next_descendant_{pre,
>> post}. BPF programs can use these kfuncs through bpf_for_each macro for
>> iteration of all descendant css under a root css.
>>
>> Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com>
>> ---
>>   include/uapi/linux/bpf.h       |  8 +++++
>>   kernel/bpf/helpers.c           |  6 ++++
>>   kernel/bpf/task_iter.c         | 53 ++++++++++++++++++++++++++++++++++
>>   tools/include/uapi/linux/bpf.h |  8 +++++
>>   tools/lib/bpf/bpf_helpers.h    | 12 ++++++++
>>   5 files changed, 87 insertions(+)
>>
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index befa55b52e29..57760afc13d0 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -7326,4 +7326,12 @@ struct bpf_iter_process {
>>          __u64 __opaque[1];
>>   } __attribute__((aligned(8)));
>>
>> +struct bpf_iter_css_pre {
>> +       __u64 __opaque[2];
>> +} __attribute__((aligned(8)));
>> +
>> +struct bpf_iter_css_post {
>> +       __u64 __opaque[2];
>> +} __attribute__((aligned(8)));
>> +
>>   #endif /* _UAPI__LINUX_BPF_H__ */
>> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
>> index 9b7d2c6f99d1..ca1f6404af9e 100644
>> --- a/kernel/bpf/helpers.c
>> +++ b/kernel/bpf/helpers.c
>> @@ -2510,6 +2510,12 @@ BTF_ID_FLAGS(func, bpf_iter_css_task_destroy, KF_ITER_DESTROY)
>>   BTF_ID_FLAGS(func, bpf_iter_process_new, KF_ITER_NEW)
>>   BTF_ID_FLAGS(func, bpf_iter_process_next, KF_ITER_NEXT | KF_RET_NULL)
>>   BTF_ID_FLAGS(func, bpf_iter_process_destroy, KF_ITER_DESTROY)
>> +BTF_ID_FLAGS(func, bpf_iter_css_pre_new, KF_ITER_NEW)
>> +BTF_ID_FLAGS(func, bpf_iter_css_pre_next, KF_ITER_NEXT | KF_RET_NULL)
>> +BTF_ID_FLAGS(func, bpf_iter_css_pre_destroy, KF_ITER_DESTROY)
>> +BTF_ID_FLAGS(func, bpf_iter_css_post_new, KF_ITER_NEW)
>> +BTF_ID_FLAGS(func, bpf_iter_css_post_next, KF_ITER_NEXT | KF_RET_NULL)
>> +BTF_ID_FLAGS(func, bpf_iter_css_post_destroy, KF_ITER_DESTROY)
>>   BTF_ID_FLAGS(func, bpf_dynptr_adjust)
>>   BTF_ID_FLAGS(func, bpf_dynptr_is_null)
>>   BTF_ID_FLAGS(func, bpf_dynptr_is_rdonly)
>> diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c
>> index 9d1927dc3a06..8963fc779b87 100644
>> --- a/kernel/bpf/task_iter.c
>> +++ b/kernel/bpf/task_iter.c
>> @@ -880,6 +880,59 @@ __bpf_kfunc void bpf_iter_process_destroy(struct bpf_iter_process *it)
>>   {
>>   }
>>
>> +struct bpf_iter_css_kern {
>> +       struct cgroup_subsys_state *root;
>> +       struct cgroup_subsys_state *pos;
>> +} __attribute__((aligned(8)));
>> +
>> +__bpf_kfunc int bpf_iter_css_pre_new(struct bpf_iter_css_pre *it,
>> +               struct cgroup_subsys_state *root)
> 
> similar to my comment on previous patches, please see
> kernel/bpf/cgroup_iter.c for iter/cgroup iterator program. Let's stay
> consistent. We have one iterator that accepts parameters defining
> iteration order and starting cgroup. Unless there are some technical
> reasons we can't follow similar approach with this open-coded iter,
> let's use the same approach. We can even reuse
> BPF_CGROUP_ITER_DESCENDANTS_PRE, BPF_CGROUP_ITER_DESCENDANTS_POST,
> BPF_CGROUP_ITER_ANCESTORS_UP enums.
> 

I know your concern. It would be nice if we keep consistent with 
kernel/bpf/cgroup_iter.c

But this patch actually want to support iterating css 
(cgroup_subsys_state) not cgroup (css is more low lever).
With css_iter we can do something like 
"for_each_mem_cgroup_tree/cpuset_for_each_descendant_pre"
in BPF Progs which is hard for cgroup_iter. In the future we can use 
this iterator to plug some customizable policy in other resource control 
system.

BTW, what I did in RFC actually very similar with the approach of 
cgroup_iter. 
(https://lore.kernel.org/all/20230827072057.1591929-4-zhouchuyi@bytedance.com/).

Thanks.

  reply	other threads:[~2023-09-15 11:57 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-12  7:01 [PATCH bpf-next v2 0/6] Add Open-coded process and css iters Chuyi Zhou
2023-09-12  7:01 ` [PATCH bpf-next v2 1/6] cgroup: Prepare for using css_task_iter_*() in BPF Chuyi Zhou
2023-09-18 20:42   ` Tejun Heo
2023-09-12  7:01 ` [PATCH bpf-next v2 2/6] bpf: Introduce css_task open-coded iterator kfuncs Chuyi Zhou
2023-09-12 17:13   ` Alexei Starovoitov
2023-09-13 14:02     ` Chuyi Zhou
2023-09-12 19:57   ` Martin KaFai Lau
2023-09-13  4:56     ` Chuyi Zhou
2023-09-14 23:26   ` Andrii Nakryiko
2023-09-12  7:01 ` [PATCH bpf-next v2 3/6] bpf: Introduce process open coded " Chuyi Zhou
2023-09-14 23:26   ` Andrii Nakryiko
2023-09-15  4:48     ` Chuyi Zhou
2023-09-15 15:03     ` Chuyi Zhou
2023-09-15 20:37       ` Andrii Nakryiko
2023-09-16 14:03         ` Chuyi Zhou
2023-09-19 23:30           ` Andrii Nakryiko
2023-09-20 12:20             ` Chuyi Zhou
2023-09-12  7:01 ` [PATCH bpf-next v2 4/6] bpf: Introduce css_descendant open-coded " Chuyi Zhou
2023-09-13  7:25   ` kernel test robot
2023-09-13  9:02   ` kernel test robot
2023-09-13  9:13   ` kernel test robot
2023-09-14 23:26   ` Andrii Nakryiko
2023-09-15 11:57     ` Chuyi Zhou [this message]
2023-09-15 20:25       ` Andrii Nakryiko
2023-09-12  7:01 ` [PATCH bpf-next v2 5/6] bpf: teach the verifier to enforce css_iter and process_iter in RCU CS Chuyi Zhou
2023-09-13 13:53   ` Chuyi Zhou
2023-09-14  8:56     ` Chuyi Zhou
2023-09-14 23:26       ` Andrii Nakryiko
2023-09-15  5:46         ` [External] " Chuyi Zhou
2023-09-15 20:23           ` Andrii Nakryiko
2023-09-14 23:26   ` Andrii Nakryiko
2023-09-12  7:01 ` [PATCH bpf-next v2 6/6] selftests/bpf: Add tests for open-coded task and css iter Chuyi Zhou
2023-09-12  7:11 ` [PATCH bpf-next v2 0/6] Add Open-coded process and css iters Chuyi Zhou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8f27e07e-e23c-af80-90eb-b1123e1f68cd@bytedance.com \
    --to=zhouchuyi@bytedance.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox