All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: alexei.starovoitov@gmail.com, daniel@iogearbox.net,
	Jiong Wang <jiong.wang@netronome.com>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, oss-drivers@netronome.com
Subject: Re: [PATCH v3 bpf-next 08/19] bpf: insert explicit zero extension insn when hardware doesn't do it implicitly
Date: Mon, 15 Apr 2019 15:29:35 +0530	[thread overview]
Message-ID: <1555321893.44its0xa9r.naveen@linux.ibm.com> (raw)
In-Reply-To: <1555106392-20117-9-git-send-email-jiong.wang@netronome.com>

Hi Jiong,

Jiong Wang wrote:
> After previous patches, verifier has marked those instructions that really
> need zero extension on dst_reg.

Thanks for implementing this -- this is very helpful on architectures 
without sub-register instructions, especially in comparison with legacy 
BPF, since the move to eBPF resulted in lot more instructions being 
generated.

I have a small nit below on the overall approach...

> 
> It is then for all back-ends to decide how to use such information to
> eliminate unnecessary zero extension code-gen during JIT compilation.
> 
> One approach is:
>   1. Verifier insert explicit zero extension for those instructions that
>      need zero extension.
>   2. All JIT back-ends do NOT generate zero extension for sub-register
>      write any more.

Is it possible to instead give a hint to the JIT back-ends on the 
instructions needing zero-extension? That would help in case of 
architectures that have single/more-optimal instruction for zero 
extension, compared to having to emit 2 instructions with the current 
approach.

- Naveen



  reply	other threads:[~2019-04-15  9:59 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-12 21:59 [PATCH v3 bpf-next 00/19] bpf: eliminate zero extensions for sub-register writes Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 01/19] bpf: refactor propagate_liveness to eliminate duplicated for loop Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 02/19] bpf: refactor propagate_liveness to eliminate code redundance Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 03/19] bpf: factor out reg and stack slot propagation into "propagate_liveness_reg" Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 04/19] bpf: refactor "check_reg_arg" to eliminate code redundancy Jiong Wang
2019-04-13  0:12   ` Alexei Starovoitov
2019-04-13  7:00     ` Jiong Wang
2019-04-15  5:41       ` Alexei Starovoitov
2019-04-12 21:59 ` [PATCH v3 bpf-next 05/19] bpf: split read liveness into REG_LIVE_READ64 and REG_LIVE_READ32 Jiong Wang
2019-04-13  1:07   ` Jakub Kicinski
2019-04-13  6:39     ` Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 06/19] bpf: mark lo32 writes that should be zero extended into hi32 Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 07/19] bpf: reduce false alarm by refining helper call arg types Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 08/19] bpf: insert explicit zero extension insn when hardware doesn't do it implicitly Jiong Wang
2019-04-15  9:59   ` Naveen N. Rao [this message]
2019-04-15 10:11     ` Naveen N. Rao
2019-04-15 11:24       ` Jiong Wang
2019-04-15 18:21         ` Naveen N. Rao
2019-04-15 19:28           ` Jiong Wang
2019-04-16  6:41             ` Naveen N. Rao
2019-04-16  7:47               ` [oss-drivers] " Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 09/19] bpf: introduce new bpf prog load flags "BPF_F_TEST_RND_HI32" Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 10/19] bpf: randomize high 32-bit when BPF_F_TEST_RND_HI32 is set Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 11/19] libbpf: add "prog_flags" to bpf_program/bpf_prog_load_attr/bpf_load_program_attr Jiong Wang
2019-04-13  1:08   ` Jakub Kicinski
2019-04-12 21:59 ` [PATCH v3 bpf-next 12/19] selftests: enable hi32 randomization for all tests Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 13/19] arm: bpf: eliminate zero extension code-gen Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 14/19] powerpc: " Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 15/19] s390: " Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 16/19] sparc: " Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 17/19] x32: " Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 18/19] riscv: " Jiong Wang
2019-04-12 21:59 ` [PATCH v3 bpf-next 19/19] nfp: " Jiong Wang

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=1555321893.44its0xa9r.naveen@linux.ibm.com \
    --to=naveen.n.rao@linux.vnet.ibm.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jiong.wang@netronome.com \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.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.