Re: [Bpf] BPF ISA conformance groups

[David Vernet <void@manifault.com>]

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

On Wed, Dec 13, 2023 at 04:12:28PM -0800, Alexei Starovoitov wrote:
> On Wed, Dec 13, 2023 at 10:56 AM David Vernet <void@manifault.com> wrote:
> >
> > Something I want to make sure is clearly spelled out: are you of the
> > opinion that a program written for offload to a Netronome device cannot
> > and should not ever be able to run on any other NIC with BPF offload?
> 
> It's certainly fine for vendors to try to replicate Netronome offload.
> The point is that it was done before any standard existed.
> If we add compliance groups to the standard now they won't fit
> netronome and won't help anyone trying to be compatible with it.
> See the point about compatibility with -mcpu=v3 and not v1.

It's unfortunate that it would make Netronome non-compliant, but I think
we should be looking more at what makes sense for future implementations
when it comes to the standard. The claim is that future devices which
are compliant would be able to have replicated offload implementations.

> > Why else would they be asking for a standard if not to
> > have some guidelines of what to implement?
> 
> Excellent question. I don't know why nvme folks need a standard.
> Lack of standard didn't stop netronome.

Christoph? Any chance you can shed some light here?

> > How do we know the semantics of the instructions won't be prohibitively
> > expensive or impractical for certain vendors? What value do we get out
> > of dictating semantics in the standard if we're not expecting any of
> > these programs to be cross-compatible anyways?
> 
> and that's a problem. hw folks are not participating in this discussion.
> Without implementers there is little chance to have successful guidelines
> for compatibility levels.
> per-instruction compatibility is already accomplished.
> We don't need groups for that.

I definitely agree that it would be nice to have hw folks included in
these discussions. What I don't quite understand though is why it would
be necessary to have them included in the discussion to decide on
conformance groups, but not on instruction semantics.

> > > "Here is a standard. Go implement it" won't work.
> >
> > What is the point of a standard if not to say, "Here's what you should
> > go implement"?
> 
> Rephrasing... "go implement it _all_" won't work.
> The standard has value without insn groups.
> Every instruction has specific meaning and encoding.
> That's what compatibility is about. Both sw and hw need to
> perform that operation.

I agree that there's value in instructions having specific meaning and
encodings, but my worry is that (for device offload) the value would be
minimized quite a bit if a developer writing a BPF offload program
doesn't also have some knowledge or guarantee of what instructions
vendors have actually implemented.

If we were to do away with conformance groups, then I as a BPF user
would have the guarantee: "Any hw device which happens to implement the
instructions in my program will behave in a predictable way". If that
user doesn't know what instructions it can count on being actually
available in devices, then they're going to end up just implementing the
program for a single device anyways. At that point, how useful was it
really to standardize on the semantics of the instructions? That user
just as soon could have read the specifications for the device and
implemented the prog according to the semantics that the vendor decided
were most appropriate for them.

That said, I definitely agree that there's value in standardizing the
semantics for _software_, because as you said, software can eventually
just be fully compliant. What's less clear to me is how useful it is for
device offload without conformance groups.

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