By Jen Rexford and Nick McKeown
First things first: Welcome to P4.org, the official home of the P4 language, open-source P4 programs, developer tools, compilers and apps.
P4 is a declarative language for telling forwarding-plane devices (switches, NICs, firewalls, filters, etc) how to process packets. It's really cool and we think it's going to change how networking devices are designed forever. If you want to learn more about P4, read the original whitepaper  and the latest language spec .
Why P4? Today, designing a piece of high-performance networking equipment is really painful. First, you decide what features you need. Then you try to find a fixed-function switch chip with roughly the features you want. You sign a non-disclosure agreement to get access to a software-development kit (SDK), and start crawling up the learning curve. Using the closed, proprietary API, you try to force fit your system requirements into the fixed capabilities of the chip. This generally requires a few unnatural acts. And at the end of the day, you have a system with top-down aspirations, but really defined (and constrained in peculiar ways) from the bottom up. And you are locked in to that chip set, because your system and your expertise hinge on that SDK.
P4 aims to fundamentally change how we design network systems. With P4 you start from your system design requirements, write a P4 program to describe how your system needs packets to be processed, and then compile your program to tell the forwarding elements what to do. Essentially, P4 allows us to bring all the benefits we're familiar with from software engineering (composing programs, debugging, code coverage, provable behavior, model checking, etc.) to the design of network systems, all the way down to the wire.
You can write P4 programs to add custom packet processing or analytics as a value-add for your network; or you can use it to reduce the number of protocols your network has to support. You can quickly deploy new protocols and header formats in days, without having to wait years for a chip vendor to support a new feature. You can customize the dataplane to match the scale of your network. You can publish your P4 programs or keep them private, which means you retain ownership of your IP and no longer need to share new features with your chip vendor and all their customers, too. In short, you can get (and stay) ahead of the game.
Why now? In the past few years it has become clear that the "match + action" abstraction is very powerful for packet forwarding. Chips are being built this way, and we expect more in the future. These chips are protocol independent (their hardware specs don't mention any protocols, and they have programmable packet parsers), yet they have very high forwarding performance. Protocol independent NIC and switch chips need a language to specify their behavior -- a language that can compile to a wide range of target forwarding devices, both hardware and software. P4 is that language.
There are many interesting research problems to be worked on related to P4. How should P4 evolve? What is the best way to compose arbitrary P4 programs? How do we test equivalence of two P4 programs, pre and post compilation? How to prove correctness of P4 programs? How to generate P4 from higher level network policy? We strongly encourage the research community to contribute new and improved techniques, proofs, and software to this website. P4 is a great way for researchers to get involved in packet processing logic, without tying their work to a particular proprietary chipset, or climbing a steep learning curve with a complex SDK.
How does P4 relate to software-defined networking (SDN) and OpenFlow? P4 lets you tell the switch how to process packets and auto-generates an API connecting the control plane and the forwarding plane. So, a P4 program could configure a switch to look like an OpenFlow 1.0 switch, or an OpenFlow 1.4 switch, or something else entirely. And the control plane that populates the match-action rules at runtime could be centralized or distributed, running on a separate controller or directly on the switch. The main point of P4 is to free the network from low-level, proprietary interfaces to fixed-function chipsets, to enable protocol-independent packet processing across a range of target platforms.
Everything on this website is open-source and free, under a very permissive Apache license. Take a look around, download and play with some of the compilers and example P4 programs. If you like what you see, consider joining P4.org. It's free too. If you join, we'll let you know about future events, meetings, and workshops where you can meet other people interested in developing and using P4 in their systems. Come be part of the community.
At one level, P4 is just a simple language for declaring how packets are to be processed. At another level, P4 turns network system design on its head. With P4, we hope to advance networks from being software-defined to completely programmable, top-to bottom, soup-to-nuts.
 P4: Programming Protocol-Independent Packet Processors, ACM Sigcomm CCR, July 2014
 The P4 Language Specification, P4.org website.