[Bpf] Instruction set extension policy

[Bpf] Instruction set extension policy

[Dave Thaler]

[-- Attachment #1.1: Type: text/plain, Size: 1517 bytes --]

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
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
defines status values for "Permanent" and "Provisional" with different
registration policies for each of those two statuses.

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.

Thoughts?

Dave

[-- Attachment #1.2: Type: text/html, Size: 5079 bytes --]

[-- Attachment #2: Type: text/plain, Size: 76 bytes --]

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] Instruction set extension policy

[Alexei Starovoitov]

On Thu, Jul 6, 2023 at 10:00 AM Dave Thaler
<dthaler=40microsoft.com@dmarc.ietf.org> 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
> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
> defines status values for “Permanent” and “Provisional” with different
> registration policies for each of those two statuses.
>
>
>
> 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.

Re: [Bpf] Instruction set extension policy

[Alexei Starovoitov]

On Thu, Jul 6, 2023 at 10:00 AM Dave Thaler
<dthaler=40microsoft.com@dmarc.ietf.org> 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
> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
> defines status values for “Permanent” and “Provisional” with different
> registration policies for each of those two statuses.
>
>
>
> 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.

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

RE: [Bpf] Instruction set extension policy

[Dave Thaler]

Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
> On Thu, Jul 6, 2023 at 10:00 AM Dave Thaler
> <dthaler=40microsoft.com@dmarc.ietf.org> 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.

Re: [Bpf] Instruction set extension policy

[Dave Thaler]

Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
> On Thu, Jul 6, 2023 at 10:00 AM Dave Thaler
> <dthaler=40microsoft.com@dmarc.ietf.org> 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.

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] Instruction set extension policy

[Alexei Starovoitov]

On Thu, Jul 6, 2023 at 6:35 PM Dave Thaler <dthaler@microsoft.com> wrote:
>
> 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.

I think that might work. What is the next step then?
Who is going to generate such a hex database?

Re: [Bpf] Instruction set extension policy

[Alexei Starovoitov]

On Thu, Jul 6, 2023 at 6:35 PM Dave Thaler <dthaler@microsoft.com> wrote:
>
> 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.

I think that might work. What is the next step then?
Who is going to generate such a hex database?

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] Instruction set extension policy

[Will Hawkins]

On Fri, Jul 7, 2023 at 12:01 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Thu, Jul 6, 2023 at 6:35 PM Dave Thaler <dthaler@microsoft.com> wrote:
> >
> > 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.
>
> I think that might work. What is the next step then?
> Who is going to generate such a hex database?

I would be more than happy to do that!
Will

>
> --
> Bpf mailing list
> Bpf@ietf.org
> https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] Instruction set extension policy

[Will Hawkins]

On Fri, Jul 7, 2023 at 12:01 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Thu, Jul 6, 2023 at 6:35 PM Dave Thaler <dthaler@microsoft.com> wrote:
> >
> > 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.
>
> I think that might work. What is the next step then?
> Who is going to generate such a hex database?

I would be more than happy to do that!
Will

>
> --
> Bpf mailing list
> Bpf@ietf.org
> https://www.ietf.org/mailman/listinfo/bpf

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

RE: [Bpf] Instruction set extension policy

[Dave Thaler]

Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > On Thu, Jul 6, 2023 at 6:35 PM Dave Thaler <dthaler@microsoft.com>
> wrote:
> > >
> > > 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...
[..]
> > I think that might work. What is the next step then?
> > Who is going to generate such a hex database?
> 
> I would be more than happy to do that!
> Will

RFC 8126 requires specifying the initial set of items in the draft, which
upon publication, IANA will use as the seed list and then be the official
list of what is registered.  I already had a list in the Appendix of the draft
which can be used/updated to be that list.

I now have the IANA Considerations text above in a change to the Internet
Draft boilerplate that surrounds the instruction-set.rst.  Since the deadline
for I-D submission is Monday, I plan to make the change and post it on
Monday after making sure any other instruction-set.rst changes get picked
up.

Dave

Re: [Bpf] Instruction set extension policy

[Dave Thaler]

Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > On Thu, Jul 6, 2023 at 6:35 PM Dave Thaler <dthaler@microsoft.com>
> wrote:
> > >
> > > 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...
[..]
> > I think that might work. What is the next step then?
> > Who is going to generate such a hex database?
> 
> I would be more than happy to do that!
> Will

RFC 8126 requires specifying the initial set of items in the draft, which
upon publication, IANA will use as the seed list and then be the official
list of what is registered.  I already had a list in the Appendix of the draft
which can be used/updated to be that list.

I now have the IANA Considerations text above in a change to the Internet
Draft boilerplate that surrounds the instruction-set.rst.  Since the deadline
for I-D submission is Monday, I plan to make the change and post it on
Monday after making sure any other instruction-set.rst changes get picked
up.

Dave
-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] Instruction set extension policy

[Michael Richardson]

[-- Attachment #1.1: Type: text/plain, Size: 2307 bytes --]


Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org> wrote:
    > 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.

agreed.

    > 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.

That seems like a really good plan.
They won't have to be long documents either.
It would be nice if there could be sufficient template so that they don't
need a lot of cross-area review to publish.

There is also a thought that there is simply a "yearly" wrap up of all
allocations.

    > 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.

    > Thoughts?

I think it important to distinguish for the group between
experimental/private-use space and provisional.

I don't think you want to renumber an instruction when it goes to Permanent
status.  I also think that you want to run this as Early Allocations, so that
they have a sunset clause, and the process for sunsetting such an allocation
should be clear.

You may also need to written policy (in the Linux kernel Documentation) about
back-patching of Provisional numbers into vendor branches and/or LTS
branches.

Can there be subtle semantic changes to Provisional allocations?
(Such as what happens when invalid data occurs?  The divide-by-zero
equivalent)



--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide





[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

[-- Attachment #2: Type: text/plain, Size: 76 bytes --]

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] Instruction set extension policy

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]


Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org> wrote:
    > 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.

agreed.

    > 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.

That seems like a really good plan.
They won't have to be long documents either.
It would be nice if there could be sufficient template so that they don't
need a lot of cross-area review to publish.

There is also a thought that there is simply a "yearly" wrap up of all
allocations.

    > 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.

    > Thoughts?

I think it important to distinguish for the group between
experimental/private-use space and provisional.

I don't think you want to renumber an instruction when it goes to Permanent
status.  I also think that you want to run this as Early Allocations, so that
they have a sunset clause, and the process for sunsetting such an allocation
should be clear.

You may also need to written policy (in the Linux kernel Documentation) about
back-patching of Provisional numbers into vendor branches and/or LTS
branches.

Can there be subtle semantic changes to Provisional allocations?
(Such as what happens when invalid data occurs?  The divide-by-zero
equivalent)



--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide





[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

RE: [Bpf] Instruction set extension policy

[Dave Thaler]

> -----Original Message-----
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> Sent: Friday, July 7, 2023 10:57 AM
> To: Dave Thaler <dthaler@microsoft.com>; bpf@ietf.org; bpf
> <bpf@vger.kernel.org>
> Subject: Re: [Bpf] Instruction set extension policy
> 
> Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org> wrote:
>     > 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.
> 
> agreed.
> 
>     > 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.
> 
> That seems like a really good plan.
> They won't have to be long documents either.
> It would be nice if there could be sufficient template so that they don't need
> a lot of cross-area review to publish.
> 
> There is also a thought that there is simply a "yearly" wrap up of all
> allocations.
> 
>     > 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.
> 
>     > Thoughts?
> 
> I think it important to distinguish for the group between
> experimental/private-use space and provisional.

Yes.  Right now I don't see a need to have experimental/private-use space.
If anyone else does, please speak up.

> I don't think you want to renumber an instruction when it goes to Permanent
> status.

Agree.  As with the URI scheme registry, the assigned values need not change
when something goes from Provisional to Permanent, only the status label
changes.  There is no numbering space division for Provisional.

> I also think that you want to run this as Early Allocations, so that they
> have a sunset clause, and the process for sunsetting such an allocation should
> be clear.

That's a fine discussion to have.  Provisional URI schemes have no such
sunset clause.  I might argue that subset clauses are only useful when space
is scarce.  Right now, that's not the case when you consider opcode+src+imm
as the space available.

> You may also need to written policy (in the Linux kernel Documentation)
> about back-patching of Provisional numbers into vendor branches and/or LTS
> branches.
> 
> Can there be subtle semantic changes to Provisional allocations?
> (Such as what happens when invalid data occurs?  The divide-by-zero
> equivalent)

I'd expect the answer to be the same as for Permanent allocations.
Offhand, I would say "yes", though of course one needs a plan for
backwards compatibility if so.

Dave

Re: [Bpf] Instruction set extension policy

[Dave Thaler]

> -----Original Message-----
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> Sent: Friday, July 7, 2023 10:57 AM
> To: Dave Thaler <dthaler@microsoft.com>; bpf@ietf.org; bpf
> <bpf@vger.kernel.org>
> Subject: Re: [Bpf] Instruction set extension policy
> 
> Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org> wrote:
>     > 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.
> 
> agreed.
> 
>     > 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.
> 
> That seems like a really good plan.
> They won't have to be long documents either.
> It would be nice if there could be sufficient template so that they don't need
> a lot of cross-area review to publish.
> 
> There is also a thought that there is simply a "yearly" wrap up of all
> allocations.
> 
>     > 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.
> 
>     > Thoughts?
> 
> I think it important to distinguish for the group between
> experimental/private-use space and provisional.

Yes.  Right now I don't see a need to have experimental/private-use space.
If anyone else does, please speak up.

> I don't think you want to renumber an instruction when it goes to Permanent
> status.

Agree.  As with the URI scheme registry, the assigned values need not change
when something goes from Provisional to Permanent, only the status label
changes.  There is no numbering space division for Provisional.

> I also think that you want to run this as Early Allocations, so that they
> have a sunset clause, and the process for sunsetting such an allocation should
> be clear.

That's a fine discussion to have.  Provisional URI schemes have no such
sunset clause.  I might argue that subset clauses are only useful when space
is scarce.  Right now, that's not the case when you consider opcode+src+imm
as the space available.

> You may also need to written policy (in the Linux kernel Documentation)
> about back-patching of Provisional numbers into vendor branches and/or LTS
> branches.
> 
> Can there be subtle semantic changes to Provisional allocations?
> (Such as what happens when invalid data occurs?  The divide-by-zero
> equivalent)

I'd expect the answer to be the same as for Permanent allocations.
Offhand, I would say "yes", though of course one needs a plan for
backwards compatibility if so.

Dave
-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf