{"id":"bc5c96e0-7c1d-410b-8dd6-89dd34ac3d53","slug":"doca-sta","kind":"skill","name":"doca-sta","summary":"Use this skill when the user is doing hands-on NVMe-over-Fabrics storage-target work on a BlueField DPU or ConnectX NIC with DOCA STA — standing up a doca_sta DOCA Core context that accelerates the ta","owner":"NVIDIA","repoUrl":"https://github.com/NVIDIA/skills/tree/HEAD/skills/doca-sta","license":"Apache-2.0","licenseTier":"permissive","trust":"official","stars":3586,"match":null,"fewStars":false,"format":"skill","createdAt":null,"addedAt":"2026-10-14T05:43:41.703Z","logoUrl":"https://avatars.githubusercontent.com/u/1728152?v=4","linkOnly":false,"collection":{"name":"skills","repo":"nvidia/skills"},"skillPath":"skills/doca-sta","categories":["data-analytics","developer-tools","memory-knowledge"],"tags":["agentic-ai","ai-agents","claude-code","codex","coding-agents","cuda","developer-tools","llm"],"runtime":"binary","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-14T05:43:41.702Z","sample":false,"url":"https://conduits.dev/tools/doca-sta","language":"Python","transports":[],"install":{},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"> Use this skill when the user is doing hands-on NVMe-over-Fabrics storage-target work on a BlueField DPU or ConnectX NIC with DOCA STA — standing up a doca_sta DOCA Core context that accelerates the target-side NVMe-oF data path over RDMA, defining doca_sta_subsystem targets (NQN + namespaces) backed by local NVMe-PCI backend disks (doca_sta_be), checking device support via doca_sta_cap_is_supported, sizing the per-connection I/O queues, or debugging DOCA_ERROR_* from a STA call. Trigger even when the user does not say \"DOCA STA\" — typical implicit phrasings include \"my NVMe-oF Connect never completes\", \"Identify Controller times out over RoCE\", \"16 I/O queues at depth 1024 — does this BlueField support that\", \"offload the nvmf target onto the DPU\", or \"DOCA_ERROR_IO_FAILED on an NVMe read\". Refuse and route elsewhere for DOCA install, raw RDMA data movement, raw packet I/O, flow-rule programming, or initiator-side / host NVMe stack work — those belong to other skills.\n\n# DOCA STA (Storage Target Acceleration)\n\n**Where to start:** This skill assumes DOCA is already installed and\nthe user is doing **hands-on NVMe-over-Fabrics storage-target work** on\na BlueField-class device with DOCA. Open [`TASKS.md`](TASKS.md) if\nthe user wants to *do* something (configure / modify / build / run\n/ test / debug); open [`CAPABILITIES.md`](CAPABILITIES.md) when the\nquestion is *what can DOCA STA express* on this version. If the\nuser has not installed DOCA yet, route to\n[`doca-setup`](../../doca-setup/SKILL.md) first. If the user is\nasking *\"is this an NVMe-oF initiator/host transport?\"*, the\nanswer is no — doca-sta accelerates the **target** side: it presents\nNVMe-oF `doca_sta_subsystem` targets backed by local NVMe-PCI\ndisks; the model lives in\n[`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes).\n\n## Example questions this skill answers well\n\nThe CLASSES of DOCA STA questions this skill is built to answer,\neach with one worked example. The agent should treat the *class*\nas the load-bearing piece — the worked example is a single\ninstance.\n\n- **\"How do I bring up an NVMe-oF target that uses the BlueField\n  to accelerate the storage data path?\"** — worked example: *\"define\n  a `doca_sta_subsystem` (NQN) with one namespace backed by a local\n  NVMe-PCI disk (`doca_sta_be`) and accept NVMe-over-RDMA\n  connections from a remote initiator\"*. Answered by the\n  target-model-and-lifecycle\n  workflow in [`TASKS.md ## configure`](TASKS.md#configure) +\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  target-object table.\n- **\"Can this BlueField accelerate an NVMe-oF target at all?\"** —\n  worked example: *\"my data center is RoCE end-to-end; does this\n  device support DOCA STA target acceleration?\"*. STA transport is\n  RDMA-only (there is no NVMe-over-TCP path). Answered by the\n  capability-query rule (`doca_sta_cap_is_supported` against a\n  `doca_devinfo`) in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the discovery step in\n  [`TASKS.md ## configure`](TASKS.md#configure).\n- **\"How deep can I size my I/O queues, and how many I/O queues\n  per connection?\"** — worked example: *\"I want 16 I/O queues at\n  depth 1024 each — does this device support that?\"*. Answered by\n  the queue-sizing capability surface in\n  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)\n  + the queue-sizing step in\n  [`TASKS.md ## configure`](TASKS.md#configure) which gates on\n  the matching `doca_sta_get_max_*` query (e.g.\n  `doca_sta_get_max_qps`, `doca_sta_get_max_io_queue_size`).\n- **\"Which other DOCA libraries do I need alongside doca-sta?\"** —\n  worked example: *\"do I need doca-rdma directly, or does doca-sta\n  hide it from me?\"*. Answered by the substrate-library rule in\n  [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy)\n  + the env-prep checklist in\n  [`TASKS.md ## configure`](TASKS.md#configure) step 1, which\n  routes the steering side to\n  [`doca-flow`](../doca-flow/SKILL.md) and the RDMA substrate\n  to [`doca-rdma`](../doca-rdma/SKILL.md).\n- **\"Is this STA capability available on my installed DOCA?\"** —\n  worked example: *\"is STA target acceleration supported on this\n  BlueField + DOCA version?\"*. Answered by the version-and-device\n  overlay in\n  [`CAPABILITIES.md ## Version compatibility`](CAPABILITIES.md#version-compatibility),\n  which cross-links the canonical detection chain in\n  [`doca-version`](../../doca-version/SKILL.md) and adds the\n  STA-specific cap-query rule (`pkg-config --modversion doca-sta`\n  is the build-time anchor; the runtime `doca_sta_cap_is_supported`\n  query is the truth).\n- **\"What does this `DOCA_ERROR_*` from a STA call mean and which\n  layer caused it?\"** — worked example: *\"`DOCA_ERROR_IO_FAILED`\n  on a submitted NVMe read I/O against a target I can ping\"*.\n  Answered by the STA 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`](../../doca-debug/SKILL.md).\n\n## Audience\n\nThis skill serves **external developers building NVMe-over-Fabrics\nstorage targets that consume DOCA STA on BlueField** — i.e., users\nwhose code calls `doca_sta_*` (directly in C/C++, or through\nFFI/bindings from another language) to accelerate the target-side\ndata path of an NVMe-oF target on the BlueField hardware: presenting\n`doca_sta_subsystem` targets (NQN + namespaces) backed by local\nNVMe-PCI disks (`doca_sta_be`) to remote initiators over RDMA. The\nskill is *not* for NVIDIA developers contributing to DOCA STA\nitself, and it is *not* for initiator/host-side NVMe stacks.\n\n**Language scope.** DOCA STA ships as a C library with\n`pkg-config` module name `doca-sta`. DOCA STA ships **no public\nsamples** — it is absent from the DOCA libraries /\nextension_libraries sample profiles — so the worked examples in\n`TASKS.md` build against the public headers directly rather than\nmodify a shipped sample. C and C++ consumers are the canonical\ncase. Other-language\nconsumers (Rust, Go, Python, …) consume the same `*.so` through\nFFI or language-specific bindings; the skill's contribution in\nthat case is to keep the target-model, lifecycle,\ncapability-discovery, queue-pair shape, substrate-dependency,\nand error-taxonomy guidance language-neutral, and to route the\nagent to the public C ABI as the authoritative surface that any\nwrapper will eventually call.\n\n## When to load this skill\n\nLoad this skill when the user is doing hands-on DOCA STA work,\nin any language. Concretely:\n\n- Initializing a `doca_sta` instance on a `doca_dev` opened\n  against a BlueField PF / SF and configuring the NVMe-oF\n  target subsystems before `doca_ctx_start()`.\n- Defining target resources — `doca_sta_subsystem` (NQN +\n  namespaces) and `doca_sta_be` backend controllers (local\n  NVMe-PCI disks) — and accepting NVMe-oF connections (admin\n  queue plus N I/O queues per connection) on the target side as\n  remote initiators connect over RDMA CM.\n- Reading or setting STA properties via the `doca_sta_set_*`\n  family, checking device support via `doca_sta_cap_is_supported`,\n  and querying sizing limits via the `doca_sta_get_max_*` family\n  (max I/O queue depth, max number of queue pairs, max I/O size,\n  max subsystems, max namespaces per subsystem, max backends).\n- Wiring the **NVMe-over-RDMA** transport — STA's only transport;\n  it lands on the `doca-rdma` substrate and uses RDMA CM for\n  connection establishment — for the target's I/O queues.\n- Wiring DOCA Flow rules so that NVMe-oF traffic actually\n  reaches the STA-managed queues — the steering boundary is\n  `doca-flow`, not `doca-sta`.\n- Debugging a `DOCA_ERROR_*` returned from a STA call (lifecycle\n  vs. capability vs. transport-layer I/O failure vs.\n  driver-below) and the per-queue events on the DOCA Core\n  progress engine.\n- Designing or extending non-C bindings (Rust, Go, Python, …)\n  that wrap the DOCA STA C ABI — for the lifecycle, queue-pair,\n  cap-query, and substrate-dependency rules the wrapper must\n  honor.\n\nDo **not** load this skill for general DOCA orientation, install\nof DOCA itself, raw RDMA data movement (use\n[`doca-rdma`](../doca-rdma/SKILL.md)), raw packet I/O on\nEthernet queues (use [`doca-eth`](../doca-eth/SKILL.md)),\nflow-rule programming (use [`doca-flow`](../doca-flow/SKILL.md)),\nor initiator/host-side NVMe stack development\n(SPDK or kernel-nvme own that, not this skill). For DOCA\ndocumentation orientation, use\n[`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.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 STA-specific\nmaterial lives in two companion files:\n\n- `CAPABILITIES.md` — what DOCA STA can express on this\n  version: the target object model (`doca_sta_subsystem` /\n  namespaces / `doca_sta_be` backend NVMe-PCI disks),\n  the NVMe queue-pair shape (admin queue + I/O queues over RDMA),\n  the RDMA-only transport,\n  the capability-query surface (`doca_sta_cap_is_supported` plus\n  the `doca_sta_get_max_*` sizing queries), the STA\n  error taxonomy (mapped onto the cross-library `DOCA_ERROR_*`\n  set), the observability surface (per-queue progress engine\n  events, capability snapshots), and the safety policy that\n  gates substrate-library, permission, and steering\n  preconditions.\n- `TASKS.md` — step-by-step workflows for the six in-scope\n  STA verbs: `configure`, `modify`, `build`, `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 BlueField (with DOCA installed at the\nstandard location) plus a remote NVMe-oF initiator reachable on\nthe fabric to connect into the accelerated target, and one or\nmore local NVMe-PCI disks to back the target's namespaces. It\ndoes not cover installing\nDOCA — that path goes through\n[`doca-setup`](../../doca-setup/SKILL.md). It does not cover\ninitiator/host-side NVMe stacks (SPDK `bdev_nvme`, kernel `nvme`\nhost) or NVMe protocol semantics above the accelerated target\ndata path — those are out of scope.\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 STA application source code, in any\n  language.** DOCA STA ships **no public samples** — there is no\n  `/opt/mellanox/doca/samples/doca_sta/` directory, and STA is\n  absent from the libraries / extension_libraries sample\n  profiles. The authoritative surface is the public headers under\n  $(pkg-config --variable=includedir doca-common) plus the public\n  DOCA STA guide; the agent builds against those directly rather\n  than modifying a shipped sample, per the\n  [`TASKS.md ## modify`](TASKS.md#modify) workflow.\n- **Initiator/host-side NVMe stack glue.** SPDK `bdev_nvme`,\n  the kernel `nvme` host, and any initiator-side NVMe stack are\n  upstream projects out of scope for this skill — DOCA STA is\n  target-side acceleration, not an initiator transport provider.\n- **Standalone build manifests** (`meson.build`, `CMakeLists.txt`,\n  `Cargo.toml`, …) parked inside the skill. The agent\n  constructs the build manifest *in the user's project\n  directory* against the user's installed DOCA, where\n  `pkg-config --modversion doca-sta` is the source of truth.\n- **A `samples/`, `bindings/`, or `reference/` subtree** of any\n  kind. A mock or incomplete artifact in this skill's tree,\n  even one labeled \"reference\", is misleading: users will\n  read it as buildable.\n\n## Loading order\n\n1. Read this `SKILL.md` first to confirm the user's question\n   is in scope.\n2. **For the STA capability matrix, the target object model,\n   queue-pair shape, RDMA-only transport, capability-query\n   rules, error taxonomy, observability, and safety policy,\n   see [CAPABILITIES.md](CAPABILITIES.md).**\n3. **For step-by-step workflows — configure, modify, build,\n   run, test, debug — see [TASKS.md](TASKS.md).**\n\nBoth companion files cross-link to each other,\n[`doca-version`](../../doca-version/SKILL.md) for the canonical\nversion-handling rules,\n[`doca-rdma`](../doca-rdma/SKILL.md) for the RDMA substrate\nthat NVMe-over-RDMA transport lands on,\n[`doca-flow`](../doca-flow/SKILL.md) for the steering rules\nthat direct NVMe traffic to STA-managed queues, and\n[`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md)\nwhenever the right answer is \"look it up in the public docs or\nthe installed package layout\" rather than \"STA-specific\nguidance\".\n\n## Related skills\n\n- [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md) —\n  the routing table for every public DOCA documentation source\n  and the on-disk layout of an installed DOCA package. The\n  STA URL slug is `DOCA-STA`.\n- [`doca-setup`](../../doca-setup/SKILL.md) — env preparation,\n  install verification, BlueField mode checks, and the\n  permission / group-membership requirements for opening a\n  `doca_dev`. This skill assumes its preconditions are\n  satisfied.\n- [`doca-version`](../../doca-version/SKILL.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 STA-specific overlay (STA target-acceleration\n  availability windows, NVMe-oF feature-set device-conditional\n  support).\n- [`doca-structured-tools-contract`](../../doca-structured-tools-contract/SKILL.md) —\n  the bundle's structured-tools precedence rule (detect /\n  prefer / fall back / report). The Command appendix in\n  [TASKS.md](TASKS.md) honors this contract.\n- [`doca-programming-guide`](../../doca-programming-guide/SKILL.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\n  layers STA specifics on top.\n- [`doca-rdma`](../doca-rdma/SKILL.md) — the RDMA substrate\n  that NVMe-over-RDMA transport lands on. STA hides most of\n  the RDMA queue-pair details from the consumer, but the user\n  still needs `doca-rdma` linked in and the device's RDMA\n  capabilities discoverable for the NVMe-over-RDMA path to\n  work.\n- [`doca-eth`](../doca-eth/SKILL.md) — the queue-pair\n  shape that STA's per-connection queue model echoes. Reach\n  here if the user is asking general questions about how\n  DOCA exposes queue-pairs that don't have an STA-specific\n  answer.\n- [`doca-flow`](../doca-flow/SKILL.md) — the steering\n  surface that decides which NVMe-oF packets land on which\n  STA-managed queue. DOCA STA does *not* program steering\n  itself; an NVMe-oF target whose connections never come up\n  is often a missing or wrong Flow rule, not a STA bug.\n- [`doca-debug`](../../doca-debug/SKILL.md) — the\n  cross-cutting debug ladder (install / version / build /\n  link / runtime / program / driver). STA-specific debug\n  (transport-type mismatches, queue-depth oversize,\n  IO-failed transport errors) overlays on top of that\n  ladder."}