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.

Data Plane

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]:

• A programmable Parser block that converts serialized packets into readable headers for the data plane program (metadata).
• A programmable Match-Action Table (MAT) block that matches entry tables and performs actions in response to matches.
• A programmable Deparser block that serializes the final header and metadata into a packet.
• A 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]:

• User-defined metadata : User-defined metadata refers to structure that are explicitly declared by the P4 programmer in the P4 program. It provides a way to carry additional context or state information along with the packet as it traverses the network device during its processing.
• Intrinsic metadata : Intrinsic metadata refers to metadata that are provided by the P4 architecture itself and are not explicitly declared by the programmer. The availability and behavior of intrinsic metadata may vary depending on the P4 architecture or target (e.g ingress_port, packet_length, egress_spec, etc).

All metadata is removed when the corresponding packet leaves the processing pipeline (e.g drop).

P4 Architecture Model

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

P4 Target Programming

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

Conclusion

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.

References

[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