NetworkingTechnologyDevops

P4 and P4Runtime: Programmable Data Planes Explained

Updated on
9 min read

Routers and switches have traditionally exposed a fixed set of packet-processing behaviors, even as the protocols and policies around them changed. P4 programmable data planes give network engineers and researchers a way to describe how a device parses and processes packets, while P4Runtime provides an API for a controller to configure the resulting pipeline. This explainer separates those two roles, shows where target hardware still sets limits, and walks through a safe software-switch lab.

What Is P4?

P4, short for Programming Protocol-independent Packet Processors, is a domain-specific language for describing packet-processing behavior in a network device. A P4 program can define which headers a device recognizes, how it classifies packets, which match-action tables it applies, and how it updates or forwards packets. The P4 project homepage introduces the language and its community; the P4_16 specification defines its syntax and semantics.

P4 is not a general-purpose language for configuring every part of a router or switch. It describes a packet-processing pipeline within an architecture supported by a compiler and target. The target might be a software switch, programmable network processor, FPGA, or a switch ASIC. Each target has its own limits and supported features.

P4Runtime is a separate control-plane API. It lets controller software communicate with a P4 device to install entries in supported tables, read state, and perform other operations described by the API. In short, P4 describes the pipeline; P4Runtime lets a controller operate parts of that pipeline. The P4Runtime specification defines the API and its limits.

The Problem P4 Solves

Traditional switch hardware implements packet parsing and forwarding with behavior selected by the vendor. Operators can configure supported features, but a new protocol header or specialized processing need may depend on a vendor software release, a new product, or an external appliance. This gap can slow experiments and make it difficult to tailor packet processing to a workload.

P4 moves some of that decision-making into a program that can be compiled for a compatible target. A team can describe a parser for a new encapsulation, add a table for a policy, or collect selected packet metadata without waiting for a fixed feature to appear in every device. That does not remove hardware constraints: a program still has to fit the target’s parser, memory, action, and pipeline resources.

This is one possible implementation beneath a broader software-defined networking design. SDN describes how network control and policy are organized; P4 defines packet processing on a device. For the larger control-plane picture, see the software-defined networking explainer. The IETF/IRTF RFC 7426 provides a useful vocabulary for SDN layers and forwarding abstractions; it is an informational RFC, not an Internet Standards Track specification.

How P4 and P4Runtime Work

A P4 target processes each packet through stages defined by its architecture and program. A simplified path looks like this:

packet
  -> parser extracts headers and metadata
  -> ingress controls classify and apply match-action tables
  -> target-specific traffic management
  -> egress controls apply further actions
  -> deparser serializes headers
  -> packet leaves an output port

The parser recognizes header formats and records which headers are present. Control blocks then use metadata and table lookups to select actions, such as changing a header field, choosing an output port, or dropping a packet. The deparser emits the resulting headers and payload. The exact stages, metadata, externs, and resource limits depend on the target architecture.

The P4 compiler translates a source program into artifacts for a target. These typically include target-specific device configuration and P4Info metadata describing the tables, actions, and other P4 entities available to a controller. The configuration is not necessarily portable between unrelated targets: even when two devices accept similar P4 source, their supported architecture features and resources may differ.

A controller connects to a device’s P4Runtime service, commonly over gRPC, and uses the P4Info model to identify programmable entities. It can write table entries that associate keys with actions and their parameters, read counters or other supported state, and manage the pipeline where the implementation supports it. The API does not automatically configure every device feature; for example, port setup and traffic management are outside the core P4Runtime scope and may require separate management interfaces.

Feature Fixed-function switch P4-programmable target
Packet parsing Uses the vendor’s supported parser and protocols A P4 program describes parsing within the target architecture
Forwarding behavior Configures available vendor-defined tables and actions Defines supported match-action logic and then populates its tables
Controller interface Often uses vendor APIs or standardized device interfaces P4Runtime can control P4-defined entities when implemented
Portability Configuration depends on vendor and product Source can be portable only across compatible architectures and features
Resource limits Determined by product capabilities Still determined by target resources, compiler, and pipeline design
Best fit Stable, widely supported networking functions Specialized packet processing, experimentation, or tailored pipelines

These are broad categories rather than a guarantee that every P4 target can replace a conventional switch. P4 is useful when the required behavior is expressible on a supported target and the operational cost of managing the custom pipeline is justified.

Components and Key Concepts

Parser and deparser

The parser extracts protocol headers in a defined sequence and can branch based on fields such as EtherType or IP protocol. It does not inspect arbitrary packet data without limits: the architecture and program define what can be parsed and how much work is possible. The deparser performs the corresponding output task by serializing valid headers and packet data.

Match-action tables

A table defines keys, available actions, and lookup behavior. A controller or static configuration supplies entries. For example, an IPv4 forwarding table might match a destination prefix and invoke an action that rewrites link-layer addresses and selects an egress port. The P4 program defines the table’s shape and behavior; runtime entries provide the network-specific values.

Architecture and target

An architecture defines the programmable blocks and interfaces available to a P4 program. A P4 program written for one architecture may need changes before it can run on another. A software model such as BMv2 is useful for functional experiments, but it does not reproduce the throughput, resource layout, or every behavior of a production ASIC.

Compiler, P4Info, and P4Runtime

The compiler checks and translates a P4 program for a selected target. P4Info provides control-plane-visible names and identifiers, while the target-specific device configuration contains the implementation artifact. P4Runtime provides the protocol used by controller software to read or update supported runtime state. This division helps avoid hard-coding table identifiers in an application, but controller and device versions still need to agree on the pipeline contract.

Real-World Use Cases

P4 is used in research and operational settings where the packet-processing behavior itself needs to change or be observed. Examples include network telemetry that adds selected metadata, custom load balancing, protocol experiments, and specialized forwarding or filtering in a data center. A team can use a software target to validate logic before considering supported hardware.

P4 does not replace routing protocols or the network control plane. A routing system may calculate reachability and a controller may translate that state into table entries; P4 defines how the device processes packets using its programmed pipeline. Existing designs such as BGP routing still provide control-plane functions that a P4 dataplane alone does not supply.

It can also complement virtual networks. Overlay protocols, virtual switches, and controllers decide how tenant traffic is represented and managed, while a programmable pipeline can implement selected packet handling underneath. See the network virtualization guide for the broader roles of underlays, overlays, and SDN.

Getting Started: Run a P4 Software-Switch Lab

The official P4 tutorials repository includes exercises for basic forwarding and P4Runtime. Its basic exercise uses the BMv2 software switch and Mininet, so it is a practical starting point without a physical programmable switch. Follow the repository’s prerequisites first; the lab environment depends on Linux networking tools and should be run in a disposable Linux VM or other supported environment.

Clone the tutorials and start the basic forwarding exercise:

git clone --depth 1 https://github.com/p4lang/tutorials.git
cd tutorials/exercises/basic
make run

At the Mininet prompt, check that the sample topology responds:

mininet> h1 ping h2
mininet> pingall

The starter program is intentionally incomplete and drops packets, so failed connectivity is expected before implementing the exercise. After changing the P4 program, make run compiles it and launches the topology again. Use the exercise’s own instructions to compare the result with the expected forwarding behavior. When finished, leave Mininet and clean up:

mininet> exit
make stop
make clean

The basic exercise separates data-plane logic from static table setup. The P4Runtime exercise in the same repository then demonstrates controller-based programming, including pushing a pipeline and installing entries. For repeatable operational workflows, the network automation tools guide covers inventory, safe changes, and validation; those practices are still relevant when the controlled device has a programmable pipeline.

Common Misconceptions

“P4 makes every switch portable”

No. The language is designed to describe packet processing independently of a specific protocol, but a P4 program still targets an architecture and compiler. Differences in parser features, externs, table capacities, and pipeline resources constrain portability.

“P4Runtime is the P4 programming language”

No. P4 is used to define packet-processing behavior. P4Runtime is an API for controlling supported P4-defined entities and pipeline configuration. A device can support one without providing every feature or workflow implied by another.

“A programmable pipeline replaces the control plane”

No. P4 describes how a target processes packets, while control-plane systems determine policy and populate runtime state. P4Runtime is one way for a controller to communicate with a target; routing, topology discovery, device management, and orchestration remain separate responsibilities.

“A software switch predicts production performance”

No. A software model can help test parser and forwarding logic, but it does not model the throughput, buffering, timing, or resource allocation of all production hardware. Hardware qualification and realistic testing are required before relying on a program in a production path.

Changelog

  • Initial publication.
TBO Editorial

About the Author

TBO Editorial writes about the latest updates about products and services related to Technology, Business, Finance & Lifestyle. Do get in touch if you want to share any useful article with our community.