Agent skill · NVIDIA
doca-dpdk-bridge
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).
What it needs
About 8k tokens when loaded.
What this skill does
DOCA DPDK Bridge 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 TASKS.md if the user wants to do something (configure / build / modify / run / test / debug); open CAPABILITIES.md when the question is what the bridge can express on this version. If the user has not installed DOCA yet, route to doca-setup 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 instead — the bridge exists for the interop case, not the start-fresh case. 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 rteeth 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.md ## Capabilities and modes the port-handover workflow in TASKS.md ## configure step 3. "How do I make a DPDK port visible to DOCA?" — worked example: "I have a DPDK port id from rteethdev; how does DOCA see it". Answered by the DPDK-port-id ↔ docadev mapping (docadpdkportprobe / docadpdkportasdev) in CAPABILITIES.md ## Capabilities and modes bridge-objects table + the binding workflow in TASKS.md ## configure step 4. "How do I move packets between DPDK mbufs and DOCA bufs?" — worked example: "DPDK delivers an rtembuf to my fastpath; I want a DOCA library to operate on the payload". …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills NVIDIA/doca-dpdk-bridge