bpf.vger.kernel.org archive mirror
 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 v2 4/4] libbpf: Add option to auto-pin maps when opening BPF object
Date: Sun, 27 Oct 2019 13:04:35 +0100	[thread overview]
Message-ID: <87pniijsx8.fsf@toke.dk> (raw)
In-Reply-To: <CAEf4BzbBmm3GfytbEtHwoD71p2XfuxuSYjhbb7rqPwUaYqvk7g@mail.gmail.com>

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

> On Thu, Oct 24, 2019 at 6:11 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> From: Toke Høiland-Jørgensen <toke@redhat.com>
>>
>> With the functions added in previous commits that can automatically pin
>> maps based on their 'pinning' setting, we can support auto-pinning of maps
>> by the simple setting of an option to bpf_object__open.
>>
>> 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().
>>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>> ---
>
> How have you tested this? From reading the code, all the maps will be
> pinned irregardless of their .pinning setting?

No, build_pin_path() checks map->pinning :)

> Please add proper tests to test_progs, testing various modes and
> overrides.

Can do.

> You keep trying to add more and more knobs :) Please stop doing that,
> even if we have a good mechanism for extensibility, it doesn't mean we
> need to increase a proliferation of options.

But I like options! ;)

> Each option has to be tested. In current version of your patches, you
> have something like 4 or 5 different knobs, do you really want to
> write tests testing each of them? ;)

Heh, I guess I can cut down the number of options to the number of tests :P

> Another high-level feedback. I think having separate passes over all
> maps (build_map_pin_paths, reuse, then we already have create_maps) is
> actually making everything more verbose and harder to extend. I'm
> thinking about all these as sub-steps of map creation. Can you please
> try refactoring so all these steps are happening per each map in one
> place: if map needs to be pinned, check if it can be reused, if not -
> create it. This actually will allow to handle races better, because
> you will be able to retry easily, while if it's all spread in
> independent passes, it becomes much harder. Please consider that.

We'll need at least two passes: set pin_path on open, and check reuse /
create / pin on load. Don't have any objections to consolidating the
other passes into create_maps; will fix, along with your comments below.

-Toke

  reply	other threads:[~2019-10-27 12:04 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
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 [this message]
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=87pniijsx8.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 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).