+44
−9
Loading
Merge branch 'jmp32-insns'
Jiong Wang says:
====================
v3 -> v4:
- Fixed rebase issue. JMP32 checks were missing in two new functions:
+ kernel/bpf/verifier.c:insn_is_cond_jump
+ drivers/net/ethernet/netronome/nfp/bpf/main.h:is_mbpf_cond_jump
(Daniel)
- Further rebased on top of latest llvm-readelf change.
v2 -> v3:
- Added missed check on JMP32 inside bpf_jit_build_body. (Sandipan)
- Wrap ?: statements in s390 port with brace. They are used by macros
which doesn't guard the operand with brace.
- Fixed the ',' issues test_verifier change.
- Reorder two selftests patches to be near each other.
- Rebased on top of latest bpf-next.
v1 -> v2:
- Updated encoding. Use reserved insn class 0x6 instead of packing with
existing BPF_JMP. (Alexei)
- Updated code comments in s390 port. (Martin)
- Separate JIT function for jeq32_imm in NFP port. (Jakub)
- Re-implemented auto-testing support. (Jakub)
- Moved testcases to test_verifer.c, plus more unit tests. (Jakub)
- Fixed JEQ/JNE range deduction. (Jakub)
- Also supported JSET in this patch set.
- Fixed/Improved range deduction for all the other operations. All C
programs under bpf selftest passed verification now.
- Improved min/max code implementation.
- Fixed bpftool/disassembler.
Current eBPF ISA has 32-bit sub-register and has defined a set of ALU32
instructions.
However, there is no JMP32 instructions, the consequence is code-gen for
32-bit sub-registers is not efficient. For example, explicit sign-extension
from 32-bit to 64-bit is needed for signed comparison.
Adding JMP32 instruction therefore could complete eBPF ISA on 32-bit
sub-register support. This also match those JMP32 instructions in most JIT
backends, for example x64-64 and AArch64. These new eBPF JMP32 instructions
could have one-to-one map on them.
A few verifier ALU32 related bugs has been fixed recently, and JMP32
introduced by this set further improves BPF sub-register ecosystem. Once
this is landed, BPF programs using 32-bit sub-register ISA could get
reasonably good support from verifier and JIT compilers. Users then could
compare the runtime efficiency of one BPF program under both modes, and
could use the one shown better from benchmark result.
From benchmark results on some Cilium BPF programs, for 64-bit arches,
after JMP32 introduced, programs compiled with -mattr=+alu32 (meaning
enable sub-register usage) are smaller in code size and generally smaller
in verifier processed insn number.
Benchmark results
===
Text size in bytes (generated by "size")
---
LLVM code-gen option default alu32 alu32/jmp32 change Vs. change Vs.
alu32 default
bpf_lb-DLB_L3.o: 6456 6280 6160 -1.91% -4.58%
bpf_lb-DLB_L4.o: 7848 7664 7136 -6.89% -9.07%
bpf_lb-DUNKNOWN.o: 2680 2664 2568 -3.60% -4.18%
bpf_lxc.o: 104824 104744 97360 -7.05% -7.12%
bpf_netdev.o: 23456 23576 21632 -8.25% -7.78%
bpf_overlay.o: 16184 16304 14648 -10.16% -9.49%
Processed instruction number
---
LLVM code-gen option default alu32 alu32/jmp32 change Vs. change Vs.
alu32 default
bpf_lb-DLB_L3.o: 1579 1281 1295 +1.09% -17.99%
bpf_lb-DLB_L4.o: 2045 1663 1556 -6.43% -23.91%
bpf_lb-DUNKNOWN.o: 606 513 501 -2.34% -17.33%
bpf_lxc.o: 85381 103218 94435 -8.51% +10.60%
bpf_netdev.o: 5246 5809 5200 -10.48% -0.08%
bpf_overlay.o: 2443 2705 2456 -9.02% -0.53%
It is even better for 32-bit arches like x32, arm32 and nfp etc, as now
some conditional jump will become JMP32 which doesn't require code-gen for
high 32-bit comparison.
Encoding
===
The new JMP32 instructions are using new BPF_JMP32 class which is using
the reserved eBPF class number 0x6. And BPF_JA/CALL/EXIT only exist for
BPF_JMP, they are reserved opcode for BPF_JMP32.
LLVM support
===
A couple of unit tests has been added and included in this set. Also LLVM
code-gen for JMP32 has been added, so you could just compile any BPF C
program with both -mcpu=probe and -mattr=+alu32 specified. If you are
compiling on a machine with kernel patched by this set, LLVM will select
the ISA automatically based on host probe results. Otherwise specify
-mcpu=v3 and -mattr=+alu32 could also force use JMP32 ISA.
LLVM support could be found at:
https://github.com/Netronome/llvm/tree/jmp32-v2
(clang driver also taught about the new "v3" processor, will send out
merge request for both clang and llvm once kernel set landed.)
JIT backends support
===
A couple of JIT backends has been supported in this set except SPARC and
MIPS. It shouldn't be a big issue for these two ports as LLVM default won't
generate JMP32 insns, it will only generate them when host machine is
probed to be with the support.
Thanks.
====================
Acked-by: 
Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>