All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiong Wang <jiong.wang@netronome.com>
To: Luke Nelson <lukenels@cs.washington.edu>
Cc: linux-kernel@vger.kernel.org,
	"Luke Nelson" <luke.r.nels@gmail.com>,
	"Song Liu" <liu.song.a23@gmail.com>,
	"Jiong Wang" <jiong.wang@netronome.com>,
	"Xi Wang" <xi.wang@gmail.com>,
	"Björn Töpel" <bjorn.topel@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>,
	netdev@vger.kernel.org, linux-riscv@lists.infradead.org,
	bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next] Enable zext optimization for more RV64G ALU ops
Date: Fri, 05 Jul 2019 10:24:22 +0100	[thread overview]
Message-ID: <8736jk4ywp.fsf@netronome.com> (raw)
In-Reply-To: <20190705001803.30094-1-luke.r.nels@gmail.com>


Luke Nelson writes:

> commit 66d0d5a854a6 ("riscv: bpf: eliminate zero extension code-gen")
> added the new zero-extension optimization for some BPF ALU operations.
>
> Since then, bugs in the JIT that have been fixed in the bpf tree require
> this optimization to be added to other operations: commit 1e692f09e091
> ("bpf, riscv: clear high 32 bits for ALU32 add/sub/neg/lsh/rsh/arsh"),
> and commit fe121ee531d1 ("bpf, riscv: clear target register high 32-bits
> for and/or/xor on ALU32")
>
> Now that these have been merged to bpf-next, the zext optimization can
> be enabled for the fixed operations.

LGTM, thanks.

Acked-by: Jiong Wang <jiong.wang@netronome.com>

>
> Cc: Song Liu <liu.song.a23@gmail.com>
> Cc: Jiong Wang <jiong.wang@netronome.com>
> Cc: Xi Wang <xi.wang@gmail.com>
> Signed-off-by: Luke Nelson <luke.r.nels@gmail.com>
> ---
>  arch/riscv/net/bpf_jit_comp.c | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/riscv/net/bpf_jit_comp.c b/arch/riscv/net/bpf_jit_comp.c
> index 876cb9c705ce..5451ef3845f2 100644
> --- a/arch/riscv/net/bpf_jit_comp.c
> +++ b/arch/riscv/net/bpf_jit_comp.c
> @@ -757,31 +757,31 @@ static int emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
>  	case BPF_ALU | BPF_ADD | BPF_X:
>  	case BPF_ALU64 | BPF_ADD | BPF_X:
>  		emit(is64 ? rv_add(rd, rd, rs) : rv_addw(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  	case BPF_ALU | BPF_SUB | BPF_X:
>  	case BPF_ALU64 | BPF_SUB | BPF_X:
>  		emit(is64 ? rv_sub(rd, rd, rs) : rv_subw(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  	case BPF_ALU | BPF_AND | BPF_X:
>  	case BPF_ALU64 | BPF_AND | BPF_X:
>  		emit(rv_and(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  	case BPF_ALU | BPF_OR | BPF_X:
>  	case BPF_ALU64 | BPF_OR | BPF_X:
>  		emit(rv_or(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  	case BPF_ALU | BPF_XOR | BPF_X:
>  	case BPF_ALU64 | BPF_XOR | BPF_X:
>  		emit(rv_xor(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  	case BPF_ALU | BPF_MUL | BPF_X:
> @@ -811,13 +811,13 @@ static int emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
>  	case BPF_ALU | BPF_RSH | BPF_X:
>  	case BPF_ALU64 | BPF_RSH | BPF_X:
>  		emit(is64 ? rv_srl(rd, rd, rs) : rv_srlw(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  	case BPF_ALU | BPF_ARSH | BPF_X:
>  	case BPF_ALU64 | BPF_ARSH | BPF_X:
>  		emit(is64 ? rv_sra(rd, rd, rs) : rv_sraw(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  
> @@ -826,7 +826,7 @@ static int emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
>  	case BPF_ALU64 | BPF_NEG:
>  		emit(is64 ? rv_sub(rd, RV_REG_ZERO, rd) :
>  		     rv_subw(rd, RV_REG_ZERO, rd), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;


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>,
	"Jiong Wang" <jiong.wang@netronome.com>,
	"Björn Töpel" <bjorn.topel@gmail.com>,
	"Palmer Dabbelt" <palmer@sifive.com>,
	"Song Liu" <liu.song.a23@gmail.com>,
	linux-kernel@vger.kernel.org,
	"Alexei Starovoitov" <ast@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: [PATCH bpf-next] Enable zext optimization for more RV64G ALU ops
Date: Fri, 05 Jul 2019 10:24:22 +0100	[thread overview]
Message-ID: <8736jk4ywp.fsf@netronome.com> (raw)
In-Reply-To: <20190705001803.30094-1-luke.r.nels@gmail.com>


Luke Nelson writes:

> commit 66d0d5a854a6 ("riscv: bpf: eliminate zero extension code-gen")
> added the new zero-extension optimization for some BPF ALU operations.
>
> Since then, bugs in the JIT that have been fixed in the bpf tree require
> this optimization to be added to other operations: commit 1e692f09e091
> ("bpf, riscv: clear high 32 bits for ALU32 add/sub/neg/lsh/rsh/arsh"),
> and commit fe121ee531d1 ("bpf, riscv: clear target register high 32-bits
> for and/or/xor on ALU32")
>
> Now that these have been merged to bpf-next, the zext optimization can
> be enabled for the fixed operations.

LGTM, thanks.

Acked-by: Jiong Wang <jiong.wang@netronome.com>

>
> Cc: Song Liu <liu.song.a23@gmail.com>
> Cc: Jiong Wang <jiong.wang@netronome.com>
> Cc: Xi Wang <xi.wang@gmail.com>
> Signed-off-by: Luke Nelson <luke.r.nels@gmail.com>
> ---
>  arch/riscv/net/bpf_jit_comp.c | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/riscv/net/bpf_jit_comp.c b/arch/riscv/net/bpf_jit_comp.c
> index 876cb9c705ce..5451ef3845f2 100644
> --- a/arch/riscv/net/bpf_jit_comp.c
> +++ b/arch/riscv/net/bpf_jit_comp.c
> @@ -757,31 +757,31 @@ static int emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
>  	case BPF_ALU | BPF_ADD | BPF_X:
>  	case BPF_ALU64 | BPF_ADD | BPF_X:
>  		emit(is64 ? rv_add(rd, rd, rs) : rv_addw(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  	case BPF_ALU | BPF_SUB | BPF_X:
>  	case BPF_ALU64 | BPF_SUB | BPF_X:
>  		emit(is64 ? rv_sub(rd, rd, rs) : rv_subw(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  	case BPF_ALU | BPF_AND | BPF_X:
>  	case BPF_ALU64 | BPF_AND | BPF_X:
>  		emit(rv_and(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  	case BPF_ALU | BPF_OR | BPF_X:
>  	case BPF_ALU64 | BPF_OR | BPF_X:
>  		emit(rv_or(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  	case BPF_ALU | BPF_XOR | BPF_X:
>  	case BPF_ALU64 | BPF_XOR | BPF_X:
>  		emit(rv_xor(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  	case BPF_ALU | BPF_MUL | BPF_X:
> @@ -811,13 +811,13 @@ static int emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
>  	case BPF_ALU | BPF_RSH | BPF_X:
>  	case BPF_ALU64 | BPF_RSH | BPF_X:
>  		emit(is64 ? rv_srl(rd, rd, rs) : rv_srlw(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  	case BPF_ALU | BPF_ARSH | BPF_X:
>  	case BPF_ALU64 | BPF_ARSH | BPF_X:
>  		emit(is64 ? rv_sra(rd, rd, rs) : rv_sraw(rd, rd, rs), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;
>  
> @@ -826,7 +826,7 @@ static int emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
>  	case BPF_ALU64 | BPF_NEG:
>  		emit(is64 ? rv_sub(rd, RV_REG_ZERO, rd) :
>  		     rv_subw(rd, RV_REG_ZERO, rd), ctx);
> -		if (!is64)
> +		if (!is64 && !aux->verifier_zext)
>  			emit_zext_32(rd, ctx);
>  		break;


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2019-07-05  9:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-05  0:18 [PATCH bpf-next] Enable zext optimization for more RV64G ALU ops Luke Nelson
2019-07-05  0:18 ` Luke Nelson
2019-07-05  6:31 ` Björn Töpel
2019-07-05  6:31   ` Björn Töpel
2019-07-05  9:24 ` Jiong Wang [this message]
2019-07-05  9:24   ` Jiong Wang
2019-07-05 22:01 ` Daniel Borkmann
2019-07-05 22:01   ` Daniel Borkmann

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=8736jk4ywp.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=liu.song.a23@gmail.com \
    --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.