All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.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 v4 4/5] libbpf: Add auto-pinning of maps when loading BPF objects
Date: Thu, 31 Oct 2019 19:06:10 +0100	[thread overview]
Message-ID: <87zhhgn625.fsf@toke.dk> (raw)
In-Reply-To: <CAEf4BzZ3Yf4fvM2bo0ES9_NzBgVdhXBkV-u4wbPGrSej+uB4Xw@mail.gmail.com>

Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:

> On Thu, Oct 31, 2019 at 10:37 AM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
>>
>> On Tue, Oct 29, 2019 at 12:39 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>
>> > ---
>>
>> Please fix unconditional pin_path setting, with that:
>>
>> Acked-by: Andrii Nakryiko <andriin@fb.com>
>>
>> >  tools/lib/bpf/bpf_helpers.h |    6 ++
>> >  tools/lib/bpf/libbpf.c      |  144 +++++++++++++++++++++++++++++++++++++++++--
>> >  tools/lib/bpf/libbpf.h      |   13 ++++
>> >  3 files changed, 154 insertions(+), 9 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;
>> >  };
>> >
>>
>> [...]
>>
>> > @@ -1270,6 +1292,28 @@ 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;
>> > +                       int err;
>> > +
>> > +                       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_warn("map '%s': invalid pinning value %u.\n",
>> > +                                       map_name, val);
>> > +                               return -EINVAL;
>> > +                       }
>> > +                       err = build_map_pin_path(map, pin_root_path);
>>
>> uhm... only if (val == LIBBPF_PIN_BY_NAME)?.. maybe extend tests with
>> a mix if auto-pinned and never pinned map to catch issue like this?
>
> I was wondering why your selftest didn't catch this, got puzzled for a
> bit. It's because this code path will be executed only when map
> defintion has __uint(pinning, LIBBPF_PIN_NONE), can you please add
> that to selftest as well?

Can do :)

-Toke

  reply	other threads:[~2019-10-31 18:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29 19:39 [PATCH bpf-next v4 0/5] libbpf: Support automatic pinning of maps using 'pinning' BTF attribute Toke Høiland-Jørgensen
2019-10-29 19:39 ` [PATCH bpf-next v4 1/5] libbpf: Fix error handling in bpf_map__reuse_fd() Toke Høiland-Jørgensen
2019-10-29 19:39 ` [PATCH bpf-next v4 2/5] libbpf: Store map pin path and status in struct bpf_map Toke Høiland-Jørgensen
2019-10-31 17:22   ` Andrii Nakryiko
2019-10-31 17:26     ` Toke Høiland-Jørgensen
2019-10-31 17:28       ` Andrii Nakryiko
2019-10-31 17:31     ` Toke Høiland-Jørgensen
2019-10-31 17:43       ` Andrii Nakryiko
2019-10-29 19:39 ` [PATCH bpf-next v4 3/5] libbpf: Move directory creation into _pin() functions Toke Høiland-Jørgensen
2019-10-31 17:27   ` Andrii Nakryiko
2019-10-29 19:39 ` [PATCH bpf-next v4 4/5] libbpf: Add auto-pinning of maps when loading BPF objects Toke Høiland-Jørgensen
2019-10-31 17:37   ` Andrii Nakryiko
2019-10-31 17:52     ` Andrii Nakryiko
2019-10-31 18:06       ` Toke Høiland-Jørgensen [this message]
2019-10-29 19:39 ` [PATCH bpf-next v4 5/5] selftests: Add tests for automatic map pinning Toke Høiland-Jørgensen
2019-10-31 18:02   ` Andrii Nakryiko
2019-10-31 18:18     ` 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=87zhhgn625.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=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=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 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.