All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vernet <void@manifault.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Dave Thaler <dthaler1968@googlemail.com>,
	bpf@ietf.org, bpf <bpf@vger.kernel.org>,
	Jakub Kicinski <kuba@kernel.org>
Subject: Re: [Bpf] BPF ISA conformance groups
Date: Fri, 5 Jan 2024 16:07:11 -0600	[thread overview]
Message-ID: <20240105220711.GA1001999@maniforge> (raw)
In-Reply-To: <ZYPiq6ijLaMl/QD8@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

On Wed, Dec 20, 2023 at 11:00:59PM -0800, Christoph Hellwig wrote:
> On Tue, Dec 19, 2023 at 07:28:10PM -0800, Alexei Starovoitov wrote:
> > Right, but bringing the verifier into the "compliance picture"
> > makes the ISA standard incomplete.
> > Same can be said about nfp compliance. It's compliant with an ISA,
> > but the verifier will reject things it doesn't support.
> 
> Yes, that's a good point.  Especially for anything call related I think
> it's fine to say they are a mandatory part of the basic some coarse
> group, but a given program type might not support it, but that is
> enforced by the verifier as the compiler should not have to known about
> the program type.

Agreed as well.

> 
> > All ld_imm64 and call insns look the same. The compiler emits
> > them the same way.
> > The src_reg encoding is what libbpf does based on compiler relocations.
> > 
> > Then the verifier checks them differently and later JIT sees
> > _all_ ld_imm64 as one type of instruction.
> > Same with call insn. To x86/arm64/riscv JITs there is only one BPF CALL insn.
> 
> Yup.  Another case for ISA supported vs program type supported (and
> enforced by the verifier).

+1

So how do we want to move forward here? It sounds like we're leaning
toward's Alexei's proposal of having:

- Base Integer Instruction Set, 32-bit
- Base Integer Instruction Set, 64-bit
- Integer Multiplication and Division
- Atomic Instructions

And then either having 3 separate groups for the calls, or putting all 3
in the basic group? I'd lean towards the latter given that we're
decoupling ISA compliance from the verifier, but don't feel strongly
either way.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: David Vernet <void@manifault.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Dave Thaler <dthaler1968@googlemail.com>,
	bpf@ietf.org, bpf <bpf@vger.kernel.org>,
	Jakub Kicinski <kuba@kernel.org>
Subject: Re: [Bpf] BPF ISA conformance groups
Date: Fri, 5 Jan 2024 16:07:11 -0600	[thread overview]
Message-ID: <20240105220711.GA1001999@maniforge> (raw)
Message-ID: <20240105220711.0rVNqxzkAGEnbj6tw-E3VYXYAW6cNkLit48NsRp2bOc@z> (raw)
In-Reply-To: <ZYPiq6ijLaMl/QD8@infradead.org>


[-- Attachment #1.1: Type: text/plain, Size: 1682 bytes --]

On Wed, Dec 20, 2023 at 11:00:59PM -0800, Christoph Hellwig wrote:
> On Tue, Dec 19, 2023 at 07:28:10PM -0800, Alexei Starovoitov wrote:
> > Right, but bringing the verifier into the "compliance picture"
> > makes the ISA standard incomplete.
> > Same can be said about nfp compliance. It's compliant with an ISA,
> > but the verifier will reject things it doesn't support.
> 
> Yes, that's a good point.  Especially for anything call related I think
> it's fine to say they are a mandatory part of the basic some coarse
> group, but a given program type might not support it, but that is
> enforced by the verifier as the compiler should not have to known about
> the program type.

Agreed as well.

> 
> > All ld_imm64 and call insns look the same. The compiler emits
> > them the same way.
> > The src_reg encoding is what libbpf does based on compiler relocations.
> > 
> > Then the verifier checks them differently and later JIT sees
> > _all_ ld_imm64 as one type of instruction.
> > Same with call insn. To x86/arm64/riscv JITs there is only one BPF CALL insn.
> 
> Yup.  Another case for ISA supported vs program type supported (and
> enforced by the verifier).

+1

So how do we want to move forward here? It sounds like we're leaning
toward's Alexei's proposal of having:

- Base Integer Instruction Set, 32-bit
- Base Integer Instruction Set, 64-bit
- Integer Multiplication and Division
- Atomic Instructions

And then either having 3 separate groups for the calls, or putting all 3
in the basic group? I'd lean towards the latter given that we're
decoupling ISA compliance from the verifier, but don't feel strongly
either way.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 76 bytes --]

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

  reply	other threads:[~2024-01-05 22:07 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-27 20:18 IETF 118 BPF WG summary David Vernet
2023-11-27 20:18 ` [Bpf] " David Vernet
2023-11-28  9:43 ` Michael Richardson
2023-11-28  9:43   ` Michael Richardson
2023-12-02 19:51 ` BPF ISA conformance groups dthaler1968
2023-12-02 19:51   ` [Bpf] " dthaler1968=40googlemail.com
2023-12-07 21:51   ` David Vernet
2023-12-07 21:51     ` David Vernet
2023-12-10  3:10     ` Alexei Starovoitov
2023-12-10  3:10       ` Alexei Starovoitov
2023-12-10 21:13       ` Watson Ladd
2023-12-10 21:13         ` Watson Ladd
2023-12-12 21:45       ` David Vernet
2023-12-12 21:45         ` David Vernet
2023-12-12 22:01         ` dthaler1968
2023-12-12 22:01           ` dthaler1968=40googlemail.com
2023-12-12 22:55           ` Alexei Starovoitov
2023-12-12 22:55             ` Alexei Starovoitov
2023-12-12 23:35             ` David Vernet
2023-12-12 23:35               ` David Vernet
2023-12-13  1:32               ` Alexei Starovoitov
2023-12-13  1:32                 ` Alexei Starovoitov
2023-12-13 18:56                 ` David Vernet
2023-12-13 18:56                   ` David Vernet
2023-12-14  0:12                   ` Alexei Starovoitov
2023-12-14  0:12                     ` Alexei Starovoitov
2023-12-14 17:44                     ` David Vernet
2023-12-14 17:44                       ` David Vernet
2023-12-15  5:29                       ` Christoph Hellwig
2023-12-15  5:29                         ` Christoph Hellwig
2023-12-19  1:15                         ` Alexei Starovoitov
2023-12-19  1:15                           ` Alexei Starovoitov
2023-12-19 18:10                           ` dthaler1968
2023-12-19 18:10                             ` dthaler1968=40googlemail.com
2023-12-20  3:28                             ` Alexei Starovoitov
2023-12-20  3:28                               ` Alexei Starovoitov
2023-12-21  7:00                               ` Christoph Hellwig
2023-12-21  7:00                                 ` Christoph Hellwig
2024-01-05 22:07                                 ` David Vernet [this message]
2024-01-05 22:07                                   ` David Vernet
2024-01-08 16:00                                   ` Christoph Hellwig
2024-01-08 21:51                                     ` Alexei Starovoitov
2024-01-08 21:51                                       ` Alexei Starovoitov
2024-01-09 11:35                                       ` Jose E. Marchesi
2024-01-09 11:35                                         ` Jose E. Marchesi
2024-01-23 21:39                                         ` David Vernet
2024-01-23 21:39                                           ` David Vernet
2024-01-23 23:29                                           ` dthaler1968
2024-01-23 23:29                                             ` dthaler1968=40googlemail.com
2024-01-25  2:55                                             ` Alexei Starovoitov
2024-01-25  2:55                                               ` Alexei Starovoitov
2024-01-09 15:26                                       ` Christoph Hellwig
2023-12-19 18:15                 ` dthaler1968
2023-12-19 18:15                   ` dthaler1968=40googlemail.com
2023-12-13 16:59         ` Christoph Hellwig
2023-12-13 16:59           ` Christoph Hellwig

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=20240105220711.GA1001999@maniforge \
    --to=void@manifault.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@ietf.org \
    --cc=bpf@vger.kernel.org \
    --cc=dthaler1968@googlemail.com \
    --cc=hch@infradead.org \
    --cc=kuba@kernel.org \
    /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.