BPF List
 help / color / mirror / Atom feed
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,
[...]

  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