Message ID | 20180711093033.GP17271@n2100.armlinux.org.uk |
---|---|
Headers | show |
Series | ARM BPF jit compiler improvements | expand |
On 07/11/2018 11:30 AM, Russell King - ARM Linux wrote: > Hi, > > This series improves the ARM BPF JIT compiler by: > - enumerating the stack layout rather than using constants that happen > to be multiples of four > - rejig the BPF "register" accesses to use negative numbers instead of > positive, which could be confused with register numbers in the bpf2a32 > array. > - since we maintain the ARM FP register as a pointer to the top of our > scratch space (or, with frame pointers enabled, a valid ARM frame > pointer register), we can access our scratch space using FP, which is > constant across all BPF programs, including tail-called programs. > - use immediate forms of ARM instructions where possible, rather than > first loading the immediate into an ARM register. > - use load-with-shift instruction rather than seperate shift instruction > followed by load > - avoid reloading index and array in the tail-call code > - use double-word load/store instructions where available > > Version 2: > - Fix ARMv5 test pointed out by Olof > - Fix build error found by 0-day (adding an additional patch) > > arch/arm/net/bpf_jit_32.c | 982 ++++++++++++++++++++++++---------------------- > arch/arm/net/bpf_jit_32.h | 42 +- > 2 files changed, 543 insertions(+), 481 deletions(-) Applied to bpf-next, thanks a lot Russell!
On Thu, Jul 12, 2018 at 09:02:41PM +0200, Daniel Borkmann wrote:
> Applied to bpf-next, thanks a lot Russell!
Thanks, I've just sent four more patches, which is the sum total of
what I'm intending to send for BPF improvements for the next merge
window.
On 07/12/2018 11:02 PM, Russell King - ARM Linux wrote: > On Thu, Jul 12, 2018 at 09:02:41PM +0200, Daniel Borkmann wrote: >> Applied to bpf-next, thanks a lot Russell! > > Thanks, I've just sent four more patches, which is the sum total of > what I'm intending to send for BPF improvements for the next merge > window. Great, thanks a lot for the batch of improvements, Russell! Did you manage to get the BPF kselftest suite working on arm32 under tools/testing/selftests/bpf/? In particular the test_verfier with bpf_jit_enabled set to 1 and test_kmod.sh has a bigger number of runtime tests that would stress it. Thanks, Daniel
On Thu, Jul 12, 2018 at 11:12:45PM +0200, Daniel Borkmann wrote: > On 07/12/2018 11:02 PM, Russell King - ARM Linux wrote: > > On Thu, Jul 12, 2018 at 09:02:41PM +0200, Daniel Borkmann wrote: > >> Applied to bpf-next, thanks a lot Russell! > > > > Thanks, I've just sent four more patches, which is the sum total of > > what I'm intending to send for BPF improvements for the next merge > > window. > > Great, thanks a lot for the batch of improvements, Russell! > > Did you manage to get the BPF kselftest suite working on arm32 under > tools/testing/selftests/bpf/? In particular the test_verfier with > bpf_jit_enabled set to 1 and test_kmod.sh has a bigger number of > runtime tests that would stress it. I have a big issue with almost all of the tools/ subdirectory, and that is that it isn't "portable". It seems that cross-build environments just weren't considered when the tools subdirectory was created - it appears to require the entire kernel tree and build tree to be accessible on the target in order to build almost everything there. (I also exclusively do split-object builds, I never do an in-source-tree build.) At least perf has the ability to ask Kbuild to package it up as a tar.* file. That can be easily transported to the target as a self-contained buildable tree, and then be able to built from that. My cross-build environment for the kernel is just for building kernels, it does not have the facilities to build for userspace - I have a wide range of userspaces across targets, with a multitude of different glibc versions, and even when they're compatible versions, they're built differently. As far as I can see, basically, most tools/ stuff requires too much effort to work around this to be of any use to me. Even if I did unpick it from the kernel source tree by hand, that would be wasted effort, because I'd need to repeat that same process whenever anything there gets updated.
On 07/12/2018 11:35 PM, Russell King - ARM Linux wrote: > On Thu, Jul 12, 2018 at 11:12:45PM +0200, Daniel Borkmann wrote: >> On 07/12/2018 11:02 PM, Russell King - ARM Linux wrote: >>> On Thu, Jul 12, 2018 at 09:02:41PM +0200, Daniel Borkmann wrote: >>>> Applied to bpf-next, thanks a lot Russell! >>> >>> Thanks, I've just sent four more patches, which is the sum total of >>> what I'm intending to send for BPF improvements for the next merge >>> window. >> >> Great, thanks a lot for the batch of improvements, Russell! >> >> Did you manage to get the BPF kselftest suite working on arm32 under >> tools/testing/selftests/bpf/? In particular the test_verfier with >> bpf_jit_enabled set to 1 and test_kmod.sh has a bigger number of >> runtime tests that would stress it. > > I have a big issue with almost all of the tools/ subdirectory, and > that is that it isn't "portable". > > It seems that cross-build environments just weren't considered when > the tools subdirectory was created - it appears to require the entire > kernel tree and build tree to be accessible on the target in order > to build almost everything there. (I also exclusively do split-object > builds, I never do an in-source-tree build.) > > At least perf has the ability to ask Kbuild to package it up as a > tar.* file. That can be easily transported to the target as a > self-contained buildable tree, and then be able to built from that. > > My cross-build environment for the kernel is just for building > kernels, it does not have the facilities to build for userspace - I > have a wide range of userspaces across targets, with a multitude of > different glibc versions, and even when they're compatible versions, > they're built differently. > > As far as I can see, basically, most tools/ stuff requires too much > effort to work around this to be of any use to me. Even if I did > unpick it from the kernel source tree by hand, that would be wasted > effort, because I'd need to repeat that same process whenever > anything there gets updated. Right, that's unfortunate, although there is one option which you could try out. The test_kmod.sh does nothing more than insmodding the test_bpf kernel module built from lib/test_bpf.c. This one at least has all the cBPF tests and a couple of eBPF ones (though most for the latter have been moved to test_verfier). You can enable it via CONFIG_TEST_BPF=m and then load it with bpf_jit_enabled set to 1. Hope that helps a bit. Thanks, Daniel