The P4 language

1. What P4 is, and P4₁₄ versus P4₁₆

P4 is a high-level programming language for network data planes. Four properties define it: it allows protocol flexibility, it specifies a packet processing pipeline, it is compiled and loaded into a target platform, and it is open and standardized. The name comes from the founding paper, P4: Programming Protocol-Independent Packet Processors (Bosshart, Daly, Gibb, Izzard, McKeown, Rexford, Schlesinger, Talayco, Vahdat, Varghese, Walker), ACM SIGCOMM CCR, July 2014.

There are two versions of the language, and the distinction matters:

The evolution from P4₁₄ to P4₁₆ is itself an instance of the top-down principle from chapter 5: P4₁₄ still baked in assumptions about the hardware; P4₁₆ pushes every hardware-specific fact out of the core language and into an architecture description, leaving the language itself protocol- and target-agnostic.

The P4₁₆ language elements are a small, deliberate set:

2. Architectures and targets

Two P4₁₆ terms carry the whole portability story, and confusing them is the single most common mistake:

The division of labour is explicit: the P4₁₆ language and the P4₁₆ core library are community-developed; the extern libraries and the architecture definition are vendor-supplied. A P4 program is written against a specific architecture, which defines which blocks are available, the interfaces of each block, and their capabilities. Example architectures named in the slides are the V1Model, the SimpleSumeSwitch and the Portable Switch Architecture (PSA).

The consequence is the sentence to remember: architectures enable portability of P4 programs across different hardware and software targets. Ask "can I implement this feature with P4?" and the honest answer is it depends on the architecture — the language is flexible enough to express almost any match-action behaviour, but the specific capabilities (ternary vs. LPM vs. exact match, counters, registers) depend on the architecture. Ask "can I run my program on switch X from vendor Y?" and the answer is probably yes, if vendor Y provides a P4 compiler for the architecture you used.

3. The V1Model and standard metadata

The course teaches against the V1Model, implemented on top of BMv2's simple_switch target (the software switch used in the labs). Its pipeline has six blocks, and knowing their order is knowing where your code runs:

Between the programmable blocks flows a struct the architecture provides: standard_metadata_t. Three of its fields are the ones you will touch constantly, and their distinction is a favourite exam point:

struct standard_metadata_t {
    bit<9>  ingress_port;
    bit<9>  egress_spec;
    bit<9>  egress_port;
    bit<32> packet_length;
    bit<32> enq_timestamp;
    bit<19> enq_qdepth;        // enqueue queue depth — used by ECN in ch. 7
    bit<48> ingress_global_timestamp;
    bit<16> mcast_grp;
    bit<1>  checksum_error;
    // ... and more
}

4. The program template

A V1Model program always has the same skeleton. The V1Switch(...) instantiation at the bottom wires the six blocks together in order — this is the program declaring which piece of code plays which role in the pipeline of the previous section.

#include <core.p4>
#include <v1model.p4>

/* HEADERS */
struct metadata { ... }
struct headers {
  ethernet_t ethernet;
  ipv4_t     ipv4;
}

/* PARSER */
parser MyParser(packet_in packet, out headers hdr,
                inout metadata meta, inout standard_metadata_t smeta) { ... }

control MyVerifyChecksum(inout headers hdr, inout metadata meta) { ... }
control MyIngress(inout headers hdr, inout metadata meta,
                  inout standard_metadata_t std_meta) { ... }
control MyEgress(inout headers hdr, inout metadata meta,
                 inout standard_metadata_t std_meta) { ... }
control MyComputeChecksum(inout headers hdr, inout metadata meta) { ... }
control MyDeparser(packet_out packet, in headers hdr) { ... }

/* SWITCH — bind the blocks into the V1Model pipeline, in order */
V1Switch(
  MyParser(),
  MyVerifyChecksum(),
  MyIngress(),
  MyEgress(),
  MyComputeChecksum(),
  MyDeparser()
) main;

The simplest complete program, the "hello world" of P4, forwards by swapping ports 1 and 2 directly in the ingress control:

5. Types, headers and the parser

P4's types are deliberately spartan, because everything about a packet is bits at fixed offsets:

typedef bit<48> macAddr_t;
typedef bit<32> ip4Addr_t;

header ethernet_t {
  macAddr_t dstAddr;
  macAddr_t srcAddr;
  bit<16>   etherType;
}
header ipv4_t {
  bit<4>    version;   bit<4>    ihl;
  bit<8>    diffserv;  bit<16>   totalLen;
  bit<16>   identification; bit<3> flags; bit<13> fragOffset;
  bit<8>    ttl;       bit<8>    protocol; bit<16> hdrChecksum;
  ip4Addr_t srcAddr;   ip4Addr_t dstAddr;
}

The parser as a state machine

Parsers are functions that map packets into headers and metadata, written in a state machine style. Every parser has three predefined states — start, accept, reject — and the programmer may define others. In each state you execute zero or more statements and then transition to another state; loops are permitted. The platform initialises user metadata to 0.

6. The select statement

P4₁₆ has a select statement to branch inside a parser. The slides describe it precisely: it is similar to case statements in C or Java, but without fall-through behaviour — no break is needed. In parsers it is often necessary to branch based on some of the bits just parsed; for example, etherType determines the format of the rest of the packet. Match patterns can be literals or simple computations such as masks.

state start {
  transition parse_ethernet;
}
state parse_ethernet {
  packet.extract(hdr.ethernet);
  transition select(hdr.ethernet.etherType) {
    0x800:   parse_ipv4;   // it is IPv4, keep parsing
    default: accept;       // not IPv4, we are done
  }
}

7. Controls, actions and tables

Controls are similar to C functions without loops. They can declare variables, create tables, instantiate externs, and their functionality is specified by the code in the apply statement. They represent everything expressible as a directed acyclic graph: match-action pipelines, deparsers, checksum updates.

Actions

Actions are also very similar to C functions, and their parameters have a direction. This is the concept that unifies the data plane and the control plane, so it is worth stating carefully:

• Directional parameters come from the data plane. Actions called directly use only directional parameters.
• Directionless parameters come from the control plane. Actions used in tables typically use directionless parameters (and may sometimes use directional ones too).

// directionless dstAddr and port are filled in by the control plane
// when it installs a table entry
action ipv4_forward(macAddr_t dstAddr, bit<9> port) {
  standard_metadata.egress_spec = port;
  hdr.ethernet.dstAddr = dstAddr;
  hdr.ipv4.ttl = hdr.ipv4.ttl - 1;
}
action drop() { mark_to_drop(); }

Tables

The table is the fundamental unit of a match-action pipeline. A table specifies what data to match on and the match kind, a list of possible actions, and optional properties (size, default action, static entries). Each table contains one or more entries (rules), and each entry has a specific key to match on, a single action executed on a match, and action data (possibly empty).

table ipv4_lpm {
  key = {
    hdr.ipv4.dstAddr: lpm;      // longest-prefix match
  }
  actions = {
    ipv4_forward;
    drop;
    NoAction;
  }
  size = 1024;
  default_action = NoAction();
}

The division of labour is the crucial part, and it is the same control/data split from chapter 3, now made concrete: the data-plane P4 program defines the format of the table (key fields, actions, action data) and performs the lookup and executes the chosen action; the control plane populates the entries with specific information, based on configuration, automatic discovery, or protocol calculations.

A control applies its tables in its apply block:

control MyIngress(inout headers hdr, inout metadata meta,
                  inout standard_metadata_t std_meta) {
  table ipv4_lpm { /* ... as above ... */ }
  apply {
    if (hdr.ipv4.isValid()) {
      ipv4_lpm.apply();
    }
  }
}

8. Match kinds

The type match_kind is special in P4. The standard library core.p4 defines three, the V1Model architecture adds two more, and other architectures may define their own — a perfect small illustration of the "architecture defines capabilities" principle from section 2.

9. Deparsing

The deparser assembles the headers back into a well-formed packet. It is expressed as a control function — no new construct is needed — and it uses the packet_out extern from core.p4, whose emit(hdr) serialises a header only if it is valid.

control MyDeparser(packet_out packet, in headers hdr) {
  apply {
    packet.emit(hdr.ethernet);
    packet.emit(hdr.ipv4);   // emitted only if still valid
  }
}

The design advantage stated in the slides is subtle but important: making deparsing explicit decouples it from parsing. You are not obliged to emit headers in the order you parsed them, or to emit everything you parsed; a header you setInvalid() during processing simply vanishes from the output. This is precisely the mechanism the tunnelling exercise in chapter 7 uses to push and pop a tunnel header — validity in, validity out.

Walk one packet through the full V1Model pipeline below, from parse to deparse.

10. What P4 cannot do — and why

The most instructive slides in the P4 deck are the ones about limitations, because the limits are not incidental — they are the price of running at line rate. The core P4 language is very small: highly portable, but very limited in expressivity.

What is missing from the language

Floating point; pointers and references; data structures and recursive data types; dynamic memory management; loops and iterators (except the parser state machine); recursion; threads. The slides give the reason in one arrow: ⇒ constant work per byte of header. Everything absent is something whose cost cannot be bounded per packet.

What cannot be done in pure P4

The closing argument of the deck answers "why P4₁₆?" and it reads as a list of software-engineering virtues rather than networking ones: clearly defined semantics (you can describe what your data plane does), expressive (a wide range of architectures through a standard methodology), high-level and target-independent (the compiler manages resources and the hardware), type-safe (enforces good design and eliminates "stupid" bugs), agile (high-speed devices become as flexible as any software), and insight (freely mixing packet headers and intermediate results).

Check your understanding