On Sat, Dec 02, 2023 at 11:51:50AM -0800, dthaler1968=40googlemail.com@xxxxxxxxxxxxxx wrote: > >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. I thought for a while about whether this should be part of the basic conformance group, and talked through it with Jakub Kicinski. I do think it makes sense to keep it separate like this. For e.g. devices with Harvard architectures, it could get quite non-trivial for the verifier to determine whether accesses to arguments stored in special register are safe. Definitely not impossible, and overall very useful to support this, but in order to ease vendor adoption it's probably best to keep this separate. > 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...) This list seems logical to me, though I do want to think a bit more about the maps one. Alexei, Christoph, anyone else? Now is the time to get aligned so we can get this to WG last call in plenty of time for IETF 119. Thanks, David
Attachment:
signature.asc
Description: PGP signature
