bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.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>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	David Miller <davem@davemloft.net>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v3 3/4] libbpf: Add auto-pinning of maps when loading BPF objects
Date: Mon, 28 Oct 2019 11:24:42 -0700	[thread overview]
Message-ID: <CAEf4BzYoEPKNFnzOEAhhE2w=U11cYfTN4o_23kjzY4ByEt5y-g@mail.gmail.com> (raw)
In-Reply-To: <157220959873.48922.4763375792594816553.stgit@toke.dk>

On Sun, Oct 27, 2019 at 1:53 PM 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, to get automatic map pinning (and reuse) on 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.
>
> Since auto-pinning only does something if any maps actually have a
> 'pinning' BTF attribute set, we default the new option to enabled, on the
> assumption that seamless pinning is what most callers want.
>
> When a map has a pin_path set at load time, libbpf will compare the map
> pinned at that location (if any), and if the attributes match, will re-use
> that map instead of creating a new one. If no existing map is found, the
> newly created map will instead be pinned at the location.
>
> Programs wanting to customise the pinning can override the pinning paths
> using bpf_map__set_pin_path() before calling bpf_object__load() (including
> setting it to NULL to disable pinning of a particular map).
>
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> ---
>  tools/lib/bpf/bpf_helpers.h |    6 ++
>  tools/lib/bpf/libbpf.c      |  142 ++++++++++++++++++++++++++++++++++++++++++-
>  tools/lib/bpf/libbpf.h      |   11 +++
>  3 files changed, 154 insertions(+), 5 deletions(-)
>

[...]

>
> -static int bpf_object__init_maps(struct bpf_object *obj, bool relaxed_maps)
> +static int bpf_object__build_map_pin_paths(struct bpf_object *obj,
> +                                          const char *path)
> +{
> +       struct bpf_map *map;
> +
> +       if (!path)
> +               path = "/sys/fs/bpf";
> +
> +       bpf_object__for_each_map(map, obj) {
> +               char buf[PATH_MAX];
> +               int err, len;
> +
> +               if (map->pinning != LIBBPF_PIN_BY_NAME)
> +                       continue;

still think it's better be done from map definition parsing code
instead of a separate path, which will ignore most of maps anyways (of
course by extracting this whole buffer creation logic into a
function).


> +
> +               len = snprintf(buf, PATH_MAX, "%s/%s", path, bpf_map__name(map));
> +               if (len < 0)
> +                       return -EINVAL;
> +               else if (len >= PATH_MAX)

[...]

>         return 0;
>  }
>
> +static bool map_is_reuse_compat(const struct bpf_map *map,
> +                               int map_fd)

nit: this should fit on single line?

> +{
> +       struct bpf_map_info map_info = {};
> +       char msg[STRERR_BUFSIZE];
> +       __u32 map_info_len;
> +
> +       map_info_len = sizeof(map_info);
> +
> +       if (bpf_obj_get_info_by_fd(map_fd, &map_info, &map_info_len)) {
> +               pr_warn("failed to get map info for map FD %d: %s\n",
> +                       map_fd, libbpf_strerror_r(errno, msg, sizeof(msg)));
> +               return false;
> +       }
> +
> +       return (map_info.type == map->def.type &&
> +               map_info.key_size == map->def.key_size &&
> +               map_info.value_size == map->def.value_size &&
> +               map_info.max_entries == map->def.max_entries &&
> +               map_info.map_flags == map->def.map_flags &&
> +               map_info.btf_key_type_id == map->btf_key_type_id &&
> +               map_info.btf_value_type_id == map->btf_value_type_id);

If map was pinned by older version of the same app, key and value type
id are probably gonna be different, even if the type definition itself
it correct. We probably shouldn't check that?

> +}
> +
> +static int
> +bpf_object__reuse_map(struct bpf_map *map)
> +{
> +       char *cp, errmsg[STRERR_BUFSIZE];
> +       int err, pin_fd;
> +
> +       pin_fd = bpf_obj_get(map->pin_path);
> +       if (pin_fd < 0) {
> +               if (errno == ENOENT) {
> +                       pr_debug("found no pinned map to reuse at '%s'\n",
> +                                map->pin_path);
> +                       return 0;
> +               }
> +
> +               cp = libbpf_strerror_r(errno, errmsg, sizeof(errmsg));
> +               pr_warn("couldn't retrieve pinned map '%s': %s\n",
> +                       map->pin_path, cp);
> +               return -errno;

store errno locally


> +       }
> +
> +       if (!map_is_reuse_compat(map, pin_fd)) {
> +               pr_warn("couldn't reuse pinned map at '%s': "
> +                       "parameter mismatch\n", map->pin_path);
> +               close(pin_fd);
> +               return -EINVAL;
> +       }
> +
> +       err = bpf_map__reuse_fd(map, pin_fd);
> +       if (err) {
> +               close(pin_fd);
> +               return err;
> +       }
> +       map->pinned = true;
> +       pr_debug("reused pinned map at '%s'\n", map->pin_path);
> +
> +       return 0;
> +}
> +

[...]

> +enum libbpf_pin_type {
> +       LIBBPF_PIN_NONE,
> +       /* PIN_BY_NAME: pin maps by name (in /sys/fs/bpf by default) */
> +       LIBBPF_PIN_BY_NAME,
> +};
> +
>  LIBBPF_API int bpf_object__pin_maps(struct bpf_object *obj, const char *path);

pin_maps should take into account opts->auto_pin_path, shouldn't it?

Which is why I also think that auto_pin_path is bad name, because it's
not only for auto-pinning, it's a pinning root path, so something like
pin_root_path or just pin_root is better and less misleading name.



>  LIBBPF_API int bpf_object__unpin_maps(struct bpf_object *obj,
>                                       const char *path);
>

  reply	other threads:[~2019-10-28 18:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-27 20:53 [PATCH bpf-next v3 0/4] libbpf: Support automatic pinning of maps using 'pinning' BTF attribute Toke Høiland-Jørgensen
2019-10-27 20:53 ` [PATCH bpf-next v3 1/4] libbpf: Fix error handling in bpf_map__reuse_fd() Toke Høiland-Jørgensen
2019-10-27 20:53 ` [PATCH bpf-next v3 2/4] libbpf: Store map pin path and status in struct bpf_map Toke Høiland-Jørgensen
2019-10-28 18:24   ` Andrii Nakryiko
2019-10-29  9:01     ` Toke Høiland-Jørgensen
2019-10-29 18:02       ` Andrii Nakryiko
2019-10-29 18:36         ` Toke Høiland-Jørgensen
2019-10-27 20:53 ` [PATCH bpf-next v3 3/4] libbpf: Add auto-pinning of maps when loading BPF objects Toke Høiland-Jørgensen
2019-10-28 18:24   ` Andrii Nakryiko [this message]
2019-10-29  9:30     ` Toke Høiland-Jørgensen
2019-10-29 18:13       ` Andrii Nakryiko
2019-10-29 18:44         ` Toke Høiland-Jørgensen
2019-10-29 18:56           ` Andrii Nakryiko
2019-10-29 19:07             ` Toke Høiland-Jørgensen
2019-10-27 20:53 ` [PATCH bpf-next v3 4/4] selftests: Add tests for automatic map pinning Toke Høiland-Jørgensen
2019-10-28 13:06   ` Jesper Dangaard Brouer
2019-10-28 13:15     ` Toke Høiland-Jørgensen
2019-10-28 15:32       ` Yonghong Song
2019-10-28 16:13         ` Jesper Dangaard Brouer
2019-10-28 17:32           ` Alexei Starovoitov
2019-10-28 18:23           ` Andrii Nakryiko
2019-10-28 18:43   ` Andrii Nakryiko

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='CAEf4BzYoEPKNFnzOEAhhE2w=U11cYfTN4o_23kjzY4ByEt5y-g@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --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).