the P4 language
/ P-four /
Most network switches are like a calculator with fixed buttons: they understand a built-in set of protocols (Ethernet, IP, TCP) and you cannot teach them anything new. P4 is a programming language that flips this around. It lets you write down how a switch should parse and process packets — what header fields exist, how to read them, which match-action tables to consult, and what to do — and then load that program onto a programmable switch. Instead of accepting whatever protocols the chip was born knowing, you define them yourself.
Concretely, a P4 program describes the packet-processing pipeline in three main pieces: a parser that says how to peel apart a packet's headers (first read 14 bytes as Ethernet, then if the type is IPv4 read 20 more bytes as IP, and so on); the match-action tables and their possible actions (match on these fields, do these things); and the order in which the packet flows through them, plus how to reassemble (deparse) it on the way out. You compile this program for a target — a programmable ASIC, a SmartNIC, or a software switch — and the device then behaves exactly as your program specifies. Crucially, P4 is protocol-independent: the chip has no built-in idea of IP or TCP until your program defines them, so you can add support for a brand-new or custom protocol without new silicon.
Why it matters: P4 is the language of programmable data planes, the answer to a real limitation of fixed pipelines and even of OpenFlow, which can only match header fields the standard already knows. With P4 you can experiment with new protocols, build custom telemetry that stamps switches' own measurements into packets, and tailor a switch to one application. Be honest about scope: P4 programs the data plane (how packets are processed at line rate), not the control plane (the logic that decides policy) — you still need a controller to fill the tables. And P4 only runs on hardware or software targets built to be programmable; it cannot reprogram a fixed-function switch.
A research team invents a new header that carries a custom routing tag. On a fixed switch this is impossible without new chips. With P4 they write a parser that reads the new header, a table that matches on the tag, and an action that forwards accordingly, then load it onto a programmable switch. The switch now forwards on a protocol that did not exist when the hardware was built.
You define the protocol; the programmable switch obeys it at line rate.
P4 programs the data plane, not the control plane: it describes how packets are parsed and acted on, but a separate controller still decides what rules to put in the tables. P4 also requires a programmable target — it cannot reprogram fixed-function silicon.