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. > 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. > > 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. > > "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.
