Open jonesmz opened 5 years ago
First of all I strongly recommend that to learn about eBPF (and XDP) use this repo instead: https://github.com/xdp-project/xdp-tutorial (as this is based on ELF-loader libbpf)
The definition of struct bpf_map_def
is located in bpf_helpers.h (and is a copy of kernels version here)
As the comment says: This is a helper structure used by eBPF C program to describe map attributes to elf_bpf loader. Thus, this struct is just a userspace struct that gets compiled into the ELF-object file, and it is the userspace ELF-loader that need to know the layout of the struct, which is converted into a BPF-syscall to create the actual map.
This git-repo contains its own ELF-loader for BPF (in bpf_load.c) which is out-of-date. This is why I recommend NOT using this for eBPF development. Instead use libbpf and see how in XDP-tutorial.
Thanks for all of these thoughts.
This is what I was saying should be put into the in-code documentation :-).
The entire eBPF ecosystem (along with plenty of other open source projects, of course) is stunningly poorly documented, to the point where I've now spent five continuous work-days researching how it's supposed to be used.
The reason why I found this repository is because it's explicitly referenced in several places, such as kernel mailing list posts related to eBPF, and also people on forums recommending that this repository be used to provide some of the relevant helper functions for working with eBPF programs.
Ultimately, I'm trying to use iproute2's tc
command to capture egress and ingress packet statistics, and have so far been able to load the eBPF program using tc
, and then access the resulting map via /sys/fs/bpf/tc/globals. Of course, I have plenty more to debug, since I'm not yet getting any data.
Either way, again, thank you for the information. Hopefully someone will have the opportunity to transform your thoughts into a PR that puts them into the code for this repository directly.
If you're willing to merge such a PR, let me know and I can make one.
As far as I can tell, when using the SEC("maps") convention, there is no definition of bpf_map_def in a header file accessible outside the kernel. So it's necessary for the user's program to explicitly define bpf_map_def, and cross their fingers that the kernel won't change anything about that struct in the future.
If that's not the case, could you point out which header file bpf_map_def is found in?