DPL: P4 on BlueField
S4·E5 Our header is not in anybody's parser · NVIDIA briefing room, the Tuesday of acceptance week
Builds on: The DOCA Flow model, DOCA Ethernet and OVS-DOCA
Before you read: what do you already know?
Wrong answers are fine and expected; trying first makes the lesson stick.
After this lesson you can
- Describe what DPL is (a P4-16-derived language on a dRMT run-to-completion pipeline) and its Beta status in 3.5.0.
- Run the compiler workflow (dpl nvp4c, .dplconfig, p4info) and name the runtime pieces (dpl_rtd, P4Runtime 9559, Admin 9600, Nspect 9560).
- List the DPU prerequisites (firmware 32.47.1000+, FLEX_PARSER_PROFILE_ENABLE=4, PROG_PARSE_GRAPH=true, DPU mode) and recognize the dialect limits.
- Judge for a given customer requirement whether DPL, DOCA Flow or OVS-DOCA is the right programming surface and defend the choice.
Episode 5 — Our header is not in anybody's parser
Four engineers from the customer’s architecture team sit across the table and the tag from the cage is the whole agenda: between two encapsulations their platform inserts a four-byte transport header of its own design, and no standard parser knows it exists. They arrive with P4 programs written for a previous switch generation and a controller that already speaks P4Runtime. The NVIDIA PM answers the roadmap question with “not announced,” twice, in the same even tone.
None of the surfaces from the first four episodes can parse that header, and that is why DPL exists. It is derived from the P4-16 language specification, but its pipeline semantics align with NVIDIA’s DPU pipeline architecture rather than a standard P4 target: run-to-completion dRMT instead of P4’s feed-forward RMT.12 Instead of writing C against an API, a developer declares parsing, matching and processing, compiles it, and controls the deployed program through P4Runtime, an open gRPC-based control-plane interface.2 The compiled pipeline runs inside the same e-switch and brings its own programmable parse graph, match/action tables and actions.2 You say the uncomfortable part before the SE can: in 3.5.0 the DPL Service is Beta, while OVS-DOCA and DOCA Flow are GA.89 Procurement, on the phone, asks the only question that matters by Friday: how many cards, and by when.
DPL is not a faster OVS; it is the only surface that parses a header nobody has seen. The architect asks what a programmable parser actually buys him, so that is where you begin.
1What DPL is
DPL, the DOCA Pipeline Language, is derived from the P4-16 language specification, but its pipeline semantics align with NVIDIA’s DPU pipeline architecture rather than a standard P4 target: a run-to-completion dRMT (disaggregated RMT) model instead of P4’s feed-forward RMT.12 Instead of C against the DOCA Flow API, a developer declares packet parsing, matching and processing in P4 syntax, compiles it, and controls the deployed program at runtime through P4Runtime, an open, gRPC-based control-plane interface, with a shared-memory interface for high-performance cases.2 In the 3.5.0 services index the DPL Service is Beta; OVS-DOCA is GA and DOCA Flow is GA.89
The toolkit has three parts: a compiler that builds BlueField-optimized pipelines, a runtime service that manages hardware deployment and control-plane interaction, and developer tools for introspecting the pipeline.2 A compiled DPL pipeline executes inside the e-switch and consists of a programmable packet parser (parse graph), match/action tables, and packet actions such as forward, drop, modify, encrypt.2 The runtime pieces are: dpl_rtd, the DPL Runtime Daemon on the BlueField, which hosts the gRPC P4Runtime server, processes controller commands, loads compiled pipeline artifacts, interfaces with the DOCA HWS driver and manages parse graphs, match tables and state; the NV HWS Driver, low-level APIs for pipeline construction and table management; DPL Nspect, a host-side CLI for viewing table contents, debugging and tracing the packet path; the DPL Debugger, a graphical interface for visualizing packet flow; and DPL Admin, a CLI for configuration items.27 The ports are P4Runtime 95594, DPL Admin 9600 and DPL Nspect/Debugger 9560.5
One inconsistency to know before a customer finds it: the system page says the controller must conform to P4Runtime v1.3.0, while the runtime and language pages quote v1.4.1 and the compiling page asks for a controller based on API version 1.4.0 or greater.243 Quote the newer figure and note the discrepancy.
DPL does not replace the e-switch management you already know: the system page says developers are free to manage the eSwitch with OVS (DOCA OVS), DPDK-based apps or DOCA management interfaces, and DPL does not constrain how virtual interfaces or bridges are configured.2 The representor names and the MTU rule from lesson 4.1 come from this same page.2
Why does NVIDIA describe the target as dRMT rather than the RMT model P4 was designed for?
2Toolchain: nvp4c, .dplconfig, p4info
The compiler is nvp4c, shipped as an executable inside a self-contained Docker image (dpl-dev) that partners obtain from NGC; a wrapper script runs it: dpl nvp4c --target [doca|doca-bf3|doca-cx9] nvp4c_args* program.p4.3 The example is dpl nvp4c --target doca hello_packet.p4, which prints Generating compiler output in "_out" and produces three files: compiler.log (warnings and errors), hello_packet.dplconfig (the binary blob containing all the data the DPL Runtime daemon needs to load the program), and hello_packet.p4info.txt (the P4Runtime protobuf file in text format).3 The system page calls p4info the target-independent protobuf description used by controllers and .dplconfig the device config loaded into BlueField hardware.2
Useful flags from the page: --target target, --odir out_directory (default _out), -I path, -D arg=value, --Wdisable[=diagnostic], --Werror[=diagnostic], --metrics metric1[,metric2] (loc, cyclomatic, halstead, unused-code and others), -g (equivalent to --debug-mode=auto), --debug-mode extern|auto, --version.3 Debug mode requires the program to call nv_send_debug_pkt() at least once.23
Naming drift: the Services Guide still uses dplp4c for the compiler, and even the compiling page’s argument description says dplp4c_args while its command line says nvp4c; the binary in 3.5.0 is nvp4c.13 Say so when a customer’s notes disagree with the CLI. The dev-container landing page lists the documentation set: Target Architecture, P4 Language Support, Installation, Compiling, Loading, Samples, Inspecting/Debugging and Program Metrics.13
Why does the compiler emit two artifacts instead of one?
3Runtime on the DPU: prerequisites and layout
The runtime service requires DPU firmware 32.47.1000 or later (SuperNIC 82.47.0000 or later), Ubuntu 24.04 on the BlueField, DOCA 3.2.0 or later, and DPU mode.45 Firmware knobs are applied by sudo ./scripts/dpl_system_setup.sh, which sets FLEX_PARSER_PROFILE_ENABLE=4, PROG_PARSE_GRAPH=true and SRIOV_EN=1 with mlxconfig.45 Compare lesson 4.2: simple_fwd_vnf wants FLEX_PARSER_PROFILE_ENABLE=3, so the two cannot share one card’s firmware profile.12
Configuration lives in /etc/dpl_rt_service/: copy the per-device template, sudo cp /etc/dpl_rt_service/devices.d/NAME.conf.template /etc/dpl_rt_service/devices.d/1000.conf, and edit it for your device; the service is a container from NGC (nvidia/doca/dpl_rt_service) described by a per-release kubelet.d YAML that dpl_rt_service_ctl.sh consumes.5 The exact image tag and YAML body are not on the pages fetched for this lesson; take them from the release’s container page rather than from memory.5
Supported targets in 3.5.0: BlueField-3 B3220 P-Series (200GbE/NDR200), B3210 P-Series (100GbE/HDR100), and the ConnectX-9 C9240 400GbE SuperNIC; the system page itself only names BlueField-3.42 DPL supports two DOCA device kinds: a local device (PF, VF or SF exposed to the host or the BlueField) and a netdev representor (the BlueField-side proxy for a host device), which is why the naming table from lesson 4.1 appears on the DPL page.2
Why does DPL need FLEX_PARSER_PROFILE_ENABLE=4 and PROG_PARSE_GRAPH=true when DOCA Flow does not?
4The dialect: what P4 you can and cannot write
DPL accepts P4-16 syntax with NVIDIA-specific semantics and limits.6 On BlueField-3 the maximum amount of user metadata is 256 bits at any single point in the program; header_stack, union and signed int are unsupported; varbit fields are available only through NvOptionParser; and only the externs provided with the DPL compiler are allowed, no custom externs.6 Bounded loops are accepted, for example for (bit<8> i = headers.ipv4.ttl; i != 0; i -= 1) { ... }.6 The match kinds and intrinsic metadata names were not captured from the fetched pages, so check the language-support page before promising a specific match type.6
For orientation, the compiler’s --metrics option can report loc, cyclomatic complexity, halstead, unused code, duplicated code, nesting depth, header manipulation and match-action counts for a program, which is a practical way to size a customer’s P4 before committing to a port.3
Why no custom externs?
5DPL, DOCA Flow, or OVS-DOCA
The three surfaces program the same e-switch. OVS-DOCA (GA) keeps a standard OVS control plane and offloads a documented feature list: VXLAN, Geneve and GRE, connection tracking (IPv6 CT new in 3.5.0, ct-ct-nat unsupported), meters, mirrors, sFlow, LAG.10 DOCA Flow (GA) is a C API for your own pipe graph with seven pipe types, domains, aging, meters and CT, as in lessons 4.2 and 4.3.119 DPL (Beta) is a declarative program with its own parse graph and tables, controlled through P4Runtime on port 9559.84
Diagram source (Mermaid)
flowchart TD; Q1["Is the data plane expressible in OpenFlow: VLAN, VXLAN/Geneve/GRE, CT, meters?"] -->|yes| OVS["OVS-DOCA, GA, no code"]; Q1 -->|no| Q2["Do you need a custom parser or declarative P4 tables?"]; Q2 -->|no| FLOW["DOCA Flow C API, GA: pipes, domains, CT, aging"]; Q2 -->|yes| Q3["FW 32.47.1000+, profile 4 + PROG_PARSE_GRAPH acceptable, Beta OK?"]; Q3 -->|yes| DPL["DPL: nvp4c + dpl_rtd + P4Runtime 9559"]; Q3 -->|no| FLOW; OVS -->|CT with NAT needed| FLOW
Every step is worked for you. Read it once, then try the faded version.The same method with steps blanked out (____). Fill them in from memory.A fresh case with no steps shown. Solve it on your own.
Ask A. A hosting customer runs an OpenFlow SDN controller and wants VXLAN tenant networks with stateful firewalling offloaded on Dell hosts with BlueField-3. Decision: OVS-DOCA. Reasons: GA; the control plane is unchanged; VXLAN and CT are on the offload list; verify with ovs-appctl dpctl/offload-stats-show. Caveat to state: ct-ct-nat is not offloaded in 3.5.0, so NAT must happen elsewhere or accept software path.10
Ask B. A security vendor ships a C-based inline inspection engine on the Arm and wants line-rate pre-filtering (ACL, LPM) with suspicious flows redirected to their engine and idle flows aged out. Decision: DOCA Flow. Reasons: GA; the ACL, LPM and RSS pipes plus aging are exactly lesson 4.2 and 4.3; they own the code and can run vnf,hws on SFs. Caveat: per-core pipe queues and FLEX_PARSER_PROFILE_ENABLE=3 if they need the VNF sample’s tunnel parsing.1112
Ask C. A telecom lab has a proprietary transport header between two encapsulations and P4 programs from a previous switch generation; they want the DPU to parse it and steer on fields the standard parser does not know. Decision: DPL. Reasons: only DPL brings a programmable parse graph; the P4 team can reuse P4-16 skills; P4Runtime keeps their controller. Costs to state: Beta; firmware 32.47.1000 or later; FLEX_PARSER_PROFILE_ENABLE=4 and PROG_PARSE_GRAPH=true (card dedicated, no profile-3 workloads); dialect limits (256-bit metadata, no header stacks or unions, only shipped externs) may force changes to the old programs.246
- Ask A: OpenFlow controller plus VXLAN plus CT: choose ____; verify with
ovs-appctl ____; caveat: ____ is not offloaded in 3.5.0. - Ask B: C engine on the Arm plus ACL/LPM pre-filter plus aging: choose ____; pipe types ____, ____ and a ____ leaf; firmware knob if tunnels are parsed by simple_fwd_vnf:
FLEX_PARSER_PROFILE_ENABLE=____. - Ask C: proprietary header, P4 team: choose ____; compiler
dpl ____ --target doca prog.p4; runtime daemon ____; firmware minimum ____; mlxconfigFLEX_PARSER_PROFILE_ENABLE=____and____=true.
A customer runs OVS-DOCA today and asks for two additions: (1) NAT on tracked connections at the edge, and (2) matching on a 4-byte proprietary tag inserted after the Ethernet header by their own appliances. Recommend a surface for each addition and a migration order.
Acceptance: (a) for NAT you cite the 3.5.0 OVS-DOCA limitation by name and propose where NAT should run instead; (b) for the tag you rule out OVS-DOCA and DOCA Flow by reference to parser programmability and pick DPL, listing firmware, mlxconfig and Beta caveats; (c) you explain why the two workloads cannot share one card’s firmware profile with a profile-3 sample, and whether they can share a card with OVS-DOCA (DPL does not constrain e-switch management by OVS); (d) you name the three ports the customer’s firewall team must open for the DPL runtime.
Why not present DPL as the default for every advanced customer, since it is the most flexible?
Case closed — the Friday sign-off
They leave with three commitments and three costs. dpl nvp4c compiles their program into a .dplconfig for the runtime and a p4info file their controller already understands.3 The runtime wants firmware 32.47.1000 or later, FLEX_PARSER_PROFILE_ENABLE=4 and PROG_PARSE_GRAPH=true, so that card is dedicated — procurement was right to ask, and one more card goes on the order.4 Their firewall team opens 9559, 9600 and 9560.45 Friday signs: tenant fabric on OVS-DOCA, security path on DOCA Flow, the tag on one Beta card the operator has already labelled PARSER — DO NOT PING, DO NOT REFLASH. The notebook closes. The SE’s spreadsheet, for once, is shorter than it was on day two.
Lab
Changes the system0 of 5 steps doneMutating steps ahead. Needs a maintenance window, out-of-band access (BMC/iDRAC/rshim console) and a rollback path. Record the pre-flight inventory before changing anything. Never on a production host.
Pre-flight (read-only) on the Arm: sudo mst start && sudo mst status -v; sudo mlxconfig -d /dev/mst/<dev> q FLEX_PARSER_PROFILE_ENABLE PROG_PARSE_GRAPH SRIOV_EN; firmware version with the MFT query you used in lesson m2-02; lsb_release -a for Ubuntu 24.04; ls /etc/dpl_rt_service/ 2>/dev/null. Record every value: they are the rollback targets.
-
Gate: if the firmware is below
32.47.1000or the OS is not Ubuntu 24.04, stop; DPL is not supported on this unit.45 IfFLEX_PARSER_PROFILE_ENABLEis 3, this card is hosting asimple_fwd_vnf-style workload; do not continue without the owner’s agreement. -
Mutating, firmware: run the runtime package’s
sudo ./scripts/dpl_system_setup.sh, or equivalentlysudo mlxconfig -d /dev/mst/<dev> s FLEX_PARSER_PROFILE_ENABLE=4 PROG_PARSE_GRAPH=true SRIOV_EN=1, then reset the card.Expected:
mlxconfig qshows the three values.4 Rollback:mlxconfig … s FLEX_PARSER_PROFILE_ENABLE=<recorded> PROG_PARSE_GRAPH=<recorded> SRIOV_EN=<recorded>and reset. -
Mutating, config:
sudo cp /etc/dpl_rt_service/devices.d/NAME.conf.template /etc/dpl_rt_service/devices.d/1000.confand edit it for your device.5 Rollback: delete1000.conf. -
Mutating, service: start the runtime container per the release’s
kubelet.dYAML viadpl_rt_service_ctl.sh(take the image tag from the release’s container page, not from this lesson).5Expected:
dpl_rtdlistening on 9559, 9600 and 9560 (ss -ltn | grep -E '9559|9600|9560').5 Rollback: stop the container with the same control script. -
Load and test only with a compiled
.dplconfigfrom yourdpl-devcontainer, then confirm the eSwitch is still manageable by OVS as the system page states (ovs-vsctl showunchanged).2 Rollback in reverse: stop the service, remove1000.conf, restore firmware values, reset.
-
Without the
dpl-devimage (partner NGC access), reconstruct the compile step on paper: forhello_packet.p4, write the command and the expected_out/tree.Expected:
dpl nvp4c --target doca hello_packet.p4, then_out/compiler.log,_out/hello_packet.dplconfig,_out/hello_packet.p4info.txt.3 If you have the container: run it and diff against your answer. -
Write the firewall request for the DPL runtime on one DPU.
Expected: TCP 9559 (P4Runtime, from the controller), 9600 (DPL Admin) and 9560 (Nspect/Debugger) from the operator hosts.5 If you listed only 9559: that is the one port the runtime-service page names; the other two come from the container-deployment page, whose own
firewall-cmd --add-portexample opens all three.45 -
In the MermaidFlow component, walk the three Worked asks and one more: “OpenFlow controller, VXLAN, and CT with NAT at the edge”.
Expected: the chart routes NAT-with-CT away from OVS-DOCA toward DOCA Flow, because
ct-ct-natis unsupported in 3.5.0.10 If your chart still ends at OVS-DOCA, you matched on “VXLAN and CT” alone: both are offloaded, and it is only their combination with NAT that the page lists as unsupported.10 -
Read the dialect limits and mark which of these P4 fragments would fail: a
header_stackof MPLS labels; aunionof two option headers;bit<300>of user metadata; a boundedforloop over TTL.Expected: the first three fail (unsupported or over 256 bits), the loop is accepted.6 If you also failed the loop, you applied a P4 core-language restriction rather than a DPL one: the page lists
header_stack,union, signedintand the 256-bit metadata ceiling, and says nothing that rules out a bounded loop.6 -
Write two sentences a customer would read in a proposal explaining the
dplp4cversusnvp4cnaming, citing the compiling page.31Expected:
nvp4cis the 3.5.0 name and the one to put in a runbook;dplp4cis the older name that still appears in the Services Guide text.31 If you wrote that one of them is wrong: both strings are in the 3.5.0 docs, so present it as a naming carry-over, not a documentation defect.1
Retrieval check
Answer from memory before looking anything up; misses become flashcards.
Explain it to a Dell SE
Explain to a Dell SE, in five sentences, when a customer should write a DPL program instead of using OVS-DOCA or DOCA Flow.
Sources
13 sourcesFacts in this lesson were checked against DOCA 3.5.0 DPL docs, 2026-09-06. Dates are when each page was fetched. Sources fetched 2026-09-06, checked 16 days ago.
- DOCA Pipeline Language Services Guide
- DPL System
- Compiling DPL Applications
- DPL Runtime Service
- DPL Container Deployment
- P4 Language Support in DPL
- DOCA Pipeline Language Developer Tools
- DOCA Services (index with quality levels)
- DOCA Libraries (index with quality levels)
- OVS-DOCA Hardware Acceleration
- DOCA Flow (programming guide)
- DOCA Simple Forward VNF Application Guide
- DPL Development Container (landing)
The same idea elsewhere
Other lessons that cover this ground, sometimes from another course's angle.