All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Alexei Starovoitov <ast@fb.com>,
	"David S . Miller" <davem@davemloft.net>
Cc: Daniel Wagner <daniel.wagner@bmw-carit.de>,
	Tom Zanussi <tom.zanussi@linux.intel.com>,
	Wang Nan <wangnan0@huawei.com>, He Kuang <hekuang@huawei.com>,
	Martin KaFai Lau <kafai@fb.com>,
	Brendan Gregg <brendan.d.gregg@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-team@fb.com
Subject: Re: [PATCH net-next 3/9] bpf: pre-allocate hash map elements
Date: Mon, 07 Mar 2016 12:08:08 +0100	[thread overview]
Message-ID: <56DD6118.7090608@iogearbox.net> (raw)
In-Reply-To: <1457315917-1970307-4-git-send-email-ast@fb.com>

On 03/07/2016 02:58 AM, Alexei Starovoitov wrote:
[...]
> ---
>   include/linux/bpf.h      |   1 +
>   include/uapi/linux/bpf.h |   3 +
>   kernel/bpf/hashtab.c     | 264 ++++++++++++++++++++++++++++++++++-------------
>   kernel/bpf/syscall.c     |   2 +-
>   4 files changed, 196 insertions(+), 74 deletions(-)

Shouldn't all other map types (like array) need something like this as well to
reserve this for their future flags?

   if (attr->map_flags)
     return ERR_PTR(-EINVAL);

> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 4b070827200d..c81efb10bbb5 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -37,6 +37,7 @@ struct bpf_map {
>   	u32 key_size;
>   	u32 value_size;
>   	u32 max_entries;
> +	u32 map_flags;

Just naming this 'flags' doesn't work due to the anonymous struct inside that
union, right? :/

>   	u32 pages;
>   	struct user_struct *user;
>   	const struct bpf_map_ops *ops;
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 6496f98d3d68..5eeb2ca9441e 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -101,12 +101,15 @@ enum bpf_prog_type {
>   #define BPF_NOEXIST	1 /* create new element if it didn't exist */
>   #define BPF_EXIST	2 /* update existing element */
>
> +#define BPF_F_NO_PREALLOC	(1ULL << 0)

Nit: Should better be (1U << 0) as map_flags are of __u32.

>   union bpf_attr {
>   	struct { /* anonymous struct used by BPF_MAP_CREATE command */
>   		__u32	map_type;	/* one of enum bpf_map_type */
>   		__u32	key_size;	/* size of key in bytes */
>   		__u32	value_size;	/* size of value in bytes */
>   		__u32	max_entries;	/* max number of entries in a map */
> +		__u32	map_flags;	/* prealloc or not */
>   	};
>
>   	struct { /* anonymous struct used by BPF_MAP_*_ELEM commands */

Thanks,
Daniel

  reply	other threads:[~2016-03-07 11:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-07  1:58 [PATCH net-next 0/9] bpf: hash map pre-alloc Alexei Starovoitov
2016-03-07  1:58 ` [PATCH net-next 1/9] bpf: prevent kprobe+bpf deadlocks Alexei Starovoitov
2016-03-07 10:07   ` Daniel Borkmann
2016-03-07  1:58 ` [PATCH net-next 2/9] bpf: introduce percpu_freelist Alexei Starovoitov
2016-03-07 10:33   ` Daniel Borkmann
2016-03-07 18:26     ` Alexei Starovoitov
2016-03-07  1:58 ` [PATCH net-next 3/9] bpf: pre-allocate hash map elements Alexei Starovoitov
2016-03-07 11:08   ` Daniel Borkmann [this message]
2016-03-07 18:29     ` Alexei Starovoitov
2016-03-07  1:58 ` [PATCH net-next 4/9] samples/bpf: make map creation more verbose Alexei Starovoitov
2016-03-07  1:58 ` [PATCH net-next 5/9] samples/bpf: move ksym_search() into library Alexei Starovoitov
2016-03-07  1:58 ` [PATCH net-next 6/9] samples/bpf: add map_flags to bpf loader Alexei Starovoitov
2016-03-07  1:58 ` [PATCH net-next 7/9] samples/bpf: test both pre-alloc and normal maps Alexei Starovoitov
2016-03-07  1:58 ` [PATCH net-next 8/9] samples/bpf: add bpf map stress test Alexei Starovoitov
2016-03-07  1:58 ` [PATCH net-next 9/9] samples/bpf: add map performance test Alexei Starovoitov

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=56DD6118.7090608@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=ast@fb.com \
    --cc=brendan.d.gregg@gmail.com \
    --cc=daniel.wagner@bmw-carit.de \
    --cc=davem@davemloft.net \
    --cc=hekuang@huawei.com \
    --cc=kafai@fb.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tom.zanussi@linux.intel.com \
    --cc=wangnan0@huawei.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 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.