RE: [Bpf] [PATCH bpf-next] bpf, docs: Expand set of initial conformance groups

[dthaler1968@googlemail.com]

David Vernet <void@manifault.com> wrote: 
[...]
> > > +  as being in the base64 conformance group.
> > > +* atom32: includes 32-bit atomic operation instructions (see `Atomic
> operations`_).
> > > +* atom64: includes atom32, plus 64-bit atomic operation instructions.
> > > +* div32: includes 32-bit division and modulo instructions.
> >
> > Did we want to separate division and modulo? It looks like Netronome
> > doesn't support modulo [0], presumably because it's not as useful as
> > in tracing.
> >
> > Jakub -- can you confirm? If so, how difficult would it have been to
> > add modulo support, and do you think it would have provided any value?
> >
> > [0]:
> > https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/net
> > ronome/nfp/bpf/jit.c#L3421
> 
> I spoke about this offline with Jakub. It turns out that there was
actually
> neither division nor modulo in the silicon. They only supported division
by the
> kernel's reciprocal division library. We could choose to apply Netronome's
> choice to the standard, but I really don't think we should.  Kuba pointed
out
> that Netronome is old silicon, and that most vendors today would likely
start
> with RISC-V.
> 
> To that point, I believe the most prudent thing is to just mirror the
smallest
> riscv32 instruction-set granularity for our conformance groups.
> For the case of multiplication, division, and modulo, this would be the
"M"
> standard extension for Integer Multiplication and Division, which provides
> signed and unsigned multiplication, division, and modulo instructions.
> 
> My suggestion is for us to mirror this exactly, here. I think the contours
set by
> RISC-V are much stronger data points for what will make sense for vendors
than
> what Netronome did on what at this point is rather old silicon.
> 
> How do we feel about having divmul32/64 conformance groups? Thus
> removing multiplication from the base32/64 groups. This would leave us
> with:
> 
> - base{32/64}   (reflecting RV32I and RV64I plus our call instructions,
> 		 which logically fit here given that RISC-V control flow
> 		 instructions are in RV{32,64}I as well)
> - divmul{32/64} (the "M" instruction set provides both 32 and 64 bit
> 		 versions of MUL(W), DIV{U}(W), and REM{U}(W)
> 		 instructions respectively)
> - atom{32/64}   (the "A" extension provides 32 and 64 bit instructions
> 		 for R32 and R64 respectively, just like with div/mod)
> - legacy
> 
> This to me seems like both the most logical layout of instructions, as
well as the
> least likely to cause pain for vendors given the precedence that's already
been
> set by RISC-V.

This sounds fine to me.

Dave