Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain where bpf_map_def comes from #34

Open
jonesmz opened this issue Jun 12, 2019 · 2 comments
Open

Explain where bpf_map_def comes from #34

jonesmz opened this issue Jun 12, 2019 · 2 comments

Comments

@jonesmz
Copy link

jonesmz commented Jun 12, 2019

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?

@netoptimizer
Copy link
Owner

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.

@jonesmz
Copy link
Author

jonesmz commented Jun 13, 2019

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.

netoptimizer added a commit that referenced this issue Jun 14, 2019
This git-repo is too closely depending on the kernel, and
people likely want to use eBPF + XDP without being so
dependend on the kernel.

The XDP-tutorial is a much cleaner approach for userspace usage.
 https://github.com/xdp-project/xdp-tutorial

This related to issue #34

Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
netoptimizer added a commit that referenced this issue Jun 14, 2019
Trying to get people to notice the XDP-tutorial, and
give many hints to use libbpf instead of this out-of-date ELF-loader.

This related to issue #34

Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants