All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Leon Hwang" <leon.hwang@linux.dev>
To: "Andrii Nakryiko" <andrii.nakryiko@gmail.com>
Cc: <bpf@vger.kernel.org>, <ast@kernel.org>, <andrii@kernel.org>,
	<daniel@iogearbox.net>, <olsajiri@gmail.com>,
	<yonghong.song@linux.dev>, <song@kernel.org>, <eddyz87@gmail.com>,
	<dxu@dxuuu.xyz>, <deso@posteo.net>, <kernel-patches-bot@fb.com>
Subject: Re: [PATCH bpf-next v3 2/6] bpf: Introduce BPF_F_CPU flag for percpu_array maps
Date: Tue, 26 Aug 2025 22:45:05 +0800	[thread overview]
Message-ID: <DCCFUUONZ808.1VU6LKUV5EMDQ@linux.dev> (raw)
In-Reply-To: <CAEf4BzZnCudvoFd9WJ+sTJ63txxWi=h_0FmVz2HKPXCeqp6zbQ@mail.gmail.com>

On Sat Aug 23, 2025 at 6:14 AM +08, Andrii Nakryiko wrote:
> On Thu, Aug 21, 2025 at 9:08 AM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> Introduce support for the BPF_F_ALL_CPUS flag in percpu_array maps to
>> allow updating values for all CPUs with a single value.
>>
>> Introduce support for the BPF_F_CPU flag in percpu_array maps to allow
>> updating value for specified CPU.
>>
>> This enhancement enables:
>>
>> * Efficient update values across all CPUs with a single value when
>>   BPF_F_ALL_CPUS is set for update_elem and update_batch APIs.
>> * Targeted update or lookup for a specified CPU when BPF_F_CPU is set.
>>
>> The BPF_F_CPU flag is passed via:
>>
>> * map_flags of lookup_elem and update_elem APIs along with embedded cpu
>>   field.
>> * elem_flags of lookup_batch and update_batch APIs along with embedded
>>   cpu field.
>>
>> Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
>> ---
>>  include/linux/bpf.h            |  3 +-
>>  include/uapi/linux/bpf.h       |  2 ++
>>  kernel/bpf/arraymap.c          | 56 ++++++++++++++++++++++++++--------
>>  kernel/bpf/syscall.c           | 27 ++++++++++------
>>  tools/include/uapi/linux/bpf.h |  2 ++
>>  5 files changed, 67 insertions(+), 23 deletions(-)
>>
>
> [...]
>
>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>> index 19f7f5de5e7dc..6251ac9bc7e42 100644
>> --- a/kernel/bpf/syscall.c
>> +++ b/kernel/bpf/syscall.c
>> @@ -131,9 +131,11 @@ bool bpf_map_write_active(const struct bpf_map *map)
>>         return atomic64_read(&map->writecnt) != 0;
>>  }
>>
>> -static u32 bpf_map_value_size(const struct bpf_map *map)
>> +static u32 bpf_map_value_size(const struct bpf_map *map, u64 flags)
>>  {
>> -       if (map->map_type == BPF_MAP_TYPE_PERCPU_HASH ||
>> +       if (map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY && (flags & (BPF_F_CPU | BPF_F_ALL_CPUS)))
>> +               return round_up(map->value_size, 8);
>
> this doesn't depend on the PERCPU_ARRAY map type, right? Any map for
> which we allowed BPF_F_CPU or BPF_F_ALL_CPUS would use this formula?
> (and if map doesn't support those flags, you should have filtered that
> out earlier, no?) So maybe add this is first separate condition before
> all this map type specific logic?
>

Right.

I will remove this map type specific logic in next revision.

>> +       else if (map->map_type == BPF_MAP_TYPE_PERCPU_HASH ||
>>             map->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH ||
>>             map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY ||
>>             map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE)
>> @@ -314,7 +316,7 @@ static int bpf_map_copy_value(struct bpf_map *map, void *key, void *value,
>>             map->map_type == BPF_MAP_TYPE_LRU_PERCPU_HASH) {
>>                 err = bpf_percpu_hash_copy(map, key, value);
>>         } else if (map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY) {
>> -               err = bpf_percpu_array_copy(map, key, value);
>> +               err = bpf_percpu_array_copy(map, key, value, flags);
>>         } else if (map->map_type == BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE) {
>>                 err = bpf_percpu_cgroup_storage_copy(map, key, value);
>>         } else if (map->map_type == BPF_MAP_TYPE_STACK_TRACE) {
>> @@ -1656,12 +1658,19 @@ static void *___bpf_copy_key(bpfptr_t ukey, u64 key_size)
>>
>>  static int check_map_flags(struct bpf_map *map, u64 flags, bool check_flag)
>
> you are later moving this into bpf.h header, so do it in previous
> patch early on, less unnecessary code churn and easier to review
> actual changes to that function in subsequent patches
>

Ack.

Thanks,
Leon

[...]

  reply	other threads:[~2025-08-26 14:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-21 16:08 [PATCH bpf-next v3 0/6] Introduce BPF_F_CPU flag for percpu maps Leon Hwang
2025-08-21 16:08 ` [PATCH bpf-next v3 1/6] bpf: Introduce internal check_map_flags helper function Leon Hwang
2025-08-22 22:14   ` Andrii Nakryiko
2025-08-26 15:24     ` Leon Hwang
2025-08-26 22:50       ` Andrii Nakryiko
2025-08-21 16:08 ` [PATCH bpf-next v3 2/6] bpf: Introduce BPF_F_CPU flag for percpu_array maps Leon Hwang
2025-08-22 22:14   ` Andrii Nakryiko
2025-08-26 14:45     ` Leon Hwang [this message]
2025-08-21 16:08 ` [PATCH bpf-next v3 3/6] bpf: Introduce BPF_F_CPU flag for percpu_hash and lru_percpu_hash maps Leon Hwang
2025-08-22 22:14   ` Andrii Nakryiko
2025-08-26 15:14     ` Leon Hwang
2025-08-21 16:08 ` [PATCH bpf-next v3 4/6] bpf: Introduce BPF_F_CPU flag for percpu_cgroup_storage maps Leon Hwang
2025-08-21 16:08 ` [PATCH bpf-next v3 5/6] libbpf: Support BPF_F_CPU for percpu maps Leon Hwang
2025-08-22 22:20   ` Andrii Nakryiko
2025-08-26 15:35     ` Leon Hwang
2025-08-26 22:50       ` Andrii Nakryiko
2025-08-21 16:08 ` [PATCH bpf-next v3 6/6] selftests/bpf: Add cases to test BPF_F_CPU flag Leon Hwang

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=DCCFUUONZ808.1VU6LKUV5EMDQ@linux.dev \
    --to=leon.hwang@linux.dev \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=deso@posteo.net \
    --cc=dxu@dxuuu.xyz \
    --cc=eddyz87@gmail.com \
    --cc=kernel-patches-bot@fb.com \
    --cc=olsajiri@gmail.com \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.