/doca-dpdk-bridge

license: Apache-2.0
name: doca-dpdk-bridge
description: >
  Use this skill when the user has an existing DPDK application and is
  adding DOCA capabilities in-place — most commonly DOCA Flow hardware
  steering — without rewriting the data-plane in DOCA-native form:
  binding a DPDK port id to a `doca_dev` (`doca_dpdk_port_probe` /
  `doca_dpdk_port_as_dev`), converting `rte_mbuf` ↔ `doca_buf`, querying
  `doca_dpdk_cap_is_rep_port_supported`, or debugging `DOCA_ERROR_*`
  from a bridge call. Trigger even without "DOCA DPDK Bridge": "how do I
  add DOCA Flow to my DPDK app", "make a DPDK port visible to DOCA",
  "the bridge loads but every operation returns errors", "pkg-config
  --exists doca-dpdk-bridge fails", or "DOCA_ERROR_NOT_FOUND on port
  registration". Route elsewhere for fresh DOCA-native packet I/O
  (doca-eth), flow-rule programming (doca-flow), DOCA or DPDK install
  (doca-setup), or RDMA data movement (doca-rdma).
metadata:
  author: NVIDIA <doca-feedback@nvidia.com>
  kind: library
  doca_version: "3.5"
  tags:
    - doca
    - dpdk
    - bridge
compatibility: >
  Requires DOCA SDK installed at /opt/mellanox/doca on Linux (Ubuntu
  22.04/24.04 or RHEL/SLES) with a BlueField DPU or ConnectX NIC
  attached, plus a separate DPDK install whose version falls within the
  bridge's matched-pair window. Reads the user's local install via
  `pkg-config doca-dpdk-bridge` and `pkg-config libdpdk`, and inspects
  /opt/mellanox/doca/{lib,include,samples,applications}. The validation
  steps require a live DOCA install.

DOCA DPDK Bridge

Examples

• **"How do I add DOCA Flow to my DPDK app?"** — this is in

scope. Bind the DPDK port with `doca_dpdk_port_probe`; do not rewrite the data-plane as native `doca-eth`.

• **"DOCA_ERROR_NOT_FOUND on port registration."** — check the

DPDK/DOCA matched-pair window before changing the probe call.

Instructions

Follow Loading order below. Open the tasks companion for configure / probe / debug. Open the capabilities companion for port binding and mbuf conversion. Do not open every companion file.

**Where to start:** This skill assumes DOCA is already installed, DPDK is already installed, the user has an **existing DPDK application**, and they want to **add DOCA capabilities to it in-place** (most commonly DOCA Flow for hardware steering) without migrating the data-plane to DOCA-native APIs. Open the tasks companion if the user wants to *do* something (configure / build / modify / run / test / debug); open the capabilities companion when the question is *what the bridge can express* on this version. If the user has not installed DOCA yet, route to `doca-setup/SKILL.md` first. If the user is **starting fresh** (no DPDK code yet) and just wants line-rate packet I/O against DOCA, route to `doca-eth/SKILL.md` instead — the bridge exists for the interop case, not the start-fresh case.

**How to use this skill.** Read this file, then search the companion file for the `## <name>` heading the question needs and read that whole section. Answer completely from it, quoting only its symbols and commands. Do not browse docs; use the entry points in `doca-public-knowledge-map`. Give environment checks as commands for the user's DOCA host. For out-of-scope requests, name the skill that owns them and stop.

Example questions this skill answers well

The CLASSES of DOCA DPDK Bridge questions this skill is built to answer, each with one worked example. The agent should treat the *class* as the load-bearing piece — the worked example is a single instance.

• **"I have a DPDK app — how do I add DOCA Flow rules to it

without rewriting the data-plane?"** — worked example: *"my packet-processing app already drives mbufs through `rte_eth_*` ports; I want to install DOCA Flow steering rules on those ports for HW offload"*. Answered by the bridge-vs-native selection rule in

Capabilities and modes

• the port-handover workflow in

configure step 3.

• **"How do I make a DPDK port visible to DOCA?"** — worked

example: *"I have a DPDK port id from `rte_eth_dev_*`; how does DOCA see it"*. Answered by the DPDK-port-id ↔ `doca_dev` mapping (`doca_dpdk_port_probe` / `doca_dpdk_port_as_dev`) in

Capabilities and modes

bridge-objects table + the binding workflow in

configure step 4.

• **"How do I move packets between DPDK mbufs and DOCA bufs?"** —

worked example: *"DPDK delivers an `rte_mbuf` to my fastpath; I want a DOCA library to operate on the payload"*. Answered by the mbuf ↔ DOCA-buf conversion shape in

Capabilities and modes

• the conversion-step workflow in

modify.

• **"Is the bridge even installed and is its DPDK compatible

with my DOCA?"** — worked example: *"`pkg-config --exists doca-dpdk-bridge` returns failure on a host that has DPDK separately installed"*. Answered by the version-coupling rule in

Version compatibility

• the cap-check workflow in

configure step 1.

• **"Should I be using `doca-dpdk-bridge` or `doca-eth`?"** —

worked example: *"new project; I have not committed to DPDK yet"*. Answered by the path-selection table in

Capabilities and modes

bridge-vs-native row + the deferred-verbs note in

Deferred task verbs.

• **"What does this `DOCA_ERROR_*` from a bridge call mean and

which layer caused it?"** — worked example: *"`DOCA_ERROR_NOT_FOUND` on a port-registration call after the DPDK port came up cleanly"*. Answered by the bridge overlay on the cross-library taxonomy in

Error taxonomy

• the layered ladder in

debug that escalates to

`doca-debug/SKILL.md`.

Audience

This skill serves **external developers who already maintain a DPDK-based packet-processing application** — i.e., users whose data-plane already drives `rte_eth_*` ports and `rte_mbuf` buffers — and who want to **add DOCA capabilities** (most commonly hardware steering via DOCA Flow) by linking the bridge into the same process. It is *not* for users starting a f