On Wed, Jul 13, 2022 at 8:35 AM Zeng, Oak <oak.zeng@xxxxxxxxx> wrote: > > Thank you sdf for the reply. please don't top post in mailing list, reply inline instead > > It is news to me that samples/bpf tend to go stale. When I looked the samples/bpf folder git history, the last update is from only 2 months ago. And yes I can see samples/bfp is not actively updated recently. We are from Intel's GPU group and we are working on some bpf tools for GPU profiling purpose. We made our work based on the structure of samples/bpf because we can conveniently use libbpf. We chose bpf c frontend (vs python frontend) because python bpf program seems can't execute under non-root leading to some security concerns. This work is not yet upstream but we planned to upstream it. > > Now if samples/bpf is going stale, we need to change our plan. Specifically I have a few questions for our future planning: > > 1. does bpf community accept more bpf samples such as using bpf to kprobe/tracepoint GPU activities? Is such work helpful/welcome to/by the community? I can see the existing samples and selftest are mainly for general linux profiling such as fs, network etc. Do you accept more samples for specific driver profiling - in our case it is profiling of Intel's i915 GPU driver. > Generic BPF tools are generally put into BCC/libbpf-tools ([0]). If they are very specialized and niche, it might not be accepted. But I'd try there first. As for samples/bpf, no we don't add any new things there. It should either be a selftest-like and go into selftests/bpf, or it should be outside of the kernel repo. [0] https://github.com/iovisor/bcc/tree/master/libbpf-tools > 2. Should we port our samples/bpf to tools/testing/selftests/bpf for upstream purpose? I am not sure whether tools/testing/selftests/bpf is a good place for our gpu profiling samples. If tools/testing/selftests/bpf is not a good place for gpu profilers, any suggestion where we can upstream our gpu profilers? If the BPF part of such profilers is complicated and stresses BPF verifier, we can put those up as "BPF verifier scalability" tests (see bpf_verif_scale.c in selftests/bpf), it's good to have real-world complicated examples there to detect regressions. But tool itself probably should be in libbpf-tools or in some dedicated repo. > > Cc other bpf reviewers. Thank you for your considerations! > > Thanks, > Oak > > > -----Original Message----- > > From: sdf@xxxxxxxxxx <sdf@xxxxxxxxxx> > > Sent: July 12, 2022 1:23 PM > > To: Zeng, Oak <oak.zeng@xxxxxxxxx> > > Cc: bpf@xxxxxxxxxxxxxxx > > Subject: Re: Build error of samples/bpf > > > > On 07/12, Zeng, Oak wrote: > > > Hello all, > > > > > I tried to build the latest samples/bpf following instructions in the > > > README.rst in samples/bpf folder. I ran into various issue such as: > > > > > samples/bpf/Makefile:375: *** Cannot find a vmlinux for VMLINUX_BTF at > > > any of " /home/szeng/dii-tools/linux/vmlinux", build the kernel or > > > set VMLINUX_BTF or VMLINUX_H variable > > > > > I was able to fix above issue by enable CONFIG_DEBUG_INFO_BTF in > > > kernel .config file. > > > > > But I eventually ran into other errors. I had to fix those errors by > > > install dwarves, updating my clang/llvm to version 10. > > > > > I was able to build it if I comment out all the xdp programs from > > > Makefile. It seems those xdp programs require advanced features such > > > as data structure layout in vmlinux.h (dumped from vmlinux using > > > bpftool) and this require special kernel config support. > > > > > So I thought instead of fixing those errors one by one, I should ask > > > those who are working in this area, is there any instructions on how > > > to build samples/bpf? The README.rst seems out-of-date, for example, > > > it doesn't mention CONFIG_DEBUG_INFO_BTF. The required llvm/clang > > > version in README.rst is also out-of-date. > > > > > More specifically, to build samples/bpf, is there an example kernel > > > .config to use? I tried those config here > > > https://github.com/torvalds/linux/blob/master/tools/testing/selftests/ > > > bpf/config > > > but build errors persist. > > > > > Or is there any other tools I need to install/update on my system? > > > > In general, I'd say, samples/bpf tend to go stale. We mostly work on the > > selftests and don't pay too much attention to the samples :-( Ideally, the > > samples should be part of selftests so they get exercised by the CI. > > > > One thing I can suggest is to look at tools/testing/selftests/bpf/vmtest.sh > > script. It builds the kernels with vetted configs capable of running selftests. > > That should be, in theory, be enough to compile the samples. > > > > > My whole build log is as below: > > [...]
