>From David Vernet's WG summary:
> After this update, the discussion moved to a topic for the BPF ISA
document that has yet to be resolved:
> ISA RFC compliance. Dave pointed out that we still need to specify which
instructions in the ISA are
> MUST, SHOULD, etc, to ensure interoperability. Several different options
were presented, including
> having individual-instruction granularity, following the clang CPU
versioning convention, and grouping
> instructions by logical functionality.
>
> We did not obtain consensus at the conference on which was the best way
forward. Some of the points raised include the following:
>
> - Following the clang CPU versioning labels is somewhat arbitrary. It
> may not be appropriate to standardize around grouping that is a result
> of largely organic historical artifacts.
> - If we decide to do logical grouping, there is a danger of
> bikeshedding. Looking at anecdotes from industry, some vendors such as
> Netronome elected to not support particular instructions for
> performance reasons.
My sense of the feedback in general was to group instructions by logical
functionality, and only create separate
conformance groups where there is some legitimate technical reason that a
runtime might not want to support
a given set of instructions. Based on discussion during the meeting, here's
a strawman set of conformance
groups to kick off discussion. I've tried to use short (like 6 characters
or fewer) names for ease of display in
document tables, and potentially in command line options to tools that might
want to use them.
A given runtime platform would be compliant to some set of the following
conformance groups:
1. "basic": all instructions not covered by another group below.
2. "atomic": all Atomic operations. I think Christoph argued for this one
in the meeting.
3. "divide": all division and modulo operations. Alexei said in the meeting
that he'd heard demand for this one.
4. "legacy": all legacy packet access instructions (deprecated).
5. "map": 64-bit immediate instructions that deal with map fds or map
indices.
6. "code": 64-bit immediate instruction that has a "code pointer" type.
7. "func": program-local functions.
Things that I *think* don't need a separate conformance group (can just be
in "basic") include:
a. Call helper function by address or BTF ID. A runtime that doesn't
support these simply won't expose any
such helper functions to BPF programs.
b. Platform variable instructions (dst = var_addr(imm)). A runtime that
doesn't support this simply won't
expose any platform variables to BPF programs.
Comments? (Let the bikeshedding begin...)
Dave
--
Bpf mailing list
Bpf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/bpf
