2016-10-17 20:28:36 +08:00
|
|
|
test_verifier
|
|
|
|
|
test_maps
|
2016-12-04 04:31:33 +08:00
|
|
|
test_lru_map
|
2017-01-22 00:26:12 +08:00
|
|
|
test_lpm_map
|
2017-02-10 07:21:45 +08:00
|
|
|
test_tag
|
2018-01-19 08:36:24 +08:00
|
|
|
FEATURE-DUMP.libbpf
|
|
|
|
|
fixdep
|
|
|
|
|
test_align
|
|
|
|
|
test_dev_cgroup
|
selftests/bpf: Replace test_progs and test_maps w/ general rule
Define test runner generation meta-rule that codifies dependencies
between test runner, its tests, and its dependent BPF programs. Use that
for defining test_progs and test_maps test-runners. Also additionally define
2 flavors of test_progs:
- alu32, which builds BPF programs with 32-bit registers codegen;
- bpf_gcc, which build BPF programs using GCC, if it supports BPF target.
Overall, this is accomplished through $(eval)'ing a set of generic
rules, which defines Makefile targets dynamically at runtime. See
comments explaining the need for 2 $(evals), though.
For each test runner we have (test_maps and test_progs, currently), and,
optionally, their flavors, the logic of build process is modeled as
follows (using test_progs as an example):
- all BPF objects are in progs/:
- BPF object's .o file is built into output directory from
corresponding progs/.c file;
- all BPF objects in progs/*.c depend on all progs/*.h headers;
- all BPF objects depend on bpf_*.h helpers from libbpf (but not
libbpf archive). There is an extra rule to trigger bpf_helper_defs.h
(re-)build, if it's not present/outdated);
- build recipe for BPF object can be re-defined per test runner/flavor;
- test files are built from prog_tests/*.c:
- all such test file objects are built on individual file basis;
- currently, every single test file depends on all BPF object files;
this might be improved in follow up patches to do 1-to-1 dependency,
but allowing to customize this per each individual test;
- each test runner definition can specify a list of extra .c and .h
files to be built along test files and test runner binary; all such
headers are becoming automatic dependency of each test .c file;
- due to test files sometimes embedding (using .incbin assembly
directive) contents of some BPF objects at compilation time, which are
expected to be in CWD of compiler, compilation for test file object does
cd into test runner's output directory; to support this mode all the
include paths are turned into absolute paths using $(abspath) make
function;
- prog_tests/test.h is automatically (re-)generated with an entry for
each .c file in prog_tests/;
- final test runner binary is linked together from test object files and
extra object files, linking together libbpf's archive as well;
- it's possible to specify extra "resource" files/targets, which will be
copied into test runner output directory, if it differes from
Makefile-wide $(OUTPUT). This is used to ensure btf_dump test cases and
urandom_read binary is put into a test runner's CWD for tests to find
them in runtime.
For flavored test runners, their output directory is a subdirectory of
common Makefile-wide $(OUTPUT) directory with flavor name used as
subdirectory name.
BPF objects targets might be reused between different test runners, so
extra checks are employed to not double-define them. Similarly, we have
redefinition guards for output directories and test headers.
test_verifier follows slightly different patterns and is simple enough
to not justify generalizing TEST_RUNNER_DEFINE/TEST_RUNNER_DEFINE_RULES
further to accomodate these differences. Instead, rules for
test_verifier are minimized and simplified, while preserving correctness
of dependencies.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20191016060051.2024182-6-andriin@fb.com
2019-10-16 14:00:49 +08:00
|
|
|
/test_progs*
|
2018-01-30 13:23:28 +08:00
|
|
|
test_tcpbpf_user
|
2018-01-19 08:36:24 +08:00
|
|
|
test_verifier_log
|
|
|
|
|
feature
|
2018-04-10 20:24:21 +08:00
|
|
|
test_sock
|
|
|
|
|
test_sock_addr
|
2019-03-01 07:31:21 +08:00
|
|
|
test_sock_fields
|
2018-04-10 20:24:21 +08:00
|
|
|
urandom_read
|
2018-04-24 06:53:05 +08:00
|
|
|
test_btf
|
2018-05-08 21:36:37 +08:00
|
|
|
test_sockmap
|
2018-05-27 19:24:10 +08:00
|
|
|
test_lirc_mode2_user
|
2018-06-04 06:59:43 +08:00
|
|
|
get_cgroup_id_user
|
2018-09-04 00:05:27 +08:00
|
|
|
test_skb_cgroup_id_user
|
|
|
|
|
test_socket_cookie
|
2019-05-26 00:37:40 +08:00
|
|
|
test_cgroup_attach
|
2018-09-04 00:05:27 +08:00
|
|
|
test_cgroup_storage
|
|
|
|
|
test_select_reuseport
|
2018-09-14 22:46:22 +08:00
|
|
|
test_flow_dissector
|
|
|
|
|
flow_dissector_load
|
2018-10-19 22:24:36 +08:00
|
|
|
test_netcnt
|
|
|
|
|
test_section_names
|
2018-12-20 14:13:09 +08:00
|
|
|
test_tcpnotify_user
|
2019-01-09 08:07:28 +08:00
|
|
|
test_libbpf
|
2019-03-22 09:54:06 +08:00
|
|
|
test_tcp_check_syncookie_user
|
2019-05-17 00:46:57 +08:00
|
|
|
test_sysctl
|
2019-05-12 15:29:18 +08:00
|
|
|
libbpf.pc
|
|
|
|
|
libbpf.so.*
|
2019-05-25 02:59:01 +08:00
|
|
|
test_hashmap
|
2019-05-25 02:59:04 +08:00
|
|
|
test_btf_dump
|
selftests/bpf: measure RTT from xdp using xdping
xdping allows us to get latency estimates from XDP. Output looks
like this:
./xdping -I eth4 192.168.55.8
Setting up XDP for eth4, please wait...
XDP setup disrupts network connectivity, hit Ctrl+C to quit
Normal ping RTT data
[Ignore final RTT; it is distorted by XDP using the reply]
PING 192.168.55.8 (192.168.55.8) from 192.168.55.7 eth4: 56(84) bytes of data.
64 bytes from 192.168.55.8: icmp_seq=1 ttl=64 time=0.302 ms
64 bytes from 192.168.55.8: icmp_seq=2 ttl=64 time=0.208 ms
64 bytes from 192.168.55.8: icmp_seq=3 ttl=64 time=0.163 ms
64 bytes from 192.168.55.8: icmp_seq=8 ttl=64 time=0.275 ms
4 packets transmitted, 4 received, 0% packet loss, time 3079ms
rtt min/avg/max/mdev = 0.163/0.237/0.302/0.054 ms
XDP RTT data:
64 bytes from 192.168.55.8: icmp_seq=5 ttl=64 time=0.02808 ms
64 bytes from 192.168.55.8: icmp_seq=6 ttl=64 time=0.02804 ms
64 bytes from 192.168.55.8: icmp_seq=7 ttl=64 time=0.02815 ms
64 bytes from 192.168.55.8: icmp_seq=8 ttl=64 time=0.02805 ms
The xdping program loads the associated xdping_kern.o BPF program
and attaches it to the specified interface. If run in client
mode (the default), it will add a map entry keyed by the
target IP address; this map will store RTT measurements, current
sequence number etc. Finally in client mode the ping command
is executed, and the xdping BPF program will use the last ICMP
reply, reformulate it as an ICMP request with the next sequence
number and XDP_TX it. After the reply to that request is received
we can measure RTT and repeat until the desired number of
measurements is made. This is why the sequence numbers in the
normal ping are 1, 2, 3 and 8. We XDP_TX a modified version
of ICMP reply 4 and keep doing this until we get the 4 replies
we need; hence the networking stack only sees reply 8, where
we have XDP_PASSed it upstream since we are done.
In server mode (-s), xdping simply takes ICMP requests and replies
to them in XDP rather than passing the request up to the networking
stack. No map entry is required.
xdping can be run in native XDP mode (the default, or specified
via -N) or in skb mode (-S).
A test program test_xdping.sh exercises some of these options.
Note that native XDP does not seem to XDP_TX for veths, hence -N
is not tested. Looking at the code, it looks like XDP_TX is
supported so I'm not sure if that's expected. Running xdping in
native mode for ixgbe as both client and server works fine.
Changes since v4
- close fds on cleanup (Song Liu)
Changes since v3
- fixed seq to be __be16 (Song Liu)
- fixed fd checks in xdping.c (Song Liu)
Changes since v2
- updated commit message to explain why seq number of last
ICMP reply is 8 not 4 (Song Liu)
- updated types of seq number, raddr and eliminated csum variable
in xdpclient/xdpserver functions as it was not needed (Song Liu)
- added XDPING_DEFAULT_COUNT definition and usage specification of
default/max counts (Song Liu)
Changes since v1
- moved from RFC to PATCH
- removed unused variable in ipv4_csum() (Song Liu)
- refactored ICMP checks into icmp_check() function called by client
and server programs and reworked client and server programs due
to lack of shared code (Song Liu)
- added checks to ensure that SKB and native mode are not requested
together (Song Liu)
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
Acked-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-06-01 01:47:14 +08:00
|
|
|
xdping
|
2019-12-03 05:59:31 +08:00
|
|
|
test_cpp
|
2019-12-14 09:43:38 +08:00
|
|
|
*.skel.h
|
2019-10-25 12:55:03 +08:00
|
|
|
/no_alu32
|
selftests/bpf: Replace test_progs and test_maps w/ general rule
Define test runner generation meta-rule that codifies dependencies
between test runner, its tests, and its dependent BPF programs. Use that
for defining test_progs and test_maps test-runners. Also additionally define
2 flavors of test_progs:
- alu32, which builds BPF programs with 32-bit registers codegen;
- bpf_gcc, which build BPF programs using GCC, if it supports BPF target.
Overall, this is accomplished through $(eval)'ing a set of generic
rules, which defines Makefile targets dynamically at runtime. See
comments explaining the need for 2 $(evals), though.
For each test runner we have (test_maps and test_progs, currently), and,
optionally, their flavors, the logic of build process is modeled as
follows (using test_progs as an example):
- all BPF objects are in progs/:
- BPF object's .o file is built into output directory from
corresponding progs/.c file;
- all BPF objects in progs/*.c depend on all progs/*.h headers;
- all BPF objects depend on bpf_*.h helpers from libbpf (but not
libbpf archive). There is an extra rule to trigger bpf_helper_defs.h
(re-)build, if it's not present/outdated);
- build recipe for BPF object can be re-defined per test runner/flavor;
- test files are built from prog_tests/*.c:
- all such test file objects are built on individual file basis;
- currently, every single test file depends on all BPF object files;
this might be improved in follow up patches to do 1-to-1 dependency,
but allowing to customize this per each individual test;
- each test runner definition can specify a list of extra .c and .h
files to be built along test files and test runner binary; all such
headers are becoming automatic dependency of each test .c file;
- due to test files sometimes embedding (using .incbin assembly
directive) contents of some BPF objects at compilation time, which are
expected to be in CWD of compiler, compilation for test file object does
cd into test runner's output directory; to support this mode all the
include paths are turned into absolute paths using $(abspath) make
function;
- prog_tests/test.h is automatically (re-)generated with an entry for
each .c file in prog_tests/;
- final test runner binary is linked together from test object files and
extra object files, linking together libbpf's archive as well;
- it's possible to specify extra "resource" files/targets, which will be
copied into test runner output directory, if it differes from
Makefile-wide $(OUTPUT). This is used to ensure btf_dump test cases and
urandom_read binary is put into a test runner's CWD for tests to find
them in runtime.
For flavored test runners, their output directory is a subdirectory of
common Makefile-wide $(OUTPUT) directory with flavor name used as
subdirectory name.
BPF objects targets might be reused between different test runners, so
extra checks are employed to not double-define them. Similarly, we have
redefinition guards for output directories and test headers.
test_verifier follows slightly different patterns and is simple enough
to not justify generalizing TEST_RUNNER_DEFINE/TEST_RUNNER_DEFINE_RULES
further to accomodate these differences. Instead, rules for
test_verifier are minimized and simplified, while preserving correctness
of dependencies.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20191016060051.2024182-6-andriin@fb.com
2019-10-16 14:00:49 +08:00
|
|
|
/bpf_gcc
|
2019-12-14 09:43:38 +08:00
|
|
|
/tools
|
