The BPF instruction set architecture is now RFC 9669

[Posted November 5, 2024 by corbet]

After a couple of years of effort, the BPF instruction set architecture has been accepted as RFC 9669, giving it a standard outside of the in-kernel implementation. This message from David Vernet (who also contributed an article on the standardization process last year) describes the process and why it is important:

Though some vendors have already implemented BPF offloading capabilities without having a standardized ISA, others are not quite as risk tolerant. As Christoph [Hellwig] discussed at LSFMM 2022, certain NVMe vendors have expressed an interest in building BPF offloading capabilities for various use cases such as eXpress Resubmission Path (XRP), but they simply can't fund such a project without certain components of BPF being standardized. Hence, the effort to standardize BPF was born.

Standards

Posted Nov 5, 2024 16:36 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (3 responses)

The thing about standards (which these vendors want) is that saying it doesn't make it so. The IETFs RFCs are often treated as standards, but they actually have a specific Standards series which isn't the RFCs, the STD series, STD-63 for example is UTF-8.

Most of the so-called "Standards Development Organisations" do not make standards, how could they. They make specifications, and the IETF stands out for having the guts to specifically note whether their specifications turned out to be standard.

If what you want is a standard, well, you're going to have to wait and see. If in fact you only ever wanted a specification then an RFC makes that possible. Seems like these vendors just wanted a specification.

Standards

Posted Nov 5, 2024 21:04 UTC (Tue) by Manifault (guest, #155796) [Link]

>If what you want is a standard, well, you're going to have to wait and see. If in fact you only ever wanted a specification then an RFC makes that possible. Seems like these vendors just wanted a specification.

A document being published as a Proposed Standard (what this RFC was published as) or an Internet Standard is merely a reflection of the topic's maturity. Both Proposed Standard and Internet Standard are specifications. Standards organizations are not in the business of enforcing that vendors implement their specifications, so the actual label that's given to it has no bearing on what vendors will decide to do beyond it being a data point that reflects the organization's confidence that the specification will or won't change over time.

The formal definition of both are here (and to reiterate, they are both specifications):

- Proposed Standard: https://datatracker.ietf.org/doc/html/rfc2026#section-4.1.1.
- Standard: https://datatracker.ietf.org/doc/html/rfc2026#section-4.1.3

Standards

Posted Nov 5, 2024 22:18 UTC (Tue) by jengelh (guest, #33263) [Link]

>The thing about standards (which these vendors want) is that saying it doesn't make it so.

It may be not be a formal IETF Standard, but it is a standard in the sense of "convention".

Standards

Posted Nov 6, 2024 13:54 UTC (Wed) by jg (guest, #17537) [Link]

For better or worse, many/most IETF standards never get beyond "proposed" standards. But they function quite well as standards, none-the-less. Industry is happy to use RFC's of whatever form as standards.

This is due to sometimes excessive niggling during the internet draft phase of a document, making it often unneeded to go through the process again to move from "proposed", to "draft", to "full" standard, along with lack of enough masochistic volunteers to drive documents through the process.

This is an observation by such a masochist, who was the editor of the HTTP standard through much of its formative years.

At least in my era, the bar was too high initially for proposed, but the pain for draft or full also to high for the intent of the IETF process to really work properly for most documents to progress in its intended way.

Jim Gettys

Compatibility

Posted Nov 6, 2024 13:36 UTC (Wed) by jezuch (subscriber, #52988) [Link] (1 responses)

Curious: is there a Conformance Test Suite and is the kernel held up to it?

Compatibility

Posted Nov 12, 2024 19:56 UTC (Tue) by jg (guest, #17537) [Link]

Usually compliance testing as in test suites is left to other organizations by the IETF.

The process for proposed to draft to full standard does ensure that only features actually implemented
in multiple implementations can become part of the draft or full standard, and that the protocol interoperates.

The IETF has by far the most experience in protocol interoperability.