*BPF ISA*

Dave Thaler provided an update on what's changed in the BPF ISA I-D
since IETF 117. Those changes included (but were not necessarily limited
to) the following:

- ABI-specific text was moved from this document into a separate ABI [0]
document that has yet to be adopted into the WG.
- IANA considerations were added to the document:
- Permanent: Standards action or IESG Review
- Provisional: Specification required
- Historical: Specification required
- For listing instructions in the IANA registry, it was decided to keep
them as a single table with multiple key fields.
- New instructions (signed division, signed modulo, move with sign
extension, load with sign extension, unconditional byte swap, and
32-bit offset jumps) were added by Yonghong Song.
- A few other fixes and improvements provided by Will Hawkins, Jose
Marchesi, and others.

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.

Once this compliance question has been resolved, we expect that the ISA
document will be ready to move to WG last call.

*BPF Memory Model and psABI*

Alexei Starovoitov presented the rough outline of a proposal for the BPF
Memory Model, and clarified some of his views on the BPF psABI. The main
thrust of the proposal was that the BPF MM should reflect that of
hardware memory models such as ARM and x86, and be mirrored after the
LKMM (Linux Kernel Memory Model), of which language MMs are a strict
subset. Existing language MMs do not properly handle control
dependencies, and suffer from issues such as OOTA (Out-of-Thin-Air)
reads. The presentation outlined the control dependencies proposed for
various types of BPF instructions, such as atomics, jumps, etc.

Overall the proposal seemed well received, though the issue of whether
ABIs should be standardized was again resurfaced. When the WG was
formed, the expectation was that such conventions would be captured in
one or more Informational documents. This question will likely have to
be resolved before an I-D could be adopted.

*Conclusion*

This was another very productive session. It's clear that we're almost
ready to make a WG last call for the ISA document. Hopefully we can
resolve the issue of compliance quickly. It's also great to see that the
BPF MM and ABI standardization discussions are proceeding. It seemed
that we all had rough consensus on the proposal for the BPF MM, so it
would be great for us to get some of that written down into the existing
ABI document.