2016-04-28 20:21:04 +08:00
|
|
|
eBPF sample programs
|
|
|
|
====================
|
|
|
|
|
samples/bpf: Switch over to libbpf
Now that libbpf under tools/lib/bpf/* is synced with the version from
samples/bpf, we can get rid most of the libbpf library here.
Committer notes:
Built it in a docker fedora rawhide container and ran it in the f25 host, seems
to work just like it did before this patch, i.e. the switch to tools/lib/bpf/
doesn't seem to have introduced problems and Joe said he tested it with
all the entries in samples/bpf/ and other code he found:
[root@f5065a7d6272 linux]# make -j4 O=/tmp/build/linux headers_install
<SNIP>
[root@f5065a7d6272 linux]# rm -rf /tmp/build/linux/samples/bpf/
[root@f5065a7d6272 linux]# make -j4 O=/tmp/build/linux samples/bpf/
make[1]: Entering directory '/tmp/build/linux'
CHK include/config/kernel.release
HOSTCC scripts/basic/fixdep
GEN ./Makefile
CHK include/generated/uapi/linux/version.h
Using /git/linux as source for kernel
CHK include/generated/utsrelease.h
HOSTCC scripts/basic/bin2c
HOSTCC arch/x86/tools/relocs_32.o
HOSTCC arch/x86/tools/relocs_64.o
LD samples/bpf/built-in.o
<SNIP>
HOSTCC samples/bpf/fds_example.o
HOSTCC samples/bpf/sockex1_user.o
/git/linux/samples/bpf/fds_example.c: In function 'bpf_prog_create':
/git/linux/samples/bpf/fds_example.c:63:6: warning: passing argument 2 of 'bpf_load_program' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
insns, insns_cnt, "GPL", 0,
^~~~~
In file included from /git/linux/samples/bpf/libbpf.h:5:0,
from /git/linux/samples/bpf/bpf_load.h:4,
from /git/linux/samples/bpf/fds_example.c:15:
/git/linux/tools/lib/bpf/bpf.h:31:5: note: expected 'struct bpf_insn *' but argument is of type 'const struct bpf_insn *'
int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
^~~~~~~~~~~~~~~~
HOSTCC samples/bpf/sockex2_user.o
<SNIP>
HOSTCC samples/bpf/xdp_tx_iptunnel_user.o
clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.2.1/include -I/git/linux/arch/x86/include -I./arch/x86/include/generated/uapi -I./arch/x86/include/generated -I/git/linux/include -I./include -I/git/linux/arch/x86/include/uapi -I/git/linux/include/uapi -I./include/generated/uapi -include /git/linux/include/linux/kconfig.h \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
-Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-O2 -emit-llvm -c /git/linux/samples/bpf/sockex1_kern.c -o -| llc -march=bpf -filetype=obj -o samples/bpf/sockex1_kern.o
HOSTLD samples/bpf/tc_l2_redirect
<SNIP>
HOSTLD samples/bpf/lwt_len_hist
HOSTLD samples/bpf/xdp_tx_iptunnel
make[1]: Leaving directory '/tmp/build/linux'
[root@f5065a7d6272 linux]#
And then, in the host:
[root@jouet bpf]# mount | grep "docker.*devicemapper\/"
/dev/mapper/docker-253:0-1705076-9bd8aa1e0af33adce89ff42090847868ca676932878942be53941a06ec5923f9 on /var/lib/docker/devicemapper/mnt/9bd8aa1e0af33adce89ff42090847868ca676932878942be53941a06ec5923f9 type xfs (rw,relatime,context="system_u:object_r:container_file_t:s0:c73,c276",nouuid,attr2,inode64,sunit=1024,swidth=1024,noquota)
[root@jouet bpf]# cd /var/lib/docker/devicemapper/mnt/9bd8aa1e0af33adce89ff42090847868ca676932878942be53941a06ec5923f9/rootfs/tmp/build/linux/samples/bpf/
[root@jouet bpf]# file offwaketime
offwaketime: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=f423d171e0487b2f802b6a792657f0f3c8f6d155, not stripped
[root@jouet bpf]# readelf -SW offwaketime
offwaketime offwaketime_kern.o offwaketime_user.o
[root@jouet bpf]# readelf -SW offwaketime_kern.o
There are 11 section headers, starting at offset 0x700:
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .strtab STRTAB 0000000000000000 000658 0000a8 00 0 0 1
[ 2] .text PROGBITS 0000000000000000 000040 000000 00 AX 0 0 4
[ 3] kprobe/try_to_wake_up PROGBITS 0000000000000000 000040 0000d8 00 AX 0 0 8
[ 4] .relkprobe/try_to_wake_up REL 0000000000000000 0005a8 000020 10 10 3 8
[ 5] tracepoint/sched/sched_switch PROGBITS 0000000000000000 000118 000318 00 AX 0 0 8
[ 6] .reltracepoint/sched/sched_switch REL 0000000000000000 0005c8 000090 10 10 5 8
[ 7] maps PROGBITS 0000000000000000 000430 000050 00 WA 0 0 4
[ 8] license PROGBITS 0000000000000000 000480 000004 00 WA 0 0 1
[ 9] version PROGBITS 0000000000000000 000484 000004 00 WA 0 0 4
[10] .symtab SYMTAB 0000000000000000 000488 000120 18 1 4 8
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
[root@jouet bpf]# ./offwaketime | head -3
qemu-system-x86;entry_SYSCALL_64_fastpath;sys_ppoll;do_sys_poll;poll_schedule_timeout;schedule_hrtimeout_range;schedule_hrtimeout_range_clock;schedule;__schedule;-;try_to_wake_up;hrtimer_wakeup;__hrtimer_run_queues;hrtimer_interrupt;local_apic_timer_interrupt;smp_apic_timer_interrupt;__irqentry_text_start;cpuidle_enter_state;cpuidle_enter;call_cpuidle;cpu_startup_entry;rest_init;start_kernel;x86_64_start_reservations;x86_64_start_kernel;start_cpu;;swapper/0 4
firefox;entry_SYSCALL_64_fastpath;sys_poll;do_sys_poll;poll_schedule_timeout;schedule_hrtimeout_range;schedule_hrtimeout_range_clock;schedule;__schedule;-;try_to_wake_up;pollwake;__wake_up_common;__wake_up_sync_key;pipe_write;__vfs_write;vfs_write;sys_write;entry_SYSCALL_64_fastpath;;Timer 1
swapper/2;start_cpu;start_secondary;cpu_startup_entry;schedule_preempt_disabled;schedule;__schedule;-;---;; 61
[root@jouet bpf]#
Signed-off-by: Joe Stringer <joe@ovn.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: netdev@vger.kernel.org
Link: https://github.com/joestringer/linux/commit/5c40f54a52b1f437123c81e21873f4b4b1f9bd55.patch
Link: http://lkml.kernel.org/n/tip-xr8twtx7sjh5821g8qw47yxk@git.kernel.org
[ Use -I$(srctree)/tools/lib/ to support out of source code tree builds, as noticed by Wang Nan ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2016-12-15 06:43:39 +08:00
|
|
|
This directory contains a test stubs, verifier test-suite and examples
|
|
|
|
for using eBPF. The examples use libbpf from tools/lib/bpf.
|
2016-04-28 20:21:04 +08:00
|
|
|
|
2023-08-24 18:22:50 +08:00
|
|
|
Note that the XDP-specific samples have been removed from this directory and
|
|
|
|
moved to the xdp-tools repository: https://github.com/xdp-project/xdp-tools
|
|
|
|
See the commit messages removing each tool from this directory for how to
|
|
|
|
convert specific command invocations between the old samples and the utilities
|
|
|
|
in xdp-tools.
|
|
|
|
|
2016-04-28 20:21:04 +08:00
|
|
|
Build dependencies
|
|
|
|
==================
|
|
|
|
|
|
|
|
Compiling requires having installed:
|
2023-07-17 00:13:51 +08:00
|
|
|
* clang
|
|
|
|
* llvm
|
|
|
|
* pahole
|
2016-04-28 20:21:04 +08:00
|
|
|
|
2023-07-17 00:13:51 +08:00
|
|
|
Consult :ref:`Documentation/process/changes.rst <changes>` for the minimum
|
|
|
|
version numbers required and how to update them. Note that LLVM's tool
|
|
|
|
'llc' must support target 'bpf', list version and supported targets with
|
|
|
|
command: ``llc --version``
|
2016-04-28 20:21:04 +08:00
|
|
|
|
2019-10-11 08:28:08 +08:00
|
|
|
Clean and configuration
|
|
|
|
-----------------------
|
|
|
|
|
|
|
|
It can be needed to clean tools, samples or kernel before trying new arch or
|
|
|
|
after some changes (on demand)::
|
|
|
|
|
|
|
|
make -C tools clean
|
|
|
|
make -C samples/bpf clean
|
|
|
|
make clean
|
|
|
|
|
2023-07-17 00:13:51 +08:00
|
|
|
Configure kernel, defconfig for instance
|
|
|
|
(see "tools/testing/selftests/bpf/config" for a reference config)::
|
2019-10-11 08:28:08 +08:00
|
|
|
|
|
|
|
make defconfig
|
|
|
|
|
2016-04-28 20:21:04 +08:00
|
|
|
Kernel headers
|
|
|
|
--------------
|
|
|
|
|
|
|
|
There are usually dependencies to header files of the current kernel.
|
|
|
|
To avoid installing devel kernel headers system wide, as a normal
|
|
|
|
user, simply call::
|
|
|
|
|
|
|
|
make headers_install
|
|
|
|
|
2022-10-19 00:32:31 +08:00
|
|
|
This will create a local "usr/include" directory in the git/build top
|
|
|
|
level directory, that the make system will automatically pick up first.
|
2016-04-28 20:21:04 +08:00
|
|
|
|
|
|
|
Compiling
|
|
|
|
=========
|
|
|
|
|
|
|
|
For building the BPF samples, issue the below command from the kernel
|
|
|
|
top level directory::
|
|
|
|
|
2019-11-11 00:31:16 +08:00
|
|
|
make M=samples/bpf
|
2016-04-28 20:21:04 +08:00
|
|
|
|
2016-04-28 20:21:09 +08:00
|
|
|
It is also possible to call make from this directory. This will just
|
2019-11-11 00:31:16 +08:00
|
|
|
hide the invocation of make as above.
|
2016-04-28 20:21:09 +08:00
|
|
|
|
2016-04-28 20:21:04 +08:00
|
|
|
Manually compiling LLVM with 'bpf' support
|
|
|
|
------------------------------------------
|
|
|
|
|
|
|
|
Since version 3.7.0, LLVM adds a proper LLVM backend target for the
|
|
|
|
BPF bytecode architecture.
|
|
|
|
|
|
|
|
By default llvm will build all non-experimental backends including bpf.
|
|
|
|
To generate a smaller llc binary one can use::
|
|
|
|
|
|
|
|
-DLLVM_TARGETS_TO_BUILD="BPF"
|
|
|
|
|
bpf, docs: Update build procedure for manually compiling LLVM and Clang
The current LLVM and Clang build procedure in samples/bpf/README.rst is
out of date. See below that the links are not accessible any more.
$ git clone http://llvm.org/git/llvm.git
Cloning into 'llvm'...
fatal: unable to access 'http://llvm.org/git/llvm.git/': Maximum (20) redirects followed
$ git clone --depth 1 http://llvm.org/git/clang.git
Cloning into 'clang'...
fatal: unable to access 'http://llvm.org/git/clang.git/': Maximum (20) redirects followed
The LLVM community has adopted new ways to build the compiler. There are
different ways to build LLVM and Clang, the Clang Getting Started page [1]
has one way. As Yonghong said, it is better to copy the build procedure
in Documentation/bpf/bpf_devel_QA.rst to keep consistent.
I verified the procedure and it is proved to be feasible, so we should
update README.rst to reflect the reality. At the same time, update the
related comment in Makefile.
Additionally, as Fangrui said, the dir llvm-project/llvm/build/install is
not used, BUILD_SHARED_LIBS=OFF is the default option [2], so also change
Documentation/bpf/bpf_devel_QA.rst together.
At last, we recommend that developers who want the fastest incremental
builds use the Ninja build system [1], you can find it in your system's
package manager, usually the package is ninja or ninja-build [3], so add
ninja to build dependencies suggested by Nathan.
[1] https://clang.llvm.org/get_started.html
[2] https://www.llvm.org/docs/CMake.html
[3] https://github.com/ninja-build/ninja/wiki/Pre-built-Ninja-packages
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Yonghong Song <yhs@fb.com>
Cc: Fangrui Song <maskray@google.com>
Link: https://lore.kernel.org/bpf/1611279584-26047-1-git-send-email-yangtiezhu@loongson.cn
2021-01-22 09:39:44 +08:00
|
|
|
We recommend that developers who want the fastest incremental builds
|
|
|
|
use the Ninja build system, you can find it in your system's package
|
|
|
|
manager, usually the package is ninja or ninja-build.
|
|
|
|
|
2016-04-28 20:21:04 +08:00
|
|
|
Quick sniplet for manually compiling LLVM and clang
|
bpf, docs: Update build procedure for manually compiling LLVM and Clang
The current LLVM and Clang build procedure in samples/bpf/README.rst is
out of date. See below that the links are not accessible any more.
$ git clone http://llvm.org/git/llvm.git
Cloning into 'llvm'...
fatal: unable to access 'http://llvm.org/git/llvm.git/': Maximum (20) redirects followed
$ git clone --depth 1 http://llvm.org/git/clang.git
Cloning into 'clang'...
fatal: unable to access 'http://llvm.org/git/clang.git/': Maximum (20) redirects followed
The LLVM community has adopted new ways to build the compiler. There are
different ways to build LLVM and Clang, the Clang Getting Started page [1]
has one way. As Yonghong said, it is better to copy the build procedure
in Documentation/bpf/bpf_devel_QA.rst to keep consistent.
I verified the procedure and it is proved to be feasible, so we should
update README.rst to reflect the reality. At the same time, update the
related comment in Makefile.
Additionally, as Fangrui said, the dir llvm-project/llvm/build/install is
not used, BUILD_SHARED_LIBS=OFF is the default option [2], so also change
Documentation/bpf/bpf_devel_QA.rst together.
At last, we recommend that developers who want the fastest incremental
builds use the Ninja build system [1], you can find it in your system's
package manager, usually the package is ninja or ninja-build [3], so add
ninja to build dependencies suggested by Nathan.
[1] https://clang.llvm.org/get_started.html
[2] https://www.llvm.org/docs/CMake.html
[3] https://github.com/ninja-build/ninja/wiki/Pre-built-Ninja-packages
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Yonghong Song <yhs@fb.com>
Cc: Fangrui Song <maskray@google.com>
Link: https://lore.kernel.org/bpf/1611279584-26047-1-git-send-email-yangtiezhu@loongson.cn
2021-01-22 09:39:44 +08:00
|
|
|
(build dependencies are ninja, cmake and gcc-c++)::
|
2016-04-28 20:21:04 +08:00
|
|
|
|
bpf, docs: Update build procedure for manually compiling LLVM and Clang
The current LLVM and Clang build procedure in samples/bpf/README.rst is
out of date. See below that the links are not accessible any more.
$ git clone http://llvm.org/git/llvm.git
Cloning into 'llvm'...
fatal: unable to access 'http://llvm.org/git/llvm.git/': Maximum (20) redirects followed
$ git clone --depth 1 http://llvm.org/git/clang.git
Cloning into 'clang'...
fatal: unable to access 'http://llvm.org/git/clang.git/': Maximum (20) redirects followed
The LLVM community has adopted new ways to build the compiler. There are
different ways to build LLVM and Clang, the Clang Getting Started page [1]
has one way. As Yonghong said, it is better to copy the build procedure
in Documentation/bpf/bpf_devel_QA.rst to keep consistent.
I verified the procedure and it is proved to be feasible, so we should
update README.rst to reflect the reality. At the same time, update the
related comment in Makefile.
Additionally, as Fangrui said, the dir llvm-project/llvm/build/install is
not used, BUILD_SHARED_LIBS=OFF is the default option [2], so also change
Documentation/bpf/bpf_devel_QA.rst together.
At last, we recommend that developers who want the fastest incremental
builds use the Ninja build system [1], you can find it in your system's
package manager, usually the package is ninja or ninja-build [3], so add
ninja to build dependencies suggested by Nathan.
[1] https://clang.llvm.org/get_started.html
[2] https://www.llvm.org/docs/CMake.html
[3] https://github.com/ninja-build/ninja/wiki/Pre-built-Ninja-packages
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Yonghong Song <yhs@fb.com>
Cc: Fangrui Song <maskray@google.com>
Link: https://lore.kernel.org/bpf/1611279584-26047-1-git-send-email-yangtiezhu@loongson.cn
2021-01-22 09:39:44 +08:00
|
|
|
$ git clone https://github.com/llvm/llvm-project.git
|
|
|
|
$ mkdir -p llvm-project/llvm/build
|
|
|
|
$ cd llvm-project/llvm/build
|
|
|
|
$ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
|
|
|
|
-DLLVM_ENABLE_PROJECTS="clang" \
|
|
|
|
-DCMAKE_BUILD_TYPE=Release \
|
|
|
|
-DLLVM_BUILD_RUNTIME=OFF
|
|
|
|
$ ninja
|
2016-04-28 20:21:04 +08:00
|
|
|
|
2016-04-28 20:21:14 +08:00
|
|
|
It is also possible to point make to the newly compiled 'llc' or
|
|
|
|
'clang' command via redefining LLC or CLANG on the make command line::
|
2016-04-28 20:21:04 +08:00
|
|
|
|
bpf, docs: Update build procedure for manually compiling LLVM and Clang
The current LLVM and Clang build procedure in samples/bpf/README.rst is
out of date. See below that the links are not accessible any more.
$ git clone http://llvm.org/git/llvm.git
Cloning into 'llvm'...
fatal: unable to access 'http://llvm.org/git/llvm.git/': Maximum (20) redirects followed
$ git clone --depth 1 http://llvm.org/git/clang.git
Cloning into 'clang'...
fatal: unable to access 'http://llvm.org/git/clang.git/': Maximum (20) redirects followed
The LLVM community has adopted new ways to build the compiler. There are
different ways to build LLVM and Clang, the Clang Getting Started page [1]
has one way. As Yonghong said, it is better to copy the build procedure
in Documentation/bpf/bpf_devel_QA.rst to keep consistent.
I verified the procedure and it is proved to be feasible, so we should
update README.rst to reflect the reality. At the same time, update the
related comment in Makefile.
Additionally, as Fangrui said, the dir llvm-project/llvm/build/install is
not used, BUILD_SHARED_LIBS=OFF is the default option [2], so also change
Documentation/bpf/bpf_devel_QA.rst together.
At last, we recommend that developers who want the fastest incremental
builds use the Ninja build system [1], you can find it in your system's
package manager, usually the package is ninja or ninja-build [3], so add
ninja to build dependencies suggested by Nathan.
[1] https://clang.llvm.org/get_started.html
[2] https://www.llvm.org/docs/CMake.html
[3] https://github.com/ninja-build/ninja/wiki/Pre-built-Ninja-packages
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Yonghong Song <yhs@fb.com>
Cc: Fangrui Song <maskray@google.com>
Link: https://lore.kernel.org/bpf/1611279584-26047-1-git-send-email-yangtiezhu@loongson.cn
2021-01-22 09:39:44 +08:00
|
|
|
make M=samples/bpf LLC=~/git/llvm-project/llvm/build/bin/llc CLANG=~/git/llvm-project/llvm/build/bin/clang
|
2017-09-21 00:11:59 +08:00
|
|
|
|
|
|
|
Cross compiling samples
|
|
|
|
-----------------------
|
|
|
|
In order to cross-compile, say for arm64 targets, export CROSS_COMPILE and ARCH
|
2019-10-11 08:28:08 +08:00
|
|
|
environment variables before calling make. But do this before clean,
|
2022-10-31 02:02:54 +08:00
|
|
|
configuration and header install steps described above. This will direct make to
|
2019-10-11 08:28:08 +08:00
|
|
|
build samples for the cross target::
|
|
|
|
|
|
|
|
export ARCH=arm64
|
|
|
|
export CROSS_COMPILE="aarch64-linux-gnu-"
|
|
|
|
|
|
|
|
Headers can be also installed on RFS of target board if need to keep them in
|
|
|
|
sync (not necessarily and it creates a local "usr/include" directory also)::
|
|
|
|
|
|
|
|
make INSTALL_HDR_PATH=~/some_sysroot/usr headers_install
|
|
|
|
|
|
|
|
Pointing LLC and CLANG is not necessarily if it's installed on HOST and have
|
|
|
|
in its targets appropriate arm64 arch (usually it has several arches).
|
|
|
|
Build samples::
|
|
|
|
|
2019-11-11 00:31:16 +08:00
|
|
|
make M=samples/bpf
|
2019-10-11 08:28:08 +08:00
|
|
|
|
|
|
|
Or build samples with SYSROOT if some header or library is absent in toolchain,
|
|
|
|
say libelf, providing address to file system containing headers and libs,
|
|
|
|
can be RFS of target board::
|
2017-09-21 00:11:59 +08:00
|
|
|
|
2019-11-11 00:31:16 +08:00
|
|
|
make M=samples/bpf SYSROOT=~/some_sysroot
|