bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, bpf@vger.kernel.org, brouer@redhat.com
Subject: Re: [PATCH bpf-next v2 3/4] libbpf: Support configurable pinning of maps from BTF annotations
Date: Fri, 25 Oct 2019 14:32:03 +0200	[thread overview]
Message-ID: <20191025143203.7e8fd0b4@carbon> (raw)
In-Reply-To: <157192270077.234778.5965993521171571751.stgit@toke.dk>

On Thu, 24 Oct 2019 15:11:40 +0200
Toke Høiland-Jørgensen <toke@redhat.com> wrote:

> From: Toke Høiland-Jørgensen <toke@redhat.com>
> 
> This adds support to libbpf for setting map pinning information as part of
> the BTF map declaration. We introduce a version new
> bpf_object__map_pin_opts() function to pin maps based on this setting, as
> well as a getter and setter function for the pin information that callers
> can use after map load.
> 
> The pinning type currently only supports a single PIN_BY_NAME mode, where
> each map will be pinned by its name in a path that can be overridden, but
> defaults to /sys/fs/bpf.
> 
> The pinning options supports a 'pin_all' setting, which corresponds to the
> old bpf_object__map_pin() function with an explicit path. In addition, the
> function now defaults to just skipping over maps that are already
> pinned (since the previous commit started recording this in struct
> bpf_map). This behaviour can be turned off with the 'no_skip_pinned' option.
> 
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> ---
>  tools/lib/bpf/bpf_helpers.h |    6 ++
>  tools/lib/bpf/libbpf.c      |  134 ++++++++++++++++++++++++++++++++++---------
>  tools/lib/bpf/libbpf.h      |   26 ++++++++
>  tools/lib/bpf/libbpf.map    |    3 +
>  4 files changed, 142 insertions(+), 27 deletions(-)
> 
> diff --git a/tools/lib/bpf/bpf_helpers.h b/tools/lib/bpf/bpf_helpers.h
> index 2203595f38c3..0c7d28292898 100644
> --- a/tools/lib/bpf/bpf_helpers.h
> +++ b/tools/lib/bpf/bpf_helpers.h
> @@ -38,4 +38,10 @@ struct bpf_map_def {
>  	unsigned int map_flags;
>  };
>  
> +enum libbpf_pin_type {
> +	LIBBPF_PIN_NONE,
> +	/* PIN_BY_NAME: pin maps by name (in /sys/fs/bpf by default) */
> +	LIBBPF_PIN_BY_NAME,
> +};
> +
>  #endif
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 848e6710b8e6..179c9911458d 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -226,6 +226,7 @@ struct bpf_map {
>  	void *priv;
>  	bpf_map_clear_priv_t clear_priv;
>  	enum libbpf_map_type libbpf_type;
> +	enum libbpf_pin_type pinning;
>  	char *pin_path;
>  	bool pinned;
>  };
> @@ -1271,6 +1272,22 @@ static int bpf_object__init_user_btf_map(struct bpf_object *obj,
>  			}
>  			map->def.value_size = sz;
>  			map->btf_value_type_id = t->type;
> +		} else if (strcmp(name, "pinning") == 0) {
> +			__u32 val;
> +
> +			if (!get_map_field_int(map_name, obj->btf, def, m,
> +					       &val))
> +				return -EINVAL;
> +			pr_debug("map '%s': found pinning = %u.\n",
> +				 map_name, val);
> +
> +			if (val != LIBBPF_PIN_NONE &&
> +			    val != LIBBPF_PIN_BY_NAME) {
> +				pr_warning("map '%s': invalid pinning value %u.\n",
> +					   map_name, val);
> +				return -EINVAL;
> +			}
> +			map->pinning = val;
>  		} else {
>  			if (strict) {
>  				pr_warning("map '%s': unknown field '%s'.\n",
[...]

How does this prepare for being compatible with iproute2 pinning?

iproute2 have these defines (in include/bpf_elf.h):

 /* Object pinning settings */
 #define PIN_NONE                0
 #define PIN_OBJECT_NS           1
 #define PIN_GLOBAL_NS           2

I do know above strcmp(name, "pinning") look at BTF info 'name' and not
directly at the ELF struct for maps.  I don't know enough about BTF
(yet), but won't BTF automatically create a "pinning" info 'name' ???
(with above defines as content/values)

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

From above enum:
 LIBBPF_PIN_BY_NAME = 1 

iproute2 ELF map struct:

/* ELF map definition */
struct bpf_elf_map {
        __u32 type;
        __u32 size_key;
        __u32 size_value;
        __u32 max_elem;
        __u32 flags;
        __u32 id;
        __u32 pinning;
        __u32 inner_id;
        __u32 inner_idx;
};


  parent reply	other threads:[~2019-10-25 12:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24 13:11 [PATCH bpf-next v2 0/4] libbpf: Support automatic pinning of maps using 'pinning' BTF attribute Toke Høiland-Jørgensen
2019-10-24 13:11 ` [PATCH bpf-next v2 1/4] libbpf: Fix error handling in bpf_map__reuse_fd() Toke Høiland-Jørgensen
2019-10-25  2:46   ` Andrii Nakryiko
2019-10-24 13:11 ` [PATCH bpf-next v2 2/4] libbpf: Store map pin path and status in struct bpf_map Toke Høiland-Jørgensen
2019-10-25  3:00   ` Andrii Nakryiko
2019-10-24 13:11 ` [PATCH bpf-next v2 3/4] libbpf: Support configurable pinning of maps from BTF annotations Toke Høiland-Jørgensen
2019-10-24 13:25   ` Toke Høiland-Jørgensen
2019-10-25  3:19   ` Andrii Nakryiko
2019-10-25 12:32   ` Jesper Dangaard Brouer [this message]
2019-10-25 17:28     ` Andrii Nakryiko
2019-10-24 13:11 ` [PATCH bpf-next v2 4/4] libbpf: Add option to auto-pin maps when opening BPF object Toke Høiland-Jørgensen
2019-10-25  4:41   ` Andrii Nakryiko
2019-10-27 12:04     ` Toke Høiland-Jørgensen
2019-10-27 20:12       ` Andrii Nakryiko
2019-10-27 20:44         ` Toke Høiland-Jørgensen

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=20191025143203.7e8fd0b4@carbon \
    --to=brouer@redhat.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=kafai@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=toke@redhat.com \
    --cc=yhs@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;
as well as URLs for NNTP newsgroup(s).