Dec 19, 2023 by Nathan Camiola | 1015 views
https://cylab.be/blog/314/the-p4-language-the-basics-of-p4-language
Programming Protocol-independent Packet Processors (P4) is a domain-specific language for network devices, specifying how data plane devices (switches, NICs, routers, filters, etc.) process packets. P4 programs are designed to be implementation-independent: they can be compiled against many different types of execution machines such as general-purpose CPUs, FPGAs, system(s)-on-chip, network processors, and ASICs.
Most of the information and images presented in this blog post comes from the forum, the Github and official P4 project documentation, as well as slides from lectures and publications on the subject. All these documents are listed in the reference section of this post.
In general, the packet-processing chip of a device implements a wide range of functionality that we may or may not require. These functionality are defined by the data plane
algorithms. The system will be constructed based on the capabilities of the chip. We refer to this style as the Bootom-Up design. The disadvantage is that we will need to replace the chip or hardware in order to add a new function, which might be expensive and/or take a long time [1].
By attempting a Top-Down design in reverse, P4 enables us to use a P4 software that is directly compiled on the device to precisely identify the packet-processing mechanism of the device [1]. In other words, P4 devices would allow users to implement their own data plane
and control plane
algorithms.
The PISA (Protocol Independent Switching Architecture) is a good example of data plane models since it is based on the concept of a programmable match-action pipeline implemented by several modern programmable switches. It is also the data plane programming model for P4 [7].
Basically, PISA is built as follows [1;7]:
Parser
block that converts serialized packets into readable headers for the data plane program (metadata).Match-Action Table (MAT)
block that matches entry tables and performs actions in response to matches.Deparser
block that serializes the final header and metadata into a packet.Metadata bus
that transports the metadata throughout the pipeline.The P4 metadata refers to the intermediate data generated during the packet processing throughout the pipeline [5;7]:
All metadata is removed when the corresponding packet leaves the processing pipeline (e.g drop).
The P4-programmable blocks (such as Parser, Ingress, etc.) and their data plane interfaces are determined by the P4 Architecture Model. In other words, the pipeline's architecture dictates the parts that can be programmed. P4 Architecture Model can be seen as a connection between the switch and the program. It outlines what can and cannot be done. Each hardware manufacturer (e.g Intel Tofino, NetFPGA SUME) is required to provide the architecture definition along with a P4 compiler [2;5].
So, P4 programs are not meant to be portable across several architectures; rather, the same program will be written differently depending on the architecture in which it is used. However, P4 programs created for a specific architecture may work on any target that implements the matching model [5].
As previously explained, the P4 Architecture Model, P4 Compiler, and the target (P4-programmable node) are provided by the manufacturer [5].
To describe all the features required, the programmer creates a P4 Program. This program defines the algorithms executed by the target's Architecture Model's programmable blocks to interact with other programmable and non-programmable blocks [5;6].
The program is compiled by the vendor's P4 Compiler, which produces "an API for controlling the state of the data plane objects from the control plane and a data plane configuration that implements the forwarding logic stated in the input program" - Language specification [5]. The control plane interacts with the data plane via runtime mechanisms (e.g P4Runtime, detailed in a future blog post).
That's the end of this first Blog Post on the basics of the P4 language. This first post is just a small overview of what P4 is all about. Further posts on its mechanics and code will follow. In the meantime, if you're interested, the P4 project's Gitlab is very well supplied with practical exercises, tutorials and other code examples.
[1] p4lang, “P4lang/Education: P4 Education,” GitHub, https://github.com/p4lang/education/blob/master/GettingStarted.md (accessed Dec. 18, 2023).
[2] “P4 programming language,” P4 Programming Language, https://forum.p4.org/ (accessed Dec. 18, 2023).
[3] “P4,” Open Networking Foundation, https://opennetworking.org/p4/ (accessed Dec. 18, 2023).
[4] p4lang, “P4lang/Tutorials: P4 language tutorials,” GitHub, https://github.com/p4lang/tutorials (accessed Dec. 18, 2023).
[5] Language specification, https://p4.org/p4-spec/docs/P4-16-v1.2.3.pdf (accessed Dec. 18, 2023).
[6] S. Laki, “Programmable Networks Lecture 2 – P4 basics & lookups” (accessed Dec. 18, 2023)
[7] F. Hauser et al., “A survey on Data Plane Programming with P4: Fundamentals, advances, and Applied Research,” Journal of Network and Computer Applications, vol. 212, p. 103561, 2023. doi:10.1016/j.jnca.2022.103561
This blog post is licensed under CC BY-SA 4.0