| Message ID | 20190115083518.10149-1-bjorn.topel@gmail.com |
|---|---|
| Headers | show |
| Series | RV64G eBPF JIT | expand |
Hi Björn, at least for me patch 3 didn't make it to the list. On Tue, Jan 15, 2019 at 09:35:15AM +0100, Björn Töpel wrote: > Hi! > > I've been hacking on a RV64G eBPF JIT compiler, and would like some > feedback. > > Codewise, it needs some refactoring. Currently there's a bit too much > copy-and-paste going on, and I know some places where I could optimize > the code generation a bit (mostly BPF_K type of instructions, dealing > with immediates). > > From a features perspective, two things are missing: > > * tail calls > * "far-branches", i.e. conditional branches that reach beyond 13b. > > The test_bpf.ko (only tested on 4.20!) passes all tests. > > I've done all the tests on QEMU (version 3.1.50), so no real hardware. > > Some questions/observations: > > * I've added "HAVE_EFFICIENT_UNALIGNED_ACCESS" to > arch/riscv/Kconfig. Is this assumption correct? > > * emit_imm() just relies on lui, adds and shifts. No fancy xori cost > optimizations like GCC does. > > * Suggestions on how to implement the tail call, given that the > prologue/epilogue has variable size. I will dig into the details of > mips/arm64/x86. :-) > > Next steps (prior patch proper) is cleaning up the code, add tail > calls, and making sure that bpftool disassembly works correctly. > > All input are welcome. This is my first RISC-V hack, so I sure there > are a lot things to improve! > > > Thanks, > Björn > > > Björn Töpel (3): > riscv: set HAVE_EFFICIENT_UNALIGNED_ACCESS > riscv: add build infra for JIT compiler > bpf, riscv: added eBPF JIT for RV64G > > arch/riscv/Kconfig | 2 + > arch/riscv/Makefile | 4 + > arch/riscv/net/Makefile | 5 + > arch/riscv/net/bpf_jit_comp.c | 1612 +++++++++++++++++++++++++++++++++ > 4 files changed, 1623 insertions(+) > create mode 100644 arch/riscv/net/Makefile > create mode 100644 arch/riscv/net/bpf_jit_comp.c > > -- > 2.19.1 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv ---end quoted text---
Den tis 15 jan. 2019 kl 16:40 skrev Christoph Hellwig <hch@infradead.org>: > > Hi Björn, > > at least for me patch 3 didn't make it to the list. > Hmm, held back: "Your message to linux-riscv awaits moderator approval". Exceeded the 40k limit. I'll wait until the moderator wakes up (Palmer?). Björn > On Tue, Jan 15, 2019 at 09:35:15AM +0100, Björn Töpel wrote: > > Hi! > > > > I've been hacking on a RV64G eBPF JIT compiler, and would like some > > feedback. > > > > Codewise, it needs some refactoring. Currently there's a bit too much > > copy-and-paste going on, and I know some places where I could optimize > > the code generation a bit (mostly BPF_K type of instructions, dealing > > with immediates). > > > > From a features perspective, two things are missing: > > > > * tail calls > > * "far-branches", i.e. conditional branches that reach beyond 13b. > > > > The test_bpf.ko (only tested on 4.20!) passes all tests. > > > > I've done all the tests on QEMU (version 3.1.50), so no real hardware. > > > > Some questions/observations: > > > > * I've added "HAVE_EFFICIENT_UNALIGNED_ACCESS" to > > arch/riscv/Kconfig. Is this assumption correct? > > > > * emit_imm() just relies on lui, adds and shifts. No fancy xori cost > > optimizations like GCC does. > > > > * Suggestions on how to implement the tail call, given that the > > prologue/epilogue has variable size. I will dig into the details of > > mips/arm64/x86. :-) > > > > Next steps (prior patch proper) is cleaning up the code, add tail > > calls, and making sure that bpftool disassembly works correctly. > > > > All input are welcome. This is my first RISC-V hack, so I sure there > > are a lot things to improve! > > > > > > Thanks, > > Björn > > > > > > Björn Töpel (3): > > riscv: set HAVE_EFFICIENT_UNALIGNED_ACCESS > > riscv: add build infra for JIT compiler > > bpf, riscv: added eBPF JIT for RV64G > > > > arch/riscv/Kconfig | 2 + > > arch/riscv/Makefile | 4 + > > arch/riscv/net/Makefile | 5 + > > arch/riscv/net/bpf_jit_comp.c | 1612 +++++++++++++++++++++++++++++++++ > > 4 files changed, 1623 insertions(+) > > create mode 100644 arch/riscv/net/Makefile > > create mode 100644 arch/riscv/net/bpf_jit_comp.c > > > > -- > > 2.19.1 > > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv > ---end quoted text---
On Tue, 15 Jan 2019 08:03:18 PST (-0800), bjorn.topel@gmail.com wrote: > Den tis 15 jan. 2019 kl 16:40 skrev Christoph Hellwig <hch@infradead.org>: >> >> Hi Björn, >> >> at least for me patch 3 didn't make it to the list. >> > > Hmm, held back: "Your message to linux-riscv awaits moderator > approval". Exceeded the 40k limit. > > I'll wait until the moderator wakes up (Palmer?). Sorry, it took me a while to wake up :) > > > Björn > >> On Tue, Jan 15, 2019 at 09:35:15AM +0100, Björn Töpel wrote: >> > Hi! >> > >> > I've been hacking on a RV64G eBPF JIT compiler, and would like some >> > feedback. >> > >> > Codewise, it needs some refactoring. Currently there's a bit too much >> > copy-and-paste going on, and I know some places where I could optimize >> > the code generation a bit (mostly BPF_K type of instructions, dealing >> > with immediates). >> > >> > From a features perspective, two things are missing: >> > >> > * tail calls >> > * "far-branches", i.e. conditional branches that reach beyond 13b. >> > >> > The test_bpf.ko (only tested on 4.20!) passes all tests. >> > >> > I've done all the tests on QEMU (version 3.1.50), so no real hardware. >> > >> > Some questions/observations: >> > >> > * I've added "HAVE_EFFICIENT_UNALIGNED_ACCESS" to >> > arch/riscv/Kconfig. Is this assumption correct? >> > >> > * emit_imm() just relies on lui, adds and shifts. No fancy xori cost >> > optimizations like GCC does. >> > >> > * Suggestions on how to implement the tail call, given that the >> > prologue/epilogue has variable size. I will dig into the details of >> > mips/arm64/x86. :-) >> > >> > Next steps (prior patch proper) is cleaning up the code, add tail >> > calls, and making sure that bpftool disassembly works correctly. >> > >> > All input are welcome. This is my first RISC-V hack, so I sure there >> > are a lot things to improve! >> > >> > >> > Thanks, >> > Björn >> > >> > >> > Björn Töpel (3): >> > riscv: set HAVE_EFFICIENT_UNALIGNED_ACCESS >> > riscv: add build infra for JIT compiler >> > bpf, riscv: added eBPF JIT for RV64G >> > >> > arch/riscv/Kconfig | 2 + >> > arch/riscv/Makefile | 4 + >> > arch/riscv/net/Makefile | 5 + >> > arch/riscv/net/bpf_jit_comp.c | 1612 +++++++++++++++++++++++++++++++++ >> > 4 files changed, 1623 insertions(+) >> > create mode 100644 arch/riscv/net/Makefile >> > create mode 100644 arch/riscv/net/bpf_jit_comp.c >> > >> > -- >> > 2.19.1 >> > >> > >> > _______________________________________________ >> > linux-riscv mailing list >> > linux-riscv@lists.infradead.org >> > http://lists.infradead.org/mailman/listinfo/linux-riscv >> ---end quoted text---
Hi, thanks for taking a shot at the eBPF JIT; this will be very useful. On Tue, 15 Jan 2019, Björn Töpel wrote: > * I've added "HAVE_EFFICIENT_UNALIGNED_ACCESS" to > arch/riscv/Kconfig. Is this assumption correct? From a hardware point of view, this is not the case on the Linux-capable RISC-V ASICs that the public can buy right now (to the best of my knowledge this is only the SiFive FU540). So I'd recommend not including this for now. - Paul
Den fre 25 jan. 2019 kl 20:54 skrev Paul Walmsley <paul.walmsley@sifive.com>: > > Hi, > > thanks for taking a shot at the eBPF JIT; this will be very useful. > > On Tue, 15 Jan 2019, Björn Töpel wrote: > > > * I've added "HAVE_EFFICIENT_UNALIGNED_ACCESS" to > > arch/riscv/Kconfig. Is this assumption correct? > > From a hardware point of view, this is not the case on the Linux-capable > RISC-V ASICs that the public can buy right now (to the best of my > knowledge this is only the SiFive FU540). > > So I'd recommend not including this for now. > Got it! Thanks for clearing that up for me! Hopefully, I'll find some time the coming week to get a v2 out with tail-call support and most comments addressed. Cheers, Björn > > - Paul
On Tue, 15 Jan 2019 00:35:15 PST (-0800), bjorn.topel@gmail.com wrote: > Hi! > > I've been hacking on a RV64G eBPF JIT compiler, and would like some > feedback. > > Codewise, it needs some refactoring. Currently there's a bit too much > copy-and-paste going on, and I know some places where I could optimize > the code generation a bit (mostly BPF_K type of instructions, dealing > with immediates). > > From a features perspective, two things are missing: > > * tail calls > * "far-branches", i.e. conditional branches that reach beyond 13b. > > The test_bpf.ko (only tested on 4.20!) passes all tests. > > I've done all the tests on QEMU (version 3.1.50), so no real hardware. > > Some questions/observations: > > * I've added "HAVE_EFFICIENT_UNALIGNED_ACCESS" to > arch/riscv/Kconfig. Is this assumption correct? > > * emit_imm() just relies on lui, adds and shifts. No fancy xori cost > optimizations like GCC does. > > * Suggestions on how to implement the tail call, given that the > prologue/epilogue has variable size. I will dig into the details of > mips/arm64/x86. :-) > > Next steps (prior patch proper) is cleaning up the code, add tail > calls, and making sure that bpftool disassembly works correctly. > > All input are welcome. This is my first RISC-V hack, so I sure there > are a lot things to improve! > > > Thanks, > Björn > > > Björn Töpel (3): > riscv: set HAVE_EFFICIENT_UNALIGNED_ACCESS > riscv: add build infra for JIT compiler > bpf, riscv: added eBPF JIT for RV64G > > arch/riscv/Kconfig | 2 + > arch/riscv/Makefile | 4 + > arch/riscv/net/Makefile | 5 + > arch/riscv/net/bpf_jit_comp.c | 1612 +++++++++++++++++++++++++++++++++ > 4 files changed, 1623 insertions(+) > create mode 100644 arch/riscv/net/Makefile > create mode 100644 arch/riscv/net/bpf_jit_comp.c Thanks for doing this. I saw a few reviews go by and I'm behind on email, so I'm going to drop this until a v2.