From: Jiong Wang <jiong.wang@netronome.com>
To: Luke Nelson <lukenels@cs.washington.edu>
Cc: "Luke Nelson" <luke.r.nels@gmail.com>,
"Xi Wang" <xi.wang@gmail.com>,
"Palmer Dabbelt" <palmer@sifive.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Martin KaFai Lau" <kafai@fb.com>,
"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>,
"Björn Töpel" <bjorn.topel@gmail.com>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next] RV32G eBPF JIT
Date: Mon, 24 Jun 2019 17:45:45 +0100 [thread overview]
Message-ID: <87h88f9bm3.fsf@netronome.com> (raw)
In-Reply-To: <20190621225938.27030-1-lukenels@cs.washington.edu>
Luke Nelson writes:
> From: Luke Nelson <luke.r.nels@gmail.com>
>
> This is an eBPF JIT for RV32G, adapted from the JIT for RV64G.
> Any feedback would be greatly appreciated.
>
> It passes 359 out of 378 tests in test_bpf.ko. The failing tests are
> features that are not supported right now:
> - ALU64 DIV/MOD:
> These require loops to emulate on 32-bit hardware,
> and are not supported on other 32-bit JITs like
> ARM32.
> - BPF_XADD | BPF_DW:
> RV32G does not have atomic instructions for operating
> on double words. This is similar to ARM32.
> - Tail calls:
> I'm working on adding support for these now, but couldn't
> find any test cases that use them. What's the best way
> of testing tail call code?
> - Far branches
> These are not supported in RV64G either.
>
> There are two main changes required for this to work compared to the
> RV64 JIT.
>
> First, eBPF registers are 64-bit, while RV32G registers are 32-bit.
> I take an approach similar to ARM32: most BPF registers map directly to
> 2 RISC-V registers, while some reside in stack scratch space and must
> be saved / restored when used.
>
> Second, many 64-bit ALU operations do not trivially map to 32-bit
> operations. Operations that move bits between high and low words, such
> as ADD, LSH, MUL, and others must emulate the 64-bit behavior in terms
> of 32-bit instructions.
>
> Signed-off-by: Luke Nelson <luke.r.nels@gmail.com>
> Cc: Xi Wang <xi.wang@gmail.com>
> ---
> arch/riscv/Kconfig | 2 +-
> arch/riscv/net/Makefile | 7 +-
> arch/riscv/net/bpf_jit_comp32.c | 1460 +++++++++++++++++++++++++++++++
> 3 files changed, 1467 insertions(+), 2 deletions(-)
> create mode 100644 arch/riscv/net/bpf_jit_comp32.c
>
<snip>
> +static void rv32_bpf_put_reg32(const s8 *reg, const s8 *src,
> + struct rv_jit_context *ctx)
> +{
> + if (is_stacked(reg[1])) {
> + emit(rv_sw(RV_REG_FP, reg[1], src[1]), ctx);
> + emit(rv_sw(RV_REG_FP, reg[0], RV_REG_ZERO), ctx);
> + } else {
> + emit(rv_addi(reg[0], RV_REG_ZERO, 0), ctx);
> + }
> +}
> +
Looks to me 32-bit optimization is not enabled.
If you define bpf_jit_needs_zext to return true
bool bpf_jit_needs_zext(void)
{
return true;
}
Then you don't need to zero high 32-bit when writing 32-bit sub-register
and you just need to implement the explicit zero extension insn which is a
special variant of BPF_MOV. This can save quite a few instructions. RV64
and arches like arm has implemented this, please search
"aux->verifier_zext".
And there is a doc for this optimization:
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/Documentation/bpf/bpf_design_QA.rst#n168
Regards,
Jiong
WARNING: multiple messages have this Message-ID (diff)
From: Jiong Wang <jiong.wang@netronome.com>
To: Luke Nelson <lukenels@cs.washington.edu>
Cc: "Song Liu" <songliubraving@fb.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
bpf@vger.kernel.org, "Daniel Borkmann" <daniel@iogearbox.net>,
"Luke Nelson" <luke.r.nels@gmail.com>,
"Björn Töpel" <bjorn.topel@gmail.com>,
"Palmer Dabbelt" <palmer@sifive.com>,
"Alexei Starovoitov" <ast@kernel.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
"Yonghong Song" <yhs@fb.com>,
linux-riscv@lists.infradead.org,
"Martin KaFai Lau" <kafai@fb.com>, "Xi Wang" <xi.wang@gmail.com>
Subject: Re: [RFC PATCH bpf-next] RV32G eBPF JIT
Date: Mon, 24 Jun 2019 17:45:45 +0100 [thread overview]
Message-ID: <87h88f9bm3.fsf@netronome.com> (raw)
In-Reply-To: <20190621225938.27030-1-lukenels@cs.washington.edu>
Luke Nelson writes:
> From: Luke Nelson <luke.r.nels@gmail.com>
>
> This is an eBPF JIT for RV32G, adapted from the JIT for RV64G.
> Any feedback would be greatly appreciated.
>
> It passes 359 out of 378 tests in test_bpf.ko. The failing tests are
> features that are not supported right now:
> - ALU64 DIV/MOD:
> These require loops to emulate on 32-bit hardware,
> and are not supported on other 32-bit JITs like
> ARM32.
> - BPF_XADD | BPF_DW:
> RV32G does not have atomic instructions for operating
> on double words. This is similar to ARM32.
> - Tail calls:
> I'm working on adding support for these now, but couldn't
> find any test cases that use them. What's the best way
> of testing tail call code?
> - Far branches
> These are not supported in RV64G either.
>
> There are two main changes required for this to work compared to the
> RV64 JIT.
>
> First, eBPF registers are 64-bit, while RV32G registers are 32-bit.
> I take an approach similar to ARM32: most BPF registers map directly to
> 2 RISC-V registers, while some reside in stack scratch space and must
> be saved / restored when used.
>
> Second, many 64-bit ALU operations do not trivially map to 32-bit
> operations. Operations that move bits between high and low words, such
> as ADD, LSH, MUL, and others must emulate the 64-bit behavior in terms
> of 32-bit instructions.
>
> Signed-off-by: Luke Nelson <luke.r.nels@gmail.com>
> Cc: Xi Wang <xi.wang@gmail.com>
> ---
> arch/riscv/Kconfig | 2 +-
> arch/riscv/net/Makefile | 7 +-
> arch/riscv/net/bpf_jit_comp32.c | 1460 +++++++++++++++++++++++++++++++
> 3 files changed, 1467 insertions(+), 2 deletions(-)
> create mode 100644 arch/riscv/net/bpf_jit_comp32.c
>
<snip>
> +static void rv32_bpf_put_reg32(const s8 *reg, const s8 *src,
> + struct rv_jit_context *ctx)
> +{
> + if (is_stacked(reg[1])) {
> + emit(rv_sw(RV_REG_FP, reg[1], src[1]), ctx);
> + emit(rv_sw(RV_REG_FP, reg[0], RV_REG_ZERO), ctx);
> + } else {
> + emit(rv_addi(reg[0], RV_REG_ZERO, 0), ctx);
> + }
> +}
> +
Looks to me 32-bit optimization is not enabled.
If you define bpf_jit_needs_zext to return true
bool bpf_jit_needs_zext(void)
{
return true;
}
Then you don't need to zero high 32-bit when writing 32-bit sub-register
and you just need to implement the explicit zero extension insn which is a
special variant of BPF_MOV. This can save quite a few instructions. RV64
and arches like arm has implemented this, please search
"aux->verifier_zext".
And there is a doc for this optimization:
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/Documentation/bpf/bpf_design_QA.rst#n168
Regards,
Jiong
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2019-06-24 16:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-21 22:59 [RFC PATCH bpf-next] RV32G eBPF JIT Luke Nelson
2019-06-21 22:59 ` Luke Nelson
2019-06-24 10:11 ` Björn Töpel
2019-06-24 10:11 ` Björn Töpel
2019-06-26 23:20 ` Luke Nelson
2019-06-26 23:20 ` Luke Nelson
2019-06-24 16:45 ` Jiong Wang [this message]
2019-06-24 16:45 ` Jiong Wang
2019-06-25 20:26 ` Luke Nelson
2019-06-25 20:26 ` Luke Nelson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h88f9bm3.fsf@netronome.com \
--to=jiong.wang@netronome.com \
--cc=aou@eecs.berkeley.edu \
--cc=ast@kernel.org \
--cc=bjorn.topel@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kafai@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=luke.r.nels@gmail.com \
--cc=lukenels@cs.washington.edu \
--cc=netdev@vger.kernel.org \
--cc=palmer@sifive.com \
--cc=songliubraving@fb.com \
--cc=xi.wang@gmail.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.