For most of networking's history the dataplane was something you configured. Vendor hardware, vendor firmware, a CLI and a feature set you either had or waited a release cycle for; rather like a car where the heater comes with the trim level and that's the end of the discussion.
Over the last four years that has stopped being true, from four directions at once.
The four strands¶
SDN and OpenFlow split the control plane from the forwarding plane. The idea was right and the first implementation was far too rigid, with a fixed set of match fields and a spec revision needed for every new protocol. OpenFlow is fading; the separation it argued for isn't.
DPDK went the other way: leave the hardware alone and haul the dataplane up into userspace, bypassing the kernel network stack altogether. Poll-mode drivers, hugepages, cores pinned to packet processing. Enormous throughput gains, and the price is owning a parallel universe with none of your kernel tooling in it.
XDP splits the difference. Run an eBPF program at the earliest point in the
driver, before sk_buff allocation, and drop or redirect right there. You get
most of the bypass benefit and you're still in the kernel, with kernel tooling
and kernel safety guarantees. The core support is queued for 4.8, which is in
release candidates as we write (LWN): the
program type, context and verifier support land, with the driver hooks
following one NIC at a time.
P4 goes to the far end and makes the hardware programmable: describe the parser and the match-action pipeline, compile it for the target. The ambition is the biggest of the four, a switch whose protocol support is software.
What they have in common¶
Each one replaces "the vendor decided what this device can parse" with "we decide".
The pattern appears in half a dozen places at once: take something hardware fixed for you and make it specifiable instead. The dataplane version happened in networking first, which is why it tends to get filed on its own.
Which of these we would bet on¶
This field has produced rather more conference talks than deployments, so a prediction rather than a tally:
- XDP wins the general case. Verified program, kernel tooling, no second universe to operate. We expect DDoS mitigation and load balancing first, because those are the workloads where a packet you can drop in the driver is worth real money, and then everything else.
- DPDK keeps telco and appliances, where the throughput earns back the operational isolation, and does not escape them.
- P4 stays narrow, tied to whichever programmable ASICs ship in volume.
- OpenFlow mostly goes, and its central argument wins outright.
The specific protocol dies and the architectural argument wins. That pattern is one to notice, because it keeps happening. It is roughly what is becoming of OpenStack's API ambitions too.
The practical gain is a deploy cycle measured in minutes.
A new attack appears on a Tuesday. Today you open a vendor case, you are told the match field you need is in next quarter's firmware, and in the meantime you filter in userspace at a tenth of line rate or you buy a box. With a programmable dataplane you write the filter, load it and drop the traffic in the driver on hardware you already own. The university or regional ISP that cannot afford a scrubbing-centre contract gets to defend itself with a commodity server, which is a real redistribution of capability away from the people who can afford appliances.
The second scenario is the one we care about more. Protocol work becomes possible for people who are not a vendor. If you can describe a parser and compile it, you can deploy a new transport, a new encapsulation or a new congestion signal on your own network and measure it on real traffic, without persuading a chip company that your use case is worth a tape-out. That is the difference between a standards process driven by whoever ships silicon and one driven by whoever can demonstrate something working.
For engineering the toil that disappears is the vendor-feature wait, and with it a whole category of architecture written around what the box happened to support. Designs stop being shaped by a datasheet.
The compiler and the silicon behind it decide who may program the pipeline; the language is open in principle and closed in practice.
P4 is a published language with an open specification (SIGCOMM CCR, 2014 for the design; the Consortium's spec is at version 1.0.2), and the only way to get a P4 program onto a fast switch is a vendor's backend compiler for a vendor's ASIC, under NDA, with the pipeline's real constraints documented only to licensees. A language anybody can write and one company can execute is not an open platform; it is a very good funnel. The way this goes wrong is P4 becoming the marketing name for one vendor's SDK, with each generation's quirks forcing rewrites and the portability story never quite arriving. We would like to be wrong about that and would not bet on it.
The merchant-silicon market is already down to a handful of suppliers for the parts that matter, and a programmable pipeline makes that concentration worse rather than better, because the software investment is per-target. Every line of pipeline code you write against one ASIC family is a switching cost you pay later.
Then there is the surveillance consequence. A dataplane you can program at line rate is a dataplane that can classify, mirror and log at line rate, on boxes already sitting at every exchange and every carrier edge. The same capability that lets a regional ISP defend itself lets a national operator implement anything a lawful-intercept order asks for, as a software update, with no procurement and nothing to notice. Interception stops being a box someone has to install.
XDP is where the open version lives, and it is keeping up: the program runs on the NIC you bought from anyone, the verifier is in the kernel you can read and nobody has to approve your filter. Here at AxisOps that is the one we invest in. We would rather have a commodity server doing 10Gb of programmable forwarding we can inspect than a clever switch whose pipeline we are licensed to describe but not to understand.
Why it matters beyond networking¶
Because XDP is evidence that the eBPF model generalises. A verified program, loaded at runtime, running in a hot kernel path, fast enough for line rate.
If that works for packets, the obvious question is what else it works for. We expect the answer to be observability, security enforcement and eventually scheduling, which is why this counts as one of the five strands rather than a networking footnote.