| Message ID | 1405708100-13604-1-git-send-email-zlim.lnx@gmail.com |
|---|---|
| State | New |
| Headers | show |
Hello, On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote: > This series implements eBPF JIT compiler for arm64. > Please see [14/14] for change log. > > Patches [1-13/14] implement code generation functions. > Patch [14/14] implements the actual eBPF JIT compiler. > > Many thanks to everyone who's reviewed the code from > RFCv1->RFCv3, especially Alexei for BPF bits, and Will > for ARM64 codegen bits :) > > BTW, I'm happy to maintain arch/arm64/net (i.e. arm64 BPF bits). > Should I add a patch updating MAINTAINERS as Patch 15? I don't think that's necessary at the moment, but if we start seeing an influx of patches to arch/arm64/net, then that could make sense in the future. > This series requires a patch that exports a function > from net/core (resulting from RFCv1 discussion). This patch > has been merged into net-next @ 9f12fbe603f7 > ("net: filter: move load_pointer() into filter.h"). > > This series applies against net-next and is tested working > with lib/test_bpf on ARMv8 Foundation Model. Looks like it works on my Juno board too, so: Acked-by: Will Deacon <will.deacon@arm.com> for the series. It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which also means the dependency on -next isn't an issue). Perhaps you could repost around -rc3? Cheers, Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon <will.deacon@arm.com> wrote: > Hello, > > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote: >> This series implements eBPF JIT compiler for arm64. >> Please see [14/14] for change log. >> >> Patches [1-13/14] implement code generation functions. >> Patch [14/14] implements the actual eBPF JIT compiler. >> >> Many thanks to everyone who's reviewed the code from >> RFCv1->RFCv3, especially Alexei for BPF bits, and Will >> for ARM64 codegen bits :) >> >> BTW, I'm happy to maintain arch/arm64/net (i.e. arm64 BPF bits). >> Should I add a patch updating MAINTAINERS as Patch 15? > > I don't think that's necessary at the moment, but if we start seeing an > influx of patches to arch/arm64/net, then that could make sense in the > future. > >> This series requires a patch that exports a function >> from net/core (resulting from RFCv1 discussion). This patch >> has been merged into net-next @ 9f12fbe603f7 >> ("net: filter: move load_pointer() into filter.h"). >> >> This series applies against net-next and is tested working >> with lib/test_bpf on ARMv8 Foundation Model. > > Looks like it works on my Juno board too, so: > > Acked-by: Will Deacon <will.deacon@arm.com> > > for the series. > > It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which > also means the dependency on -next isn't an issue). Perhaps you could repost > around -rc3? Thanks for testing! Nice to see it working on real hw. I'm not sure why you're proposing a 4+ week delay. The patches will rot instead of getting used and tested. Imo it makes sense to get them into net-next now for 3.17. JIT is disabled by sysctl by default anyway. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote: > On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon <will.deacon@arm.com> wrote: > > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote: > >> This series implements eBPF JIT compiler for arm64. > >> Please see [14/14] for change log. > >> > >> Patches [1-13/14] implement code generation functions. > >> Patch [14/14] implements the actual eBPF JIT compiler. > >> > >> Many thanks to everyone who's reviewed the code from > >> RFCv1->RFCv3, especially Alexei for BPF bits, and Will > >> for ARM64 codegen bits :) > >> > >> BTW, I'm happy to maintain arch/arm64/net (i.e. arm64 BPF bits). > >> Should I add a patch updating MAINTAINERS as Patch 15? > > > > I don't think that's necessary at the moment, but if we start seeing an > > influx of patches to arch/arm64/net, then that could make sense in the > > future. > > > >> This series requires a patch that exports a function > >> from net/core (resulting from RFCv1 discussion). This patch > >> has been merged into net-next @ 9f12fbe603f7 > >> ("net: filter: move load_pointer() into filter.h"). > >> > >> This series applies against net-next and is tested working > >> with lib/test_bpf on ARMv8 Foundation Model. > > > > Looks like it works on my Juno board too, so: > > > > Acked-by: Will Deacon <will.deacon@arm.com> > > > > for the series. > > > > It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which > > also means the dependency on -next isn't an issue). Perhaps you could repost > > around -rc3? > > Thanks for testing! Nice to see it working on real hw. > I'm not sure why you're proposing a 4+ week delay. The patches > will rot instead of getting used and tested. Imo it makes sense to > get them into net-next now for 3.17. > JIT is disabled by sysctl by default anyway. We normally like some patches (especially new functionality) to sit in linux-next for a while before the mering window (ideally starting with -rc4 or -rc5). We are at -rc6 already, so getting close to the 3.17 merging window. Another aspect is that the arm64/bpf branch depends on the net tree, so it can't easily go in via the arm64 tree for 3.17 (3.18 would not be a problem).
On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote: >> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon <will.deacon@arm.com> wrote: >> > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote: [...] >> >> This series applies against net-next and is tested working >> >> with lib/test_bpf on ARMv8 Foundation Model. >> > >> > Looks like it works on my Juno board too, so: >> > >> > Acked-by: Will Deacon <will.deacon@arm.com> >> > >> > for the series. >> > >> > It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which >> > also means the dependency on -next isn't an issue). Perhaps you could repost >> > around -rc3? >> >> Thanks for testing! Nice to see it working on real hw. >> I'm not sure why you're proposing a 4+ week delay. The patches >> will rot instead of getting used and tested. Imo it makes sense to >> get them into net-next now for 3.17. >> JIT is disabled by sysctl by default anyway. > > We normally like some patches (especially new functionality) to sit in > linux-next for a while before the mering window (ideally starting with > -rc4 or -rc5). We are at -rc6 already, so getting close to the 3.17 > merging window. > > Another aspect is that the arm64/bpf branch depends on the net tree, so > it can't easily go in via the arm64 tree for 3.17 (3.18 would not be a > problem). Hi Catalin, I take it you prefer this series going through arm64 tree, targeting 3.18, is that right? I understand your preference to have it sitting in linux-next for a longer period for arm64 material, I'll repost this again after 3.17 so it gets more exposure in linux-next. BTW, are you open to this series going through net tree? I'm (preemptively) asking because during development of this series, I've had to rebase a couple times against net-next to handle dependencies. Or is the general practice to handle conflicts in linux-next itself? > > -- > Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Thu, Jul 24, 2014 at 05:55:36AM +0100, Z Lim wrote: > On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas > <catalin.marinas@arm.com> wrote: > > On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote: > >> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon <will.deacon@arm.com> wrote: > >> > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote: > [...] > >> >> This series applies against net-next and is tested working > >> >> with lib/test_bpf on ARMv8 Foundation Model. > >> > > >> > Looks like it works on my Juno board too, so: > >> > > >> > Acked-by: Will Deacon <will.deacon@arm.com> > >> > > >> > for the series. > >> > > >> > It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which > >> > also means the dependency on -next isn't an issue). Perhaps you could repost > >> > around -rc3? > >> > >> Thanks for testing! Nice to see it working on real hw. > >> I'm not sure why you're proposing a 4+ week delay. The patches > >> will rot instead of getting used and tested. Imo it makes sense to > >> get them into net-next now for 3.17. > >> JIT is disabled by sysctl by default anyway. > > > > We normally like some patches (especially new functionality) to sit in > > linux-next for a while before the mering window (ideally starting with > > -rc4 or -rc5). We are at -rc6 already, so getting close to the 3.17 > > merging window. > > > > Another aspect is that the arm64/bpf branch depends on the net tree, so > > it can't easily go in via the arm64 tree for 3.17 (3.18 would not be a > > problem). > > Hi Catalin, I take it you prefer this series going through arm64 tree, > targeting 3.18, is that right? Right. > I understand your preference to have it sitting in linux-next for a > longer period for arm64 material, I'll repost this again after 3.17 so > it gets more exposure in linux-next. Brill, thanks! > BTW, are you open to this series going through net tree? I'm > (preemptively) asking because during development of this series, I've > had to rebase a couple times against net-next to handle dependencies. > Or is the general practice to handle conflicts in linux-next itself? We don't have a problem with it going via the -net tree if there's a reason for doing so (i.e. a new dependency that crops up after your rebase) but we should stick with the arm64 tree if we can. Cheers, Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hi Z Lim, On Thu, Jul 24, 2014 at 05:55:36AM +0100, Z Lim wrote: > On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas > <catalin.marinas@arm.com> wrote: > > On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote: > >> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon <will.deacon@arm.com> wrote: > >> > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote: > [...] > >> >> This series applies against net-next and is tested working > >> >> with lib/test_bpf on ARMv8 Foundation Model. > >> > > >> > Looks like it works on my Juno board too, so: > >> > > >> > Acked-by: Will Deacon <will.deacon@arm.com> > >> > > >> > for the series. > >> > > >> > It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which > >> > also means the dependency on -next isn't an issue). Perhaps you could repost > >> > around -rc3? > >> > >> Thanks for testing! Nice to see it working on real hw. > >> I'm not sure why you're proposing a 4+ week delay. The patches > >> will rot instead of getting used and tested. Imo it makes sense to > >> get them into net-next now for 3.17. > >> JIT is disabled by sysctl by default anyway. > > > > We normally like some patches (especially new functionality) to sit in > > linux-next for a while before the mering window (ideally starting with > > -rc4 or -rc5). We are at -rc6 already, so getting close to the 3.17 > > merging window. > > > > Another aspect is that the arm64/bpf branch depends on the net tree, so > > it can't easily go in via the arm64 tree for 3.17 (3.18 would not be a > > problem). > > Hi Catalin, I take it you prefer this series going through arm64 tree, > targeting 3.18, is that right? > > I understand your preference to have it sitting in linux-next for a > longer period for arm64 material, I'll repost this again after 3.17 so > it gets more exposure in linux-next. Any chance you could post a new version of this, based on a 3.17 -rc, please? Whilst your current patches apply, I get a bunch of errors if I try to build them. Cheers, Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hi Will, On Tue, Aug 26, 2014 at 2:58 AM, Will Deacon <will.deacon@arm.com> wrote: > Hi Z Lim, > > On Thu, Jul 24, 2014 at 05:55:36AM +0100, Z Lim wrote: >> On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas >> <catalin.marinas@arm.com> wrote: >> > On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote: >> >> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon <will.deacon@arm.com> wrote: >> >> > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote: >> [...] >> >> >> This series applies against net-next and is tested working >> >> >> with lib/test_bpf on ARMv8 Foundation Model. >> >> > >> >> > Looks like it works on my Juno board too, so: >> >> > >> >> > Acked-by: Will Deacon <will.deacon@arm.com> >> >> > >> >> > for the series. >> >> > >> >> > It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which >> >> > also means the dependency on -next isn't an issue). Perhaps you could repost >> >> > around -rc3? >> >> >> >> Thanks for testing! Nice to see it working on real hw. >> >> I'm not sure why you're proposing a 4+ week delay. The patches >> >> will rot instead of getting used and tested. Imo it makes sense to >> >> get them into net-next now for 3.17. >> >> JIT is disabled by sysctl by default anyway. >> > >> > We normally like some patches (especially new functionality) to sit in >> > linux-next for a while before the mering window (ideally starting with >> > -rc4 or -rc5). We are at -rc6 already, so getting close to the 3.17 >> > merging window. >> > >> > Another aspect is that the arm64/bpf branch depends on the net tree, so >> > it can't easily go in via the arm64 tree for 3.17 (3.18 would not be a >> > problem). >> >> Hi Catalin, I take it you prefer this series going through arm64 tree, >> targeting 3.18, is that right? >> >> I understand your preference to have it sitting in linux-next for a >> longer period for arm64 material, I'll repost this again after 3.17 so >> it gets more exposure in linux-next. > > Any chance you could post a new version of this, based on a 3.17 -rc, > please? Whilst your current patches apply, I get a bunch of errors if I try > to build them. Sure. I just rebased onto -rc2 and fixed up as necessary due to changes introduced in net. I'll post a v2 shortly. Thanks for the reminder :) z > > Cheers, > > Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This series implements eBPF JIT compiler for arm64. Please see [14/14] for change log. Patches [1-13/14] implement code generation functions. Patch [14/14] implements the actual eBPF JIT compiler. Many thanks to everyone who's reviewed the code from RFCv1->RFCv3, especially Alexei for BPF bits, and Will for ARM64 codegen bits :) BTW, I'm happy to maintain arch/arm64/net (i.e. arm64 BPF bits). Should I add a patch updating MAINTAINERS as Patch 15? This series requires a patch that exports a function from net/core (resulting from RFCv1 discussion). This patch has been merged into net-next @ 9f12fbe603f7 ("net: filter: move load_pointer() into filter.h"). This series applies against net-next and is tested working with lib/test_bpf on ARMv8 Foundation Model. ----- The following changes since commit da388973d4a15e71cada1219d625b5393c90e5ae: iw_cxgb4: fix for 64-bit integer division (2014-07-17 16:52:08 -0700) are available in the git repository at: https://github.com/zlim/linux.git arm64/bpf for you to fetch changes up to eef34dcb8bb9a3712091e0cdea4a1c3a6e42912a: arm64: eBPF JIT compiler (2014-07-18 11:06:28 -0700) ---------------------------------------------------------------- Zi Shen Lim (14): arm64: introduce aarch64_insn_gen_comp_branch_imm() arm64: introduce aarch64_insn_gen_branch_reg() arm64: introduce aarch64_insn_gen_cond_branch_imm() arm64: introduce aarch64_insn_gen_load_store_reg() arm64: introduce aarch64_insn_gen_load_store_pair() arm64: introduce aarch64_insn_gen_add_sub_imm() arm64: introduce aarch64_insn_gen_bitfield() arm64: introduce aarch64_insn_gen_movewide() arm64: introduce aarch64_insn_gen_add_sub_shifted_reg() arm64: introduce aarch64_insn_gen_data1() arm64: introduce aarch64_insn_gen_data2() arm64: introduce aarch64_insn_gen_data3() arm64: introduce aarch64_insn_gen_logical_shifted_reg() arm64: eBPF JIT compiler Documentation/networking/filter.txt | 2 +- arch/arm64/Kconfig | 1 + arch/arm64/Makefile | 1 + arch/arm64/include/asm/insn.h | 249 +++++++++++++ arch/arm64/kernel/insn.c | 646 +++++++++++++++++++++++++++++++++- arch/arm64/net/Makefile | 4 + arch/arm64/net/bpf_jit.h | 169 +++++++++ arch/arm64/net/bpf_jit_comp.c | 677 ++++++++++++++++++++++++++++++++++++ 8 files changed, 1741 insertions(+), 8 deletions(-) create mode 100644 arch/arm64/net/Makefile create mode 100644 arch/arm64/net/bpf_jit.h create mode 100644 arch/arm64/net/bpf_jit_comp.c