DOCA DPDK Bridge
Add DOCA capabilities to an existing DPDK data plane without rewriting it.
The documentation clearly scopes use to existing DPDK applications and discloses DOCA/DPDK dependencies, privilege requirements, version coupling, lifecycle order, and reverse teardown; it also prohibits guessing APIs. However, it involves sudo, hugepages, PCI binding, and hardware access without explicit per-step user confirmation, isolation guidance, or a verified rollback path, so points are deducted.
Configuration, build, run, test, and debug workflows are detailed, with useful error taxonomy and layered failure handling. Static review cannot verify key paths, and several API or compatibility claims depend on the local installation or companion material not independently reproduced here, so the score remains below the static ceiling.
Trigger conditions, audience, exclusions, routing to related skills, and C/C++ language boundaries are unusually explicit. Nevertheless, the skill requires Linux, NVIDIA hardware, and preinstalled SDK/DPDK components; Chinese-language support is not demonstrated, and mainland-China reachability of external documentation is unverified, so points are deducted.
The information architecture, loading order, task taxonomy, examples, limitations, and maintenance intake are clear. However, the version is still TBD, author and changelog information are incomplete, the SKILL.md license differs from the supplied NOASSERTION repository metadata, and the SKILLCARD declares a different license combination, so maintainability and governance lose points.
The skill gives actionable guidance for adding DOCA to an existing DPDK application, including port binding, buffer conversion, and fault isolation. It ships no runnable sample, static evidence does not independently verify correctness, and several outcomes require host-specific checks, so only limited effectiveness credit is warranted.
Symbols, commands, paths, error mappings, and version checkpoints provide some auditability. However, the benchmark reports an unavailable evaluation dataset and lacks independently reproducible committed tests or corroborating sources, so verifiability is low.
- Obtain explicit user confirmation before sudo, hugepage, PCI-device binding, or hardware-port changes, and establish a recovery plan.
- Do not treat the BENCHMARK.md PASS claim or the SKILLCARD signing fields as independently verified evidence; the report says the evaluation dataset was unavailable and metadata conflicts exist.
- Use the user's installed headers, pkg-config output, and actual DOCA/DPDK compatibility window as authority rather than relying solely on documented API or compatibility assertions.
What does this skill do, and when should you use it?
This skill is for developers who already maintain a DPDK packet-processing application and want to add DOCA capabilities in the same process, most commonly DOCA Flow hardware steering. It covers mapping DPDK port IDs to doca_dev devices, converting rte_mbuf and DOCA buffers, checking bridge capabilities, and diagnosing DOCA_ERROR_* results. It assumes Linux, an installed DOCA SDK and separate DPDK installation, compatible versions, supported NVIDIA hardware, and appropriate privileges. The SKILL.md is a thin loader; detailed capability and task guidance is delegated to CAPABILITIES.md and TASKS.md.
Reads local installation information through pkg-config doca-dpdk-bridge and pkg-config libdpdk, and inspects libraries, headers, samples, and applications under /opt/mellanox/doca. Guides use of doca_dpdk_port_probe and doca_dpdk_port_as_dev to map a DPDK port to doca_dev. Covers rte_mbuf-to-DOCA-buffer conversion through the doca_dpdk_mempool surface, the doca_dpdk_cap_is_rep_port_supported capability query, and layered diagnosis of DOCA_ERROR_* across installation, version, build, link, runtime, program, and driver layers.
- A DPDK application owner adding DOCA Flow hardware steering without migrating the data plane to DOCA-native APIs.
- A developer who needs DOCA Core or DOCA Flow to see a physical port already represented by a DPDK port ID.
- A packet-processing developer who needs to pass DPDK rte_mbuf data into a DOCA library.
- A developer whose bridge pkg-config check fails or whose DPDK and DOCA versions may not form a matched pair.
- A developer investigating port-registration, permission, capability, or buffer-conversion DOCA_ERROR_* results.
What are this skill's strengths and limitations?
- Focused on the existing-DPDK-to-DOCA interoperability case.
- Covers port handover, buffer conversion, capability checks, version coupling, and layered troubleshooting.
- Clearly distinguishes the bridge path from fresh DOCA-native packet I/O.
- Uses the user's installed pkg-config metadata as the source of truth instead of assuming a fixed build setup.
- Not intended for fresh DOCA-native packet I/O, DOCA installation, or learning DPDK itself.
- Ships no ready-to-build application source, samples subtree, bindings, reference subtree, or standalone build manifest.
- Requires Linux, matched DOCA/DPDK versions, supported hardware, and device-related privileges; the exact version window is not specified in the supplied text.
- The provided SKILL.md is primarily a loader and depends on companion files for the detailed matrix and procedures.
How do you install this skill?
Use the repository README's skills CLI flow: npx skills add nvidia/skills --skill doca-dpdk-bridge --yes. The skill becomes available to a compatible Agent when a relevant task is encountered. The supplied material does not document a specific local installation directory or provide DOCA/DPDK installation instructions.
How do you use this skill?
Start with an existing DPDK application and confirm that DOCA and DPDK are installed and that the process can access the target device. Example prompts include: "How do I add DOCA Flow rules to my existing DPDK app without rewriting the data plane?", "How do I register a DPDK port as a doca_dev?", and "pkg-config --exists doca-dpdk-bridge fails; how should I debug it?" For configure, build, modify, run, test, or debug work, load TASKS.md; for the capability matrix and safety rules, load CAPABILITIES.md.
How does this skill compare with similar options?
Use doca-dpdk-bridge when an existing DPDK data plane must gain DOCA capabilities. For a new project without DPDK lock-in that needs DOCA-native packet I/O, the source recommends doca-eth. doca-flow is a complementary steering library, while doca-setup handles DOCA installation preparation.