PaperlayerView exact revision on arXiv

Source-linked AI summary

A Survey on Data Plane Programming with P4: Fundamentals, Advances, and Applied Research

Frederik Hauser, Marco Häberle, Daniel Merling, Steffen Lindner, Vladimir Gurevich, Florian Zeiger, Reinhard Frank, Michael Menth

arXiv:2101.10632v3cs.NI

TL;DR

Traditional networking devices restrict users from changing vendor-defined data-plane algorithms, motivating programmable data planes and P4. This survey explains P4 technology and analyzes 245 applied-research papers, finding broad academic uptake while identifying portability and target limitations.

  • Problem

    Traditional networking devices let users configure control-plane features but restrict changes to underlying data-plane algorithms, limiting user-defined forwarding behavior.

  • Method

    The survey provides a tutorial on P4 technology and categorizes 245 applied-research papers by domains, prototypes, targets, source-code availability, and P4 core features.

  • Results

    The survey finds tremendous uptake of P4 for academic prototyping from 2018 to 2021 and identifies P4 core features used across research domains.

  • Takeaways & Limitations

    P4 supports custom headers, flexible header processing, and target-specific functions across applications including traffic management, routing, and network prototypes.

  • Takeaways & Limitations

    Modern data plane programming languages have not yet achieved the portability of general-purpose programming languages, and bmv2 cannot provide high throughput for productive deployment.

Abstract

from arXiv · show

Programmable data planes allow users to define their own data plane algorithms for network devices including appropriate data plane application programming interfaces (APIs) which may be leveraged by user-defined software-defined networking (SDN) control. This offers great flexibility for network customization, be it for specialized, commercial appliances, e.g., in 5G or data center networks, or for rapid prototyping in industrial and academic research. Programming protocol-independent packet processors (P4) has emerged as the currently most widespread abstraction, programming language, and concept for data plane programming. It is developed and standardized by an open community, and it is supported by various software and hardware platforms. In the first part of this paper we give a tutorial of data plane programming models, the P4 programming language, architectures, compilers, targets, and data plane APIs. We also consider research efforts to advance P4 technology. In the second part, we categorize a large body of literature of P4-based applied research into different research domains, summarize the contributions of these papers, and extract prototypes, target platforms, and source code availability. For each research domain, we analyze how the reviewed works benefit from P4's core features. Finally, we discuss potential next steps based on our findings.

1. Introduction

The survey motivates programmable data planes as a way to let users define forwarding behavior, then presents P4 as the leading abstraction and surveys its technology and applications. It combines a tutorial on P4 with a categorized review of 245 applied-research papers.

  • 1. Introduction: Programmable data planes let users define packet headers, forwarding behavior, and data plane APIs instead of relying solely on vendor-defined algorithms.SDN makes control-plane algorithms programmable, while data plane programming extends programmability to forwarding devices.
  • 1. Introduction: P4 is currently the most widespread data plane programming abstraction, language, and concept, with support from an open community and software- and hardware-based targets.The paper describes P4 as widely applied in both academia and industry.
  • Contributions: The first part explains P4 programming, architectures, compilers, targets, APIs, and research advances, while relating P4 to SDN and other programming models.The overview covers both foundational material and efforts to advance P4 technology.
  • Contributions: The second part categorizes 245 P4-based research papers by application domain and characterizes their prototypes, target platforms, source-code availability, and use of P4 core features.The review includes publications through the end of 2020 and selected papers from 2021.
  • Novelty: Earlier surveys either mentioned P4 briefly or treated it as one language among several, whereas this survey reviews P4 technology and applied research more comprehensively.The paper specifically contrasts its coverage with a survey of 33 works and a technical report covering 150 papers.

P4 Architectures & Compilers

The supplied material identifies terminology associated with P4 architectures, targets, and networking systems, and indicates that Figure 1 depicts the paper’s organization.

  • Organization: Figure 1 is described as depicting the organization of the paper.The supplied caption provides no further encoding or comparison.
  • Compilers and programming: The glossary includes compiler- and programming-related terms such as HDL, HLIR, SDK, DSL, and eBPF.The passages provide acronym expansions but no compiler workflow or comparison among these technologies.
  • Terminology: PISA is identified as the Protocol Independent Switching Architecture.The acronym list expands PISA but does not describe its architecture.
  • Terminology: PSA is identified as the Portable Switch Architecture, while TNA is identified as the Tofino Native Architecture.These entries name two architecture-related terms in the paper’s terminology.

2. Network Programmability

Network programmability is the ability to define processing algorithms in network nodes, extending beyond configurable parameters to user-defined control and data planes. The section traces the progression from traditional vendor-controlled devices through SDN to programmable data planes, emphasizing increased flexibility and rapid customization alongside portability limits.

  • Definition of Terms: Network programmability means executing externally defined processing algorithms, unlike mere flexibility that changes only parameters of internally defined algorithms.
  • Control Plane Programmability and SDN: Traditional routers and switches embed complex data and control plane algorithms that users generally cannot replace.
  • Control Plane Programmability and SDN: SDN lets users replace built-in control-plane algorithms through remote APIs, while the underlying data plane remains non-replaceable.
  • Control Plane Programmability and SDN: OpenFlow standardized a messaging API for controlling data-plane functionality, but assumed an incompletely specified and unchangeable data plane.
  • Data Plane Programming: Data plane programming lets users define forwarding algorithms and custom network equipment, while P4 is the most widely used language for PISA.
  • Benefits: Programmable data planes enable algorithms to be deployed in days rather than the long development cycles of new silicon, but portability remains below general-purpose languages.

3. The P4 Programming Language

P416 refines P4 into an architecture-agnostic, statically typed language whose programs are parsed, processed through match-action pipelines, and deparsed for target execution.

  • 3.1. Specification History: P416 addresses P414 limitations including weak typing, loose semantics, low-level constructs, and weak support for program modularity.
  • 3.1. Specification History: P416 separates core language features from architecture descriptions and vendor-provided architecture libraries to support multiple targets and pipeline architectures.
  • 3.2. Development and Deployment Process: P4 deployment combines user programs with target-specific fixed-function components, while manufacturer compilers translate them into executable target code and generate data plane APIs.
  • 3.3. Processing Pipeline: The P4 pipeline uses metadata to connect blocks: parsers extract headers, match-action units modify headers and metadata, and deparsers reassemble packets with their payloads.
  • 3.4. Data Types and Parsers: P416 provides basic and variable-width types, compositional header, header-stack, and struct types, and FSM-based parsers for user-defined packet formats.

4. P4 Architectures & Compilers

P4 architectures abstract target capabilities between the core language and hardware or software targets, while compilers translate architecture-specific programs through common and target-specific stages.

  • 4.1. P416 Architectures: A P416 architecture represents a target’s capabilities and logical pipeline view, allowing programs to run on all targets implementing that architecture.
  • 4.2. Externs: P4 externs expose target-specific functions such as checksums, hashes, counters, meters, registers, and random number generation.
  • 4.2. Externs: Externs, tables, and value sets can preserve state between packets, with access by the control plane, data plane, or both depending on vendor-specific API definitions.
  • 4.3. Common P416 Architectures: The common architectures include v1model, PSA, SimpleSumeArchitecture, and the proprietary Tofino Native Architecture.
  • 4.4. P4 Compilers: Most P4 compilers use a two-layer model with a common frontend producing an intermediate representation and a target-specific backend performing target-specific transformations.
  • 4.4. P4 Compilers: The p4c compiler supports P414 and P416 code across architectures and provides reference backends including bmv2, eBPF, and uBPF.

5. P4 Targets

P4 targets span software, FPGA, ASIC, and NPU platforms, with different compilation workflows and runtime capabilities. The surveyed implementations range from CPU-based switches to high-throughput FPGA parsers and specialized hardware.

  • Target categories: P4 targets are categorized into software, FPGA, ASIC, and NPU platforms with differing supported architectures and development states.The survey compiles target platforms, supported architectures, and current development status.
  • Software-based targets: Software targets execute P4 forwarding programs on standard CPUs, including p4c-based switches, BPF-derived targets, DPDK/ODP systems, OVS, and VPP integrations.Their compilation strategies differ: some generate program-specific code, while others load representations or plugins at runtime.
  • Software-based targets: bmv2 separates its static target implementation from P4 programs compiled into JSON, supports multiple target variants, and provides runtime APIs such as Thrift or P4Runtime.Reported bmv2 throughput reaches up to 1 Gbit/s for an IPv4 LPM routing program, although bmv2 is intended for testing.
  • Software-based targets: T4P4S separates hardware-independent and hardware-dependent functionality by compiling P4 into target-independent C interfacing with accelerated packet-processing libraries.Reported optimizations improve T4P4S performance by up to 15%, and its source code is available on GitHub.
  • FPGA targets: FPGA tool chains compile P4 through synthesis, verification, validation, and placement/routing, producing firmware for platforms such as NetFPGA and vendor-supported boards.Some workflows permit custom HDL externs, while commercial services can hide HDL development from users.
  • FPGA research results: Optimized P4-derived FPGA parsers achieve 100 Gbit/s on Virtex-7, 1 Tbit/s on UltraScale+, and 800 Gbit/s on Virtex-7 follow-up implementations.The 100 Gbit/s parser uses 2.78% slice LUTs and 0.76% slice registers.

6. P4 Data Plane APIs

P4 data plane APIs expose runtime control of programmable entities and packet I/O, and can be classified by abstraction, program dependence, and controller location. The survey focuses on P4Runtime, BRI, and BM Runtime as common program-independent APIs.

  • API role: Data plane APIs let control planes manage P4 targets through runtime control of MATs and extern objects, packet I/O, and program loading.The API is provided by a device driver or equivalent software component.
  • API characterization: P4 data plane APIs are characterized by abstraction level, dependence on the P4 program, and control-plane location.These dimensions distinguish hardware access from P4-object access, program-specific from generic interfaces, and local from remote control.
  • Abstraction level: Device-access APIs provide low-overhead hardware access but are neither vendor- nor device-independent, whereas data-plane-specific APIs can expose P4 objects independently of hardware details.The latter may provide vendor and device independence.
  • Program dependence: Program-dependent APIs require recompilation or control-plane modification when P4-derived names or structures change, while program-independent APIs retain fixed interfaces.Program-independent APIs operate on P4 objects whose names the control plane knows.
  • Controller location: Local APIs execute on the target’s CPU, whereas remote APIs use RPC mechanisms such as Thrift or gRPC for separate-system control and centralized SDN operation.Remote control increases system stability and modularity and supports asynchronous communication and concurrent calls.
  • Common APIs: P4Runtime, BRI, and BM Runtime are all data-plane-specific and program-independent, but use different local or remote control mechanisms.P4Runtime and BF Runtime use gRPC, BfRt provides local bindings, and BM Runtime uses Thrift.

7. Advances in P4 Data Plane Programming

Research advances address P4 development and deployment, analysis and testing, target virtualization and composition, and control-plane-related capabilities. The surveyed work introduces tools for abstraction, verification, runtime adaptation, multi-program execution, and heterogeneous targets.

  • Scope: The survey organizes advances around development and deployment optimization, testing and debugging, P4 targets, and control-plane operation.Figure 24 structures the research overview accordingly.
  • Development and deployment: Development research includes higher-level code generation, modularity, incremental deployment, type safety, intent-based programming, and rapid data-plane reactions.Examples include Graph-to-P4, DaPIPE, SafeP4, P4I/O, Mantis, and Lyra.
  • Testing and debugging: Verification and testing work spans simulation, formal and symbolic analysis, runtime checks, test-packet generation, fault detection, debugging, and compiler-bug discovery.Tools such as PFPSim, netdiff, P4pktgen, P4Tester, and Gauntlet target different stages of the P4 toolchain.
  • P4 target research: Virtualization research enables multiple network functions or tenants to share P4 resources through hypervisors, compiler transformations, hardware reconfiguration, or privileged pipelines.HyPer4 supports slicing and snapshotting but reports 80 to 90% lower performance than native execution; HyperV reports a 2.5x performance advantage over HyPer4 and fourfold lower resource requirements.
  • Composite targets: Composite targets combine software, FPGA, and ASIC processing to address target-dependent feature support, while XLT extends match tables to gigabyte scale using FPGA and DRAM.The composite data plane appears as one P4 target despite heterogeneous underlying processing.

8. Applied Research Domains: Classification & Overview

The survey classifies P4 applied research into hierarchical domains and relates each domain to P4 features, prototypes, target platforms, and source-code availability. Its review covers 245 applied-research papers through 2020 plus selected 2021 papers.

  • Classification method: The survey defines P4 core features to evaluate why P4 is useful for implementing data-plane algorithms across applied research domains.The features support reasoning about the surveyed prototypes’ implementation choices.
  • Core features: P4’s programmable headers support standard, use-case-specific, and new protocols, including protocol extensions and in-band signaling.This flexibility makes custom packet formats available to end users.
  • Core features: Control blocks, match-action tables, metadata, and user-defined actions provide flexible, parameterized packet-processing logic managed through data plane APIs.The combination supports header processing and runtime table-entry management.
  • Core features: P4 externs add target-specific functions such as stateful processing, recirculation, multicast, hashing, and cryptography, but their availability can make implementations platform-dependent.High-throughput Tofino targets provide only a fixed set of externs, while software targets can integrate custom externs.
  • Core features: P4 programs can be changed on installed targets, supporting agile development, frequent deployments, and incremental functionality extensions.New program versions can be deployed as functionality evolves.
  • Survey organization: The classification uses a two-level hierarchy organized by application fields, with domain tables listing publication year, target platforms, and source-code availability.This structure is intended to support browsing and section-specific conclusions.
  • Survey scope: The review includes 245 applied-research papers: 68 published by 2018, 80 in 2019, 93 in 2020, and 4 in 2021; 60 released source code.The corpus is drawn from 377 surveyed scientific publications and includes journal, conference, workshop, and preprint papers.

9. Applied Research Domains: Monitoring

The survey covers P4-based monitoring research spanning heavy-hitter detection, flow monitoring, sketches, and in-band network telemetry. These works use programmable switches and controller interaction to analyze traffic at different granularities.

  • P4 monitoring research includes heavy-hitter detection, flow monitoring, sketches, in-band network telemetry, and other application areas.
  • Heavy-hitter detection: Heavy-hitter systems use hash tables, TCAM prefix refinement, counters, or fully data-plane algorithms to identify large or changing traffic flows.
  • In-band telemetry: P4 monitoring research includes INT implementations and platforms such as bmv2, Tofino, Netronome, and NetFPGA-SUME.

2018 bmv2,

The section surveys additional monitoring applications, including traffic classification, performance diagnosis, queue occupancy, and telemetry. Representative systems divide processing between programmable data planes and software components.

  • Flow monitoring: TurboFlow generates micro-flow records in the data plane and aggregates them into full flow records on the switch CPU.
  • Flow monitoring: “∗Flow” computes grouped packet vectors in a switching ASIC while software performs aggregation for dynamic and concurrent measurements.
  • Flow monitoring: FlowStalker performs proactive per-flow counting and reactive metric collection for large flows, with a controller gathering cluster-wide information.
  • Performance monitoring: SpiderMon detects flows whose accumulated latency exceeds a threshold and traces interfering-flow paths to analyze performance degradation.
  • In-band telemetry: IntOpt computes minimal monitoring flows covering telemetry demands and periodically inserts probes into the network.
  • Other applications: TCP-friendly P4 meters achieve rates of up to 85% of the target rate, compared with about 10% for meters in commercial switches.

10. Applied Research Domains: Traffic Management and Congestion Control

Traffic-management research applies P4 to data-center switching, load balancing, congestion control, queue management, scheduling, and offloading. The surveyed systems exploit flexible header processing and target-specific functions, while hardware support constrains portability.

  • P4 traffic-management research covers switching, load balancing, congestion notification, scheduling, aggregation, AQM, and traffic offloading.
  • Data-center switching: Data-center switching projects implement features including VLAN, VXLAN, ECMP, IP forwarding, ACLs, mirroring, MAC learning, and control-plane messaging.
  • Load balancing: Load-balancing systems use probes, flowlets, utilization-aware weights, custom headers, registers, or hash-space partitioning to adapt forwarding.
  • Traffic offloading: Falcon reduces scheduling overhead by a factor of 26 and increases scheduling throughput by a factor of 25 compared to state-of-the-art schedulers.
  • Summary and analysis: The domain benefits from custom headers, flexible header processing, and target-specific functions, but externs, priority queues, and floating-point operations may limit portability.

11. Applied Research Domains: Routing and Forwarding

Routing and forwarding research uses P4 for source routing, multicast, publish/subscribe, named data networking, resilience, and latency-critical RPCs. Custom headers and flexible processing support specialized forwarding behavior, while target-specific state can constrain implementations.

  • Source routing: Source-routing systems encode forwarding operations in packet header stacks that network devices process hop by hop.
  • Multicast: Multicast systems use packet-carried destination information or policy-aware forwarding to improve scalability and adapt delivery.
  • Publish/subscribe: Publish/subscribe implementations encode distribution trees or subscription attributes in headers, with some separating static P4 pipelines from dynamic filters.
  • Named data networking: NDN.p4 initially lacks caching because of P4 stateful-storage limitations, while later work adds caching through P4 externs.
  • Data-plane resilience: P4-Protect duplicates packets over disjoint paths and achieves line-rate processing at 100 Gbit/s on Tofino.
  • Other applications: R2P2 uses a P4 or DPDK router module to relay and load-balance latency-critical RPC requests in datacenters and distributed infrastructure.
  • Summary and analysis: Routing and forwarding benefit from custom headers and flexible processing, while most projects were developed for bmv2 and may transfer when target-specific actions are unnecessary.

12. Applied Research Domains: Advanced Networking

Applied research uses P4 to move cellular, IoT, industrial, time-sensitive, and network-function processing into programmable data planes. The surveyed systems demonstrate performance-oriented offloading, protocol translation, sensing and control, synchronization, and NFV deployment across software and hardware targets.

  • 12.1. Cellular Networks (4G/5G): P4-based mobile-core systems offload packet processing and control-plane state to programmable switches for higher throughput, lower latency, and scalable line-rate operation.The Evolved Packet Gateway reaches line rate with low latency and jitter while scaling to 1.7 million active users; TurboEPC stores state in match-action tables and processes signaling messages in the data plane.
  • 12.2. Internet of Things (IoT): BLESS and Muppet use P4 switches as policy-based IoT service proxies, with Muppet additionally enabling inter-protocol services among Zigbee, BLE, and IP.Muppet can automatically send HTTP transactions when specified BLE/Zigbee transaction sequences are observed.
  • 12.2. Internet of Things (IoT): P4 implementations aggregate small IoT packets and provide network-level IoT data aggregation to reduce header overhead, traffic, or destination computation.IoTP stores flow packets in registers until aggregation is possible.
  • 12.3. Industrial Networking: Industrial-networking prototypes place sensing, emergency control, coordinate transformation, linear-quadratic regulation, or time synchronization on P4-capable devices.The surveyed results include direct data-plane stop commands, LQR control commands, and a request-response protocol for global time synchronization.
  • 12.5. Network Function Virtualization (NFV): NFV frameworks use P4 across software switches, hardware switches, SmartNICs, and containers to deploy, decompose, steer, optimize, or rapidly prototype network functions.Approaches include runtime reconfiguration, controller-visible unified abstractions, MILP-based table partitioning, and traffic steering between embedded and virtual functions.

13. Applied Research Domains: Network Security

P4-based security research covers firewalls, port knocking, DDoS mitigation, and related mechanisms by combining programmable parsing, state, counters, custom headers, and data-plane APIs. The surveyed prototypes apply these mechanisms to cellular, enterprise, application-layer, and transport-security settings.

  • 13.1. Firewalls: P4 firewalls parse protocol-specific headers, install allow or drop policies through data-plane interfaces, and track traffic statistics with counters and match-action tables.Examples include GTP-aware 5G firewalls and firewalls supporting Ethernet, IPv4/IPv6, UDP, TCP, ban lists, and whitelist filtering.
  • 13.2. Port Knocking: P4Knocking and ticket-based designs implement port-knocking authentication on switches using stateful registers, hashing, HIT/MISS processing, and control-plane-maintained policies.The designs address knock-sequence tracking and forwarding authorization directly in the switch.
  • 13.3. DDoS Attack Mitigation: DDoS-mitigation systems use P4 state, sketches, custom signaling headers, digests, access-control lists, and rate limits to detect or suppress attacks near the network edge.Covered mechanisms target amplified reflection, SIP, TCP SYN flood, DNS spoofing, and application-layer attacks, with some control-plane or machine-learning assistance.
  • 13.7. Summary: Across the surveyed security prototypes, flexible packet-header processing is central, while many systems also depend on target-specific header-processing functions.Custom headers support GTP firewalls, SIP DDoS mitigation, Modbus intrusion detection, and cooperative in-band signaling.

14. Miscellaneous Applied Research Domains

Miscellaneous P4 research applies programmable data planes to network coding, event processing, consensus, state migration, memory extension, DNS, and in-network inference. These systems demonstrate broad functionality but also expose portability, state-processing, and implementation-detail constraints.

  • 14.1. Network Coding: Network-coding prototypes implement packet splitting, encoding, decoding, and complex Galois-field operations using P4 externs, clone or recirculate operations, and packet storage.The reviewed implementations target software switches, and the surveyed work reports limited consideration of hardware targets.
  • 14.2. Event Processing: P4CEP and DAIET move event processing and aggregation into the network, processing sensor streams on switches and reducing traffic or destination computational load.P4CEP requires workarounds for limitations in stateful packet processing, while DAIET provides only a few implementation details.
  • 14.2.2. In-Network Consensus: Consensus and distributed-state systems offload Raft components, response comparison, consistency mechanisms, time synchronization, and state synchronization to P4 switches.P4BFT compares controller responses, SwiShmem operates consistency mechanisms at line rate, and SC-BFT accelerates consensus by processing information at line rate.
  • 14.3. State Migration: P4Sync migrates register state between switches without controller interaction and authenticates transferred state with packet generation and a hash chain.Each packet contains hashes of the current payload and the previous packet payload.
  • 14.4. Application Support: Other prototypes extend P4 beyond switching by combining on-switch and server memory, enabling runtime OVS programming, hybrid DNS processing, computer-vision filters, or neural computation.These designs use RDMA, P4-to-BPF compilation, control-plane cache management, P4 NIC match-action tables, or dedicated neural compute sticks.
  • 14.5. Summary: Miscellaneous prototypes rely heavily on target-specific functions and externs, with many developed for bmv2 and only limited portability to hardware platforms.Traditional protocols and network elements additionally use custom headers, flexible parsing, and control-plane processing for corner cases.

15. Discussion & Outlook

The survey finds that P4 supports broad customization and rapid prototyping, but target constraints, extern dependencies, and limited hardware portability shape its practical use. bmv2 dominates functional prototyping, while Tofino provides high-throughput deployment potential.

  • P4 Targets: bmv2 supports most surveyed prototypes because it is freely available, unconstrained by hardware restrictions, and extensible through custom externs.Its software-only design supports functional experimentation but not high-throughput production deployment.
  • P4 Targets: Tofino is the predominant hardware platform because it combines native P4 support with throughput above 12.8 Tbit/s and ports up to 400 Gbit/s.The survey identifies Tofino-based devices as suitable for production environments such as data centers and core networks.
  • P4 Targets: FPGA- and NPU-based targets offer extensible externs but generally have fewer ports and lower throughput, limiting them mainly to special-purpose server applications.P4 benefits on these platforms depend on the use case, programmer expertise, and whether target independence is desired.
  • Target Independence and Portability: P4 program portability is limited when prototypes depend on complex algorithms, fixed-function blocks, or custom externs unavailable on other platforms.Even platforms with similar externs may require significant code adaptation.
  • Target Independence and Portability: Some surveyed applications use P4 for complex packet processing even though it was primarily conceived for packet-header processing with simple high-speed operations.This mismatch can mean that such applications depart from P4’s original objectives.
  • Disaggregation: Disaggregated white-box hardware can be reused for multiple purposes through P4 programs, potentially increasing development agility and reducing time to market.The survey identifies disaggregation as a possible major driver for P4 adoption.
  • P4 Evolution: Extern functions expand P4’s use cases with encryption, floating-point operations, flexible hashing, and more complex calculations, but reduce portability.The survey presents this trade-off as a continuing issue for programmable targets.

16. Conclusion

The paper combines a tutorial on P4 technology with a systematic survey of applied research. Its review of 245 papers shows rapid academic uptake, widespread bmv2 prototyping, and frequent reliance on Tofino for hardware evaluation, while portability remains constrained.

  • Tutorial and technology overview: The first part provides a tutorial on data-plane programming with P4, covering models, PISA, languages, architectures, compilers, targets, APIs, and research advances.It also distinguishes P4-based data-plane programmability from SDN.
  • Applied-research survey: The second part analyzes 245 P4-based applied-research papers by domain, contributions, prototypes, target platforms, source-code availability, and use of P4 core features.The survey uses these categories to compare how P4 supports different prototype implementations.
  • Survey findings: P4 experienced tremendous uptake for academic prototyping from 2018 to 2021, supported by openly available learning resources and the bmv2 software target.The paper describes these resources as an accessible starting point, including for beginners.
  • Survey findings: Most hardware-based prototypes use Tofino, while most P4-based prototypes use bmv2 and many remain unported because of algorithmic complexity and missing extern functions.The paper expects this pattern may change as additional P4 hardware targets become available.
  • Outlook: The survey expects P4 to become a base technology for multiple hardware appliances, particularly in disaggregation and small-scale markets.This outlook follows the observed growth of P4-based activity and the reuse potential of programmable hardware.
Loading 2101.10632v3…