[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-nvidia-doca-dpa":3,"mdc-67xhuv-key":31,"related-repo-nvidia-doca-dpa":1795,"related-org-nvidia-doca-dpa":1901},{"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-dpa","program NVIDIA BlueField DPA host-side applications","Use this skill when the user is doing hands-on DOCA DPA host-side work on a BlueField — creating the `doca_dpa` Core context, loading a DPACC-compiled DPA app image (`doca_dpa_app`), creating DPA threads, launching kernels via `doca_dpa_kernel_launch_update_*`, draining `doca_dpa_completion`, running `doca_dpa_cap_*` discovery, choosing between the DPA comm component (inter-DPA messaging) and the DPA verbs component (in-kernel RDMA), or debugging `DOCA_ERROR_*` from `doca_dpa_*`. Trigger even without \"DOCA DPA\" or \"Data-Path Accelerator\": \"run compute on the DPA from my host\", \"DPA kernel hangs, no completion\", \"DOCA_ERROR_DRIVER on launch\", \"DOCA\u002FDPACC version skew\", or \"does this BlueField expose a DPA\". Route elsewhere for DPA-side kernel programming itself, DPACC compiler internals, host↔DPU messaging (doca-comch), host-side RDMA (doca-rdma), and GPU-initiated networking (doca-gpunetio).\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},"Hardware","hardware","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:28.459015","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-dpa","---\nlicense: Apache-2.0\nname: doca-dpa\ndescription: >\n  Use this skill when the user is doing hands-on DOCA DPA host-side\n  work on a BlueField — creating the `doca_dpa` Core context, loading\n  a DPACC-compiled DPA app image (`doca_dpa_app`), creating DPA\n  threads, launching kernels via `doca_dpa_kernel_launch_update_*`,\n  draining `doca_dpa_completion`, running `doca_dpa_cap_*` discovery,\n  choosing between the DPA comm component (inter-DPA messaging) and the\n  DPA verbs component (in-kernel RDMA), or debugging `DOCA_ERROR_*`\n  from `doca_dpa_*`. Trigger even without \"DOCA DPA\" or \"Data-Path\n  Accelerator\": \"run compute on the DPA from my host\", \"DPA kernel\n  hangs, no completion\", \"DOCA_ERROR_DRIVER on launch\", \"DOCA\u002FDPACC\n  version skew\", or \"does this BlueField expose a DPA\". Route elsewhere\n  for DPA-side kernel programming itself, DPACC compiler internals,\n  host↔DPU messaging (doca-comch), host-side RDMA (doca-rdma), and\n  GPU-initiated networking (doca-gpunetio).\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 whose\n  generation exposes the DPA processor to the host, plus the\n  matching DPACC compiler at a version listed compatible by\n  the DOCA Compatibility Policy. Reads `pkg-config --modversion\n  doca-dpa` and the installed `dpacc` version, and inspects\n  \u002Fopt\u002Fmellanox\u002Fdoca\u002F{lib,include,samples\u002Fdoca_dpa,applications}.\n---\n\n# DOCA DPA\n\n**Where to start:** This skill assumes DOCA is already installed,\nthe user's BlueField has a DPA processor and the host can see it\nthrough DOCA, and the user is doing **hands-on DPA work from the\nhost side** — i.e. using `doca-dpa` to load a DPA application\nimage, launch DPA kernels, and exchange data with the DPA\nprocessor. Open [`TASKS.md`](TASKS.md) if the user wants to *do*\nsomething (configure \u002F build \u002F modify \u002F run \u002F test \u002F debug); open\n[`CAPABILITIES.md`](CAPABILITIES.md) when the question is *what\ncan the host-side DPA API express* on this version + this\nBlueField generation. If the user has not installed DOCA yet,\nroute to [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) first; if the\nuser is asking how to *write* the DPA-side kernel itself (the\ncode that runs on the DPA processor, compiled by `dpacc`), that\nis a different scope — route via\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\nto the public DOCA DPA \u002F DPACC \u002F DPA-Comms \u002F DPA-Verbs guides\n(this skill does not redefine those DPA-side surfaces).\n\n## Example questions this skill answers well\n\nThe CLASSES of DPA questions this skill is built to answer, each\nwith one worked example. The agent should treat the *class* as\nthe load-bearing piece — the worked example is a single\ninstance.\n\n- **\"How do I run a piece of compute on the DPA processor from\n  my host program?\"** — worked example: *\"load a DPA kernel that\n  counts events in a loop and reports the count back to the\n  host\"*. Answered by the two-side-program model + the\n  host-side launch workflow in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the bring-up steps in\n  [`TASKS.md ## configure`](TASKS.md#configure).\n- **\"Does this BlueField even have a DPA, and which DPA features\n  does my DOCA install expose?\"** — worked example: *\"my host\n  has a BlueField; can I use the DPA on it for a programmable\n  control workload?\"*. Answered by the dual-axis capability rule\n  (BlueField-generation axis via `doca_dpa_cap_*` against the\n  active `doca_devinfo` plus the DOCA-install axis via\n  `pkg-config --modversion doca-dpa`) in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the device-enumeration step in\n  [`TASKS.md ## configure`](TASKS.md#configure).\n- **\"Why does my host-side DPA setup fail with\n  `DOCA_ERROR_NOT_SUPPORTED` even though DOCA Core looks\n  healthy?\"** — worked example: *\"the BlueField generation in\n  this host predates the DPA feature my code uses\"*. Answered by\n  the env-precondition matrix in\n  [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy)\n  + the env checklist in\n  [`TASKS.md ## configure`](TASKS.md#configure) step 1.\n- **\"How do I get arguments and results between my host program\n  and my DPA kernel?\"** — worked example: *\"pass a buffer pointer\n  and a length into the DPA kernel as launch arguments; read a\n  completion back when the kernel finishes\"*. Answered by the\n  launch-argument + completion overlay in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the launch + drain steps in\n  [`TASKS.md ## run`](TASKS.md#run).\n- **\"Is the DPA host-side API I'm reading about on my installed\n  DOCA?\"** — worked example: *\"is the host-side launch helper I\n  see in the docs available against the DOCA + DPACC versions on\n  this host?\"*. Answered by the version-compatibility overlay in\n  [`CAPABILITIES.md ## Version compatibility`](CAPABILITIES.md#version-compatibility)\n  which cross-links the canonical detection chain in\n  [`doca-version`](..\u002F..\u002Fdoca-version\u002FSKILL.md) and adds the\n  DPA-specific *DOCA must match DPACC* overlay.\n- **\"What does this `DOCA_ERROR_*` from a `doca_dpa_*` call mean\n  and which layer caused it?\"** — worked example: *\"`DOCA_ERROR_DRIVER`\n  on a host-side launch call — is it DOCA, the DPACC-produced\n  image, or the DPA processor itself?\"*. Answered by the DPA\n  overlay on the cross-library 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- **\"How does my DPA kernel send a small message to another\n  DPA thread on the same DPA processor?\"** — worked example:\n  *\"two DPA threads in the same loaded `doca_dpa_app`; thread A\n  sends a counter value to thread B over a DPA-side comms\n  endpoint and thread B signals the host through\n  `doca_dpa_completion`\"*. Answered by the DPA-Comms routing\n  rule, primitive families, host-side capability-budget rule,\n  and DPA-Comms error overlay in\n  [`CAPABILITIES.md ## comms`](CAPABILITIES.md#comms) plus the\n  configure \u002F build \u002F modify \u002F run \u002F test \u002F debug overlay in\n  [`TASKS.md ## comms`](TASKS.md#comms). Disambiguates the DPA\n  device-side comm component from host-side `doca-comch` and\n  host-side `doca-rdma`.\n- **\"How do I do RDMA directly from inside my DPA kernel to a\n  remote peer, without round-tripping to the host?\"** — worked\n  example: *\"my DPA kernel needs to fetch the next 4 KiB input\n  buffer from a remote node via RDMA read before continuing\n  compute; the host round-trip is the measured bottleneck\"*.\n  Answered by the 4-way RDMA matrix, the host-configures-QP \u002F\n  DPA-uses-QP coupling rule, the host-side cap-query rule for\n  the specific verb, and the DPA-Verbs error overlay in\n  [`CAPABILITIES.md ## verbs`](CAPABILITIES.md#verbs) plus the\n  workflow overlay in [`TASKS.md ## verbs`](TASKS.md#verbs).\n  Includes the climb-back rule for when the latency-tuning\n  premise stops holding.\n\n## Audience\n\nThis skill serves **external developers building applications\nthat consume the DOCA DPA library from the host side** — i.e.,\nusers whose code calls `doca_dpa_*` from host C \u002F C++ to stand\nup the per-DPA-instance context, load a DPA application image\nthat `dpacc` produced from their DPA-side source, create one or\nmore DPA threads, launch DPA kernels with arguments, and drain\ncompletions. It is *not* for NVIDIA developers contributing to\nDOCA DPA itself, nor is it the place to learn how to *write*\nthe DPA-side kernel code (that path goes through the public\nDOCA DPA, DPACC, DPA-Comms, and DPA-Verbs guides via\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)).\n\n**Language scope.** DOCA DPA ships as a host-side C library\nwith `pkg-config` module name `doca-dpa`. The host-side API is\nC; the DPA-side kernel is a separate translation unit written\nin the language the DPACC compiler accepts and compiled by\n`dpacc` into a binary that the host packages into the\nexecutable as the DPA application image. The shipped samples\nunder `\u002Fopt\u002Fmellanox\u002Fdoca\u002Fsamples\u002Fdoca_dpa\u002F` are written in C\nplus DPA-side source (NVIDIA's choice). Other-language\nconsumers are limited in practice — the DPA-side kernel has no\nFFI escape hatch because it must be a translation unit `dpacc`\naccepts — but a Rust \u002F Go \u002F Python host-side wrapper that drives\n`doca_dpa_*` setup and launches a DPA kernel image built\nseparately is still useful, and the skill keeps the lifecycle,\ncapability-discovery, env-precondition, and error-taxonomy\nguidance language-neutral.\n\n## When to load this skill\n\nLoad this skill when the user is doing hands-on DOCA DPA work\n**from the host side**, in any host language plus a DPA-side\ntranslation unit built by `dpacc`. Concretely:\n\n- Initializing a `doca_dpa` against a `doca_dev` that maps to a\n  BlueField with a DPA processor visible to the host.\n- Loading a DPA application image (`doca_dpa_app`) that\n  `dpacc` produced from the user's DPA-side source, into the\n  `doca_dpa` context.\n- Creating one or more DPA execution contexts (`doca_dpa_thread`)\n  so DPA kernels have somewhere to run on the DPA processor.\n- Launching a DPA kernel function with arguments from the host\n  via the `doca_dpa_kernel_launch_update_*` family, and\n  reasoning about which argument shape is supported on this\n  install.\n- Attaching a `doca_dpa_completion` to observe when async DPA\n  work finishes, and draining it from the host side.\n- Checking which DPA features are supported on the active\n  `doca_devinfo` via the `doca_dpa_cap_*` family — BlueField\n  generations differ in DPA hardware support.\n- Debugging a `DOCA_ERROR_*` returned from a `doca_dpa_*` call\n  — in particular disambiguating *DPA not present on this\n  BlueField* from *DPA feature too new for this hardware\n  generation* from *DPACC-produced image mismatched against\n  the host-side DOCA install* from *DPA driver layer\n  reporting failure*.\n- Designing host-side bindings in a non-C language that drive\n  a DPA application image they built separately with `dpacc` —\n  the env-precondition and capability-discovery rules in this\n  skill still apply.\n- Writing DPA-side kernel code that calls the DPA device-side\n  comm component **`libdoca_dpa_dev_comm.a`** (header\n  `doca_dpa_dev_comch_msgq.h`) — for inter-DPA-thread\n  messaging or coordination signals between DPA threads on the\n  same `doca_dpa_app`. The DPA-Comms routing rule, primitive\n  families, capability rule (there is no per-primitive host\n  cap-query family — host-side DPA discovery is only\n  `doca_dpa_cap_is_supported` \u002F\n  `doca_dpa_cap_get_max_kernel_time_alive_supported`), error\n  overlay (`_AGAIN` → kernel must yield; `_BAD_STATE`\n  disambiguation from the parent's host-side `_BAD_STATE`), and\n  the configure \u002F build \u002F modify \u002F run \u002F test \u002F debug overlay\n  live in [`CAPABILITIES.md ## comms`](CAPABILITIES.md#comms) and\n  [`TASKS.md ## comms`](TASKS.md#comms) under this same skill.\n- Writing DPA-side kernel code that calls the DPA device-side\n  verbs component **`libdoca_dpa_dev_verbs.a`** (header\n  `doca_dpa_dev_verbs.h`) — for RDMA from inside\n  the DPA kernel to a remote peer when the host round-trip is\n  the measured latency bottleneck. The 4-way RDMA matrix, the\n  host-configures-QP \u002F DPA-uses-QP coupling rule, the\n  capability rule (no per-verb host cap-query family exists;\n  verb availability follows the BlueField generation + matched\n  DOCA\u002FDPACC install, read from `doca_dpa_dev_verbs.h` and the\n  shipped sample), the IO_FAILED → CQE-inspection\n  overlay, and the climb-back rule live in\n  [`CAPABILITIES.md ## verbs`](CAPABILITIES.md#verbs) and\n  [`TASKS.md ## verbs`](TASKS.md#verbs) under this same skill.\n\nDo **not** load this skill for general DOCA orientation,\ninstall of DOCA or the DPACC compiler, the DPA-side\n  programming model itself (how to write a DPA kernel; the\n  DPA device-side comm and verbs components\n  (`libdoca_dpa_dev_comm.a` \u002F `libdoca_dpa_dev_verbs.a`) that\n  run *inside* the DPA kernel), or non-DPA library questions.\nFor those, route through\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\nto the matching upstream guide.\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\nDPA-specific material lives in two companion files:\n\n- `CAPABILITIES.md` — what the host-side DPA API can express on\n  this version + this BlueField generation: the per-DPA-instance\n  `doca_dpa` context, the loaded `doca_dpa_app` image produced\n  by `dpacc`, the `doca_dpa_thread` execution context, the\n  host-initiated kernel launch surface\n  (`doca_dpa_kernel_launch_update_*`), the `doca_dpa_completion`\n  mechanism, the capability-query surface (`doca_dpa_cap_*`),\n  the DPA error taxonomy mapped onto the cross-library\n  `DOCA_ERROR_*` set, the observability surface (host-side\n  completions plus the public DPA developer tools surface\n  reachable via `doca-public-knowledge-map`), and the safety\n  policy that gates env preconditions (DPA-capable BlueField,\n  matched DOCA + DPACC versions, DPA-side image and host-side\n  expected entry points agree).\n- `TASKS.md` — step-by-step workflows for the six in-scope DPA\n  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.\n\nThe skill assumes a host where DOCA is already installed at\nthe standard location, a BlueField with a DPA processor is\nphysically present and visible to the host, the DPACC compiler\nis installed at a version matched to the DOCA install per the\nDOCA Compatibility Policy, and the user already knows how (at\nleast at a sketch level) to write the DPA-side kernel that\n`dpacc` will compile. It does not cover installing DOCA or the\nDPACC compiler — that path goes through\n[`doca-setup`](..\u002F..\u002Fdoca-setup\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 DPA application source code or DPA-side\n  kernel source, in any language.** The verified DPA source is\n  the shipped C + DPA-side samples at\n  `\u002Fopt\u002Fmellanox\u002Fdoca\u002Fsamples\u002Fdoca_dpa\u002F`. 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 DPA-specific overrides in\n  [`TASKS.md ## modify`](TASKS.md#modify).\n- **Standalone build manifests** (`meson.build`,\n  `CMakeLists.txt`, …) parked inside the skill. The agent\n  constructs the build manifest *in the user's project\n  directory* against the user's installed DOCA + DPACC\n  compiler, where `pkg-config --modversion doca-dpa` and the\n  installed `dpacc` are the two sources 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,\n  even one labeled \"reference\", is misleading: users will read\n  it as buildable.\n- **DPA device-side content for the comm \u002F verbs components\n  (`libdoca_dpa_dev_comm.a` \u002F `libdoca_dpa_dev_verbs.a`).**\n  These are *DPA-side* archives shipped as part of `doca-dpa`\n  (NOT separate pkg-config modules): their symbols are called\n  from inside the DPA kernel and linked into the DPA image by\n  `dpacc`, not from the host. Their public guides are reachable\n  via\n  [`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md).\n  This skill names them and routes; it does not redefine them.\n\n## Loading order\n\n1. Read this `SKILL.md` first to confirm the user's question is\n   in scope (host-side DPA work, not DPA-side kernel-writing).\n2. **For the DPA capability matrix, the `doca_dpa` per-instance\n   context, the loaded `doca_dpa_app` image, the\n   `doca_dpa_thread` execution context, the kernel-launch +\n   completion model, the dual capability query, the\n   env-precondition policy, the error taxonomy, the\n   observability surface, and the safety policy, see\n   [CAPABILITIES.md](CAPABILITIES.md).**\n3. **For step-by-step workflows — configure, build, modify,\n   run, 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 (with the DPA overlay that DOCA\nmust match the DPACC compiler), and\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\nwhenever the right answer is \"look it up in the public DOCA\nDPA, DPACC, DPA-Comms, or DPA-Verbs guide, or in the on-disk\ninstall layout\" rather than \"DPA host-side-specific guidance\".\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\n  source and the on-disk layout of an installed DOCA package.\n  The DPA public guide is at\n  \u003Chttps:\u002F\u002Fdocs.nvidia.com\u002Fdoca\u002Fsdk\u002FDOCA-DPA\u002Findex.html>; the\n  DPACC compiler guide, the DPA-Comms guide (DPA-side\n  communications), the DPA-Verbs guide (DPA-side verbs), and\n  the DPA Tools umbrella (developer \u002F admin CLIs for DPA)\n  live in the same routing table and are *companion surfaces*\n  to this skill rather than redefined by it.\n- [`doca-setup`](..\u002F..\u002Fdoca-setup\u002FSKILL.md) — env preparation,\n  install verification, DPACC compiler install \u002F verification,\n  and the *I have no install yet* path with the public NGC\n  DOCA container. This skill assumes its preconditions are\n  satisfied AND that DPACC is installed at a version that\n  matches DOCA.\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  the DPA-specific *DOCA-and-DPACC must match* overlay per the\n  DOCA Compatibility Policy.\n- [`doca-structured-tools-contract`](..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md) —\n  the bundle's structured-tools precedence rule (detect \u002F\n  prefer \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 Core-context lifecycle, the cross-library\n  `DOCA_ERROR_*` taxonomy, and the program-side debug order.\n  This skill layers DPA specifics on top.\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). DPA-specific debug (DPACC + DOCA version\n  skew, DPA not present on this BlueField generation, DPA\n  kernel hangs that show no host-side completion,\n  launch-argument shape mismatches between the host launch\n  call and the DPA-side function signature) overlays on top\n  of that ladder.\n\nDOCA DPA's DPA device-side components — the comm archive\n`libdoca_dpa_dev_comm.a` (communication primitives the DPA\nkernel itself calls, header `doca_dpa_dev_comch_msgq.h`) and\nthe verbs archive `libdoca_dpa_dev_verbs.a` (ibverbs-like RDMA\nverbs the DPA kernel itself calls, header\n`doca_dpa_dev_verbs.h`) — are **DPA-side archives shipped\nwithin `doca-dpa`**, not separate pkg-config modules, and each\nhas its own public guide. No library skill ships for them in\nthis bundle yet; for any DPA-side question, route via\n[`doca-public-knowledge-map`](..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md)\nto the public *DOCA DPA Comms* and *DOCA DPA Verbs* guides\nand to the shipped `\u002Fopt\u002Fmellanox\u002Fdoca\u002Fsamples\u002Fdoca_dpa\u002F`\nsamples (which include both host-side and DPA-side\ntranslation units). Conflating them with `doca-dpa` is the\nsingle most common DPA first-app design error.\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 whose generation exposes the DPA processor to the host, plus the matching DPACC compiler at a version listed compatible by the DOCA Compatibility Policy. Reads `pkg-config --modversion doca-dpa` and the installed `dpacc` version, and inspects \u002Fopt\u002Fmellanox\u002Fdoca\u002F{lib,include,samples\u002Fdoca_dpa,applications}.\n",{"type":37,"children":38},"root",[39,47,151,158,170,622,628,677,731,737,756,1057,1099,1105,1117,1256,1277,1283,1295,1470,1476,1540,1565,1571,1712],{"type":40,"tag":41,"props":42,"children":43},"element","h1",{"id":4},[44],{"type":45,"value":46},"text","DOCA DPA",{"type":40,"tag":48,"props":49,"children":50},"p",{},[51,57,59,64,66,72,74,84,86,92,94,103,105,110,112,122,124,129,131,137,139,149],{"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,\nthe user's BlueField has a DPA processor and the host can see it\nthrough DOCA, and the user is doing ",{"type":40,"tag":52,"props":60,"children":61},{},[62],{"type":45,"value":63},"hands-on DPA work from the\nhost side",{"type":45,"value":65}," — i.e. using ",{"type":40,"tag":67,"props":68,"children":70},"code",{"className":69},[],[71],{"type":45,"value":4},{"type":45,"value":73}," to load a DPA application\nimage, launch DPA kernels, and exchange data with the DPA\nprocessor. Open ",{"type":40,"tag":75,"props":76,"children":78},"a",{"href":77},"TASKS.md",[79],{"type":40,"tag":67,"props":80,"children":82},{"className":81},[],[83],{"type":45,"value":77},{"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},"\nsomething (configure \u002F build \u002F modify \u002F run \u002F test \u002F debug); open\n",{"type":40,"tag":75,"props":95,"children":97},{"href":96},"CAPABILITIES.md",[98],{"type":40,"tag":67,"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\ncan the host-side DPA API express",{"type":45,"value":111}," on this version + this\nBlueField generation. If the user has not installed DOCA yet,\nroute to ",{"type":40,"tag":75,"props":113,"children":115},{"href":114},"..\u002F..\u002Fdoca-setup\u002FSKILL.md",[116],{"type":40,"tag":67,"props":117,"children":119},{"className":118},[],[120],{"type":45,"value":121},"doca-setup",{"type":45,"value":123}," first; if the\nuser is asking how to ",{"type":40,"tag":87,"props":125,"children":126},{},[127],{"type":45,"value":128},"write",{"type":45,"value":130}," the DPA-side kernel itself (the\ncode that runs on the DPA processor, compiled by ",{"type":40,"tag":67,"props":132,"children":134},{"className":133},[],[135],{"type":45,"value":136},"dpacc",{"type":45,"value":138},"), that\nis a different scope — route via\n",{"type":40,"tag":75,"props":140,"children":142},{"href":141},"..\u002F..\u002Fdoca-public-knowledge-map\u002FSKILL.md",[143],{"type":40,"tag":67,"props":144,"children":146},{"className":145},[],[147],{"type":45,"value":148},"doca-public-knowledge-map",{"type":45,"value":150},"\nto the public DOCA DPA \u002F DPACC \u002F DPA-Comms \u002F DPA-Verbs guides\n(this skill does not redefine those DPA-side surfaces).",{"type":40,"tag":152,"props":153,"children":155},"h2",{"id":154},"example-questions-this-skill-answers-well",[156],{"type":45,"value":157},"Example questions this skill answers well",{"type":40,"tag":48,"props":159,"children":160},{},[161,163,168],{"type":45,"value":162},"The CLASSES of DPA questions this skill is built to answer, each\nwith one worked example. The agent should treat the ",{"type":40,"tag":87,"props":164,"children":165},{},[166],{"type":45,"value":167},"class",{"type":45,"value":169}," as\nthe load-bearing piece — the worked example is a single\ninstance.",{"type":40,"tag":171,"props":172,"children":173},"ul",{},[174,222,287,339,382,429,510,581],{"type":40,"tag":175,"props":176,"children":177},"li",{},[178,183,185,190,192,202],{"type":40,"tag":52,"props":179,"children":180},{},[181],{"type":45,"value":182},"\"How do I run a piece of compute on the DPA processor from\nmy host program?\"",{"type":45,"value":184}," — worked example: ",{"type":40,"tag":87,"props":186,"children":187},{},[188],{"type":45,"value":189},"\"load a DPA kernel that\ncounts events in a loop and reports the count back to the\nhost\"",{"type":45,"value":191},". Answered by the two-side-program model + the\nhost-side launch workflow in\n",{"type":40,"tag":75,"props":193,"children":195},{"href":194},"CAPABILITIES.md#capabilities-and-modes",[196],{"type":40,"tag":67,"props":197,"children":199},{"className":198},[],[200],{"type":45,"value":201},"CAPABILITIES.md ## Capabilities and modes",{"type":40,"tag":171,"props":203,"children":204},{},[205],{"type":40,"tag":175,"props":206,"children":207},{},[208,210,220],{"type":45,"value":209},"the bring-up steps in\n",{"type":40,"tag":75,"props":211,"children":213},{"href":212},"TASKS.md#configure",[214],{"type":40,"tag":67,"props":215,"children":217},{"className":216},[],[218],{"type":45,"value":219},"TASKS.md ## configure",{"type":45,"value":221},".",{"type":40,"tag":175,"props":223,"children":224},{},[225,230,231,236,238,244,246,252,254,260,262,270],{"type":40,"tag":52,"props":226,"children":227},{},[228],{"type":45,"value":229},"\"Does this BlueField even have a DPA, and which DPA features\ndoes my DOCA install expose?\"",{"type":45,"value":184},{"type":40,"tag":87,"props":232,"children":233},{},[234],{"type":45,"value":235},"\"my host\nhas a BlueField; can I use the DPA on it for a programmable\ncontrol workload?\"",{"type":45,"value":237},". Answered by the dual-axis capability rule\n(BlueField-generation axis via ",{"type":40,"tag":67,"props":239,"children":241},{"className":240},[],[242],{"type":45,"value":243},"doca_dpa_cap_*",{"type":45,"value":245}," against the\nactive ",{"type":40,"tag":67,"props":247,"children":249},{"className":248},[],[250],{"type":45,"value":251},"doca_devinfo",{"type":45,"value":253}," plus the DOCA-install axis via\n",{"type":40,"tag":67,"props":255,"children":257},{"className":256},[],[258],{"type":45,"value":259},"pkg-config --modversion doca-dpa",{"type":45,"value":261},") in\n",{"type":40,"tag":75,"props":263,"children":264},{"href":194},[265],{"type":40,"tag":67,"props":266,"children":268},{"className":267},[],[269],{"type":45,"value":201},{"type":40,"tag":171,"props":271,"children":272},{},[273],{"type":40,"tag":175,"props":274,"children":275},{},[276,278,286],{"type":45,"value":277},"the device-enumeration step in\n",{"type":40,"tag":75,"props":279,"children":280},{"href":212},[281],{"type":40,"tag":67,"props":282,"children":284},{"className":283},[],[285],{"type":45,"value":219},{"type":45,"value":221},{"type":40,"tag":175,"props":288,"children":289},{},[290,303,304,309,311,321],{"type":40,"tag":52,"props":291,"children":292},{},[293,295,301],{"type":45,"value":294},"\"Why does my host-side DPA setup fail with\n",{"type":40,"tag":67,"props":296,"children":298},{"className":297},[],[299],{"type":45,"value":300},"DOCA_ERROR_NOT_SUPPORTED",{"type":45,"value":302}," even though DOCA Core looks\nhealthy?\"",{"type":45,"value":184},{"type":40,"tag":87,"props":305,"children":306},{},[307],{"type":45,"value":308},"\"the BlueField generation in\nthis host predates the DPA feature my code uses\"",{"type":45,"value":310},". Answered by\nthe env-precondition matrix in\n",{"type":40,"tag":75,"props":312,"children":314},{"href":313},"CAPABILITIES.md#safety-policy",[315],{"type":40,"tag":67,"props":316,"children":318},{"className":317},[],[319],{"type":45,"value":320},"CAPABILITIES.md ## Safety policy",{"type":40,"tag":171,"props":322,"children":323},{},[324],{"type":40,"tag":175,"props":325,"children":326},{},[327,329,337],{"type":45,"value":328},"the env checklist in\n",{"type":40,"tag":75,"props":330,"children":331},{"href":212},[332],{"type":40,"tag":67,"props":333,"children":335},{"className":334},[],[336],{"type":45,"value":219},{"type":45,"value":338}," step 1.",{"type":40,"tag":175,"props":340,"children":341},{},[342,347,348,353,355,363],{"type":40,"tag":52,"props":343,"children":344},{},[345],{"type":45,"value":346},"\"How do I get arguments and results between my host program\nand my DPA kernel?\"",{"type":45,"value":184},{"type":40,"tag":87,"props":349,"children":350},{},[351],{"type":45,"value":352},"\"pass a buffer pointer\nand a length into the DPA kernel as launch arguments; read a\ncompletion back when the kernel finishes\"",{"type":45,"value":354},". Answered by the\nlaunch-argument + completion overlay in\n",{"type":40,"tag":75,"props":356,"children":357},{"href":194},[358],{"type":40,"tag":67,"props":359,"children":361},{"className":360},[],[362],{"type":45,"value":201},{"type":40,"tag":171,"props":364,"children":365},{},[366],{"type":40,"tag":175,"props":367,"children":368},{},[369,371,381],{"type":45,"value":370},"the launch + drain steps in\n",{"type":40,"tag":75,"props":372,"children":374},{"href":373},"TASKS.md#run",[375],{"type":40,"tag":67,"props":376,"children":378},{"className":377},[],[379],{"type":45,"value":380},"TASKS.md ## run",{"type":45,"value":221},{"type":40,"tag":175,"props":383,"children":384},{},[385,390,391,396,398,408,410,420,422,427],{"type":40,"tag":52,"props":386,"children":387},{},[388],{"type":45,"value":389},"\"Is the DPA host-side API I'm reading about on my installed\nDOCA?\"",{"type":45,"value":184},{"type":40,"tag":87,"props":392,"children":393},{},[394],{"type":45,"value":395},"\"is the host-side launch helper I\nsee in the docs available against the DOCA + DPACC versions on\nthis host?\"",{"type":45,"value":397},". Answered by the version-compatibility overlay in\n",{"type":40,"tag":75,"props":399,"children":401},{"href":400},"CAPABILITIES.md#version-compatibility",[402],{"type":40,"tag":67,"props":403,"children":405},{"className":404},[],[406],{"type":45,"value":407},"CAPABILITIES.md ## Version compatibility",{"type":45,"value":409},"\nwhich cross-links the canonical detection chain in\n",{"type":40,"tag":75,"props":411,"children":413},{"href":412},"..\u002F..\u002Fdoca-version\u002FSKILL.md",[414],{"type":40,"tag":67,"props":415,"children":417},{"className":416},[],[418],{"type":45,"value":419},"doca-version",{"type":45,"value":421}," and adds the\nDPA-specific ",{"type":40,"tag":87,"props":423,"children":424},{},[425],{"type":45,"value":426},"DOCA must match DPACC",{"type":45,"value":428}," overlay.",{"type":40,"tag":175,"props":430,"children":431},{},[432,453,454,467,469,479],{"type":40,"tag":52,"props":433,"children":434},{},[435,437,443,445,451],{"type":45,"value":436},"\"What does this ",{"type":40,"tag":67,"props":438,"children":440},{"className":439},[],[441],{"type":45,"value":442},"DOCA_ERROR_*",{"type":45,"value":444}," from a ",{"type":40,"tag":67,"props":446,"children":448},{"className":447},[],[449],{"type":45,"value":450},"doca_dpa_*",{"type":45,"value":452}," call mean\nand which layer caused it?\"",{"type":45,"value":184},{"type":40,"tag":87,"props":455,"children":456},{},[457,459,465],{"type":45,"value":458},"\"",{"type":40,"tag":67,"props":460,"children":462},{"className":461},[],[463],{"type":45,"value":464},"DOCA_ERROR_DRIVER",{"type":45,"value":466},"\non a host-side launch call — is it DOCA, the DPACC-produced\nimage, or the DPA processor itself?\"",{"type":45,"value":468},". Answered by the DPA\noverlay on the cross-library taxonomy in\n",{"type":40,"tag":75,"props":470,"children":472},{"href":471},"CAPABILITIES.md#error-taxonomy",[473],{"type":40,"tag":67,"props":474,"children":476},{"className":475},[],[477],{"type":45,"value":478},"CAPABILITIES.md ## Error taxonomy",{"type":40,"tag":171,"props":480,"children":481},{},[482],{"type":40,"tag":175,"props":483,"children":484},{},[485,487,497,499,509],{"type":45,"value":486},"the layered ladder in\n",{"type":40,"tag":75,"props":488,"children":490},{"href":489},"TASKS.md#debug",[491],{"type":40,"tag":67,"props":492,"children":494},{"className":493},[],[495],{"type":45,"value":496},"TASKS.md ## debug",{"type":45,"value":498}," that escalates to\n",{"type":40,"tag":75,"props":500,"children":502},{"href":501},"..\u002F..\u002Fdoca-debug\u002FSKILL.md",[503],{"type":40,"tag":67,"props":504,"children":506},{"className":505},[],[507],{"type":45,"value":508},"doca-debug",{"type":45,"value":221},{"type":40,"tag":175,"props":511,"children":512},{},[513,518,520,540,542,552,554,564,566,572,574,580],{"type":40,"tag":52,"props":514,"children":515},{},[516],{"type":45,"value":517},"\"How does my DPA kernel send a small message to another\nDPA thread on the same DPA processor?\"",{"type":45,"value":519}," — worked example:\n",{"type":40,"tag":87,"props":521,"children":522},{},[523,525,531,533,539],{"type":45,"value":524},"\"two DPA threads in the same loaded ",{"type":40,"tag":67,"props":526,"children":528},{"className":527},[],[529],{"type":45,"value":530},"doca_dpa_app",{"type":45,"value":532},"; thread A\nsends a counter value to thread B over a DPA-side comms\nendpoint and thread B signals the host through\n",{"type":40,"tag":67,"props":534,"children":536},{"className":535},[],[537],{"type":45,"value":538},"doca_dpa_completion",{"type":45,"value":458},{"type":45,"value":541},". Answered by the DPA-Comms routing\nrule, primitive families, host-side capability-budget rule,\nand DPA-Comms error overlay in\n",{"type":40,"tag":75,"props":543,"children":545},{"href":544},"CAPABILITIES.md#comms",[546],{"type":40,"tag":67,"props":547,"children":549},{"className":548},[],[550],{"type":45,"value":551},"CAPABILITIES.md ## comms",{"type":45,"value":553}," plus the\nconfigure \u002F build \u002F modify \u002F run \u002F test \u002F debug overlay in\n",{"type":40,"tag":75,"props":555,"children":557},{"href":556},"TASKS.md#comms",[558],{"type":40,"tag":67,"props":559,"children":561},{"className":560},[],[562],{"type":45,"value":563},"TASKS.md ## comms",{"type":45,"value":565},". Disambiguates the DPA\ndevice-side comm component from host-side ",{"type":40,"tag":67,"props":567,"children":569},{"className":568},[],[570],{"type":45,"value":571},"doca-comch",{"type":45,"value":573}," and\nhost-side ",{"type":40,"tag":67,"props":575,"children":577},{"className":576},[],[578],{"type":45,"value":579},"doca-rdma",{"type":45,"value":221},{"type":40,"tag":175,"props":582,"children":583},{},[584,589,591,596,598,608,610,620],{"type":40,"tag":52,"props":585,"children":586},{},[587],{"type":45,"value":588},"\"How do I do RDMA directly from inside my DPA kernel to a\nremote peer, without round-tripping to the host?\"",{"type":45,"value":590}," — worked\nexample: ",{"type":40,"tag":87,"props":592,"children":593},{},[594],{"type":45,"value":595},"\"my DPA kernel needs to fetch the next 4 KiB input\nbuffer from a remote node via RDMA read before continuing\ncompute; the host round-trip is the measured bottleneck\"",{"type":45,"value":597},".\nAnswered by the 4-way RDMA matrix, the host-configures-QP \u002F\nDPA-uses-QP coupling rule, the host-side cap-query rule for\nthe specific verb, and the DPA-Verbs error overlay in\n",{"type":40,"tag":75,"props":599,"children":601},{"href":600},"CAPABILITIES.md#verbs",[602],{"type":40,"tag":67,"props":603,"children":605},{"className":604},[],[606],{"type":45,"value":607},"CAPABILITIES.md ## verbs",{"type":45,"value":609}," plus the\nworkflow overlay in ",{"type":40,"tag":75,"props":611,"children":613},{"href":612},"TASKS.md#verbs",[614],{"type":40,"tag":67,"props":615,"children":617},{"className":616},[],[618],{"type":45,"value":619},"TASKS.md ## verbs",{"type":45,"value":621},".\nIncludes the climb-back rule for when the latency-tuning\npremise stops holding.",{"type":40,"tag":152,"props":623,"children":625},{"id":624},"audience",[626],{"type":45,"value":627},"Audience",{"type":40,"tag":48,"props":629,"children":630},{},[631,633,638,640,645,647,652,654,659,661,665,667,675],{"type":45,"value":632},"This skill serves ",{"type":40,"tag":52,"props":634,"children":635},{},[636],{"type":45,"value":637},"external developers building applications\nthat consume the DOCA DPA library from the host side",{"type":45,"value":639}," — i.e.,\nusers whose code calls ",{"type":40,"tag":67,"props":641,"children":643},{"className":642},[],[644],{"type":45,"value":450},{"type":45,"value":646}," from host C \u002F C++ to stand\nup the per-DPA-instance context, load a DPA application image\nthat ",{"type":40,"tag":67,"props":648,"children":650},{"className":649},[],[651],{"type":45,"value":136},{"type":45,"value":653}," produced from their DPA-side source, create one or\nmore DPA threads, launch DPA kernels with arguments, and drain\ncompletions. It is ",{"type":40,"tag":87,"props":655,"children":656},{},[657],{"type":45,"value":658},"not",{"type":45,"value":660}," for NVIDIA developers contributing to\nDOCA DPA itself, nor is it the place to learn how to ",{"type":40,"tag":87,"props":662,"children":663},{},[664],{"type":45,"value":128},{"type":45,"value":666},"\nthe DPA-side kernel code (that path goes through the public\nDOCA DPA, DPACC, DPA-Comms, and DPA-Verbs guides via\n",{"type":40,"tag":75,"props":668,"children":669},{"href":141},[670],{"type":40,"tag":67,"props":671,"children":673},{"className":672},[],[674],{"type":45,"value":148},{"type":45,"value":676},").",{"type":40,"tag":48,"props":678,"children":679},{},[680,685,687,693,695,700,702,707,709,715,717,722,724,729],{"type":40,"tag":52,"props":681,"children":682},{},[683],{"type":45,"value":684},"Language scope.",{"type":45,"value":686}," DOCA DPA ships as a host-side C library\nwith ",{"type":40,"tag":67,"props":688,"children":690},{"className":689},[],[691],{"type":45,"value":692},"pkg-config",{"type":45,"value":694}," module name ",{"type":40,"tag":67,"props":696,"children":698},{"className":697},[],[699],{"type":45,"value":4},{"type":45,"value":701},". The host-side API is\nC; the DPA-side kernel is a separate translation unit written\nin the language the DPACC compiler accepts and compiled by\n",{"type":40,"tag":67,"props":703,"children":705},{"className":704},[],[706],{"type":45,"value":136},{"type":45,"value":708}," into a binary that the host packages into the\nexecutable as the DPA application image. The shipped samples\nunder ",{"type":40,"tag":67,"props":710,"children":712},{"className":711},[],[713],{"type":45,"value":714},"\u002Fopt\u002Fmellanox\u002Fdoca\u002Fsamples\u002Fdoca_dpa\u002F",{"type":45,"value":716}," are written in C\nplus DPA-side source (NVIDIA's choice). Other-language\nconsumers are limited in practice — the DPA-side kernel has no\nFFI escape hatch because it must be a translation unit ",{"type":40,"tag":67,"props":718,"children":720},{"className":719},[],[721],{"type":45,"value":136},{"type":45,"value":723},"\naccepts — but a Rust \u002F Go \u002F Python host-side wrapper that drives\n",{"type":40,"tag":67,"props":725,"children":727},{"className":726},[],[728],{"type":45,"value":450},{"type":45,"value":730}," setup and launches a DPA kernel image built\nseparately is still useful, and the skill keeps the lifecycle,\ncapability-discovery, env-precondition, and error-taxonomy\nguidance language-neutral.",{"type":40,"tag":152,"props":732,"children":734},{"id":733},"when-to-load-this-skill",[735],{"type":45,"value":736},"When to load this skill",{"type":40,"tag":48,"props":738,"children":739},{},[740,742,747,749,754],{"type":45,"value":741},"Load this skill when the user is doing hands-on DOCA DPA work\n",{"type":40,"tag":52,"props":743,"children":744},{},[745],{"type":45,"value":746},"from the host side",{"type":45,"value":748},", in any host language plus a DPA-side\ntranslation unit built by ",{"type":40,"tag":67,"props":750,"children":752},{"className":751},[],[753],{"type":45,"value":136},{"type":45,"value":755},". Concretely:",{"type":40,"tag":171,"props":757,"children":758},{},[759,780,806,819,832,844,863,907,919,1009],{"type":40,"tag":175,"props":760,"children":761},{},[762,764,770,772,778],{"type":45,"value":763},"Initializing a ",{"type":40,"tag":67,"props":765,"children":767},{"className":766},[],[768],{"type":45,"value":769},"doca_dpa",{"type":45,"value":771}," against a ",{"type":40,"tag":67,"props":773,"children":775},{"className":774},[],[776],{"type":45,"value":777},"doca_dev",{"type":45,"value":779}," that maps to a\nBlueField with a DPA processor visible to the host.",{"type":40,"tag":175,"props":781,"children":782},{},[783,785,790,792,797,799,804],{"type":45,"value":784},"Loading a DPA application image (",{"type":40,"tag":67,"props":786,"children":788},{"className":787},[],[789],{"type":45,"value":530},{"type":45,"value":791},") that\n",{"type":40,"tag":67,"props":793,"children":795},{"className":794},[],[796],{"type":45,"value":136},{"type":45,"value":798}," produced from the user's DPA-side source, into the\n",{"type":40,"tag":67,"props":800,"children":802},{"className":801},[],[803],{"type":45,"value":769},{"type":45,"value":805}," context.",{"type":40,"tag":175,"props":807,"children":808},{},[809,811,817],{"type":45,"value":810},"Creating one or more DPA execution contexts (",{"type":40,"tag":67,"props":812,"children":814},{"className":813},[],[815],{"type":45,"value":816},"doca_dpa_thread",{"type":45,"value":818},")\nso DPA kernels have somewhere to run on the DPA processor.",{"type":40,"tag":175,"props":820,"children":821},{},[822,824,830],{"type":45,"value":823},"Launching a DPA kernel function with arguments from the host\nvia the ",{"type":40,"tag":67,"props":825,"children":827},{"className":826},[],[828],{"type":45,"value":829},"doca_dpa_kernel_launch_update_*",{"type":45,"value":831}," family, and\nreasoning about which argument shape is supported on this\ninstall.",{"type":40,"tag":175,"props":833,"children":834},{},[835,837,842],{"type":45,"value":836},"Attaching a ",{"type":40,"tag":67,"props":838,"children":840},{"className":839},[],[841],{"type":45,"value":538},{"type":45,"value":843}," to observe when async DPA\nwork finishes, and draining it from the host side.",{"type":40,"tag":175,"props":845,"children":846},{},[847,849,854,856,861],{"type":45,"value":848},"Checking which DPA features are supported on the active\n",{"type":40,"tag":67,"props":850,"children":852},{"className":851},[],[853],{"type":45,"value":251},{"type":45,"value":855}," via the ",{"type":40,"tag":67,"props":857,"children":859},{"className":858},[],[860],{"type":45,"value":243},{"type":45,"value":862}," family — BlueField\ngenerations differ in DPA hardware support.",{"type":40,"tag":175,"props":864,"children":865},{},[866,868,873,875,880,882,887,889,894,895,900,901,906],{"type":45,"value":867},"Debugging a ",{"type":40,"tag":67,"props":869,"children":871},{"className":870},[],[872],{"type":45,"value":442},{"type":45,"value":874}," returned from a ",{"type":40,"tag":67,"props":876,"children":878},{"className":877},[],[879],{"type":45,"value":450},{"type":45,"value":881}," call\n— in particular disambiguating ",{"type":40,"tag":87,"props":883,"children":884},{},[885],{"type":45,"value":886},"DPA not present on this\nBlueField",{"type":45,"value":888}," from ",{"type":40,"tag":87,"props":890,"children":891},{},[892],{"type":45,"value":893},"DPA feature too new for this hardware\ngeneration",{"type":45,"value":888},{"type":40,"tag":87,"props":896,"children":897},{},[898],{"type":45,"value":899},"DPACC-produced image mismatched against\nthe host-side DOCA install",{"type":45,"value":888},{"type":40,"tag":87,"props":902,"children":903},{},[904],{"type":45,"value":905},"DPA driver layer\nreporting failure",{"type":45,"value":221},{"type":40,"tag":175,"props":908,"children":909},{},[910,912,917],{"type":45,"value":911},"Designing host-side bindings in a non-C language that drive\na DPA application image they built separately with ",{"type":40,"tag":67,"props":913,"children":915},{"className":914},[],[916],{"type":45,"value":136},{"type":45,"value":918}," —\nthe env-precondition and capability-discovery rules in this\nskill still apply.",{"type":40,"tag":175,"props":920,"children":921},{},[922,924,933,935,941,943,948,950,956,958,964,966,972,974,980,982,987,989,997,999,1007],{"type":45,"value":923},"Writing DPA-side kernel code that calls the DPA device-side\ncomm component ",{"type":40,"tag":52,"props":925,"children":926},{},[927],{"type":40,"tag":67,"props":928,"children":930},{"className":929},[],[931],{"type":45,"value":932},"libdoca_dpa_dev_comm.a",{"type":45,"value":934}," (header\n",{"type":40,"tag":67,"props":936,"children":938},{"className":937},[],[939],{"type":45,"value":940},"doca_dpa_dev_comch_msgq.h",{"type":45,"value":942},") — for inter-DPA-thread\nmessaging or coordination signals between DPA threads on the\nsame ",{"type":40,"tag":67,"props":944,"children":946},{"className":945},[],[947],{"type":45,"value":530},{"type":45,"value":949},". The DPA-Comms routing rule, primitive\nfamilies, capability rule (there is no per-primitive host\ncap-query family — host-side DPA discovery is only\n",{"type":40,"tag":67,"props":951,"children":953},{"className":952},[],[954],{"type":45,"value":955},"doca_dpa_cap_is_supported",{"type":45,"value":957}," \u002F\n",{"type":40,"tag":67,"props":959,"children":961},{"className":960},[],[962],{"type":45,"value":963},"doca_dpa_cap_get_max_kernel_time_alive_supported",{"type":45,"value":965},"), error\noverlay (",{"type":40,"tag":67,"props":967,"children":969},{"className":968},[],[970],{"type":45,"value":971},"_AGAIN",{"type":45,"value":973}," → kernel must yield; ",{"type":40,"tag":67,"props":975,"children":977},{"className":976},[],[978],{"type":45,"value":979},"_BAD_STATE",{"type":45,"value":981},"\ndisambiguation from the parent's host-side ",{"type":40,"tag":67,"props":983,"children":985},{"className":984},[],[986],{"type":45,"value":979},{"type":45,"value":988},"), and\nthe configure \u002F build \u002F modify \u002F run \u002F test \u002F debug overlay\nlive in ",{"type":40,"tag":75,"props":990,"children":991},{"href":544},[992],{"type":40,"tag":67,"props":993,"children":995},{"className":994},[],[996],{"type":45,"value":551},{"type":45,"value":998}," and\n",{"type":40,"tag":75,"props":1000,"children":1001},{"href":556},[1002],{"type":40,"tag":67,"props":1003,"children":1005},{"className":1004},[],[1006],{"type":45,"value":563},{"type":45,"value":1008}," under this same skill.",{"type":40,"tag":175,"props":1010,"children":1011},{},[1012,1014,1023,1024,1030,1032,1037,1039,1047,1048,1056],{"type":45,"value":1013},"Writing DPA-side kernel code that calls the DPA device-side\nverbs component ",{"type":40,"tag":52,"props":1015,"children":1016},{},[1017],{"type":40,"tag":67,"props":1018,"children":1020},{"className":1019},[],[1021],{"type":45,"value":1022},"libdoca_dpa_dev_verbs.a",{"type":45,"value":934},{"type":40,"tag":67,"props":1025,"children":1027},{"className":1026},[],[1028],{"type":45,"value":1029},"doca_dpa_dev_verbs.h",{"type":45,"value":1031},") — for RDMA from inside\nthe DPA kernel to a remote peer when the host round-trip is\nthe measured latency bottleneck. The 4-way RDMA matrix, the\nhost-configures-QP \u002F DPA-uses-QP coupling rule, the\ncapability rule (no per-verb host cap-query family exists;\nverb availability follows the BlueField generation + matched\nDOCA\u002FDPACC install, read from ",{"type":40,"tag":67,"props":1033,"children":1035},{"className":1034},[],[1036],{"type":45,"value":1029},{"type":45,"value":1038}," and the\nshipped sample), the IO_FAILED → CQE-inspection\noverlay, and the climb-back rule live in\n",{"type":40,"tag":75,"props":1040,"children":1041},{"href":600},[1042],{"type":40,"tag":67,"props":1043,"children":1045},{"className":1044},[],[1046],{"type":45,"value":607},{"type":45,"value":998},{"type":40,"tag":75,"props":1049,"children":1050},{"href":612},[1051],{"type":40,"tag":67,"props":1052,"children":1054},{"className":1053},[],[1055],{"type":45,"value":619},{"type":45,"value":1008},{"type":40,"tag":48,"props":1058,"children":1059},{},[1060,1062,1066,1068,1073,1075,1080,1082,1087,1089,1097],{"type":45,"value":1061},"Do ",{"type":40,"tag":52,"props":1063,"children":1064},{},[1065],{"type":45,"value":658},{"type":45,"value":1067}," load this skill for general DOCA orientation,\ninstall of DOCA or the DPACC compiler, the DPA-side\nprogramming model itself (how to write a DPA kernel; the\nDPA device-side comm and verbs components\n(",{"type":40,"tag":67,"props":1069,"children":1071},{"className":1070},[],[1072],{"type":45,"value":932},{"type":45,"value":1074}," \u002F ",{"type":40,"tag":67,"props":1076,"children":1078},{"className":1077},[],[1079],{"type":45,"value":1022},{"type":45,"value":1081},") that\nrun ",{"type":40,"tag":87,"props":1083,"children":1084},{},[1085],{"type":45,"value":1086},"inside",{"type":45,"value":1088}," the DPA kernel), or non-DPA library questions.\nFor those, route through\n",{"type":40,"tag":75,"props":1090,"children":1091},{"href":141},[1092],{"type":40,"tag":67,"props":1093,"children":1095},{"className":1094},[],[1096],{"type":45,"value":148},{"type":45,"value":1098},"\nto the matching upstream guide.",{"type":40,"tag":152,"props":1100,"children":1102},{"id":1101},"what-this-skill-provides",[1103],{"type":45,"value":1104},"What this skill provides",{"type":40,"tag":48,"props":1106,"children":1107},{},[1108,1110,1115],{"type":45,"value":1109},"This is a ",{"type":40,"tag":52,"props":1111,"children":1112},{},[1113],{"type":45,"value":1114},"thin loader",{"type":45,"value":1116},". The body keeps only the orientation\nneeded to pick the right next file. The substantive\nDPA-specific material lives in two companion files:",{"type":40,"tag":171,"props":1118,"children":1119},{},[1120,1193],{"type":40,"tag":175,"props":1121,"children":1122},{},[1123,1128,1130,1135,1137,1142,1144,1149,1151,1156,1158,1163,1165,1170,1172,1177,1179,1184,1186,1191],{"type":40,"tag":67,"props":1124,"children":1126},{"className":1125},[],[1127],{"type":45,"value":96},{"type":45,"value":1129}," — what the host-side DPA API can express on\nthis version + this BlueField generation: the per-DPA-instance\n",{"type":40,"tag":67,"props":1131,"children":1133},{"className":1132},[],[1134],{"type":45,"value":769},{"type":45,"value":1136}," context, the loaded ",{"type":40,"tag":67,"props":1138,"children":1140},{"className":1139},[],[1141],{"type":45,"value":530},{"type":45,"value":1143}," image produced\nby ",{"type":40,"tag":67,"props":1145,"children":1147},{"className":1146},[],[1148],{"type":45,"value":136},{"type":45,"value":1150},", the ",{"type":40,"tag":67,"props":1152,"children":1154},{"className":1153},[],[1155],{"type":45,"value":816},{"type":45,"value":1157}," execution context, the\nhost-initiated kernel launch surface\n(",{"type":40,"tag":67,"props":1159,"children":1161},{"className":1160},[],[1162],{"type":45,"value":829},{"type":45,"value":1164},"), the ",{"type":40,"tag":67,"props":1166,"children":1168},{"className":1167},[],[1169],{"type":45,"value":538},{"type":45,"value":1171},"\nmechanism, the capability-query surface (",{"type":40,"tag":67,"props":1173,"children":1175},{"className":1174},[],[1176],{"type":45,"value":243},{"type":45,"value":1178},"),\nthe DPA error taxonomy mapped onto the cross-library\n",{"type":40,"tag":67,"props":1180,"children":1182},{"className":1181},[],[1183],{"type":45,"value":442},{"type":45,"value":1185}," set, the observability surface (host-side\ncompletions plus the public DPA developer tools surface\nreachable via ",{"type":40,"tag":67,"props":1187,"children":1189},{"className":1188},[],[1190],{"type":45,"value":148},{"type":45,"value":1192},"), and the safety\npolicy that gates env preconditions (DPA-capable BlueField,\nmatched DOCA + DPACC versions, DPA-side image and host-side\nexpected entry points agree).",{"type":40,"tag":175,"props":1194,"children":1195},{},[1196,1201,1203,1209,1211,1217,1218,1224,1225,1231,1232,1238,1240,1246,1248,1254],{"type":40,"tag":67,"props":1197,"children":1199},{"className":1198},[],[1200],{"type":45,"value":77},{"type":45,"value":1202}," — step-by-step workflows for the six in-scope DPA\nverbs: ",{"type":40,"tag":67,"props":1204,"children":1206},{"className":1205},[],[1207],{"type":45,"value":1208},"configure",{"type":45,"value":1210},", ",{"type":40,"tag":67,"props":1212,"children":1214},{"className":1213},[],[1215],{"type":45,"value":1216},"build",{"type":45,"value":1210},{"type":40,"tag":67,"props":1219,"children":1221},{"className":1220},[],[1222],{"type":45,"value":1223},"modify",{"type":45,"value":1210},{"type":40,"tag":67,"props":1226,"children":1228},{"className":1227},[],[1229],{"type":45,"value":1230},"run",{"type":45,"value":1210},{"type":40,"tag":67,"props":1233,"children":1235},{"className":1234},[],[1236],{"type":45,"value":1237},"test",{"type":45,"value":1239},",\n",{"type":40,"tag":67,"props":1241,"children":1243},{"className":1242},[],[1244],{"type":45,"value":1245},"debug",{"type":45,"value":1247},". Plus a ",{"type":40,"tag":67,"props":1249,"children":1251},{"className":1250},[],[1252],{"type":45,"value":1253},"Deferred task verbs",{"type":45,"value":1255}," block that points\nout-of-scope questions at the right next skill.",{"type":40,"tag":48,"props":1257,"children":1258},{},[1259,1261,1266,1268,1276],{"type":45,"value":1260},"The skill assumes a host where DOCA is already installed at\nthe standard location, a BlueField with a DPA processor is\nphysically present and visible to the host, the DPACC compiler\nis installed at a version matched to the DOCA install per the\nDOCA Compatibility Policy, and the user already knows how (at\nleast at a sketch level) to write the DPA-side kernel that\n",{"type":40,"tag":67,"props":1262,"children":1264},{"className":1263},[],[1265],{"type":45,"value":136},{"type":45,"value":1267}," will compile. It does not cover installing DOCA or the\nDPACC compiler — that path goes through\n",{"type":40,"tag":75,"props":1269,"children":1270},{"href":114},[1271],{"type":40,"tag":67,"props":1272,"children":1274},{"className":1273},[],[1275],{"type":45,"value":121},{"type":45,"value":221},{"type":40,"tag":152,"props":1278,"children":1280},{"id":1279},"what-this-skill-deliberately-does-not-ship",[1281],{"type":45,"value":1282},"What this skill deliberately does not ship",{"type":40,"tag":48,"props":1284,"children":1285},{},[1286,1288,1293],{"type":45,"value":1287},"This skill is ",{"type":40,"tag":52,"props":1289,"children":1290},{},[1291],{"type":45,"value":1292},"agent guidance",{"type":45,"value":1294},", 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":171,"props":1296,"children":1297},{},[1298,1338,1384,1417],{"type":40,"tag":175,"props":1299,"children":1300},{},[1301,1306,1308,1313,1315,1325,1327,1337],{"type":40,"tag":52,"props":1302,"children":1303},{},[1304],{"type":45,"value":1305},"Pre-written DOCA DPA application source code or DPA-side\nkernel source, in any language.",{"type":45,"value":1307}," The verified DPA source is\nthe shipped C + DPA-side samples at\n",{"type":40,"tag":67,"props":1309,"children":1311},{"className":1310},[],[1312],{"type":45,"value":714},{"type":45,"value":1314},". 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":75,"props":1316,"children":1318},{"href":1317},"..\u002F..\u002Fdoca-programming-guide\u002FSKILL.md",[1319],{"type":40,"tag":67,"props":1320,"children":1322},{"className":1321},[],[1323],{"type":45,"value":1324},"doca-programming-guide",{"type":45,"value":1326},",\nlayered with the DPA-specific overrides in\n",{"type":40,"tag":75,"props":1328,"children":1330},{"href":1329},"TASKS.md#modify",[1331],{"type":40,"tag":67,"props":1332,"children":1334},{"className":1333},[],[1335],{"type":45,"value":1336},"TASKS.md ## modify",{"type":45,"value":221},{"type":40,"tag":175,"props":1339,"children":1340},{},[1341,1346,1348,1354,1355,1361,1363,1368,1370,1375,1377,1382],{"type":40,"tag":52,"props":1342,"children":1343},{},[1344],{"type":45,"value":1345},"Standalone build manifests",{"type":45,"value":1347}," (",{"type":40,"tag":67,"props":1349,"children":1351},{"className":1350},[],[1352],{"type":45,"value":1353},"meson.build",{"type":45,"value":1239},{"type":40,"tag":67,"props":1356,"children":1358},{"className":1357},[],[1359],{"type":45,"value":1360},"CMakeLists.txt",{"type":45,"value":1362},", …) parked inside the skill. The agent\nconstructs the build manifest ",{"type":40,"tag":87,"props":1364,"children":1365},{},[1366],{"type":45,"value":1367},"in the user's project\ndirectory",{"type":45,"value":1369}," against the user's installed DOCA + DPACC\ncompiler, where ",{"type":40,"tag":67,"props":1371,"children":1373},{"className":1372},[],[1374],{"type":45,"value":259},{"type":45,"value":1376}," and the\ninstalled ",{"type":40,"tag":67,"props":1378,"children":1380},{"className":1379},[],[1381],{"type":45,"value":136},{"type":45,"value":1383}," are the two sources of truth.",{"type":40,"tag":175,"props":1385,"children":1386},{},[1387,1415],{"type":40,"tag":52,"props":1388,"children":1389},{},[1390,1392,1398,1399,1405,1407,1413],{"type":45,"value":1391},"A ",{"type":40,"tag":67,"props":1393,"children":1395},{"className":1394},[],[1396],{"type":45,"value":1397},"samples\u002F",{"type":45,"value":1210},{"type":40,"tag":67,"props":1400,"children":1402},{"className":1401},[],[1403],{"type":45,"value":1404},"bindings\u002F",{"type":45,"value":1406},", or ",{"type":40,"tag":67,"props":1408,"children":1410},{"className":1409},[],[1411],{"type":45,"value":1412},"reference\u002F",{"type":45,"value":1414}," subtree",{"type":45,"value":1416}," of any\nkind. A mock or incomplete artifact in this skill's tree,\neven one labeled \"reference\", is misleading: users will read\nit as buildable.",{"type":40,"tag":175,"props":1418,"children":1419},{},[1420,1437,1439,1444,1446,1451,1453,1458,1460,1468],{"type":40,"tag":52,"props":1421,"children":1422},{},[1423,1425,1430,1431,1436],{"type":45,"value":1424},"DPA device-side content for the comm \u002F verbs components\n(",{"type":40,"tag":67,"props":1426,"children":1428},{"className":1427},[],[1429],{"type":45,"value":932},{"type":45,"value":1074},{"type":40,"tag":67,"props":1432,"children":1434},{"className":1433},[],[1435],{"type":45,"value":1022},{"type":45,"value":676},{"type":45,"value":1438},"\nThese are ",{"type":40,"tag":87,"props":1440,"children":1441},{},[1442],{"type":45,"value":1443},"DPA-side",{"type":45,"value":1445}," archives shipped as part of ",{"type":40,"tag":67,"props":1447,"children":1449},{"className":1448},[],[1450],{"type":45,"value":4},{"type":45,"value":1452},"\n(NOT separate pkg-config modules): their symbols are called\nfrom inside the DPA kernel and linked into the DPA image by\n",{"type":40,"tag":67,"props":1454,"children":1456},{"className":1455},[],[1457],{"type":45,"value":136},{"type":45,"value":1459},", not from the host. Their public guides are reachable\nvia\n",{"type":40,"tag":75,"props":1461,"children":1462},{"href":141},[1463],{"type":40,"tag":67,"props":1464,"children":1466},{"className":1465},[],[1467],{"type":45,"value":148},{"type":45,"value":1469},".\nThis skill names them and routes; it does not redefine them.",{"type":40,"tag":152,"props":1471,"children":1473},{"id":1472},"loading-order",[1474],{"type":45,"value":1475},"Loading order",{"type":40,"tag":1477,"props":1478,"children":1479},"ol",{},[1480,1493,1527],{"type":40,"tag":175,"props":1481,"children":1482},{},[1483,1485,1491],{"type":45,"value":1484},"Read this ",{"type":40,"tag":67,"props":1486,"children":1488},{"className":1487},[],[1489],{"type":45,"value":1490},"SKILL.md",{"type":45,"value":1492}," first to confirm the user's question is\nin scope (host-side DPA work, not DPA-side kernel-writing).",{"type":40,"tag":175,"props":1494,"children":1495},{},[1496],{"type":40,"tag":52,"props":1497,"children":1498},{},[1499,1501,1506,1508,1513,1515,1520,1522,1526],{"type":45,"value":1500},"For the DPA capability matrix, the ",{"type":40,"tag":67,"props":1502,"children":1504},{"className":1503},[],[1505],{"type":45,"value":769},{"type":45,"value":1507}," per-instance\ncontext, the loaded ",{"type":40,"tag":67,"props":1509,"children":1511},{"className":1510},[],[1512],{"type":45,"value":530},{"type":45,"value":1514}," image, the\n",{"type":40,"tag":67,"props":1516,"children":1518},{"className":1517},[],[1519],{"type":45,"value":816},{"type":45,"value":1521}," execution context, the kernel-launch +\ncompletion model, the dual capability query, the\nenv-precondition policy, the error taxonomy, the\nobservability surface, and the safety policy, see\n",{"type":40,"tag":75,"props":1523,"children":1524},{"href":96},[1525],{"type":45,"value":96},{"type":45,"value":221},{"type":40,"tag":175,"props":1528,"children":1529},{},[1530],{"type":40,"tag":52,"props":1531,"children":1532},{},[1533,1535,1539],{"type":45,"value":1534},"For step-by-step workflows — configure, build, modify,\nrun, test, debug — see ",{"type":40,"tag":75,"props":1536,"children":1537},{"href":77},[1538],{"type":45,"value":77},{"type":45,"value":221},{"type":40,"tag":48,"props":1541,"children":1542},{},[1543,1545,1553,1555,1563],{"type":45,"value":1544},"Both companion files cross-link to each other,\n",{"type":40,"tag":75,"props":1546,"children":1547},{"href":412},[1548],{"type":40,"tag":67,"props":1549,"children":1551},{"className":1550},[],[1552],{"type":45,"value":419},{"type":45,"value":1554}," for the canonical\nDOCA version-handling rules (with the DPA overlay that DOCA\nmust match the DPACC compiler), and\n",{"type":40,"tag":75,"props":1556,"children":1557},{"href":141},[1558],{"type":40,"tag":67,"props":1559,"children":1561},{"className":1560},[],[1562],{"type":45,"value":148},{"type":45,"value":1564},"\nwhenever the right answer is \"look it up in the public DOCA\nDPA, DPACC, DPA-Comms, or DPA-Verbs guide, or in the on-disk\ninstall layout\" rather than \"DPA host-side-specific guidance\".",{"type":40,"tag":152,"props":1566,"children":1568},{"id":1567},"related-skills",[1569],{"type":45,"value":1570},"Related skills",{"type":40,"tag":171,"props":1572,"children":1573},{},[1574,1603,1623,1651,1672,1699],{"type":40,"tag":175,"props":1575,"children":1576},{},[1577,1585,1587,1594,1596,1601],{"type":40,"tag":75,"props":1578,"children":1579},{"href":141},[1580],{"type":40,"tag":67,"props":1581,"children":1583},{"className":1582},[],[1584],{"type":45,"value":148},{"type":45,"value":1586}," —\nthe routing table for every public DOCA documentation\nsource and the on-disk layout of an installed DOCA package.\nThe DPA public guide is at\n",{"type":40,"tag":75,"props":1588,"children":1592},{"href":1589,"rel":1590},"https:\u002F\u002Fdocs.nvidia.com\u002Fdoca\u002Fsdk\u002FDOCA-DPA\u002Findex.html",[1591],"nofollow",[1593],{"type":45,"value":1589},{"type":45,"value":1595},"; the\nDPACC compiler guide, the DPA-Comms guide (DPA-side\ncommunications), the DPA-Verbs guide (DPA-side verbs), and\nthe DPA Tools umbrella (developer \u002F admin CLIs for DPA)\nlive in the same routing table and are ",{"type":40,"tag":87,"props":1597,"children":1598},{},[1599],{"type":45,"value":1600},"companion surfaces",{"type":45,"value":1602},"\nto this skill rather than redefined by it.",{"type":40,"tag":175,"props":1604,"children":1605},{},[1606,1614,1616,1621],{"type":40,"tag":75,"props":1607,"children":1608},{"href":114},[1609],{"type":40,"tag":67,"props":1610,"children":1612},{"className":1611},[],[1613],{"type":45,"value":121},{"type":45,"value":1615}," — env preparation,\ninstall verification, DPACC compiler install \u002F verification,\nand the ",{"type":40,"tag":87,"props":1617,"children":1618},{},[1619],{"type":45,"value":1620},"I have no install yet",{"type":45,"value":1622}," path with the public NGC\nDOCA container. This skill assumes its preconditions are\nsatisfied AND that DPACC is installed at a version that\nmatches DOCA.",{"type":40,"tag":175,"props":1624,"children":1625},{},[1626,1634,1636,1642,1644,1649],{"type":40,"tag":75,"props":1627,"children":1628},{"href":412},[1629],{"type":40,"tag":67,"props":1630,"children":1632},{"className":1631},[],[1633],{"type":45,"value":419},{"type":45,"value":1635}," — canonical\nDOCA version-handling rules. This skill's ",{"type":40,"tag":67,"props":1637,"children":1639},{"className":1638},[],[1640],{"type":45,"value":1641},"## Version compatibility",{"type":45,"value":1643}," cross-links the four-way match rule and adds\nthe DPA-specific ",{"type":40,"tag":87,"props":1645,"children":1646},{},[1647],{"type":45,"value":1648},"DOCA-and-DPACC must match",{"type":45,"value":1650}," overlay per the\nDOCA Compatibility Policy.",{"type":40,"tag":175,"props":1652,"children":1653},{},[1654,1664,1666,1670],{"type":40,"tag":75,"props":1655,"children":1657},{"href":1656},"..\u002F..\u002Fdoca-structured-tools-contract\u002FSKILL.md",[1658],{"type":40,"tag":67,"props":1659,"children":1661},{"className":1660},[],[1662],{"type":45,"value":1663},"doca-structured-tools-contract",{"type":45,"value":1665}," —\nthe bundle's structured-tools precedence rule (detect \u002F\nprefer \u002F fall back \u002F report). The Command appendix in\n",{"type":40,"tag":75,"props":1667,"children":1668},{"href":77},[1669],{"type":45,"value":77},{"type":45,"value":1671}," honors this contract.",{"type":40,"tag":175,"props":1673,"children":1674},{},[1675,1683,1685,1690,1692,1697],{"type":40,"tag":75,"props":1676,"children":1677},{"href":1317},[1678],{"type":40,"tag":67,"props":1679,"children":1681},{"className":1680},[],[1682],{"type":45,"value":1324},{"type":45,"value":1684}," —\ngeneral DOCA programming patterns shared by every library:\nthe canonical ",{"type":40,"tag":67,"props":1686,"children":1688},{"className":1687},[],[1689],{"type":45,"value":692},{"type":45,"value":1691}," + meson build pattern, the\nuniversal modify-a-shipped-sample first-app workflow, the\nuniversal Core-context lifecycle, the cross-library\n",{"type":40,"tag":67,"props":1693,"children":1695},{"className":1694},[],[1696],{"type":45,"value":442},{"type":45,"value":1698}," taxonomy, and the program-side debug order.\nThis skill layers DPA specifics on top.",{"type":40,"tag":175,"props":1700,"children":1701},{},[1702,1710],{"type":40,"tag":75,"props":1703,"children":1704},{"href":501},[1705],{"type":40,"tag":67,"props":1706,"children":1708},{"className":1707},[],[1709],{"type":45,"value":508},{"type":45,"value":1711}," — the cross-cutting\ndebug ladder (install \u002F version \u002F build \u002F link \u002F runtime \u002F\nprogram \u002F driver). DPA-specific debug (DPACC + DOCA version\nskew, DPA not present on this BlueField generation, DPA\nkernel hangs that show no host-side completion,\nlaunch-argument shape mismatches between the host launch\ncall and the DPA-side function signature) overlays on top\nof that ladder.",{"type":40,"tag":48,"props":1713,"children":1714},{},[1715,1717,1722,1724,1729,1731,1736,1738,1743,1745,1755,1757,1765,1767,1772,1774,1779,1781,1786,1788,1793],{"type":45,"value":1716},"DOCA DPA's DPA device-side components — the comm archive\n",{"type":40,"tag":67,"props":1718,"children":1720},{"className":1719},[],[1721],{"type":45,"value":932},{"type":45,"value":1723}," (communication primitives the DPA\nkernel itself calls, header ",{"type":40,"tag":67,"props":1725,"children":1727},{"className":1726},[],[1728],{"type":45,"value":940},{"type":45,"value":1730},") and\nthe verbs archive ",{"type":40,"tag":67,"props":1732,"children":1734},{"className":1733},[],[1735],{"type":45,"value":1022},{"type":45,"value":1737}," (ibverbs-like RDMA\nverbs the DPA kernel itself calls, header\n",{"type":40,"tag":67,"props":1739,"children":1741},{"className":1740},[],[1742],{"type":45,"value":1029},{"type":45,"value":1744},") — are ",{"type":40,"tag":52,"props":1746,"children":1747},{},[1748,1750],{"type":45,"value":1749},"DPA-side archives shipped\nwithin ",{"type":40,"tag":67,"props":1751,"children":1753},{"className":1752},[],[1754],{"type":45,"value":4},{"type":45,"value":1756},", not separate pkg-config modules, and each\nhas its own public guide. No library skill ships for them in\nthis bundle yet; for any DPA-side question, route via\n",{"type":40,"tag":75,"props":1758,"children":1759},{"href":141},[1760],{"type":40,"tag":67,"props":1761,"children":1763},{"className":1762},[],[1764],{"type":45,"value":148},{"type":45,"value":1766},"\nto the public ",{"type":40,"tag":87,"props":1768,"children":1769},{},[1770],{"type":45,"value":1771},"DOCA DPA Comms",{"type":45,"value":1773}," and ",{"type":40,"tag":87,"props":1775,"children":1776},{},[1777],{"type":45,"value":1778},"DOCA DPA Verbs",{"type":45,"value":1780}," guides\nand to the shipped ",{"type":40,"tag":67,"props":1782,"children":1784},{"className":1783},[],[1785],{"type":45,"value":714},{"type":45,"value":1787},"\nsamples (which include both host-side and DPA-side\ntranslation units). Conflating them with ",{"type":40,"tag":67,"props":1789,"children":1791},{"className":1790},[],[1792],{"type":45,"value":4},{"type":45,"value":1794}," is the\nsingle most common DPA first-app design error.",{"items":1796,"total":1900},[1797,1814,1828,1842,1854,1871,1886],{"slug":1798,"name":1798,"fn":1799,"description":1800,"org":1801,"tags":1802,"stars":20,"repoUrl":21,"updatedAt":1813},"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},[1803,1806,1809,1810],{"name":1804,"slug":1805,"type":15},"Data Analysis","data-analysis",{"name":1807,"slug":1808,"type":15},"Data Engineering","data-engineering",{"name":9,"slug":8,"type":15},{"name":1811,"slug":1812,"type":15},"Performance","performance","2026-07-14T05:28:43.176466",{"slug":1815,"name":1815,"fn":1816,"description":1817,"org":1818,"tags":1819,"stars":20,"repoUrl":21,"updatedAt":1827},"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},[1820,1823,1826],{"name":1821,"slug":1822,"type":15},"Deployment","deployment",{"name":1824,"slug":1825,"type":15},"Infrastructure","infrastructure",{"name":9,"slug":8,"type":15},"2026-07-14T05:29:06.667109",{"slug":1829,"name":1829,"fn":1830,"description":1831,"org":1832,"tags":1833,"stars":20,"repoUrl":21,"updatedAt":1841},"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},[1834,1837,1838],{"name":1835,"slug":1836,"type":15},"Agents","agents",{"name":9,"slug":8,"type":15},{"name":1839,"slug":1840,"type":15},"Research","research","2026-07-14T05:28:06.816956",{"slug":1843,"name":1843,"fn":1844,"description":1845,"org":1846,"tags":1847,"stars":20,"repoUrl":21,"updatedAt":1853},"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},[1848,1849,1850],{"name":1804,"slug":1805,"type":15},{"name":9,"slug":8,"type":15},{"name":1851,"slug":1852,"type":15},"Testing","testing","2026-07-17T05:29:03.913266",{"slug":1855,"name":1855,"fn":1856,"description":1857,"org":1858,"tags":1859,"stars":20,"repoUrl":21,"updatedAt":1870},"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},[1860,1863,1866,1867],{"name":1861,"slug":1862,"type":15},"Automation","automation",{"name":1864,"slug":1865,"type":15},"Imaging","imaging",{"name":9,"slug":8,"type":15},{"name":1868,"slug":1869,"type":15},"Video","video","2026-07-17T05:28:53.905004",{"slug":1872,"name":1872,"fn":1873,"description":1874,"org":1875,"tags":1876,"stars":20,"repoUrl":21,"updatedAt":1885},"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},[1877,1878,1881,1882],{"name":1821,"slug":1822,"type":15},{"name":1879,"slug":1880,"type":15},"Docker","docker",{"name":9,"slug":8,"type":15},{"name":1883,"slug":1884,"type":15},"Operations","operations","2026-07-17T05:28:56.913999",{"slug":1887,"name":1887,"fn":1888,"description":1889,"org":1890,"tags":1891,"stars":20,"repoUrl":21,"updatedAt":1899},"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},[1892,1893,1896],{"name":9,"slug":8,"type":15},{"name":1894,"slug":1895,"type":15},"Quantum Computing","quantum-computing",{"name":1897,"slug":1898,"type":15},"Simulation","simulation","2026-07-14T05:26:58.898253",305,{"items":1902,"total":2053},[1903,1921,1937,1948,1960,1974,1987,2001,2012,2021,2035,2044],{"slug":1904,"name":1904,"fn":1905,"description":1906,"org":1907,"tags":1908,"stars":1918,"repoUrl":1919,"updatedAt":1920},"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},[1909,1912,1915],{"name":1910,"slug":1911,"type":15},"Documentation","documentation",{"name":1913,"slug":1914,"type":15},"MCP","mcp",{"name":1916,"slug":1917,"type":15},"Search","search",21777,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FNemoClaw","2026-07-20T06:00:01.461044",{"slug":1922,"name":1922,"fn":1923,"description":1924,"org":1925,"tags":1926,"stars":1934,"repoUrl":1935,"updatedAt":1936},"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},[1927,1930,1931],{"name":1928,"slug":1929,"type":15},"Containers","containers",{"name":1821,"slug":1822,"type":15},{"name":1932,"slug":1933,"type":15},"Python","python",17049,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FMegatron-LM","2026-07-27T06:06:11.249662",{"slug":1938,"name":1938,"fn":1939,"description":1940,"org":1941,"tags":1942,"stars":1934,"repoUrl":1935,"updatedAt":1947},"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},[1943,1946],{"name":1944,"slug":1945,"type":15},"CI\u002FCD","ci-cd",{"name":1821,"slug":1822,"type":15},"2026-07-14T05:25:59.97109",{"slug":1949,"name":1949,"fn":1950,"description":1951,"org":1952,"tags":1953,"stars":1934,"repoUrl":1935,"updatedAt":1959},"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},[1954,1955,1956],{"name":1944,"slug":1945,"type":15},{"name":1821,"slug":1822,"type":15},{"name":1957,"slug":1958,"type":15},"GitHub","github","2026-07-27T06:06:12.278222",{"slug":1961,"name":1961,"fn":1962,"description":1963,"org":1964,"tags":1965,"stars":1934,"repoUrl":1935,"updatedAt":1973},"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},[1966,1969,1970],{"name":1967,"slug":1968,"type":15},"Debugging","debugging",{"name":1957,"slug":1958,"type":15},{"name":1971,"slug":1972,"type":15},"Triage","triage","2026-07-14T05:25:57.442089",{"slug":1975,"name":1975,"fn":1976,"description":1977,"org":1978,"tags":1979,"stars":1934,"repoUrl":1935,"updatedAt":1986},"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},[1980,1983],{"name":1981,"slug":1982,"type":15},"Best Practices","best-practices",{"name":1984,"slug":1985,"type":15},"Code Analysis","code-analysis","2026-07-14T05:25:56.18433",{"slug":1988,"name":1988,"fn":1989,"description":1990,"org":1991,"tags":1992,"stars":1934,"repoUrl":1935,"updatedAt":2000},"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},[1993,1996,1999],{"name":1994,"slug":1995,"type":15},"Machine Learning","machine-learning",{"name":1997,"slug":1998,"type":15},"Migration","migration",{"name":9,"slug":8,"type":15},"2026-07-17T06:07:11.777011",{"slug":2002,"name":2002,"fn":2003,"description":2004,"org":2005,"tags":2006,"stars":1934,"repoUrl":1935,"updatedAt":2011},"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},[2007,2010],{"name":2008,"slug":2009,"type":15},"QA","qa",{"name":1851,"slug":1852,"type":15},"2026-07-14T05:25:53.673039",{"slug":2013,"name":2013,"fn":2014,"description":2015,"org":2016,"tags":2017,"stars":1934,"repoUrl":1935,"updatedAt":2020},"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},[2018,2019],{"name":1821,"slug":1822,"type":15},{"name":1824,"slug":1825,"type":15},"2026-07-14T05:25:49.362534",{"slug":2022,"name":2022,"fn":2023,"description":2024,"org":2025,"tags":2026,"stars":1934,"repoUrl":1935,"updatedAt":2034},"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},[2027,2030,2031],{"name":2028,"slug":2029,"type":15},"Code Review","code-review",{"name":1957,"slug":1958,"type":15},{"name":2032,"slug":2033,"type":15},"Pull Requests","pull-requests","2026-07-14T05:26:01.226578",{"slug":2036,"name":2036,"fn":2037,"description":2038,"org":2039,"tags":2040,"stars":1934,"repoUrl":1935,"updatedAt":2043},"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},[2041,2042],{"name":2008,"slug":2009,"type":15},{"name":1851,"slug":1852,"type":15},"2026-07-14T05:25:54.928983",{"slug":2045,"name":2045,"fn":2046,"description":2047,"org":2048,"tags":2049,"stars":1934,"repoUrl":1935,"updatedAt":2052},"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},[2050,2051],{"name":1861,"slug":1862,"type":15},{"name":1944,"slug":1945,"type":15},"2026-07-30T05:29:03.275638",496]