Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > On Thu, Jul 6, 2023 at 10:00 AM Dave Thaler > <dthaler=40microsoft.com@xxxxxxxxxxxxxx> wrote: > > > > The charter for the newly formed IETF BPF WG includes: > > > > “The BPF working group is initially tasked with … creating a clear process > for extensions, …” > > > > > > > > I wanted to kick off a discussion of this topic in preparation for > > discussion at IETF 117. > > > > > > > > Once the BPF ISA is published in an RFC, we expect more instructions > > may be added over time. It seems undesirable to delay use such > > additions until > > > > another RFC can be published, although having them appear in an RFC > > would be a good thing in my view. > > > > > > > > Personally, I envision such additions to appear in an RFC per > > extension > > > > (i.e., set of additions) rather than obsoleting the original ISA RFC. > > So I would propose the ability to reference another document (e.g., > > one in the Linux kernel tree) in the meantime. > > > > > > > > For comparison, the IANA registry for URI schemes at [...] defines status values for “Permanent” and > > “Provisional” with different registration policies for each of those > > two statuses. I have to correct myself, it actually has 3, the third being Historical, which does make sense for deprecated instructions. > > Similarly, I would propose as a strawman using an IANA registry (as > > most IETF standards do) that requires say an IETF Standards Track RFC > > for > > > > “Permanent” status, and “Specification required” (a public > > specification reviewed by a designated expert) for “Provisional” > registrations. > > So updating a document in say the Linux kernel tree would be > > sufficient for Provisional registration, and the status of an > > instruction would change to Permanent once it appears in an RFC. > > The definition of status and the semantics make sense, but I suspect to > implement them via full IANA would require to list every instruction encoding > in the registry and that's where IANA key/value mapping won't work. > 8-bit opcode is often not enough to denote an instruction. > All of v1,v2,v3,v4 existing extensions to BPF ISA happened by a combination > of new 8-bit opcodes and using reserved bits in other parts of 64-bit insn. > Now we pretty much ran out of 8-bit opcodes. > So there is really nothing the IANA registry can help with. I don't see any problem with defining an IANA registry with multiple "key" fields (opcode+src+imm). All existing instructions can be done as such. Below is strawman text that I think follows IANA's requirements outlined in RFC 8126... -Dave --- snip --- IANA Considerations =================== This document proposes a new IANA registry for BPF instructions, as follows: * Name of the registry: BPF Instruction Set * Name of the registry group: same as registry name * Required information for registrations: The values to appear in the entry fields. * Syntax of registry entries: Each entry has the following fields: * opcode: a 1-byte value in hex format indicating the value of the opcode field * src: a 4-bit value in hex format indicating the value of the src field, or "any" * imm: either a value in hex format indicating the value of the imm field, or "any" * description: description of what the instruction does, typically in pseudocode * reference: a reference to the defining specification * status: Permanent, Provisional, or Historical * Registration policy (see RFC 8126 section 4 for details): * Permanent: Standards action * Provisional: Specification required * Historical: Specification required * Initial registrations: See the Appendix. Instructions other than those listed as deprecated are Permanent. Any listed as deprecated are Historical.
