P4 Language Support in DPL

This section outlines the P4-16 language features supported by the DOCA Pipeline Language (DPL) and notes any known deviations or limitations. All references are based on the P4 Language Specification version v1.2.5.

NVIDIA® BlueField® networking platforms (DPU or SuperNIC) are designed to accelerate data center workloads by offloading and isolating key infrastructure tasks, including networking, storage, and security. BlueField-3 combines ASIC performance with programmable flexibility, supporting up to 400G connectivity—ideal for AI and HPC environments.

To optimize for high-performance hardware, the P4 implementation on BlueField differs from generic software targets. As a result, DOCA Pipeline Language (DPL) selectively supports P4 features that align with its target architecture. This section details which P4 features are currently supported, restricted, or unsupported.

The DPL compiler implements a performance-oriented subset of P4-16, aligned with the capabilities of the BlueField hardware. Unsupported features are typically those that require runtime flexibility (e.g., dynamic parsing or general-purpose control logic) which are not efficient in ASIC-based systems. Developers should reference this section during development to ensure compatibility and portability of P4 programs targeting DPL.

Identifiers

• Identifiers starting with __ are reserved for internal compiler use

• All other identifiers conform to P4 spec §6.4.1

Data Types

Refer to section "Operators" for support of operations on values with these types.

Derived Types

Statements and Expressions

Operators

The P4-16 language specification lists a wide variety of operations that the language accepts for the supported data types (see Section 8). The table below lists the operators that are officially supported by the NVIDIA P4 compiler:

1. Cast to bit<32> for runtime comparison ⤶   ⤶   ⤶   ⤶

2. Disabled by default. Use the flag --enable runtime-value-comparison to enable this feature ⤶   ⤶   ⤶   ⤶   ⤶   ⤶   ⤶   ⤶   ⤶   ⤶   ⤶   ⤶

3. If neither LHS nor RHS are constants, then both must be exactly 32 bits wide ⤶   ⤶   ⤶   ⤶

4. RHS must be compile-time constant. See spec 8.9.2 ⤶   ⤶   ⤶   ⤶   ⤶   ⤶

5. H and L are subject to the restrictions described in the spec 8.6. ⤶   ⤶   ⤶

6. Width must be exactly 32 bits ⤶   ⤶   ⤶   ⤶   ⤶   ⤶   ⤶   ⤶

7. Only valid in P4 Table entries ⤶   ⤶

8. Limited to those fields that can be a copy source ⤶

9. Limited on a per extern function basis ⤶   ⤶

10. RHS must be compile-time constant. ⤶   ⤶   ⤶

11. RHS must be constant. ⤶   ⤶   ⤶

Variables

Variables are supported in accordance with the following spec items:

• Constants (spec 11.1)

  • "Compile-time known values" are evaluated on a best-effort basis. It is possible that a compile-time known value may not be recognized by the compiler as such.

• Variables (spec 11.2)

• Instantiations (spec 11.3)

  • Instantiations with abstract methods (spec 11.3.1) are allowed in BlueField Target Architecture

  • Named arguments are not supported

Variables may be declared in any of the locations described in (spec 11.2) and follow the scope rules described there.

The compiler will emit errors for uninitialized values. In some cases where a struct is partially initialized, only a warning may be produced. In some cases there may be no error emitted when an uninitialized struct field is accessed. The accessed field will then contain an undefined value.

Control Apply Block

The apply block within a control logic supports a specific subset of P4 statements to ensure deterministic execution and hardware compatibility.

Supported Statements

The following statements are supported within the control flow:

• table.apply() calls

• if / else statements

• switch statements

• Extern function and method calls

• Assignment statements (using supported operators)

• The empty statement (;)

• return statements

Loop Constructs

The for loop is supported, provided it adheres to strict structural restrictions. These constraints are necessary to ensure the compiler can statically verify loop termination (preventing infinite loops in the hardware pipeline).

Both break and continue statements are supported within the loop body.

Loop Constraints

To ensure validity, the loop must follow this specific decrementing pattern:

1. Init Clause: Must be a single assignment defining the loop variable.

2. Condition Clause: Must test that the loop variable is not equal to zero (!= 0).

3. Update Clause: Must be a single operation-assignment that decrements the variable by 1 (-= 1).

4. Body Constraint: The loop body must not modify the loop control variable.

Example Implementation

            

            
bit<32> sum = 1;
 
/* Valid Decrementing Loop */
for (
    bit<8> i = headers.ipv4.ttl;  // Init statement
    i != 0;                       // Condition
    i -= 1                        // Update statement
) {
    if (i == 64) {
        continue;
    } else if (i == 1) {
        break;
    } else {
        sum += 1;
    }
}
        

Hardware Constraints: Steering Hop Limits

The BlueField hardware enforces a global limit on the absolute number of steering hops in the pipeline. This acts as a safety mechanism to prevent infinite loops in the data path.

• Scope: This "TTL" (Time To Live) or hop limit is managed by the firmware. It is an accumulation over all steering domains (not just the DPL program).

• Validation: Because this is a runtime hardware state dependent on the total system configuration, it is out of the scope of DPL to validate at compile time.

• Behavior: Once the limit is exceeded, the packet is immediately dropped.

Troubleshooting Steering Violations

Violations of this limit can be detected by monitoring specific steering failure counters exposed to the kernel.

Relevant counters:

• generated_pkt_steering_fail

• handled_pkt_steering_fail

These can be inspected using the devlink health reporter. See the command devlink health diagnose in the Linux Kernel Documentation.

Table Apply

Calling the apply method on a table produces a result object that can return specific attributes about the table lookup outcome:

• bool hit

• bool miss

• enum action_run

Actions

Actions support the same statements as controls except for the following:

• table.apply() calls

• Conditional statements - if and switch

Actions support the same expressions as controls except for the following:

• Boolean logical operators - &&, ||, ternary operator

• Comparisons (==, !=, etc.)

The DPL compiler generates a p4info file compliant with the P4Runtime Specification (v1.4.1) for all supported DPL features.

Supported Annotations

The compiler supports the following package annotations as outlined in the P4Runtime PkgInfo Message. These allow for better documentation and versioning of the P4 program.

• @pkginfo with the following fields:

  • name

  • version

  • doc

  • arch

• @brief

• @description

Limitations and Unsupported Features

The following P4Runtime features are not supported in this target architecture:

Unsupported P4Info Objects

• ValueSet

• Register

• Digest

Unsupported P4 Entity Messages

The following runtime entities cannot be manipulated via P4Runtime on this target:

• Packet Replication:

  • PacketReplicationEngineEntry

  • MulticastGroupEntry

  • CloneSessionEntry

• State and Metadata:

  • ValueSetEntry

  • RegisterEntry

  • DigestEntry