From: "Björn Töpel" <bjorn.topel@gmail.com>
To: Palmer Dabbelt <palmerdabbelt@google.com>
Cc: Netdev <netdev@vger.kernel.org>,
linux-riscv@lists.infradead.org, bpf <bpf@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH bpf-next v2 7/9] riscv, bpf: optimize calls
Date: Tue, 7 Jan 2020 11:14:17 +0100 [thread overview]
Message-ID: <CAJ+HfNhvTdsBq_tmKNcxVdS=nro=jwL5yLxnyDXO02Vai+5YNg@mail.gmail.com> (raw)
In-Reply-To: <mhng-041b1051-f9ac-4cd8-95bf-731bb1bfbdb8@palmerdabbelt-glaptop>
On Mon, 23 Dec 2019 at 19:58, Palmer Dabbelt <palmerdabbelt@google.com> wrote:
>
> On Mon, 16 Dec 2019 01:13:41 PST (-0800), Bjorn Topel wrote:
> > Instead of using emit_imm() and emit_jalr() which can expand to six
> > instructions, start using jal or auipc+jalr.
> >
> > Signed-off-by: Björn Töpel <bjorn.topel@gmail.com>
> > ---
> > arch/riscv/net/bpf_jit_comp.c | 101 +++++++++++++++++++++-------------
> > 1 file changed, 64 insertions(+), 37 deletions(-)
> >
> > diff --git a/arch/riscv/net/bpf_jit_comp.c b/arch/riscv/net/bpf_jit_comp.c
> > index 46cff093f526..8d7e3343a08c 100644
> > --- a/arch/riscv/net/bpf_jit_comp.c
> > +++ b/arch/riscv/net/bpf_jit_comp.c
> > @@ -811,11 +811,12 @@ static void emit_sext_32_rd(u8 *rd, struct rv_jit_context *ctx)
> > *rd = RV_REG_T2;
> > }
> >
> > -static void emit_jump_and_link(u8 rd, int rvoff, struct rv_jit_context *ctx)
> > +static void emit_jump_and_link(u8 rd, s64 rvoff, bool force_jalr,
> > + struct rv_jit_context *ctx)
> > {
> > s64 upper, lower;
> >
> > - if (is_21b_int(rvoff)) {
> > + if (rvoff && is_21b_int(rvoff) && !force_jalr) {
> > emit(rv_jal(rd, rvoff >> 1), ctx);
> > return;
> > }
> > @@ -832,6 +833,28 @@ static bool is_signed_bpf_cond(u8 cond)
> > cond == BPF_JSGE || cond == BPF_JSLE;
> > }
> >
> > +static int emit_call(bool fixed, u64 addr, struct rv_jit_context *ctx)
> > +{
> > + s64 off = 0;
> > + u64 ip;
> > + u8 rd;
> > +
> > + if (addr && ctx->insns) {
> > + ip = (u64)(long)(ctx->insns + ctx->ninsns);
> > + off = addr - ip;
> > + if (!is_32b_int(off)) {
> > + pr_err("bpf-jit: target call addr %pK is out of range\n",
> > + (void *)addr);
> > + return -ERANGE;
> > + }
> > + }
> > +
> > + emit_jump_and_link(RV_REG_RA, off, !fixed, ctx);
> > + rd = bpf_to_rv_reg(BPF_REG_0, ctx);
> > + emit(rv_addi(rd, RV_REG_A0, 0), ctx);
>
> Why are they out of order? It seems like it'd be better to just have the BPF
> calling convention match the RISC-V calling convention, as that'd avoid
> juggling the registers around.
>
BPF passes arguments in R1, R2, ..., and return value in R0. Given
that a0 plays the role of R1 and R0, how can we avoid the register
juggling (without complicating the JIT too much)? It would be nice
though... and ARM64 has the same concern AFAIK.
[...]
> > @@ -1599,36 +1611,51 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
> > for (i = 0; i < 16; i++) {
> > pass++;
> > ctx->ninsns = 0;
> > - if (build_body(ctx, extra_pass)) {
> > + if (build_body(ctx, extra_pass, ctx->offset)) {
> > prog = orig_prog;
> > goto out_offset;
> > }
> > build_prologue(ctx);
> > ctx->epilogue_offset = ctx->ninsns;
> > build_epilogue(ctx);
> > - if (ctx->ninsns == prev_ninsns)
> > - break;
> > +
> > + if (ctx->ninsns == prev_ninsns) {
> > + if (jit_data->header)
> > + break;
> > +
> > + image_size = sizeof(u32) * ctx->ninsns;
> > + jit_data->header =
> > + bpf_jit_binary_alloc(image_size,
> > + &jit_data->image,
> > + sizeof(u32),
> > + bpf_fill_ill_insns);
> > + if (!jit_data->header) {
> > + prog = orig_prog;
> > + goto out_offset;
> > + }
> > +
> > + ctx->insns = (u32 *)jit_data->image;
> > + /* Now, when the image is allocated, the image
> > + * can potentially shrink more (auipc/jalr ->
> > + * jal).
> > + */
> > + }
>
> It seems like these fragments should go along with patch #2 that introduces the
> code, as I don't see anything above that makes this necessary here.
>
No, you're right.
Björn
next prev parent reply other threads:[~2020-01-07 10:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-16 9:13 [PATCH bpf-next v2 0/9] riscv: BPF JIT fix, optimizations and far jumps support Björn Töpel
2019-12-16 9:13 ` [PATCH bpf-next v2 1/9] riscv, bpf: fix broken BPF tail calls Björn Töpel
2019-12-16 9:13 ` [PATCH bpf-next v2 2/9] riscv, bpf: add support for far branching Björn Töpel
2019-12-16 9:13 ` [PATCH bpf-next v2 3/9] riscv, bpf: add support for far branching when emitting tail call Björn Töpel
2019-12-16 9:13 ` [PATCH bpf-next v2 4/9] riscv, bpf: add support for far jumps and exits Björn Töpel
2019-12-16 9:13 ` [PATCH bpf-next v2 5/9] riscv, bpf: optimize BPF tail calls Björn Töpel
2019-12-16 9:13 ` [PATCH bpf-next v2 6/9] riscv, bpf: provide RISC-V specific JIT image alloc/free Björn Töpel
2019-12-16 15:09 ` Daniel Borkmann
2019-12-18 6:23 ` Björn Töpel
2020-01-04 1:32 ` Paul Walmsley
2020-01-07 10:24 ` Björn Töpel
2020-01-07 10:47 ` Paul Walmsley
2020-02-02 13:37 ` Alex Ghiti
2020-02-03 12:28 ` Björn Töpel
2020-02-03 20:57 ` Alex Ghiti
2019-12-16 9:13 ` [PATCH bpf-next v2 7/9] riscv, bpf: optimize calls Björn Töpel
2019-12-16 9:13 ` [PATCH bpf-next v2 8/9] riscv, bpf: add missing uapi header for BPF_PROG_TYPE_PERF_EVENT programs Björn Töpel
2019-12-16 9:13 ` [PATCH bpf-next v2 9/9] riscv, perf: add arch specific perf_arch_bpf_user_pt_regs Björn Töpel
2019-12-19 15:07 ` [PATCH bpf-next v2 0/9] riscv: BPF JIT fix, optimizations and far jumps support Daniel Borkmann
2019-12-19 22:02 ` [PATCH bpf-next v2 1/9] riscv, bpf: fix broken BPF tail calls Palmer Dabbelt
2019-12-23 18:03 ` [PATCH bpf-next v2 2/9] riscv, bpf: add support for far branching Palmer Dabbelt
2020-01-07 8:13 ` Björn Töpel
2020-01-23 2:08 ` Palmer Dabbelt
2019-12-23 18:18 ` [PATCH bpf-next v2 3/9] riscv, bpf: add support for far branching when emitting tail call Palmer Dabbelt
2019-12-23 18:18 ` [PATCH bpf-next v2 4/9] riscv, bpf: add support for far jumps and exits Palmer Dabbelt
2019-12-23 18:29 ` [PATCH bpf-next v2 5/9] riscv, bpf: optimize BPF tail calls Palmer Dabbelt
2019-12-23 18:30 ` [PATCH bpf-next v2 6/9] riscv, bpf: provide RISC-V specific JIT image alloc/free Palmer Dabbelt
2019-12-23 18:58 ` [PATCH bpf-next v2 7/9] riscv, bpf: optimize calls Palmer Dabbelt
2020-01-07 10:14 ` Björn Töpel [this message]
2020-01-28 2:15 ` Palmer Dabbelt
2020-02-03 12:11 ` Björn Töpel
2019-12-23 18:58 ` [PATCH bpf-next v2 8/9] riscv, bpf: add missing uapi header for BPF_PROG_TYPE_PERF_EVENT programs Palmer Dabbelt
2019-12-23 18:58 ` [PATCH bpf-next v2 9/9] riscv, perf: add arch specific perf_arch_bpf_user_pt_regs Palmer Dabbelt
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='CAJ+HfNhvTdsBq_tmKNcxVdS=nro=jwL5yLxnyDXO02Vai+5YNg@mail.gmail.com' \
--to=bjorn.topel@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=linux-riscv@lists.infradead.org \
--cc=netdev@vger.kernel.org \
--cc=palmerdabbelt@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).