All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: YiFei Zhu <zhuyifei@google.com>
Cc: Yonghong Song <yhs@fb.com>, YiFei Zhu <zhuyifei1999@gmail.com>,
	bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Stanislav Fomichev <sdf@google.com>,
	Mahesh Bandewar <maheshb@google.com>
Subject: Re: [PATCH bpf-next 4/5] bpftool: support dumping metadata
Date: Sun, 23 Aug 2020 20:36:07 +0200	[thread overview]
Message-ID: <874kot2ors.fsf@toke.dk> (raw)
In-Reply-To: <CAA-VZP=Jo0iQRpP+QEmB359C5TS=0BnDHTAzd6yC85aOkEJrsA@mail.gmail.com>

YiFei Zhu <zhuyifei@google.com> writes:

> On Fri, Aug 21, 2020 at 3:58 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>> Yonghong Song <yhs@fb.com> writes:
>> > Not sure whether we need formal libbpf API to access metadata or not.
>> > This may help other applications too. But we can delay until it is
>> > necessary.
>>
>> Yeah, please put in a libbpf accessor as well; I would like to use this
>> from libxdp - without a skeleton :)
>>
>> -Toke
>
> I don't think I have an idea on a good API in libbpf that could be
> used to get the metadata of an existing program in kernel, that could
> be reused by bpftool without duplicating all the code. Maybe we can
> discuss this in a follow up series?

I think the most important part is getting a reference to the metadata
map. So a function that basically does what the top half of what your
show_prog_metadata() function does: given a prog fd, walk the map ids,
check if any of them looks like a metadata map, and if so return the map
fd.

Should be pretty straight-forward to reuse between bpftool/libbpf, no?

-Toke


  reply	other threads:[~2020-08-23 18:36 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-20  9:42 [PATCH bpf-next 0/5] Allow storage of flexible metadata information for eBPF programs YiFei Zhu
2020-08-20  9:42 ` [PATCH bpf-next 1/5] bpf: Mutex protect used_maps array and count YiFei Zhu
2020-08-20 21:18   ` Yonghong Song
2020-08-20  9:42 ` [PATCH bpf-next 2/5] bpf: Add BPF_PROG_BIND_MAP syscall YiFei Zhu
2020-08-20 21:23   ` Yonghong Song
2020-08-20  9:42 ` [PATCH bpf-next 3/5] libbpf: Add BPF_PROG_BIND_MAP syscall and use it on .metadata section YiFei Zhu
2020-08-20 20:38   ` Yonghong Song
2020-08-21  7:52     ` YiFei Zhu
2020-08-21 15:14       ` Yonghong Song
2020-08-25 20:45   ` Andrey Ignatov
2020-08-26  4:02   ` Andrii Nakryiko
2020-08-20  9:42 ` [PATCH bpf-next 4/5] bpftool: support dumping metadata YiFei Zhu
2020-08-20 21:11   ` Yonghong Song
2020-08-21  8:58     ` Toke Høiland-Jørgensen
2020-08-21 20:10       ` YiFei Zhu
2020-08-23 18:36         ` Toke Høiland-Jørgensen [this message]
2020-08-28 17:00           ` sdf
2020-08-28 20:55             ` Toke Høiland-Jørgensen
2020-08-26  5:36   ` Andrii Nakryiko
2020-08-28 16:59     ` sdf
2020-09-03  5:18       ` Andrii Nakryiko
2020-08-20  9:42 ` [PATCH bpf-next 5/5] selftests/bpf: Test bpftool loading and " YiFei Zhu
2020-08-20 21:15   ` Yonghong Song
2020-08-26  4:00     ` 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=874kot2ors.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=maheshb@google.com \
    --cc=sdf@google.com \
    --cc=yhs@fb.com \
    --cc=zhuyifei1999@gmail.com \
    --cc=zhuyifei@google.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.