From: Yonghong Song <yhs@fb.com>
To: Paul Chaignon <paul.chaignon@orange.com>,
"bpf@vger.kernel.org" <bpf@vger.kernel.org>
Cc: "paul.chaignon@gmail.com" <paul.chaignon@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>, Martin Lau <kafai@fb.com>,
Song Liu <songliubraving@fb.com>,
Andrii Nakryiko <andriin@fb.com>
Subject: Re: [PATCH bpf-next 1/3] bpf: Single-cpu updates for per-cpu maps
Date: Wed, 18 Dec 2019 19:10:38 +0000 [thread overview]
Message-ID: <377d5ad0-cf4f-4c8b-c23d-ed37dce4ad9f@fb.com> (raw)
In-Reply-To: <ec8fd77bb20881e7149f7444e731c510790191ce.1576673842.git.paul.chaignon@orange.com>
On 12/18/19 6:23 AM, Paul Chaignon wrote:
> Currently, userspace programs have to update the values of all CPUs at
> once when updating per-cpu maps. This limitation prevents the update of
> a single CPU's value without the risk of missing concurrent updates on
> other CPU's values.
>
> This patch allows userspace to update the value of a specific CPU in
> per-cpu maps. The CPU whose value should be updated is encoded in the
> 32 upper-bits of the flags argument, as follows. The new BPF_CPU flag
> can be combined with existing flags.
>
> bpf_map_update_elem(..., cpuid << 32 | BPF_CPU)
Some additional comments beyond Alexei's one.
>
> Signed-off-by: Paul Chaignon <paul.chaignon@orange.com>
> ---
> include/uapi/linux/bpf.h | 4 +++
> kernel/bpf/arraymap.c | 19 ++++++++-----
> kernel/bpf/hashtab.c | 49 ++++++++++++++++++++--------------
> kernel/bpf/local_storage.c | 16 +++++++----
> kernel/bpf/syscall.c | 17 +++++++++---
> tools/include/uapi/linux/bpf.h | 4 +++
> 6 files changed, 74 insertions(+), 35 deletions(-)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index dbbcf0b02970..2efb17d2c77a 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -316,6 +316,10 @@ enum bpf_attach_type {
> #define BPF_NOEXIST 1 /* create new element if it didn't exist */
> #define BPF_EXIST 2 /* update existing element */
> #define BPF_F_LOCK 4 /* spin_lock-ed map_lookup/map_update */
> +#define BPF_CPU 8 /* single-cpu update for per-cpu maps */
> +
> +/* CPU mask for single-cpu updates */
> +#define BPF_CPU_MASK 0xFFFFFFFF00000000ULL
BPF_F_CPU_MASK?
>
> /* flags for BPF_MAP_CREATE command */
> #define BPF_F_NO_PREALLOC (1U << 0)
> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> index f0d19bbb9211..a96e94696819 100644
> --- a/kernel/bpf/arraymap.c
> +++ b/kernel/bpf/arraymap.c
> @@ -302,7 +302,8 @@ static int array_map_update_elem(struct bpf_map *map, void *key, void *value,
> u32 index = *(u32 *)key;
> char *val;
>
> - if (unlikely((map_flags & ~BPF_F_LOCK) > BPF_EXIST))
> + if (unlikely((map_flags & ~BPF_CPU_MASK & ~BPF_F_LOCK &
> + ~BPF_CPU) > BPF_EXIST))
Maybe create a macro ARRAY_UPDATE_FLAG_MASK similar to existing
ARRAY_CREATE_FLAG_MASK? This will make a little easier to follow,
esp. we got three individual flags here.
There are possibly some other places as well below can be done
in a similar way.
> /* unknown flags */
> return -EINVAL;
>
> @@ -341,7 +342,7 @@ int bpf_percpu_array_update(struct bpf_map *map, void *key, void *value,
> int cpu, off = 0;
> u32 size;
>
> - if (unlikely(map_flags > BPF_EXIST))
> + if (unlikely((map_flags & ~BPF_CPU_MASK & ~BPF_CPU) > BPF_EXIST))
~(BPF_F_CPU_MASK | BPF_F_CPU) or create a macro for like
ARRAY_UPDATE_CPU_MASK for (BPF_F_CPU_MASK | BPF_F_CPU)?
> /* unknown flags */
> return -EINVAL;
>
> @@ -349,7 +350,7 @@ int bpf_percpu_array_update(struct bpf_map *map, void *key, void *value,
> /* all elements were pre-allocated, cannot insert a new one */
> return -E2BIG;
>
> - if (unlikely(map_flags == BPF_NOEXIST))
> + if (unlikely(map_flags & BPF_NOEXIST))
> /* all elements already exist */
> return -EEXIST;
>
> @@ -362,9 +363,15 @@ int bpf_percpu_array_update(struct bpf_map *map, void *key, void *value,
> size = round_up(map->value_size, 8);
> rcu_read_lock();
> pptr = array->pptrs[index & array->index_mask];
> - for_each_possible_cpu(cpu) {
> - bpf_long_memcpy(per_cpu_ptr(pptr, cpu), value + off, size);
> - off += size;
> + if (map_flags & BPF_CPU) {
> + bpf_long_memcpy(per_cpu_ptr(pptr, map_flags >> 32), value,
> + size);
> + } else {
> + for_each_possible_cpu(cpu) {
> + bpf_long_memcpy(per_cpu_ptr(pptr, cpu), value + off,
> + size);
> + off += size;
> + }
> }
> rcu_read_unlock();
> return 0;
> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index 22066a62c8c9..be45c7c4509f 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -695,12 +695,12 @@ static void free_htab_elem(struct bpf_htab *htab, struct htab_elem *l)
> }
>
> static void pcpu_copy_value(struct bpf_htab *htab, void __percpu *pptr,
> - void *value, bool onallcpus)
> + void *value, int cpuid)
> {
> - if (!onallcpus) {
> + if (cpuid == -1) {
Magic number -1 and -2 should be macros?
> /* copy true value_size bytes */
> memcpy(this_cpu_ptr(pptr), value, htab->map.value_size);
> - } else {
> + } else if (cpuid == -2) {
> u32 size = round_up(htab->map.value_size, 8);
> int off = 0, cpu;
>
> @@ -709,6 +709,10 @@ static void pcpu_copy_value(struct bpf_htab *htab, void __percpu *pptr,
[...]
next prev parent reply other threads:[~2019-12-18 19:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-18 14:22 [PATCH bpf-next 0/3] Single-cpu updates for per-cpu maps Paul Chaignon
2019-12-18 14:23 ` [PATCH bpf-next 1/3] bpf: " Paul Chaignon
2019-12-18 18:00 ` Alexei Starovoitov
2019-12-19 9:14 ` Paul Chaignon
2019-12-18 19:10 ` Yonghong Song [this message]
2019-12-19 0:49 ` Andrii Nakryiko
2019-12-18 14:23 ` [PATCH bpf-next 2/3] selftests/bpf: Tests for single-cpu updates of " Paul Chaignon
2019-12-18 14:23 ` [PATCH bpf-next 3/3] bpftool: Support single-cpu updates for " Paul Chaignon
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=377d5ad0-cf4f-4c8b-c23d-ed37dce4ad9f@fb.com \
--to=yhs@fb.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kafai@fb.com \
--cc=netdev@vger.kernel.org \
--cc=paul.chaignon@gmail.com \
--cc=paul.chaignon@orange.com \
--cc=songliubraving@fb.com \
/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