On Thu, May 25, 2017 at 05:38:26PM -0700, David Daney wrote: > Since the eBPF machine has 64-bit registers, we only support this in > 64-bit kernels. As of the writing of this commit log test-bpf is showing: > > test_bpf: Summary: 316 PASSED, 0 FAILED, [308/308 JIT'ed] > > All current test cases are successfully compiled. > > Signed-off-by: David Daney <david.daney@xxxxxxxxxx> > --- > arch/mips/Kconfig | 1 + > arch/mips/net/bpf_jit.c | 1627 ++++++++++++++++++++++++++++++++++++++++++++++- > arch/mips/net/bpf_jit.h | 7 + > 3 files changed, 1633 insertions(+), 2 deletions(-) Great stuff. I wonder what is the performance difference interpreter vs JIT > + * eBPF stack frame will be something like: > + * > + * Entry $sp ------> +--------------------------------+ > + * | $ra (optional) | > + * +--------------------------------+ > + * | $s0 (optional) | > + * +--------------------------------+ > + * | $s1 (optional) | > + * +--------------------------------+ > + * | $s2 (optional) | > + * +--------------------------------+ > + * | $s3 (optional) | > + * +--------------------------------+ > + * | tmp-storage (if $ra saved) | > + * $sp + tmp_offset --> +--------------------------------+ <--BPF_REG_10 > + * | BPF_REG_10 relative storage | > + * | MAX_BPF_STACK (optional) | > + * | . | > + * | . | > + * | . | > + * $sp --------> +--------------------------------+ > + * > + * If BPF_REG_10 is never referenced, then the MAX_BPF_STACK sized > + * area is not allocated. > + */ It's especially great to see that you've put the tmp storage above program stack and made the stack allocation optional. At the moment I'm working on reducing bpf program stack size, so that JIT and interpreter can use only the stack they need. Looking at this JIT code only minimal changes will be needed.
