From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: sdf@google.com, netdev@vger.kernel.org, bpf@vger.kernel.org,
davem@davemloft.net, ast@kernel.org, daniel@iogearbox.net,
YiFei Zhu <zhuyifei1999@gmail.com>,
andriin@fb.com
Subject: Re: [PATCH bpf-next v3 4/8] libbpf: implement bpf_prog_find_metadata
Date: Wed, 02 Sep 2020 23:33:05 +0200 [thread overview]
Message-ID: <87mu27hnji.fsf@toke.dk> (raw)
In-Reply-To: <20200902210838.7a26mfi54dufou5a@ast-mbp.dhcp.thefacebook.com>
Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
> On Wed, Sep 02, 2020 at 11:43:26AM +0200, Toke Høiland-Jørgensen wrote:
>> >
>> > I don't feel great about this libbpf api. bpftool already does
>> > bpf_obj_get_info_by_fd() for progs and for maps.
>> > This extra step and extra set of syscalls is redundant work.
>> > I think it's better to be done as part of bpftool.
>> > It doesn't quite fit as generic api.
>>
>> Why not?
>
> It's a helper function on top of already provided api and implemented
> in the most brute force and inefficient way.
> bpftool implementation of the same will be more efficient.
Right, certainly wouldn't mind something more efficient. But to me, the
inefficiency is outweighed by convenience of having this canonical
reference for 'this is the metadata map'.
>> so. If we don't have it, people will have to go look at bpftool code,
>> and we'll end up with copied code snippets, which seems less than ideal.
>
> I'd like to see the real use case first before hypothesising.
For me, that would be incorporating support for this into
libxdp/xdp-tools; which was the reason I asked for this to be split into
a separate API in the first place. But okay, not going to keep arguing
about this, I can copy-paste code as well as the next person.
-Toke
next prev parent reply other threads:[~2020-09-02 21:33 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-28 19:35 [PATCH bpf-next v3 0/8] Allow storage of flexible metadata information for eBPF programs Stanislav Fomichev
2020-08-28 19:35 ` [PATCH bpf-next v3 1/8] bpf: Mutex protect used_maps array and count Stanislav Fomichev
2020-08-28 19:35 ` [PATCH bpf-next v3 2/8] bpf: Add BPF_PROG_BIND_MAP syscall Stanislav Fomichev
2020-09-03 2:15 ` Andrii Nakryiko
2020-08-28 19:35 ` [PATCH bpf-next v3 3/8] libbpf: Add BPF_PROG_BIND_MAP syscall and use it on .metadata section Stanislav Fomichev
2020-09-03 2:31 ` Andrii Nakryiko
2020-09-04 1:29 ` Alexei Starovoitov
2020-09-04 23:18 ` Andrii Nakryiko
2020-09-07 8:49 ` Toke Høiland-Jørgensen
2020-09-08 15:19 ` Stanislav Fomichev
2020-09-08 18:20 ` Andrii Nakryiko
2020-09-08 18:10 ` Andrii Nakryiko
2020-09-09 10:58 ` Toke Høiland-Jørgensen
2020-09-09 16:34 ` Andrii Nakryiko
2020-09-08 17:44 ` Andrey Ignatov
2020-09-08 18:24 ` Andrii Nakryiko
2020-08-28 19:35 ` [PATCH bpf-next v3 4/8] libbpf: implement bpf_prog_find_metadata Stanislav Fomichev
2020-08-28 21:10 ` Toke Høiland-Jørgensen
2020-08-31 15:40 ` sdf
2020-09-01 22:58 ` Alexei Starovoitov
2020-09-02 9:43 ` Toke Høiland-Jørgensen
2020-09-02 21:08 ` Alexei Starovoitov
2020-09-02 21:33 ` Toke Høiland-Jørgensen [this message]
2020-08-28 19:36 ` [PATCH bpf-next v3 5/8] bpftool: support dumping metadata Stanislav Fomichev
2020-09-03 5:00 ` Andrii Nakryiko
2020-09-08 20:53 ` Stanislav Fomichev
2020-09-08 22:35 ` Andrii Nakryiko
2020-09-08 22:49 ` Stanislav Fomichev
2020-08-28 19:36 ` [PATCH bpf-next v3 6/8] bpftool: support metadata internal map in gen skeleton Stanislav Fomichev
2020-08-28 19:36 ` [PATCH bpf-next v3 7/8] bpftool: mention --metadata in the documentation Stanislav Fomichev
2020-08-28 19:36 ` [PATCH bpf-next v3 8/8] selftests/bpf: Test load and dump metadata with btftool and skel Stanislav Fomichev
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=87mu27hnji.fsf@toke.dk \
--to=toke@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=sdf@google.com \
--cc=zhuyifei1999@gmail.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).