On Tue, Dec 12, 2023 at 03:45:32PM -0600, David Vernet wrote: > > I think we should do just two categories: legacy and the rest, > > since any scheme will be flawed and infinite bikeshedding will ensue. > > If we do this, then aren't we forcing every vendor that adds BPF support > to support every single instruction if they want to be compliant? Yes, you do. And if we have use cases and implementation restrictions that ask for not supporting some that would be the biggest reason to have more groups. I brough up some examples where we don't need e.g. atomics. I've not really heard from implementor that implementing the instructions is a burden for them, though. > I think it's reasonable to expect that if you require an atomic add, > that you may also require the other atomic instructions as well and that > it would be logical to group them together, yes. I believe that > Netronome supports all of the atomic instructions, as one example. If > you're providing a BPF runtime in an environment where atomic adds are > required, I think it stands to reason that you should probably support > the other atomics as well, no? Agreed. > From my perspective, the reason that we want conformance groups is > purely for compliance and cross compatibility. If someone has a BPF > program that does some class of operations, then conformance groups > inform them about whether their prog will be able to run on some vendor > implementation of BPF. Yes. > FWIW, my perspective is that we should be aiming to enable compliance. > I don't see any reason why a BPF prog that's offloaded to a NIC to do > packet filtering shouldn't be able to e.g. run on multiple devices. > That certainly won't be the case for every type of BPF program, but > classifying groups of instructions does seem prudent. 100% agreed.
