P4 Network Data Plane Programming: What it is, and Why it Matters

By Shahzad Chowdry | Jun 01, 2016

Earlier this week, two notable P4 Language Consortium events took place at Stanford University: the P4 Developer Day 2016 and the P4 Workshop 2016. Both events were single-day conferences sponsored by the P4 Language Consortium ( Below are some of my impressions of the events and the key takeaways.

A Little Background on P4

Before getting into the details of the conference itself, I’ll briefly cover the history and purpose of P4 for those of you who are new to the language. The name, P4, comes from a 2014 ACM SIGCOMM research paper which first proposed its creation. The paper was titled, “P4: Programming Protocol-Independent Packet Processors,” was authored by many of the founding members of the P4 Language Consortium.

P4 is a high-level programming language intended to describe the behavior of the data plane of any system or appliance that forwards, modifies or inspects network traffic. Depending on the flexibility and complexity of the system/appliance, the data plane of such systems can run the gamut from fixed-function ASICs (such as those used in L2 switches) all the way to fully programmable, general purpose CPUs found in whitebox implementations of routers, web proxies and firewalls. When the designers of P4 state that it is a programming language intended for packet processors, which packet processing device are they referring to?Hardwired ASICs, FPGAs or CISC CPUs? The answer is, “All of the above, provided they can interpret P4.”

One of the primary goals of P4 is to keep the language hardware independent. P4 is meant to describe/specify the behavior of the data plane but not how the data plane is actually implemented. The job of interpreting P4 behavioral code and generating a lower-level, device-specific, implementation falls to manufacturers of the target systems. For example, Netronome’s Agilio® CX and LX SmartNICs have data planes based on Netronome’s Network Flow Processors (NFP-4000 and NFP-6000 respectively). The NFPs perform the heavy lifting in the data plane and are fully P4 compliant. Netronome’s Software Development Kit (SDK) includes a P4 Integrated Development Environment (IDE) that will allow developers to write P4 source code and rules, compile the P4 to an NFP-specific representation that is used to program the data plane. The IDE also facilitates P4 development by providing step-wise P4 code execution, visibility to counters and registers and the ability to insert code breakpoints.

Target (or hardware) independence wasn’t the only goal of P4. The other two primary goals of P4 are protocol independence and reconfigurability. Most network data planes perform three basic operations: packet parsing, match/action operations, and packet reassembly. P4 provides coding constructs that make describing these operations easy to understand. And because P4 is an actual language, users have the ability to define the packet header structures the parser will extract. This is a vast improvement over protocols like OpenFlow which can only parse the headers for supported network protocols. If you wish to parse Ethernet, IP or TCP headers using OpenFlow – no problem, all those protocols are officially supported. But what do you do if the packets entering your data plane contain protocol headers that are not supported by OpenFlow? For example, if you need to parse an NVGRE packet, you will have to wait until OpenFlow adds support for that protocol. Contrast this with P4, which will allow you to specify the header stackup of inner and outer Ethernet and IP headers and the GRE header and parse it. This ability is known as protocol independence. Additionally, the ability to write new P4 source code and rules, compile it and push it to the data plane of a system already deployed in a production environment is known as reconfigurability. You aren’t simply updating the data in forwarding table, you are restructuring/redesigning the table itself!

P4 Developer Day 2016

P4 Developer Day took place on May 23rd at Stanford University. This was day one of a two-day conference and its focus was on education and hands-on labs. After the morning introductions, a series of technical presentations were presented. They covered P4 language tutorials and developers’ experiences using P4 to configure a variety of data plane architectures.

The afternoon sessions provided conference attendees the opportunity to participate in hands-on P4 labs. Netronome was one of the companies hosting such a lab, and I was one of Netronome employees that helped attendees use the Netronome IDE to complete a series of P4 labs. When I say Netronome’s P4 lab session was “hands-on,” I truly mean it. Netronome’s session didn’t consist of slideware or a P4 hardware simulator – lab attendees used P4 to program actual Netronome Agilio CX SmartNICs. The Agilio SmartNICs were hosted in servers located in Netronome labs in Santa Clara, Pittsburgh and Boxborough. Lab attendees used the Netronome IDE and P4 to describe a packet-forwarding data plane. The IDE then linked and programmed an actual Agilio CX SmartNIC. Attendees could then log into the host server and a traffic generator to test the operation of the P4-specified data plane they just programmed.

P4 Developer Day 2016 attendees

Feedback from the session was overwhelmingly positive. One attendee commented that that he came into the lab knowing very little about P4 but by then end of the lab, had written a P4 data plane and programmed actual hardware. Not bad for 90 minutes worth of work!

P4 Workshop 2016

P4 Workshop 2016

The P4 Workshop was on the second day of the conference and it was filled with interesting P4-related papers and product demonstrations.

Netronome gave two presentations at the workshop. The first was a joint presentation given by Tom Tofigh, a Principal Member of Technical Staff at AT&T Labs, and Nic Viljoen, a Research Engineer at Netronome. Tom and Nic described how AT&T is using P4 programmable NICs to provide real time measurement of traffic flows in the AT&T cloud.

Speaker presenting Comparing OpenFlow and P4 SmartNIC Data Planes

The second presentation, “Comparing OpenFlow and P4 SmartNIC Data Planes,” was given by Netronome Chief Architect, Senior Vice President, Software Engineering, and Co-Founder, Johann Tönsing. Johann discussed the architectural tradeoffs associated with coding in P4 versus using the OpenFlow protocol to describe the match-action behavior of the data plane on a Netronome Agilio SmartNIC.

General Comments About Both Conferences

  • The P4 language has a large and growing ecosystem of academic researchers and corporations using the language in products that are commercially available today.
  • The P4 specification continues to evolve. There are a number of new features and functionality the P4 Consortium is looking to add to the next version of the specification, including the ability to specify a state-aware data plane.
  • The use of P4 could expand to use beyond specifying data plane behavior.Network Telemetry, control plane applications, and packet scheduling functions are just a few of the applications that have been implemented using P4.

If you find the capabilities and potential of P4 intriguing, then you should consider joining the P4 Language Consortium ( and attending future P4 conferences the Consortium and other member companies host.

Visit and to learn more about Netronome’s involvement with the P4 programming language.