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@xxxxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
