[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-nvidia-doca-dpdk-bridge":3,"mdc-wc338e-key":31,"related-org-nvidia-doca-dpdk-bridge":1484,"related-repo-nvidia-doca-dpdk-bridge":1645},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":20,"repoUrl":21,"updatedAt":22,"license":23,"forks":24,"topics":25,"repo":26,"sourceUrl":29,"mdContent":30},"doca-dpdk-bridge","integrate DOCA Flow into DPDK applications","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` \u002F `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\u002FO (doca-eth), flow-rule programming (doca-flow), DOCA or DPDK install (doca-setup), or RDMA data movement (doca-rdma).\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},"nvidia","NVIDIA","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fnvidia.png",[12,16,17],{"name":13,"slug":14,"type":15},"Networking","networking","tag",{"name":9,"slug":8,"type":15},{"name":18,"slug":19,"type":15},"Engineering","engineering",2473,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills","2026-07-20T06:24:13.723776","Apache-2.0",281,[],{"repoUrl":21,"stars":20,"forks":24,"topics":27,"description":28},[],"AI agent skills published by NVIDIA","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Fskills\u002Ftree\u002FHEAD\u002Fskills\u002Fdoca-dpdk-bridge","---\nlicense: Apache-2.0\nname: doca-dpdk-bridge\ndescription: >\n  Use this skill when the user has an existing DPDK application and is\n  adding DOCA capabilities in-place — most commonly DOCA Flow hardware\n  steering — without rewriting the data-plane in DOCA-native form:\n  binding a DPDK port id to a `doca_dev` (`doca_dpdk_port_probe` \u002F\n  `doca_dpdk_port_as_dev`), converting `rte_mbuf` ↔ `doca_buf`,\n  querying `doca_dpdk_cap_is_rep_port_supported`, or debugging\n  `DOCA_ERROR_*` from a bridge call. Trigger even without \"DOCA DPDK\n  Bridge\": \"how do I add DOCA Flow to my DPDK app\", \"make a DPDK port\n  visible to DOCA\", \"the bridge loads but every operation returns\n  errors\", \"pkg-config --exists doca-dpdk-bridge fails\", or\n  \"DOCA_ERROR_NOT_FOUND on port registration\". Route elsewhere for\n  fresh DOCA-native packet I\u002FO (doca-eth), flow-rule programming\n  (doca-flow), DOCA or DPDK install (doca-setup), or RDMA data\n  movement (doca-rdma).\nmetadata:\n  kind: library\ncompatibility: >\n  Requires DOCA SDK installed at \u002Fopt\u002Fmellanox\u002Fdoca on Linux\n  (Ubuntu 22.04\u002F24.04 or RHEL\u002FSLES) with a BlueField DPU or\n  ConnectX NIC attached, plus a separate DPDK install whose\n  version falls within the bridge's matched-pair window. Reads\n  the user's local install via `pkg-config doca-dpdk-bridge` and\n  `pkg-config libdpdk`, and inspects\n  \u002Fopt\u002Fmellanox\u002Fdoca\u002F{lib,include,samples,applications}.\n---\n\n# DOCA DPDK Bridge\n\n**Where to start:** This skill assumes DOCA is already installed,\nDPDK is already installed, the user has an **existing DPDK\napplication**, and they want to **add DOCA capabilities to it\nin-place** (most commonly DOCA Flow for hardware steering)\nwithout migrating the data-plane to DOCA-native APIs. Open\n[`TASKS.md`](TASKS.md) if the user wants to *do* something\n(configure \u002F build \u002F modify \u002F run \u002F test \u002F debug); open\n[`CAPABILITIES.md`](CAPABILITIES.md) when the question is *what\nthe bridge can express* on this version. If the user has not\ninstalled DOCA yet, route to\n[`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) first. If the user is\n**starting fresh** (no DPDK code yet) and just wants line-rate\npacket I\u002FO against DOCA, route to\n[`doca-eth`](..\u002Fdoca-eth\u002FSKILL.md) instead — the bridge exists\nfor the interop case, not the start-fresh case.\n\n## Example questions this skill answers well\n\nThe CLASSES of DOCA DPDK Bridge questions this skill is built to\nanswer, each with one worked example. The agent should treat the\n*class* as the load-bearing piece — the worked example is a\nsingle instance.\n\n- **\"I have a DPDK app — how do I add DOCA Flow rules to it\n  without rewriting the data-plane?\"** — worked example: *\"my\n  packet-processing app already drives mbufs through `rte_eth_*`\n  ports; I want to install DOCA Flow steering rules on those\n  ports for HW offload\"*. Answered by the bridge-vs-native\n  selection rule in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the port-handover workflow in\n  [`TASKS.md ## configure`](TASKS.md#configure) step 3.\n- **\"How do I make a DPDK port visible to DOCA?\"** — worked\n  example: *\"I have a DPDK port id from `rte_eth_dev_*`; how does\n  DOCA see it\"*. Answered by the DPDK-port-id ↔ `doca_dev`\n  mapping (`doca_dpdk_port_probe` \u002F `doca_dpdk_port_as_dev`) in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  bridge-objects table + the binding workflow in\n  [`TASKS.md ## configure`](TASKS.md#configure) step 4.\n- **\"How do I move packets between DPDK mbufs and DOCA bufs?\"** —\n  worked example: *\"DPDK delivers an `rte_mbuf` to my fastpath; I\n  want a DOCA library to operate on the payload\"*. Answered by\n  the mbuf ↔ DOCA-buf conversion shape in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the conversion-step workflow in\n  [`TASKS.md ## modify`](TASKS.md#modify).\n- **\"Is the bridge even installed and is its DPDK compatible\n  with my DOCA?\"** — worked example: *\"`pkg-config --exists\n  doca-dpdk-bridge` returns failure on a host that has DPDK\n  separately installed\"*. Answered by the version-coupling rule\n  in\n  [`CAPABILITIES.md ## Version compatibility`](CAPABILITIES.md#version-compatibility)\n  + the cap-check workflow in\n  [`TASKS.md ## configure`](TASKS.md#configure) step 1.\n- **\"Should I be using `doca-dpdk-bridge` or `doca-eth`?\"** —\n  worked example: *\"new project; I have not committed to DPDK\n  yet\"*. Answered by the path-selection table in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  bridge-vs-native row + the deferred-verbs note in\n  [`TASKS.md ## Deferred task verbs`](TASKS.md#deferred-task-verbs).\n- **\"What does this `DOCA_ERROR_*` from a bridge call mean and\n  which layer caused it?\"** — worked example: *\"`DOCA_ERROR_NOT_FOUND`\n  on a port-registration call after the DPDK port came up\n  cleanly\"*. Answered by the bridge overlay on the cross-library\n  taxonomy in\n  [`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)\n  + the layered ladder in\n  [`TASKS.md ## debug`](TASKS.md#debug) that escalates to\n  [`doca-debug`](..\u002F..\u002Fdoca-debug\u002FSKILL.md).\n\n## Audience\n\nThis skill serves **external developers who already maintain a\nDPDK-based packet-processing application** — i.e., users whose\ndata-plane already drives `rte_eth_*` ports and `rte_mbuf`\nbuffers — and who want to **add DOCA capabilities** (most\ncommonly hardware steering via DOCA Flow) by linking the bridge\ninto the same process. It is *not* for users starting a fresh\nDOCA-native project (route to [`doca-eth`](..\u002Fdoca-eth\u002FSKILL.md))\nand *not* for users running pure DPDK with no interest in DOCA\n(no skill in this bundle applies). It is also not for NVIDIA\ndevelopers contributing to DOCA DPDK Bridge itself.\n\n**Language scope.** DOCA DPDK Bridge ships as a C library with\n`pkg-config` module name `doca-dpdk-bridge` (the agent must\nconfirm the spelling against the user's install via\n`pkg-config --exists doca-dpdk-bridge`; some DOCA releases use a\nslightly different module name and the agent must not guess).\nThe shipped samples are written in C. C and C++ consumers are\nthe canonical case; the worked examples in `TASKS.md` assume\nthat path. Other-language consumers (Rust, Go, Python, …)\ntypically do not use this bridge — DPDK itself is C-shaped, and\na non-C DPDK app is rare; if the user is in that minority, the\nskill's contribution is to keep the port-handover, capability,\npermission, and error-taxonomy guidance language-neutral and\nroute them to the public C ABI as the authoritative surface.\n\n## When to load this skill\n\nLoad this skill when the user is doing hands-on DOCA DPDK Bridge\nwork, in any language. Concretely:\n\n- The user has an EXISTING DPDK application (their data-plane\n  already drives `rte_eth_dev_*` ports and `rte_mbuf` buffers),\n  and they want to layer DOCA on top — adding DOCA Flow rules,\n  feeding packets into a DOCA accelerator (Compress, AES-GCM, …),\n  or wiring a DOCA service into the same process.\n- The user needs to bind a DPDK port id to a `doca_dev` (via\n  `doca_dpdk_port_probe` \u002F `doca_dpdk_port_as_dev`) so DOCA Core\n  \u002F DOCA Flow can operate on the same physical port.\n- The user needs to convert between DPDK mbufs and DOCA-bufs at\n  the data-plane boundary, and is asking about the conversion\n  helpers and their cost.\n- The user is debugging a `DOCA_ERROR_*` returned from a bridge\n  call (lifecycle vs. permission vs. capability vs. DPDK-port-not-\n  registered vs. mbuf-conversion-failed) and the layered DPDK ↔\n  DOCA stack underneath.\n- The user is hitting cross-version pain: their DPDK install and\n  their DOCA install are not the matched pair the bridge expects.\n- The user is asking *\"native `doca-eth` or `doca-dpdk-bridge`?\"*\n  and the agent needs the path-selection rule.\n\nDo **not** load this skill for general DOCA orientation, install\nof DOCA itself, fresh DOCA-native packet I\u002FO (use\n[`doca-eth`](..\u002Fdoca-eth\u002FSKILL.md)), flow-rule programming on\nits own (use [`doca-flow`](..\u002Fdoca-flow\u002FSKILL.md)), host ↔ DPU\ncontrol messaging (use [`doca-comch`](..\u002Fdoca-comch\u002FSKILL.md)),\nor RDMA data movement (use [`doca-rdma`](..\u002Fdoca-rdma\u002FSKILL.md)).\nFor DOCA documentation orientation, use\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md).\n\n## What this skill provides\n\nThis is a **thin loader**. The body keeps only the orientation\nneeded to pick the right next file. The substantive bridge-\nspecific material lives in two companion files:\n\n- `CAPABILITIES.md` — what the DOCA DPDK Bridge can express on\n  this version: the bridge-vs-native selection rule (when to\n  use `doca-dpdk-bridge` vs native `doca-eth`), the\n  bridge-object surface (DPDK-port-id ↔ `doca_dev` mapping, the\n  `doca_dpdk_mempool` mbuf ↔ DOCA-buf conversion), the\n  capability-query surface (the single\n  `doca_dpdk_cap_is_rep_port_supported`), the bridge error taxonomy\n  (mapped onto the cross-library `DOCA_ERROR_*` set), the\n  observability surface (DPDK-side counters + DOCA-side PE\n  events), and the safety policy that gates the matched-pair\n  DPDK ↔ DOCA version coupling, the EAL-must-be-up\n  precondition, and DPDK-side privileges.\n- `TASKS.md` — step-by-step workflows for the six in-scope\n  bridge verbs: `configure`, `build`, `modify`, `run`, `test`,\n  `debug`. Plus a `Deferred task verbs` block that points\n  out-of-scope questions at the right next skill, and a\n  `Command appendix` of the recurring commands the agent\n  reaches for.\n\nThe skill assumes a host or BlueField where DOCA AND DPDK are\nalready installed at the standard locations and the user has the\nprivileges their public install profile expects (typically sudo\nor `mlnx`-group membership for DOCA, plus the DPDK-side\nprivileges to mount hugepages, bind PCIe ports, and open the\ntarget `rte_eth` device). It does not cover installing DOCA —\nthat path goes through [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md);\nit does not cover installing or learning DPDK itself — that\nbelongs in upstream DPDK documentation reachable via\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md).\n\n## What this skill deliberately does not ship\n\nThis skill is **agent guidance**, not a samples or templates\nbundle. To keep the boundary clean, it deliberately does not\ncontain — and pull requests should not add:\n\n- **Pre-written DOCA DPDK Bridge application source code, in any\n  language.** The verified bridge source code is the bridge\n  usage inside the shipped C DOCA Flow samples at\n  `\u002Fopt\u002Fmellanox\u002Fdoca\u002Fsamples\u002Fdoca_flow\u002F` (e.g. `flow_common.c`,\n  which calls `doca_dpdk_port_probe()` \u002F `doca_dpdk_port_as_dev()`),\n  plus the canonical reference applications that pair DPDK +\n  DOCA Flow (see\n  [`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\n  for the reference-applications index). The agent's job is to\n  route the user to those files and prescribe a minimum-diff\n  modification on them via the universal modify-a-sample\n  workflow in\n  [`doca-programming-guide`](..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md),\n  layered with the bridge-specific overrides in\n  [`TASKS.md ## modify`](TASKS.md#modify).\n- **Standalone build manifests** (`meson.build`,\n  `CMakeLists.txt`, `Cargo.toml`, …) parked inside the skill.\n  The agent constructs the build manifest *in the user's project\n  directory* against the user's installed DOCA + DPDK, where\n  `pkg-config --modversion doca-dpdk-bridge` and\n  `pkg-config --modversion libdpdk` are the source of truth.\n- **A `samples\u002F`, `bindings\u002F`, or `reference\u002F` subtree** of any\n  kind. A mock or incomplete artifact in this skill's tree, even\n  one labeled \"reference\", is misleading: users will read it as\n  buildable.\n\n## Loading order\n\n1. Read this `SKILL.md` first to confirm the user's question is\n   in scope (existing DPDK app + wants DOCA on top — not fresh).\n2. **For the bridge capability matrix, the bridge-vs-native\n   selection rule, port-handover surface, capability-query rules,\n   error taxonomy, observability, and safety policy, see\n   [CAPABILITIES.md](CAPABILITIES.md).**\n3. **For step-by-step workflows — configure, build, modify, run,\n   test, debug — see [TASKS.md](TASKS.md).**\n\nBoth companion files cross-link to each other,\n[`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) for the canonical\nDOCA version-handling rules,\n[`doca-eth`](..\u002Fdoca-eth\u002FSKILL.md) for the start-fresh path that\nis the bridge's deliberate alternative,\n[`doca-flow`](..\u002Fdoca-flow\u002FSKILL.md) for the steering library\nthat is the most common reason to use this bridge in the first\nplace, and\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\nwhenever the right answer is \"look it up in the public docs or\nthe installed package layout\" rather than \"bridge-specific\nguidance\".\n\n## Related skills\n\n- [`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md) —\n  the routing table for every public DOCA documentation source\n  and the on-disk layout of an installed DOCA package. The\n  bridge URL slug is `DOCA-DPDK-Bridge`. Reference applications\n  that pair DPDK + DOCA Flow (the canonical adopters of this\n  bridge) are reachable from the same map's reference-\n  applications index.\n- [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) — env preparation,\n  install verification, hugepage mounts (DPDK requirement),\n  port-state checks (`devlink dev show`, `ip link`), permission\n  and group-membership requirements for opening a `doca_dev`\n  AND for binding PCIe ports under DPDK. This skill assumes its\n  preconditions are satisfied.\n- [`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) — canonical\n  DOCA version-handling rules. This skill's `## Version\n  compatibility` cross-links the four-way match rule and adds\n  only the bridge-specific overlay (DPDK ↔ DOCA matched-pair\n  coupling).\n- [`doca-structured-tools-contract`](..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md) —\n  the bundle's structured-tools precedence rule (detect \u002F prefer\n  \u002F fall back \u002F report). The Command appendix in\n  [TASKS.md](TASKS.md) honors this contract.\n- [`doca-programming-guide`](..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md) —\n  general DOCA programming patterns shared by every library:\n  the canonical `pkg-config` + meson build pattern, the\n  universal modify-a-shipped-sample first-app workflow, the\n  universal lifecycle, the cross-library `DOCA_ERROR_*`\n  taxonomy, and the program-side debug order. This skill layers\n  bridge specifics on top.\n- [`doca-eth`](..\u002Fdoca-eth\u002FSKILL.md) — the **alternative path**\n  for users starting fresh: pure DOCA-native queue I\u002FO via\n  `doca_eth_rxq` \u002F `doca_eth_txq` with no DPDK in the picture.\n  The bridge exists *because* migrating an existing DPDK app to\n  `doca-eth` is often the wrong tradeoff; for a new project\n  with no DPDK lock-in, `doca-eth` is the right choice.\n- [`doca-flow`](..\u002Fdoca-flow\u002FSKILL.md) — the steering library\n  that is the most common reason a DPDK app reaches for this\n  bridge. The bridge binds a DPDK port id to a `doca_dev`;\n  DOCA Flow programs steering rules onto that `doca_dev`. The two\n  libraries are designed to compose.\n- [`doca-debug`](..\u002F..\u002Fdoca-debug\u002FSKILL.md) — the cross-cutting\n  debug ladder (install \u002F version \u002F build \u002F link \u002F runtime \u002F\n  program \u002F driver). Bridge-specific debug (DPDK ↔ DOCA version\n  drift, port-not-registered symptoms, mbuf-conversion failures)\n  overlays on top of that ladder.\n",{"data":32,"body":36},{"license":23,"name":4,"description":6,"metadata":33,"compatibility":35},{"kind":34},"library","Requires DOCA SDK installed at \u002Fopt\u002Fmellanox\u002Fdoca on Linux (Ubuntu 22.04\u002F24.04 or RHEL\u002FSLES) 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 \u002Fopt\u002Fmellanox\u002Fdoca\u002F{lib,include,samples,applications}.\n",{"type":37,"children":38},"root",[39,47,143,150,162,519,525,581,620,626,631,723,791,797,809,937,977,983,995,1158,1164,1207,1254,1260],{"type":40,"tag":41,"props":42,"children":43},"element","h1",{"id":4},[44],{"type":45,"value":46},"text","DOCA DPDK Bridge",{"type":40,"tag":48,"props":49,"children":50},"p",{},[51,57,59,64,66,71,73,84,86,92,94,103,105,110,112,122,124,129,131,141],{"type":40,"tag":52,"props":53,"children":54},"strong",{},[55],{"type":45,"value":56},"Where to start:",{"type":45,"value":58}," This skill assumes DOCA is already installed,\nDPDK is already installed, the user has an ",{"type":40,"tag":52,"props":60,"children":61},{},[62],{"type":45,"value":63},"existing DPDK\napplication",{"type":45,"value":65},", and they want to ",{"type":40,"tag":52,"props":67,"children":68},{},[69],{"type":45,"value":70},"add DOCA capabilities to it\nin-place",{"type":45,"value":72}," (most commonly DOCA Flow for hardware steering)\nwithout migrating the data-plane to DOCA-native APIs. Open\n",{"type":40,"tag":74,"props":75,"children":77},"a",{"href":76},"TASKS.md",[78],{"type":40,"tag":79,"props":80,"children":82},"code",{"className":81},[],[83],{"type":45,"value":76},{"type":45,"value":85}," if the user wants to ",{"type":40,"tag":87,"props":88,"children":89},"em",{},[90],{"type":45,"value":91},"do",{"type":45,"value":93}," something\n(configure \u002F build \u002F modify \u002F run \u002F test \u002F debug); open\n",{"type":40,"tag":74,"props":95,"children":97},{"href":96},"CAPABILITIES.md",[98],{"type":40,"tag":79,"props":99,"children":101},{"className":100},[],[102],{"type":45,"value":96},{"type":45,"value":104}," when the question is ",{"type":40,"tag":87,"props":106,"children":107},{},[108],{"type":45,"value":109},"what\nthe bridge can express",{"type":45,"value":111}," on this version. If the user has not\ninstalled DOCA yet, route to\n",{"type":40,"tag":74,"props":113,"children":115},{"href":114},"..\u002F..\u002Fdoca-setup\u002FSKILL.md",[116],{"type":40,"tag":79,"props":117,"children":119},{"className":118},[],[120],{"type":45,"value":121},"doca-setup",{"type":45,"value":123}," first. If the user is\n",{"type":40,"tag":52,"props":125,"children":126},{},[127],{"type":45,"value":128},"starting fresh",{"type":45,"value":130}," (no DPDK code yet) and just wants line-rate\npacket I\u002FO against DOCA, route to\n",{"type":40,"tag":74,"props":132,"children":134},{"href":133},"..\u002Fdoca-eth\u002FSKILL.md",[135],{"type":40,"tag":79,"props":136,"children":138},{"className":137},[],[139],{"type":45,"value":140},"doca-eth",{"type":45,"value":142}," instead — the bridge exists\nfor the interop case, not the start-fresh case.",{"type":40,"tag":144,"props":145,"children":147},"h2",{"id":146},"example-questions-this-skill-answers-well",[148],{"type":45,"value":149},"Example questions this skill answers well",{"type":40,"tag":48,"props":151,"children":152},{},[153,155,160],{"type":45,"value":154},"The CLASSES of DOCA DPDK Bridge questions this skill is built to\nanswer, each with one worked example. The agent should treat the\n",{"type":40,"tag":87,"props":156,"children":157},{},[158],{"type":45,"value":159},"class",{"type":45,"value":161}," as the load-bearing piece — the worked example is a\nsingle instance.",{"type":40,"tag":163,"props":164,"children":165},"ul",{},[166,222,291,344,396,447],{"type":40,"tag":167,"props":168,"children":169},"li",{},[170,175,177,190,192,202],{"type":40,"tag":52,"props":171,"children":172},{},[173],{"type":45,"value":174},"\"I have a DPDK app — how do I add DOCA Flow rules to it\nwithout rewriting the data-plane?\"",{"type":45,"value":176}," — worked example: ",{"type":40,"tag":87,"props":178,"children":179},{},[180,182,188],{"type":45,"value":181},"\"my\npacket-processing app already drives mbufs through ",{"type":40,"tag":79,"props":183,"children":185},{"className":184},[],[186],{"type":45,"value":187},"rte_eth_*",{"type":45,"value":189},"\nports; I want to install DOCA Flow steering rules on those\nports for HW offload\"",{"type":45,"value":191},". Answered by the bridge-vs-native\nselection rule in\n",{"type":40,"tag":74,"props":193,"children":195},{"href":194},"CAPABILITIES.md#capabilities-and-modes",[196],{"type":40,"tag":79,"props":197,"children":199},{"className":198},[],[200],{"type":45,"value":201},"CAPABILITIES.md ## Capabilities and modes",{"type":40,"tag":163,"props":203,"children":204},{},[205],{"type":40,"tag":167,"props":206,"children":207},{},[208,210,220],{"type":45,"value":209},"the port-handover workflow in\n",{"type":40,"tag":74,"props":211,"children":213},{"href":212},"TASKS.md#configure",[214],{"type":40,"tag":79,"props":215,"children":217},{"className":216},[],[218],{"type":45,"value":219},"TASKS.md ## configure",{"type":45,"value":221}," step 3.",{"type":40,"tag":167,"props":223,"children":224},{},[225,230,232,245,247,253,255,261,263,269,271,279,281,289],{"type":40,"tag":52,"props":226,"children":227},{},[228],{"type":45,"value":229},"\"How do I make a DPDK port visible to DOCA?\"",{"type":45,"value":231}," — worked\nexample: ",{"type":40,"tag":87,"props":233,"children":234},{},[235,237,243],{"type":45,"value":236},"\"I have a DPDK port id from ",{"type":40,"tag":79,"props":238,"children":240},{"className":239},[],[241],{"type":45,"value":242},"rte_eth_dev_*",{"type":45,"value":244},"; how does\nDOCA see it\"",{"type":45,"value":246},". Answered by the DPDK-port-id ↔ ",{"type":40,"tag":79,"props":248,"children":250},{"className":249},[],[251],{"type":45,"value":252},"doca_dev",{"type":45,"value":254},"\nmapping (",{"type":40,"tag":79,"props":256,"children":258},{"className":257},[],[259],{"type":45,"value":260},"doca_dpdk_port_probe",{"type":45,"value":262}," \u002F ",{"type":40,"tag":79,"props":264,"children":266},{"className":265},[],[267],{"type":45,"value":268},"doca_dpdk_port_as_dev",{"type":45,"value":270},") in\n",{"type":40,"tag":74,"props":272,"children":273},{"href":194},[274],{"type":40,"tag":79,"props":275,"children":277},{"className":276},[],[278],{"type":45,"value":201},{"type":45,"value":280},"\nbridge-objects table + the binding workflow in\n",{"type":40,"tag":74,"props":282,"children":283},{"href":212},[284],{"type":40,"tag":79,"props":285,"children":287},{"className":286},[],[288],{"type":45,"value":219},{"type":45,"value":290}," step 4.",{"type":40,"tag":167,"props":292,"children":293},{},[294,299,301,314,316,324],{"type":40,"tag":52,"props":295,"children":296},{},[297],{"type":45,"value":298},"\"How do I move packets between DPDK mbufs and DOCA bufs?\"",{"type":45,"value":300}," —\nworked example: ",{"type":40,"tag":87,"props":302,"children":303},{},[304,306,312],{"type":45,"value":305},"\"DPDK delivers an ",{"type":40,"tag":79,"props":307,"children":309},{"className":308},[],[310],{"type":45,"value":311},"rte_mbuf",{"type":45,"value":313}," to my fastpath; I\nwant a DOCA library to operate on the payload\"",{"type":45,"value":315},". Answered by\nthe mbuf ↔ DOCA-buf conversion shape in\n",{"type":40,"tag":74,"props":317,"children":318},{"href":194},[319],{"type":40,"tag":79,"props":320,"children":322},{"className":321},[],[323],{"type":45,"value":201},{"type":40,"tag":163,"props":325,"children":326},{},[327],{"type":40,"tag":167,"props":328,"children":329},{},[330,332,342],{"type":45,"value":331},"the conversion-step workflow in\n",{"type":40,"tag":74,"props":333,"children":335},{"href":334},"TASKS.md#modify",[336],{"type":40,"tag":79,"props":337,"children":339},{"className":338},[],[340],{"type":45,"value":341},"TASKS.md ## modify",{"type":45,"value":343},".",{"type":40,"tag":167,"props":345,"children":346},{},[347,352,353,366,368,378],{"type":40,"tag":52,"props":348,"children":349},{},[350],{"type":45,"value":351},"\"Is the bridge even installed and is its DPDK compatible\nwith my DOCA?\"",{"type":45,"value":176},{"type":40,"tag":87,"props":354,"children":355},{},[356,358,364],{"type":45,"value":357},"\"",{"type":40,"tag":79,"props":359,"children":361},{"className":360},[],[362],{"type":45,"value":363},"pkg-config --exists doca-dpdk-bridge",{"type":45,"value":365}," returns failure on a host that has DPDK\nseparately installed\"",{"type":45,"value":367},". Answered by the version-coupling rule\nin\n",{"type":40,"tag":74,"props":369,"children":371},{"href":370},"CAPABILITIES.md#version-compatibility",[372],{"type":40,"tag":79,"props":373,"children":375},{"className":374},[],[376],{"type":45,"value":377},"CAPABILITIES.md ## Version compatibility",{"type":40,"tag":163,"props":379,"children":380},{},[381],{"type":40,"tag":167,"props":382,"children":383},{},[384,386,394],{"type":45,"value":385},"the cap-check workflow in\n",{"type":40,"tag":74,"props":387,"children":388},{"href":212},[389],{"type":40,"tag":79,"props":390,"children":392},{"className":391},[],[393],{"type":45,"value":219},{"type":45,"value":395}," step 1.",{"type":40,"tag":167,"props":397,"children":398},{},[399,418,419,424,426,434,436,446],{"type":40,"tag":52,"props":400,"children":401},{},[402,404,409,411,416],{"type":45,"value":403},"\"Should I be using ",{"type":40,"tag":79,"props":405,"children":407},{"className":406},[],[408],{"type":45,"value":4},{"type":45,"value":410}," or ",{"type":40,"tag":79,"props":412,"children":414},{"className":413},[],[415],{"type":45,"value":140},{"type":45,"value":417},"?\"",{"type":45,"value":300},{"type":40,"tag":87,"props":420,"children":421},{},[422],{"type":45,"value":423},"\"new project; I have not committed to DPDK\nyet\"",{"type":45,"value":425},". Answered by the path-selection table in\n",{"type":40,"tag":74,"props":427,"children":428},{"href":194},[429],{"type":40,"tag":79,"props":430,"children":432},{"className":431},[],[433],{"type":45,"value":201},{"type":45,"value":435},"\nbridge-vs-native row + the deferred-verbs note in\n",{"type":40,"tag":74,"props":437,"children":439},{"href":438},"TASKS.md#deferred-task-verbs",[440],{"type":40,"tag":79,"props":441,"children":443},{"className":442},[],[444],{"type":45,"value":445},"TASKS.md ## Deferred task verbs",{"type":45,"value":343},{"type":40,"tag":167,"props":448,"children":449},{},[450,463,464,476,478,488],{"type":40,"tag":52,"props":451,"children":452},{},[453,455,461],{"type":45,"value":454},"\"What does this ",{"type":40,"tag":79,"props":456,"children":458},{"className":457},[],[459],{"type":45,"value":460},"DOCA_ERROR_*",{"type":45,"value":462}," from a bridge call mean and\nwhich layer caused it?\"",{"type":45,"value":176},{"type":40,"tag":87,"props":465,"children":466},{},[467,468,474],{"type":45,"value":357},{"type":40,"tag":79,"props":469,"children":471},{"className":470},[],[472],{"type":45,"value":473},"DOCA_ERROR_NOT_FOUND",{"type":45,"value":475},"\non a port-registration call after the DPDK port came up\ncleanly\"",{"type":45,"value":477},". Answered by the bridge overlay on the cross-library\ntaxonomy in\n",{"type":40,"tag":74,"props":479,"children":481},{"href":480},"CAPABILITIES.md#error-taxonomy",[482],{"type":40,"tag":79,"props":483,"children":485},{"className":484},[],[486],{"type":45,"value":487},"CAPABILITIES.md ## Error taxonomy",{"type":40,"tag":163,"props":489,"children":490},{},[491],{"type":40,"tag":167,"props":492,"children":493},{},[494,496,506,508,518],{"type":45,"value":495},"the layered ladder in\n",{"type":40,"tag":74,"props":497,"children":499},{"href":498},"TASKS.md#debug",[500],{"type":40,"tag":79,"props":501,"children":503},{"className":502},[],[504],{"type":45,"value":505},"TASKS.md ## debug",{"type":45,"value":507}," that escalates to\n",{"type":40,"tag":74,"props":509,"children":511},{"href":510},"..\u002F..\u002Fdoca-debug\u002FSKILL.md",[512],{"type":40,"tag":79,"props":513,"children":515},{"className":514},[],[516],{"type":45,"value":517},"doca-debug",{"type":45,"value":343},{"type":40,"tag":144,"props":520,"children":522},{"id":521},"audience",[523],{"type":45,"value":524},"Audience",{"type":40,"tag":48,"props":526,"children":527},{},[528,530,535,537,542,544,549,551,556,558,563,565,573,575,579],{"type":45,"value":529},"This skill serves ",{"type":40,"tag":52,"props":531,"children":532},{},[533],{"type":45,"value":534},"external developers who already maintain a\nDPDK-based packet-processing application",{"type":45,"value":536}," — i.e., users whose\ndata-plane already drives ",{"type":40,"tag":79,"props":538,"children":540},{"className":539},[],[541],{"type":45,"value":187},{"type":45,"value":543}," ports and ",{"type":40,"tag":79,"props":545,"children":547},{"className":546},[],[548],{"type":45,"value":311},{"type":45,"value":550},"\nbuffers — and who want to ",{"type":40,"tag":52,"props":552,"children":553},{},[554],{"type":45,"value":555},"add DOCA capabilities",{"type":45,"value":557}," (most\ncommonly hardware steering via DOCA Flow) by linking the bridge\ninto the same process. It is ",{"type":40,"tag":87,"props":559,"children":560},{},[561],{"type":45,"value":562},"not",{"type":45,"value":564}," for users starting a fresh\nDOCA-native project (route to ",{"type":40,"tag":74,"props":566,"children":567},{"href":133},[568],{"type":40,"tag":79,"props":569,"children":571},{"className":570},[],[572],{"type":45,"value":140},{"type":45,"value":574},")\nand ",{"type":40,"tag":87,"props":576,"children":577},{},[578],{"type":45,"value":562},{"type":45,"value":580}," for users running pure DPDK with no interest in DOCA\n(no skill in this bundle applies). It is also not for NVIDIA\ndevelopers contributing to DOCA DPDK Bridge itself.",{"type":40,"tag":48,"props":582,"children":583},{},[584,589,591,597,599,604,606,611,613,618],{"type":40,"tag":52,"props":585,"children":586},{},[587],{"type":45,"value":588},"Language scope.",{"type":45,"value":590}," DOCA DPDK Bridge ships as a C library with\n",{"type":40,"tag":79,"props":592,"children":594},{"className":593},[],[595],{"type":45,"value":596},"pkg-config",{"type":45,"value":598}," module name ",{"type":40,"tag":79,"props":600,"children":602},{"className":601},[],[603],{"type":45,"value":4},{"type":45,"value":605}," (the agent must\nconfirm the spelling against the user's install via\n",{"type":40,"tag":79,"props":607,"children":609},{"className":608},[],[610],{"type":45,"value":363},{"type":45,"value":612},"; some DOCA releases use a\nslightly different module name and the agent must not guess).\nThe shipped samples are written in C. C and C++ consumers are\nthe canonical case; the worked examples in ",{"type":40,"tag":79,"props":614,"children":616},{"className":615},[],[617],{"type":45,"value":76},{"type":45,"value":619}," assume\nthat path. Other-language consumers (Rust, Go, Python, …)\ntypically do not use this bridge — DPDK itself is C-shaped, and\na non-C DPDK app is rare; if the user is in that minority, the\nskill's contribution is to keep the port-handover, capability,\npermission, and error-taxonomy guidance language-neutral and\nroute them to the public C ABI as the authoritative surface.",{"type":40,"tag":144,"props":621,"children":623},{"id":622},"when-to-load-this-skill",[624],{"type":45,"value":625},"When to load this skill",{"type":40,"tag":48,"props":627,"children":628},{},[629],{"type":45,"value":630},"Load this skill when the user is doing hands-on DOCA DPDK Bridge\nwork, in any language. Concretely:",{"type":40,"tag":163,"props":632,"children":633},{},[634,652,677,682,694,699],{"type":40,"tag":167,"props":635,"children":636},{},[637,639,644,645,650],{"type":45,"value":638},"The user has an EXISTING DPDK application (their data-plane\nalready drives ",{"type":40,"tag":79,"props":640,"children":642},{"className":641},[],[643],{"type":45,"value":242},{"type":45,"value":543},{"type":40,"tag":79,"props":646,"children":648},{"className":647},[],[649],{"type":45,"value":311},{"type":45,"value":651}," buffers),\nand they want to layer DOCA on top — adding DOCA Flow rules,\nfeeding packets into a DOCA accelerator (Compress, AES-GCM, …),\nor wiring a DOCA service into the same process.",{"type":40,"tag":167,"props":653,"children":654},{},[655,657,662,664,669,670,675],{"type":45,"value":656},"The user needs to bind a DPDK port id to a ",{"type":40,"tag":79,"props":658,"children":660},{"className":659},[],[661],{"type":45,"value":252},{"type":45,"value":663}," (via\n",{"type":40,"tag":79,"props":665,"children":667},{"className":666},[],[668],{"type":45,"value":260},{"type":45,"value":262},{"type":40,"tag":79,"props":671,"children":673},{"className":672},[],[674],{"type":45,"value":268},{"type":45,"value":676},") so DOCA Core\n\u002F DOCA Flow can operate on the same physical port.",{"type":40,"tag":167,"props":678,"children":679},{},[680],{"type":45,"value":681},"The user needs to convert between DPDK mbufs and DOCA-bufs at\nthe data-plane boundary, and is asking about the conversion\nhelpers and their cost.",{"type":40,"tag":167,"props":683,"children":684},{},[685,687,692],{"type":45,"value":686},"The user is debugging a ",{"type":40,"tag":79,"props":688,"children":690},{"className":689},[],[691],{"type":45,"value":460},{"type":45,"value":693}," returned from a bridge\ncall (lifecycle vs. permission vs. capability vs. DPDK-port-not-\nregistered vs. mbuf-conversion-failed) and the layered DPDK ↔\nDOCA stack underneath.",{"type":40,"tag":167,"props":695,"children":696},{},[697],{"type":45,"value":698},"The user is hitting cross-version pain: their DPDK install and\ntheir DOCA install are not the matched pair the bridge expects.",{"type":40,"tag":167,"props":700,"children":701},{},[702,704,721],{"type":45,"value":703},"The user is asking ",{"type":40,"tag":87,"props":705,"children":706},{},[707,709,714,715,720],{"type":45,"value":708},"\"native ",{"type":40,"tag":79,"props":710,"children":712},{"className":711},[],[713],{"type":45,"value":140},{"type":45,"value":410},{"type":40,"tag":79,"props":716,"children":718},{"className":717},[],[719],{"type":45,"value":4},{"type":45,"value":417},{"type":45,"value":722},"\nand the agent needs the path-selection rule.",{"type":40,"tag":48,"props":724,"children":725},{},[726,728,732,734,742,744,754,756,766,768,778,780,790],{"type":45,"value":727},"Do ",{"type":40,"tag":52,"props":729,"children":730},{},[731],{"type":45,"value":562},{"type":45,"value":733}," load this skill for general DOCA orientation, install\nof DOCA itself, fresh DOCA-native packet I\u002FO (use\n",{"type":40,"tag":74,"props":735,"children":736},{"href":133},[737],{"type":40,"tag":79,"props":738,"children":740},{"className":739},[],[741],{"type":45,"value":140},{"type":45,"value":743},"), flow-rule programming on\nits own (use ",{"type":40,"tag":74,"props":745,"children":747},{"href":746},"..\u002Fdoca-flow\u002FSKILL.md",[748],{"type":40,"tag":79,"props":749,"children":751},{"className":750},[],[752],{"type":45,"value":753},"doca-flow",{"type":45,"value":755},"), host ↔ DPU\ncontrol messaging (use ",{"type":40,"tag":74,"props":757,"children":759},{"href":758},"..\u002Fdoca-comch\u002FSKILL.md",[760],{"type":40,"tag":79,"props":761,"children":763},{"className":762},[],[764],{"type":45,"value":765},"doca-comch",{"type":45,"value":767},"),\nor RDMA data movement (use ",{"type":40,"tag":74,"props":769,"children":771},{"href":770},"..\u002Fdoca-rdma\u002FSKILL.md",[772],{"type":40,"tag":79,"props":773,"children":775},{"className":774},[],[776],{"type":45,"value":777},"doca-rdma",{"type":45,"value":779},").\nFor DOCA documentation orientation, use\n",{"type":40,"tag":74,"props":781,"children":783},{"href":782},"..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md",[784],{"type":40,"tag":79,"props":785,"children":787},{"className":786},[],[788],{"type":45,"value":789},"doca-public-knowledge-map",{"type":45,"value":343},{"type":40,"tag":144,"props":792,"children":794},{"id":793},"what-this-skill-provides",[795],{"type":45,"value":796},"What this skill provides",{"type":40,"tag":48,"props":798,"children":799},{},[800,802,807],{"type":45,"value":801},"This is a ",{"type":40,"tag":52,"props":803,"children":804},{},[805],{"type":45,"value":806},"thin loader",{"type":45,"value":808},". The body keeps only the orientation\nneeded to pick the right next file. The substantive bridge-\nspecific material lives in two companion files:",{"type":40,"tag":163,"props":810,"children":811},{},[812,866],{"type":40,"tag":167,"props":813,"children":814},{},[815,820,822,827,829,834,836,841,843,849,851,857,859,864],{"type":40,"tag":79,"props":816,"children":818},{"className":817},[],[819],{"type":45,"value":96},{"type":45,"value":821}," — what the DOCA DPDK Bridge can express on\nthis version: the bridge-vs-native selection rule (when to\nuse ",{"type":40,"tag":79,"props":823,"children":825},{"className":824},[],[826],{"type":45,"value":4},{"type":45,"value":828}," vs native ",{"type":40,"tag":79,"props":830,"children":832},{"className":831},[],[833],{"type":45,"value":140},{"type":45,"value":835},"), the\nbridge-object surface (DPDK-port-id ↔ ",{"type":40,"tag":79,"props":837,"children":839},{"className":838},[],[840],{"type":45,"value":252},{"type":45,"value":842}," mapping, the\n",{"type":40,"tag":79,"props":844,"children":846},{"className":845},[],[847],{"type":45,"value":848},"doca_dpdk_mempool",{"type":45,"value":850}," mbuf ↔ DOCA-buf conversion), the\ncapability-query surface (the single\n",{"type":40,"tag":79,"props":852,"children":854},{"className":853},[],[855],{"type":45,"value":856},"doca_dpdk_cap_is_rep_port_supported",{"type":45,"value":858},"), the bridge error taxonomy\n(mapped onto the cross-library ",{"type":40,"tag":79,"props":860,"children":862},{"className":861},[],[863],{"type":45,"value":460},{"type":45,"value":865}," set), the\nobservability surface (DPDK-side counters + DOCA-side PE\nevents), and the safety policy that gates the matched-pair\nDPDK ↔ DOCA version coupling, the EAL-must-be-up\nprecondition, and DPDK-side privileges.",{"type":40,"tag":167,"props":867,"children":868},{},[869,874,876,882,884,890,891,897,898,904,905,911,913,919,921,927,929,935],{"type":40,"tag":79,"props":870,"children":872},{"className":871},[],[873],{"type":45,"value":76},{"type":45,"value":875}," — step-by-step workflows for the six in-scope\nbridge verbs: ",{"type":40,"tag":79,"props":877,"children":879},{"className":878},[],[880],{"type":45,"value":881},"configure",{"type":45,"value":883},", ",{"type":40,"tag":79,"props":885,"children":887},{"className":886},[],[888],{"type":45,"value":889},"build",{"type":45,"value":883},{"type":40,"tag":79,"props":892,"children":894},{"className":893},[],[895],{"type":45,"value":896},"modify",{"type":45,"value":883},{"type":40,"tag":79,"props":899,"children":901},{"className":900},[],[902],{"type":45,"value":903},"run",{"type":45,"value":883},{"type":40,"tag":79,"props":906,"children":908},{"className":907},[],[909],{"type":45,"value":910},"test",{"type":45,"value":912},",\n",{"type":40,"tag":79,"props":914,"children":916},{"className":915},[],[917],{"type":45,"value":918},"debug",{"type":45,"value":920},". Plus a ",{"type":40,"tag":79,"props":922,"children":924},{"className":923},[],[925],{"type":45,"value":926},"Deferred task verbs",{"type":45,"value":928}," block that points\nout-of-scope questions at the right next skill, and a\n",{"type":40,"tag":79,"props":930,"children":932},{"className":931},[],[933],{"type":45,"value":934},"Command appendix",{"type":45,"value":936}," of the recurring commands the agent\nreaches for.",{"type":40,"tag":48,"props":938,"children":939},{},[940,942,948,950,956,958,966,968,976],{"type":45,"value":941},"The skill assumes a host or BlueField where DOCA AND DPDK are\nalready installed at the standard locations and the user has the\nprivileges their public install profile expects (typically sudo\nor ",{"type":40,"tag":79,"props":943,"children":945},{"className":944},[],[946],{"type":45,"value":947},"mlnx",{"type":45,"value":949},"-group membership for DOCA, plus the DPDK-side\nprivileges to mount hugepages, bind PCIe ports, and open the\ntarget ",{"type":40,"tag":79,"props":951,"children":953},{"className":952},[],[954],{"type":45,"value":955},"rte_eth",{"type":45,"value":957}," device). It does not cover installing DOCA —\nthat path goes through ",{"type":40,"tag":74,"props":959,"children":960},{"href":114},[961],{"type":40,"tag":79,"props":962,"children":964},{"className":963},[],[965],{"type":45,"value":121},{"type":45,"value":967},";\nit does not cover installing or learning DPDK itself — that\nbelongs in upstream DPDK documentation reachable via\n",{"type":40,"tag":74,"props":969,"children":970},{"href":782},[971],{"type":40,"tag":79,"props":972,"children":974},{"className":973},[],[975],{"type":45,"value":789},{"type":45,"value":343},{"type":40,"tag":144,"props":978,"children":980},{"id":979},"what-this-skill-deliberately-does-not-ship",[981],{"type":45,"value":982},"What this skill deliberately does not ship",{"type":40,"tag":48,"props":984,"children":985},{},[986,988,993],{"type":45,"value":987},"This skill is ",{"type":40,"tag":52,"props":989,"children":990},{},[991],{"type":45,"value":992},"agent guidance",{"type":45,"value":994},", not a samples or templates\nbundle. To keep the boundary clean, it deliberately does not\ncontain — and pull requests should not add:",{"type":40,"tag":163,"props":996,"children":997},{},[998,1070,1125],{"type":40,"tag":167,"props":999,"children":1000},{},[1001,1006,1008,1014,1016,1022,1024,1030,1031,1037,1039,1047,1049,1059,1061,1069],{"type":40,"tag":52,"props":1002,"children":1003},{},[1004],{"type":45,"value":1005},"Pre-written DOCA DPDK Bridge application source code, in any\nlanguage.",{"type":45,"value":1007}," The verified bridge source code is the bridge\nusage inside the shipped C DOCA Flow samples at\n",{"type":40,"tag":79,"props":1009,"children":1011},{"className":1010},[],[1012],{"type":45,"value":1013},"\u002Fopt\u002Fmellanox\u002Fdoca\u002Fsamples\u002Fdoca_flow\u002F",{"type":45,"value":1015}," (e.g. ",{"type":40,"tag":79,"props":1017,"children":1019},{"className":1018},[],[1020],{"type":45,"value":1021},"flow_common.c",{"type":45,"value":1023},",\nwhich calls ",{"type":40,"tag":79,"props":1025,"children":1027},{"className":1026},[],[1028],{"type":45,"value":1029},"doca_dpdk_port_probe()",{"type":45,"value":262},{"type":40,"tag":79,"props":1032,"children":1034},{"className":1033},[],[1035],{"type":45,"value":1036},"doca_dpdk_port_as_dev()",{"type":45,"value":1038},"),\nplus the canonical reference applications that pair DPDK +\nDOCA Flow (see\n",{"type":40,"tag":74,"props":1040,"children":1041},{"href":782},[1042],{"type":40,"tag":79,"props":1043,"children":1045},{"className":1044},[],[1046],{"type":45,"value":789},{"type":45,"value":1048},"\nfor the reference-applications index). The agent's job is to\nroute the user to those files and prescribe a minimum-diff\nmodification on them via the universal modify-a-sample\nworkflow in\n",{"type":40,"tag":74,"props":1050,"children":1052},{"href":1051},"..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md",[1053],{"type":40,"tag":79,"props":1054,"children":1056},{"className":1055},[],[1057],{"type":45,"value":1058},"doca-programming-guide",{"type":45,"value":1060},",\nlayered with the bridge-specific overrides in\n",{"type":40,"tag":74,"props":1062,"children":1063},{"href":334},[1064],{"type":40,"tag":79,"props":1065,"children":1067},{"className":1066},[],[1068],{"type":45,"value":341},{"type":45,"value":343},{"type":40,"tag":167,"props":1071,"children":1072},{},[1073,1078,1080,1086,1087,1093,1094,1100,1102,1107,1109,1115,1117,1123],{"type":40,"tag":52,"props":1074,"children":1075},{},[1076],{"type":45,"value":1077},"Standalone build manifests",{"type":45,"value":1079}," (",{"type":40,"tag":79,"props":1081,"children":1083},{"className":1082},[],[1084],{"type":45,"value":1085},"meson.build",{"type":45,"value":912},{"type":40,"tag":79,"props":1088,"children":1090},{"className":1089},[],[1091],{"type":45,"value":1092},"CMakeLists.txt",{"type":45,"value":883},{"type":40,"tag":79,"props":1095,"children":1097},{"className":1096},[],[1098],{"type":45,"value":1099},"Cargo.toml",{"type":45,"value":1101},", …) parked inside the skill.\nThe agent constructs the build manifest ",{"type":40,"tag":87,"props":1103,"children":1104},{},[1105],{"type":45,"value":1106},"in the user's project\ndirectory",{"type":45,"value":1108}," against the user's installed DOCA + DPDK, where\n",{"type":40,"tag":79,"props":1110,"children":1112},{"className":1111},[],[1113],{"type":45,"value":1114},"pkg-config --modversion doca-dpdk-bridge",{"type":45,"value":1116}," and\n",{"type":40,"tag":79,"props":1118,"children":1120},{"className":1119},[],[1121],{"type":45,"value":1122},"pkg-config --modversion libdpdk",{"type":45,"value":1124}," are the source of truth.",{"type":40,"tag":167,"props":1126,"children":1127},{},[1128,1156],{"type":40,"tag":52,"props":1129,"children":1130},{},[1131,1133,1139,1140,1146,1148,1154],{"type":45,"value":1132},"A ",{"type":40,"tag":79,"props":1134,"children":1136},{"className":1135},[],[1137],{"type":45,"value":1138},"samples\u002F",{"type":45,"value":883},{"type":40,"tag":79,"props":1141,"children":1143},{"className":1142},[],[1144],{"type":45,"value":1145},"bindings\u002F",{"type":45,"value":1147},", or ",{"type":40,"tag":79,"props":1149,"children":1151},{"className":1150},[],[1152],{"type":45,"value":1153},"reference\u002F",{"type":45,"value":1155}," subtree",{"type":45,"value":1157}," of any\nkind. A mock or incomplete artifact in this skill's tree, even\none labeled \"reference\", is misleading: users will read it as\nbuildable.",{"type":40,"tag":144,"props":1159,"children":1161},{"id":1160},"loading-order",[1162],{"type":45,"value":1163},"Loading order",{"type":40,"tag":1165,"props":1166,"children":1167},"ol",{},[1168,1181,1194],{"type":40,"tag":167,"props":1169,"children":1170},{},[1171,1173,1179],{"type":45,"value":1172},"Read this ",{"type":40,"tag":79,"props":1174,"children":1176},{"className":1175},[],[1177],{"type":45,"value":1178},"SKILL.md",{"type":45,"value":1180}," first to confirm the user's question is\nin scope (existing DPDK app + wants DOCA on top — not fresh).",{"type":40,"tag":167,"props":1182,"children":1183},{},[1184],{"type":40,"tag":52,"props":1185,"children":1186},{},[1187,1189,1193],{"type":45,"value":1188},"For the bridge capability matrix, the bridge-vs-native\nselection rule, port-handover surface, capability-query rules,\nerror taxonomy, observability, and safety policy, see\n",{"type":40,"tag":74,"props":1190,"children":1191},{"href":96},[1192],{"type":45,"value":96},{"type":45,"value":343},{"type":40,"tag":167,"props":1195,"children":1196},{},[1197],{"type":40,"tag":52,"props":1198,"children":1199},{},[1200,1202,1206],{"type":45,"value":1201},"For step-by-step workflows — configure, build, modify, run,\ntest, debug — see ",{"type":40,"tag":74,"props":1203,"children":1204},{"href":76},[1205],{"type":45,"value":76},{"type":45,"value":343},{"type":40,"tag":48,"props":1208,"children":1209},{},[1210,1212,1222,1224,1232,1234,1242,1244,1252],{"type":45,"value":1211},"Both companion files cross-link to each other,\n",{"type":40,"tag":74,"props":1213,"children":1215},{"href":1214},"..\u002F..\u002Fdoca-version\u002FSKILL.md",[1216],{"type":40,"tag":79,"props":1217,"children":1219},{"className":1218},[],[1220],{"type":45,"value":1221},"doca-version",{"type":45,"value":1223}," for the canonical\nDOCA version-handling rules,\n",{"type":40,"tag":74,"props":1225,"children":1226},{"href":133},[1227],{"type":40,"tag":79,"props":1228,"children":1230},{"className":1229},[],[1231],{"type":45,"value":140},{"type":45,"value":1233}," for the start-fresh path that\nis the bridge's deliberate alternative,\n",{"type":40,"tag":74,"props":1235,"children":1236},{"href":746},[1237],{"type":40,"tag":79,"props":1238,"children":1240},{"className":1239},[],[1241],{"type":45,"value":753},{"type":45,"value":1243}," for the steering library\nthat is the most common reason to use this bridge in the first\nplace, and\n",{"type":40,"tag":74,"props":1245,"children":1246},{"href":782},[1247],{"type":40,"tag":79,"props":1248,"children":1250},{"className":1249},[],[1251],{"type":45,"value":789},{"type":45,"value":1253},"\nwhenever the right answer is \"look it up in the public docs or\nthe installed package layout\" rather than \"bridge-specific\nguidance\".",{"type":40,"tag":144,"props":1255,"children":1257},{"id":1256},"related-skills",[1258],{"type":45,"value":1259},"Related skills",{"type":40,"tag":163,"props":1261,"children":1262},{},[1263,1284,1319,1340,1361,1388,1444,1471],{"type":40,"tag":167,"props":1264,"children":1265},{},[1266,1274,1276,1282],{"type":40,"tag":74,"props":1267,"children":1268},{"href":782},[1269],{"type":40,"tag":79,"props":1270,"children":1272},{"className":1271},[],[1273],{"type":45,"value":789},{"type":45,"value":1275}," —\nthe routing table for every public DOCA documentation source\nand the on-disk layout of an installed DOCA package. The\nbridge URL slug is ",{"type":40,"tag":79,"props":1277,"children":1279},{"className":1278},[],[1280],{"type":45,"value":1281},"DOCA-DPDK-Bridge",{"type":45,"value":1283},". Reference applications\nthat pair DPDK + DOCA Flow (the canonical adopters of this\nbridge) are reachable from the same map's reference-\napplications index.",{"type":40,"tag":167,"props":1285,"children":1286},{},[1287,1295,1297,1303,1304,1310,1312,1317],{"type":40,"tag":74,"props":1288,"children":1289},{"href":114},[1290],{"type":40,"tag":79,"props":1291,"children":1293},{"className":1292},[],[1294],{"type":45,"value":121},{"type":45,"value":1296}," — env preparation,\ninstall verification, hugepage mounts (DPDK requirement),\nport-state checks (",{"type":40,"tag":79,"props":1298,"children":1300},{"className":1299},[],[1301],{"type":45,"value":1302},"devlink dev show",{"type":45,"value":883},{"type":40,"tag":79,"props":1305,"children":1307},{"className":1306},[],[1308],{"type":45,"value":1309},"ip link",{"type":45,"value":1311},"), permission\nand group-membership requirements for opening a ",{"type":40,"tag":79,"props":1313,"children":1315},{"className":1314},[],[1316],{"type":45,"value":252},{"type":45,"value":1318},"\nAND for binding PCIe ports under DPDK. This skill assumes its\npreconditions are satisfied.",{"type":40,"tag":167,"props":1320,"children":1321},{},[1322,1330,1332,1338],{"type":40,"tag":74,"props":1323,"children":1324},{"href":1214},[1325],{"type":40,"tag":79,"props":1326,"children":1328},{"className":1327},[],[1329],{"type":45,"value":1221},{"type":45,"value":1331}," — canonical\nDOCA version-handling rules. This skill's ",{"type":40,"tag":79,"props":1333,"children":1335},{"className":1334},[],[1336],{"type":45,"value":1337},"## Version compatibility",{"type":45,"value":1339}," cross-links the four-way match rule and adds\nonly the bridge-specific overlay (DPDK ↔ DOCA matched-pair\ncoupling).",{"type":40,"tag":167,"props":1341,"children":1342},{},[1343,1353,1355,1359],{"type":40,"tag":74,"props":1344,"children":1346},{"href":1345},"..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md",[1347],{"type":40,"tag":79,"props":1348,"children":1350},{"className":1349},[],[1351],{"type":45,"value":1352},"doca-structured-tools-contract",{"type":45,"value":1354}," —\nthe bundle's structured-tools precedence rule (detect \u002F prefer\n\u002F fall back \u002F report). The Command appendix in\n",{"type":40,"tag":74,"props":1356,"children":1357},{"href":76},[1358],{"type":45,"value":76},{"type":45,"value":1360}," honors this contract.",{"type":40,"tag":167,"props":1362,"children":1363},{},[1364,1372,1374,1379,1381,1386],{"type":40,"tag":74,"props":1365,"children":1366},{"href":1051},[1367],{"type":40,"tag":79,"props":1368,"children":1370},{"className":1369},[],[1371],{"type":45,"value":1058},{"type":45,"value":1373}," —\ngeneral DOCA programming patterns shared by every library:\nthe canonical ",{"type":40,"tag":79,"props":1375,"children":1377},{"className":1376},[],[1378],{"type":45,"value":596},{"type":45,"value":1380}," + meson build pattern, the\nuniversal modify-a-shipped-sample first-app workflow, the\nuniversal lifecycle, the cross-library ",{"type":40,"tag":79,"props":1382,"children":1384},{"className":1383},[],[1385],{"type":45,"value":460},{"type":45,"value":1387},"\ntaxonomy, and the program-side debug order. This skill layers\nbridge specifics on top.",{"type":40,"tag":167,"props":1389,"children":1390},{},[1391,1399,1401,1406,1408,1414,1415,1421,1423,1428,1430,1435,1437,1442],{"type":40,"tag":74,"props":1392,"children":1393},{"href":133},[1394],{"type":40,"tag":79,"props":1395,"children":1397},{"className":1396},[],[1398],{"type":45,"value":140},{"type":45,"value":1400}," — the ",{"type":40,"tag":52,"props":1402,"children":1403},{},[1404],{"type":45,"value":1405},"alternative path",{"type":45,"value":1407},"\nfor users starting fresh: pure DOCA-native queue I\u002FO via\n",{"type":40,"tag":79,"props":1409,"children":1411},{"className":1410},[],[1412],{"type":45,"value":1413},"doca_eth_rxq",{"type":45,"value":262},{"type":40,"tag":79,"props":1416,"children":1418},{"className":1417},[],[1419],{"type":45,"value":1420},"doca_eth_txq",{"type":45,"value":1422}," with no DPDK in the picture.\nThe bridge exists ",{"type":40,"tag":87,"props":1424,"children":1425},{},[1426],{"type":45,"value":1427},"because",{"type":45,"value":1429}," migrating an existing DPDK app to\n",{"type":40,"tag":79,"props":1431,"children":1433},{"className":1432},[],[1434],{"type":45,"value":140},{"type":45,"value":1436}," is often the wrong tradeoff; for a new project\nwith no DPDK lock-in, ",{"type":40,"tag":79,"props":1438,"children":1440},{"className":1439},[],[1441],{"type":45,"value":140},{"type":45,"value":1443}," is the right choice.",{"type":40,"tag":167,"props":1445,"children":1446},{},[1447,1455,1457,1462,1464,1469],{"type":40,"tag":74,"props":1448,"children":1449},{"href":746},[1450],{"type":40,"tag":79,"props":1451,"children":1453},{"className":1452},[],[1454],{"type":45,"value":753},{"type":45,"value":1456}," — the steering library\nthat is the most common reason a DPDK app reaches for this\nbridge. The bridge binds a DPDK port id to a ",{"type":40,"tag":79,"props":1458,"children":1460},{"className":1459},[],[1461],{"type":45,"value":252},{"type":45,"value":1463},";\nDOCA Flow programs steering rules onto that ",{"type":40,"tag":79,"props":1465,"children":1467},{"className":1466},[],[1468],{"type":45,"value":252},{"type":45,"value":1470},". The two\nlibraries are designed to compose.",{"type":40,"tag":167,"props":1472,"children":1473},{},[1474,1482],{"type":40,"tag":74,"props":1475,"children":1476},{"href":510},[1477],{"type":40,"tag":79,"props":1478,"children":1480},{"className":1479},[],[1481],{"type":45,"value":517},{"type":45,"value":1483}," — the cross-cutting\ndebug ladder (install \u002F version \u002F build \u002F link \u002F runtime \u002F\nprogram \u002F driver). Bridge-specific debug (DPDK ↔ DOCA version\ndrift, port-not-registered symptoms, mbuf-conversion failures)\noverlays on top of that ladder.",{"items":1485,"total":1644},[1486,1504,1522,1533,1545,1559,1572,1586,1599,1610,1624,1633],{"slug":1487,"name":1487,"fn":1488,"description":1489,"org":1490,"tags":1491,"stars":1501,"repoUrl":1502,"updatedAt":1503},"nemoclaw-user-guide","retrieve NemoClaw documentation and configuration","Guides human users' AI agents to the NemoClaw docs MCP server and canonical Fern documentation in Markdown form. Use when users ask how to install, configure, operate, troubleshoot, secure, or learn NemoClaw with an AI coding assistant. Trigger keywords - nemoclaw docs, use nemoclaw with ai agent, nemoclaw mcp docs, nemoclaw install help, nemoclaw quickstart, nemoclaw markdown docs, llms.txt, agent skills.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1492,1495,1498],{"name":1493,"slug":1494,"type":15},"Documentation","documentation",{"name":1496,"slug":1497,"type":15},"MCP","mcp",{"name":1499,"slug":1500,"type":15},"Search","search",21777,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FNemoClaw","2026-07-20T06:00:01.461044",{"slug":1505,"name":1505,"fn":1506,"description":1507,"org":1508,"tags":1509,"stars":1519,"repoUrl":1520,"updatedAt":1521},"mcore-build-and-dependency","manage Megatron-LM development environments","Container-based dev environment setup and dependency management for Megatron-LM. Covers acquiring and launching the CI container, uv package management, and updating uv.lock.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1510,1513,1516],{"name":1511,"slug":1512,"type":15},"Containers","containers",{"name":1514,"slug":1515,"type":15},"Deployment","deployment",{"name":1517,"slug":1518,"type":15},"Python","python",17049,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FMegatron-LM","2026-07-27T06:06:11.249662",{"slug":1523,"name":1523,"fn":1524,"description":1525,"org":1526,"tags":1527,"stars":1519,"repoUrl":1520,"updatedAt":1532},"mcore-bump-base-image","update NVIDIA PyTorch base images","Bump the NVIDIA PyTorch base image (`nvcr.io\u002Fnvidia\u002Fpytorch:YY.MM-py3`) used by Megatron-LM CI. Covers the two pin sites (GitHub CI in `docker\u002F.ngc_version.dev` and GitLab CI in `.gitlab\u002Fstages\u002F01.build.yml`), the post-bump CI loop (re-run functional tests, refresh golden values, mark broken tests), and the gotchas that bit PRs",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1528,1531],{"name":1529,"slug":1530,"type":15},"CI\u002FCD","ci-cd",{"name":1514,"slug":1515,"type":15},"2026-07-14T05:25:59.97109",{"slug":1534,"name":1534,"fn":1535,"description":1536,"org":1537,"tags":1538,"stars":1519,"repoUrl":1520,"updatedAt":1544},"mcore-cicd","manage CI\u002FCD pipelines for Megatron-LM","CI\u002FCD reference for Megatron-LM. Covers CI pipeline structure, PR scope labels, triggering internal GitLab CI (which force-pushes the current branch to a pull-request\u002FBRANCH ref — always dry-run and verify the destination first; never run against shared or protected branches), and CI failure investigation.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1539,1540,1541],{"name":1529,"slug":1530,"type":15},{"name":1514,"slug":1515,"type":15},{"name":1542,"slug":1543,"type":15},"GitHub","github","2026-07-27T06:06:12.278222",{"slug":1546,"name":1546,"fn":1547,"description":1548,"org":1549,"tags":1550,"stars":1519,"repoUrl":1520,"updatedAt":1558},"mcore-create-issue","investigate CI failures and create issues","Investigate a failing GitHub Actions run or job and create a GitHub issue for the failure.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1551,1554,1555],{"name":1552,"slug":1553,"type":15},"Debugging","debugging",{"name":1542,"slug":1543,"type":15},{"name":1556,"slug":1557,"type":15},"Triage","triage","2026-07-14T05:25:57.442089",{"slug":1560,"name":1560,"fn":1561,"description":1562,"org":1563,"tags":1564,"stars":1519,"repoUrl":1520,"updatedAt":1571},"mcore-linting-and-formatting","lint and format Megatron-LM code","Linting and formatting for Megatron-LM. Covers running autoformat.sh, tools (ruff, black, isort, pylint, mypy), and code style rules.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1565,1568],{"name":1566,"slug":1567,"type":15},"Best Practices","best-practices",{"name":1569,"slug":1570,"type":15},"Code Analysis","code-analysis","2026-07-14T05:25:56.18433",{"slug":1573,"name":1573,"fn":1574,"description":1575,"org":1576,"tags":1577,"stars":1519,"repoUrl":1520,"updatedAt":1585},"mcore-migrate-gpt-to-hybrid","migrate Megatron-LM models to HybridModel","Migration guide for moving Megatron Core GPTModel checkpoints, model providers, training commands, and layer mappings to HybridModel.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1578,1581,1584],{"name":1579,"slug":1580,"type":15},"Machine Learning","machine-learning",{"name":1582,"slug":1583,"type":15},"Migration","migration",{"name":9,"slug":8,"type":15},"2026-07-17T06:07:11.777011",{"slug":1587,"name":1587,"fn":1588,"description":1589,"org":1590,"tags":1591,"stars":1519,"repoUrl":1520,"updatedAt":1598},"mcore-onboard-gb200-1node-tests","onboard functional tests for GB200","Onboard 1-node GitHub MR functional tests for GB200 from existing mr-scoped 2-node tests.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1592,1595],{"name":1593,"slug":1594,"type":15},"QA","qa",{"name":1596,"slug":1597,"type":15},"Testing","testing","2026-07-14T05:25:53.673039",{"slug":1600,"name":1600,"fn":1601,"description":1602,"org":1603,"tags":1604,"stars":1519,"repoUrl":1520,"updatedAt":1609},"mcore-run-on-slurm","launch distributed training jobs on SLURM","How to launch distributed Megatron-LM training jobs on a SLURM cluster. Covers a minimal sbatch skeleton, environment-variable setup for torch.distributed.run, CUDA_DEVICE_MAX_CONNECTIONS rules across hardware and parallelism modes, container conventions, monitoring, and per-rank failure diagnosis.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1605,1606],{"name":1514,"slug":1515,"type":15},{"name":1607,"slug":1608,"type":15},"Infrastructure","infrastructure","2026-07-14T05:25:49.362534",{"slug":1611,"name":1611,"fn":1612,"description":1613,"org":1614,"tags":1615,"stars":1519,"repoUrl":1520,"updatedAt":1623},"mcore-split-pr","split pull requests to reduce review load","Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1616,1619,1620],{"name":1617,"slug":1618,"type":15},"Code Review","code-review",{"name":1542,"slug":1543,"type":15},{"name":1621,"slug":1622,"type":15},"Pull Requests","pull-requests","2026-07-14T05:26:01.226578",{"slug":1625,"name":1625,"fn":1626,"description":1627,"org":1628,"tags":1629,"stars":1519,"repoUrl":1520,"updatedAt":1632},"mcore-testing","run and manage Megatron-LM tests","Test system for Megatron-LM. Covers test layout, recipe YAML structure, adding and running unit and functional tests, golden values, marker filters, and CI parity.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1630,1631],{"name":1593,"slug":1594,"type":15},{"name":1596,"slug":1597,"type":15},"2026-07-14T05:25:54.928983",{"slug":1634,"name":1634,"fn":1635,"description":1636,"org":1637,"tags":1638,"stars":1519,"repoUrl":1520,"updatedAt":1643},"nightly-sync","manage nightly main-to-dev sync workflows","Domain knowledge for the nightly main-to-dev sync workflow. Covers merge strategy, CI architecture, failure investigation, and known issues.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1639,1642],{"name":1640,"slug":1641,"type":15},"Automation","automation",{"name":1529,"slug":1530,"type":15},"2026-07-30T05:29:03.275638",496,{"items":1646,"total":1742},[1647,1664,1674,1688,1698,1713,1728],{"slug":1648,"name":1648,"fn":1649,"description":1650,"org":1651,"tags":1652,"stars":20,"repoUrl":21,"updatedAt":1663},"accelerated-computing-cudf","accelerate data processing with cuDF","Official NVIDIA-authored guidance for NVIDIA cuDF GPU DataFrames, pandas acceleration, dask-cuDF, ETL, joins, groupby, CSV\u002FParquet I\u002FO, nullable semantics, and multi-GPU DataFrame workloads.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1653,1656,1659,1660],{"name":1654,"slug":1655,"type":15},"Data Analysis","data-analysis",{"name":1657,"slug":1658,"type":15},"Data Engineering","data-engineering",{"name":9,"slug":8,"type":15},{"name":1661,"slug":1662,"type":15},"Performance","performance","2026-07-14T05:28:43.176466",{"slug":1665,"name":1665,"fn":1666,"description":1667,"org":1668,"tags":1669,"stars":20,"repoUrl":21,"updatedAt":1673},"aiq-deploy","deploy and manage NVIDIA AI-Q infrastructure","Use when asked to install, deploy, run, validate, troubleshoot, or stop NVIDIA AI-Q Blueprint infrastructure.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1670,1671,1672],{"name":1514,"slug":1515,"type":15},{"name":1607,"slug":1608,"type":15},{"name":9,"slug":8,"type":15},"2026-07-14T05:29:06.667109",{"slug":1675,"name":1675,"fn":1676,"description":1677,"org":1678,"tags":1679,"stars":20,"repoUrl":21,"updatedAt":1687},"aiq-research","conduct deep research with AI-Q","Use when asked to run deep research or AI-Q research through a reachable NVIDIA AI-Q Blueprint backend.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1680,1683,1684],{"name":1681,"slug":1682,"type":15},"Agents","agents",{"name":9,"slug":8,"type":15},{"name":1685,"slug":1686,"type":15},"Research","research","2026-07-14T05:28:06.816956",{"slug":1689,"name":1689,"fn":1690,"description":1691,"org":1692,"tags":1693,"stars":20,"repoUrl":21,"updatedAt":1697},"amc-run-sample-calibration","run AMC sample dataset calibration","Run end-to-end calibration on the shipped sample dataset (sdg_08_2_sample_data_010926.zip) against a running AMC microservice. Use when user says 'test sample dataset', 'run sample calibration', 'verify AMC install', or 'launch and test'.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1694,1695,1696],{"name":1654,"slug":1655,"type":15},{"name":9,"slug":8,"type":15},{"name":1596,"slug":1597,"type":15},"2026-07-17T05:29:03.913266",{"slug":1699,"name":1699,"fn":1700,"description":1701,"org":1702,"tags":1703,"stars":20,"repoUrl":21,"updatedAt":1712},"amc-run-video-calibration","calibrate video datasets with AutoMagicCalib","Calibrate a new dataset from pre-recorded video files via the AutoMagicCalib REST API. Use when user has local MP4s and says 'calibrate my videos', 'run AMC on these videos', or similar. For RTSP\u002Flive streams, use amc-run-rtsp-calibration instead.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1704,1705,1708,1709],{"name":1640,"slug":1641,"type":15},{"name":1706,"slug":1707,"type":15},"Imaging","imaging",{"name":9,"slug":8,"type":15},{"name":1710,"slug":1711,"type":15},"Video","video","2026-07-17T05:28:53.905004",{"slug":1714,"name":1714,"fn":1715,"description":1716,"org":1717,"tags":1718,"stars":20,"repoUrl":21,"updatedAt":1727},"amc-setup-calibration-stack","deploy AutoMagicCalib microservice with Docker","Launch AutoMagicCalib microservice and web UI from NGC release images via Docker Compose. Use when user says 'deploy auto calibration', 'launch auto calibration', 'launch AMC', 'start MS+UI', or 'set up auto-magic-calib'. Requires NGC API key.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1719,1720,1723,1724],{"name":1514,"slug":1515,"type":15},{"name":1721,"slug":1722,"type":15},"Docker","docker",{"name":9,"slug":8,"type":15},{"name":1725,"slug":1726,"type":15},"Operations","operations","2026-07-17T05:28:56.913999",{"slug":1729,"name":1729,"fn":1730,"description":1731,"org":1732,"tags":1733,"stars":20,"repoUrl":21,"updatedAt":1741},"cudaq-guide","develop quantum applications with CUDA-Q","CUDA-Q onboarding guide for installation, test programs, GPU simulation, QPU hardware, and quantum applications.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":9},[1734,1735,1738],{"name":9,"slug":8,"type":15},{"name":1736,"slug":1737,"type":15},"Quantum Computing","quantum-computing",{"name":1739,"slug":1740,"type":15},"Simulation","simulation","2026-07-14T05:26:58.898253",305]