Re: [Bpf] Review of draft-thaler-bpf-isa-01

[David Vernet <[e-mail]>]

On Mon, Aug 14, 2023 at 11:17:59AM -0500, David Vernet wrote:
> On Fri, Aug 11, 2023 at 02:36:04PM -0700, Watson Ladd wrote:
> > Dear David,
> 
> Hi Watson,

Hi everyone,

Watson and I discussed this today in more detail over a call. I think
we're now on the same page, and I want to update the lists with where we
landed so others can weigh in. The TL;DR is that the ISA document as it
exists today is trying to toe the line between being two different types
of ISA documents:

1. An ARM/x86-esque ISA document that exists somewhat in isolation, and
   just defines the encodings and high-level semantics of instructions.
   For example, if you look at the ARM A64 Instruction Set Architecture
   for Armv8 and Armv8-A document, it literally just jumps straight into
   encodings and high-level semantics of the instructions. There's
   literally zero information about the ARM memory model, execution
   environment, etc. All of that is captured in separate architecture
   documents.

2. The RISC-V ISA model, which goes into significantly more detail on
   the architecture of RISC-V, and formalizes not just the instructions,
   but the execution and memory models, memory consistency model, etc.

I am (and I believe Watson is as well following our discussion) of the
opinion that our ISA document belongs squarely in the first category,
and shouldn't try to also fit into the second. We're defining the
instruction encodings, and describing their semantics at a high level
without much formality. This is intentional -- our WG charter specifies
many more documents that cover all of these details (some of which will
likely be contentious and require a lot of thought and discussion) in
the proper scopes. For example, our planned documents include but are
not limited to:

- [I] an architecture and framework document

- one or more documents that recommend conventions and guidelines
  for producing portable BPF program binaries

- [PS] cross-platform map types allowing native data structure access
  from BPF programs

- [PS] cross-platform helper functions, e.g., for manipulation of maps

- [PS] cross-platform BPF program types that define the higher level
  execution environment for BPF programs

With all that said, I think our ISA document would improve a lot with
the following changes:

1. Removing all the ABI-specific stuff from the ISA document.  For
   example, calling conventions need to go. This was discussed at IETF
   117, so should hopefully be non-controversial. I'll send a patch
   later that moves this to a separate abi.rst document that we can then
   fold into Will's work.

2. This wasn't discussed at IETF 117, but also removing extraneous
   verbiage such as the "Helper functions" and "Maps" paragraphs, and
   maybe more such as "Platform Variables". These blurbs are useful for
   giving some context on the actual instructions in the ISA, but
   they're insufficient on their own to be of practical use.

So the TL;DR is: let's make the ISA document just an ISA document.
We're in it for the long haul, and the time to properly introduce,
define, and explain all of these concepts is when we write the documents
that are meant to capture all of that information.

Watson -- please let me know if I've misrepresented anything. It would
be great to get others' thoughts as well.

Thanks,
David