From: Jesper Dangaard Brouer <jbrouer@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: brouer@redhat.com,
"Michal Swiatkowski" <michal.swiatkowski@linux.intel.com>,
"Toke Høiland-Jørgensen" <toke@redhat.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"John Fastabend" <john.fastabend@gmail.com>,
BPF-dev-list <bpf@vger.kernel.org>,
"Magnus Karlsson" <magnus.karlsson@gmail.com>,
"William Tu" <u9012063@gmail.com>,
xdp-hints@xdp-project.net,
"Zaremba Larysa" <larysa.zaremba@intel.com>,
"Jiri Olsa" <jolsa@redhat.com>
Subject: Re: XDP-hints: Howto support multiple BTF types per packet basis?
Date: Fri, 10 Sep 2021 13:16:46 +0200 [thread overview]
Message-ID: <2ed2a06c-6796-229d-05d4-9a6464330e9e@redhat.com> (raw)
In-Reply-To: <CAEf4BzabVVPgRB9V=DAFjzYSx-q59bmBsQQAupKYWy5eUxqVkw@mail.gmail.com>
On 09/09/2021 20.19, Andrii Nakryiko wrote:
> Depending on what IDs we are talking about (sorry, I don't follow this
> thread very closely, so if you are curious about some aspects of BTF
> or libbpf APIs, it would be good to have a specific questions with
> some context). BTF as kernel object has it's own ID allocated through
> idr, so yes, they are unique. so vmlinux BTF object will have it's own
> ID, while each module's BTF will have it's own.
>
> But if we are talking about BTF type IDs, that's entirely different
> thing. BTF type IDs start from 1 (0 is reserved for special 'VOID'
> type) all the way to number of types in vmlinux BTF. Then each module
> extends vmlinx BTF starting at N + 1 and going to N + M, where N is
> number of BTF types in vmlinux BTF and M is number of added types in
> module BTF.
>
> So in that regard each module has BTF type IDs that are overlapping
> with other modules, which is why for unique fetching of BTF types from
> modules you also need BTF object FD or ID of a module BTF, and then
> BTF type ID within that module. But as I said, I didn't follow along
> closely, so not sure if I'm answering the right question, sorry.
Thanks for answering. This N vmlinux IDs + M module IDs was important
to know, thanks for correcting my understanding on this, as this does
affect our ideas for using BTF for XDP-hints.
This "just" means that the BTF ID will be per driver. I think we can
still make this work, as the AF_XDP userspace program will already need
to bind to a device. Thus, we can still send a simple btf_id in
metadata, and AF_XDP prog will just have device-map with expected
btf_id's from this device (to validate if it knows howto decode contents).
It is slightly more annoying for my xdp_frame + cpumap use-case, as it
can get XDP_REDIRECT'ed frames from many net_devices, but we do have
xdp_frame->dev_rx (net_device) avail, so I can resolve this.
--Jesper
Finding some random BTF ID in two module and notice they point to
different types.
# bpftool btf dump file /sys/kernel/btf/ixgbe | grep 95905
[95905] FUNC 'ixgbe_set_rx_mode' type_id=95829 linkage=static
# bpftool btf dump file /sys/kernel/btf/igc | grep 95905
[95905] FUNC 'igc_ethtool_get_link_ksettings' type_id=95904 linkage=static
next prev parent reply other threads:[~2021-09-10 11:16 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210526125848.1c7adbb0@carbon>
[not found] ` <CAEf4BzYXUDyQaBjZmb_Q5-z3jw1-Uvdgxm+cfcQjSwb9oRoXnQ@mail.gmail.com>
[not found] ` <60aeb01ebcd10_fe49208b8@john-XPS-13-9370.notmuch>
[not found] ` <CAEf4Bza3m5dwZ_d0=zAWR+18f5RUjzv9=1NbhTKAO1uzWg_fzQ@mail.gmail.com>
[not found] ` <60aeeb5252147_19a622085a@john-XPS-13-9370.notmuch>
[not found] ` <CAEf4Bzb1OZHpHYagbVs7s9tMSk4wrbxzGeBCCBHQ-qCOgdu6EQ@mail.gmail.com>
[not found] ` <60b08442b18d5_1cf8208a0@john-XPS-13-9370.notmuch>
2021-05-28 9:16 ` Toke Høiland-Jørgensen
2021-05-28 10:38 ` Alexander Lobakin
2021-05-28 14:35 ` John Fastabend
2021-05-28 15:33 ` Toke Høiland-Jørgensen
2021-05-28 16:02 ` Jesper Dangaard Brouer
2021-05-28 17:29 ` John Fastabend
2021-05-30 3:27 ` Andrii Nakryiko
2021-05-31 11:03 ` Toke Høiland-Jørgensen
2021-05-31 13:17 ` Jesper Dangaard Brouer
2021-06-02 0:22 ` John Fastabend
2021-06-02 16:18 ` Jakub Kicinski
2021-06-22 7:44 ` Michal Swiatkowski
2021-06-22 11:53 ` Toke Høiland-Jørgensen
2021-06-23 8:32 ` Michal Swiatkowski
2021-06-24 12:23 ` Toke Høiland-Jørgensen
2021-06-24 13:07 ` Magnus Karlsson
2021-06-24 14:58 ` Alexei Starovoitov
2021-06-24 15:11 ` Zvi Effron
2021-06-24 16:04 ` Toke Høiland-Jørgensen
2021-06-24 16:32 ` Zvi Effron
2021-06-24 16:45 ` Jesper Dangaard Brouer
2021-07-08 8:32 ` Michal Swiatkowski
2021-07-09 10:57 ` Toke Høiland-Jørgensen
2021-09-02 2:49 ` Michal Swiatkowski
2021-09-02 9:17 ` Jesper Dangaard Brouer
2021-09-07 6:27 ` Michal Swiatkowski
2021-09-08 13:28 ` Jesper Dangaard Brouer
2021-09-09 18:19 ` Andrii Nakryiko
2021-09-10 11:16 ` Jesper Dangaard Brouer [this message]
[not found] ` <20210526222023.44f9b3c6@carbon>
[not found] ` <CAEf4BzZ+VSemxx7WFanw7DfLGN7w42G6ZC4dvOSB1zAsUgRQaw@mail.gmail.com>
2021-05-28 11:16 ` Jesper Dangaard Brouer
2021-05-30 3:24 ` 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
List information: https://lists.xdp-project.net/postorius/lists/xdp-hints.xdp-project.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2ed2a06c-6796-229d-05d4-9a6464330e9e@redhat.com \
--to=jbrouer@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@redhat.com \
--cc=kuba@kernel.org \
--cc=larysa.zaremba@intel.com \
--cc=magnus.karlsson@gmail.com \
--cc=michal.swiatkowski@linux.intel.com \
--cc=toke@redhat.com \
--cc=u9012063@gmail.com \
--cc=xdp-hints@xdp-project.net \
/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