Hi everyone, We have some exciting news to share: The IETF BPF Instruction Set Architecture document has officially been published as RFC 9669 [0]. It's been a long road, so I wanted to take this opportunity to talk about the process of bringing the RFC document to fruition, and why it's important that we've standardized core components of the BPF ecosystem. [0]: https://www.rfc-editor.org/rfc/rfc9669.html Why is standardization important to BPF? ---------------------------------------- Those of you who are familiar with the IETF may be wondering why an organization that has traditionally standardized networking protocols ended up being the standards body for BPF, and why BPF needed to be standardized in the first place. We all know why it's important for there to be a standard around the encoding and semantics of the bits of an IP packet, for example, but why would BPF need something similar? The short answer: device offload. Some device vendors, such as Netronome [1], have already implemented devices that are capable of running XDP programs on the device directly rather than on the CPU. The use cases for this are quite straightforward: if you have e.g. a BPF program that will decide to drop a packet, making that decision on the NIC rather than on the CPU will save CPU capacity, power consumption, etc. [1]: https://github.com/Netronome/bpf-samples Though some vendors have already implemented BPF offloading capabilities without having a standardized ISA, others are not quite as risk tolerant. As Christoph discussed [2] 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) [3], but they simply can't fund such a project without certain components of BPF being standardized. Hence, the effort to standardize BPF was born. [2]: https://www.youtube.com/watch?v=9NmDqjfMKfo [3]: https://www.usenix.org/conference/osdi22/presentation/zhong Of course, in addition to device offload, the standardization effort may well bear fruit in other areas such as software compatibility. The standardization process --------------------------- Let's talk briefly about what was involved with the standardization process. I'm going to skip a lot of details here, and mostly just want to go over the broad strokes to connect where we started to where we are now. This whole effort really kicked off in earnest by Christoph back at LSFMM in 2022. At the time of Christoph's presentation (linked above), we had decided on neither the organization we would work with to push through the standardization, nor the scope of standardization. As discussed on LWN [4], several different organizations were considered. The first choice was the eBPF Foundation, with the idea of course being that the charter of the organization is to manage the financial and technical direction of the project. Another candidate was the Organization for the Advancement of Structured Information Standards (OASIS), as they were the organization that standardized virtio [5]. Finally, the IETF was considered, as Dave Thaler (the engineer who drove BPF adoption at Microsoft and a participant in LSFMM 2022) was a long-time IETF member, as was Christoph. [4]: https://lwn.net/Articles/926882/ [5]: https://lwn.net/Articles/580186/ Following LSFMM 2022, a Side Meeting [6] was conducted as part of IETF 115 to discuss whether BPF was an appropriate topic for standardization with the IETF. The IETF had always primarily focused on networking topics as described above, with the occasional foray into other areas such as file formats [7]. Though there were some skeptics, the takeaway from IETF 115 was ultimately that the IETF was eager to be the standardizing body (thanks to strong encouragement from the then-IETF Chair Lars Eggert), and that we would figure out how to make it work as we went along. [6]: https://lore.kernel.org/all/DM4PR21MB3440837AE8F54F8E6EA5D475A3119@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ [7]: https://www.rfc-editor.org/info/rfc9116 Fast forward to IETF 116 [8] in Yokohama. After more deliberation and community input, the decision was made to form the BPF working group [9]. The working group was categorized as part of the Internet Area under the leadership of Erik Kline as our Area Director, and with myself and Suresh Krishnan serving as co-chairs. At this point there were still some key unanswered questions, such as how the Linux kernel community and the IETF would work together given the vastly different workflow patterns followed by each organization, and how we would reconcile document licensing and copyright. Though it took some patience and persistence, these issues were all ultimately addressed, and the group charter was published with a list of documents that were in scope for our roadmap. At the head of this roadmap was the ISA document: [PS] the BPF instruction set architecture (ISA) that defines the instructions and low-level virtual machine for BPF programs, [8]: https://datatracker.ietf.org/meeting/116/session/bpf [9]: https://datatracker.ietf.org/group/bpf/about/ From that point, it was a matter of iterating on and completing the ISA document. A large part of this effort was resolving technical considerations, such as proposed semantics [10] for new instructions such as indirect calls (CALLX). Others topics were procedural questions, such as what the process should be for adding new instructions, deprecating old instructions, how to aggregate instructions into conformance groups [11], etc. Though it sometimes required a lot of discussion and time to resolve a topic, we always managed to reach consensus. Likely worth noting as well is that discussions often spanned both the mailing list, as well as in person (or virtual) discussions at IETF conferences. Eventually, the number of open topics and discussions in the working group was whittled down to zero, and we moved the document to Working Group Last Call in early March of this year (2024). After a few more steps in the IETF document lifecycle [12], such as moving to IESG evaluation, getting approval from the IESG, and then finally having RFC editors review and approve the document, our efforts were rewarded when the document was officially ratified as RFC 9669 on 10/31/2024. [10]: https://lore.kernel.org/bpf/20240213175141.10347-1-dthaler1968@xxxxxxxxx/ [11]: https://lore.kernel.org/bpf/072101da2558$fe5f5020$fb1df060$@gmail.com/ [12]: https://chairs.ietf.org/documents/lifecycle What's next? ------------ Getting the ISA document ratified as a Proposed Standard is a significant milestone. The primary value proposition of the standardization effort was to incentivize vendors to build BPF offload by de-risking their investment. Now that we have an official Proposed Standard that's been ratified, the plan is to take a step back and see how the industry responds. If we observe that vendors have taken notice and either begin investing in BPF offload, or join the IETF discussions to talk about what other standards they would need, we can plan to ramp back up on our time investments, start attending IETF conferences again, etc. Until then, the plan is to try and minimize the overhead of IETF processes, while still optimizing for iterating on documents, and meeting in person as a working group on an ad-hoc basis, when required. To stress: "minimize" does not mean "cease functioning". Work is continuing in the background on other documents such as the psABI document, and patches and participation in the WG are both accepted, and encouraged. I want to give a big thank you to everyone who has participated in the BPF IETF working group so far, and helped us to achieve this milestone. There are too many individuals who helped to enumerate everyone, but I do want to thank Dave Thaler in particular for being the primary author of the document, and for putting in so much work to drive the document to completion over the last ~1.5 years. Congratulations, everyone, and thank you again for being a part of this. ----------------------------------------- David Vernet - BPF Working Group Co-Chair
Attachment:
signature.asc
Description: PGP signature
