XDP hardware hints discussion mail archive
 help / color / mirror / Atom feed
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



  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