Re: [Bpf] Standardizing BPF assembly language?

From: David Vernet <void@manifault.com>
To: dthaler1968=40googlemail.com@dmarc.ietf.org
Cc: bpf@ietf.org, bpf@vger.kernel.org, jose.marchesi@oracle.com
Subject: Re: [Bpf] Standardizing BPF assembly language?
Date: Tue, 23 Jan 2024 15:31:00 -0600	[thread overview]
Message-ID: <20240123213100.GA221838@maniforge> (raw)
In-Reply-To: <1b5d01da4e1b$95506b50$bff141f0$@gmail.com>

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

On Tue, Jan 23, 2024 at 08:45:32AM -0800, dthaler1968=40googlemail.com@dmarc.ietf.org wrote:
> At LSF/MM/BPF 2023, Jose gave a presentation about BPF assembly
> language (http://vger.kernel.org/bpfconf2023_material/compiled_bpf.txt).
> 
> Jose wrote in that link:
> > There are two dialects of BPF assembler in use today:
> >
> > - A "pseudo-c" dialect (originally "BPF verifier format")
> >  : r1 = *(u64 *)(r2 + 0x00f0)
> >  : if r1 > 2 goto label
> >  : lock *(u32 *)(r2 + 10) += r3
> >
> > - An "assembler-like" dialect
> >  : ldxdw %r1, [%r2 + 0x00f0]
> >  : jgt %r1, 2, label
> >  : xaddw [%r2 + 2], r3
> 
> During Jose's talk, I discovered that uBPF didn't quote match the
> second dialect and submitted a bug report.  By the time the conference
> was over, uBPF had been updated to match GCC, so that discussion
> worked to reduce the number of variants.
> 
> As more instructions get added and supported by more tools and compilers
> there's the risk of even more variants unless it's standardized.
> 
> Hence I'd recommend that BPF assembly language get documented in some WG
> draft.  If folks agree with that premise, the first question is then: which
> document?

> One possible answer would be the ISA document that specifies the
> instructions, since that would the IANA registry could list the
> assembly for each instruction, and any future documents that add
> instructions would necessarily need to specify the assembly for them,
> preventing variants from springing up for new instructions.

I'm not opposed to this, but would strongly prefer that we do it as an
extension if we go this route to avoid scope creep for the first
iteration.

> A second question would be, which dialect(s) to standardize.  Jose's
> link above argues that the second dialect should be the one
> standardized (tools are free to support multiple dialects for
> backwards compat if they want).  See the link for rationale.

My recollection was that the outcome of that discussion is that we were
going to continue to support both. If we wanted to standardize, I have a
hard time seeing any other way other than to standardize both dialects
unless there's been a significant change in sentiment since LSFMM.

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