Doca Sta

DOCA STA (Storage Target Acceleration)

Where to start: This skill assumes DOCA is already installed and the user is doing hands-on NVMe-over-Fabrics storage-target work on a BlueField-class device with DOCA. Open TASKS.md if the user wants to do something (configure / modify / build / run / test / debug); open CAPABILITIES.md when the question is what can DOCA STA express on this version. If the user has not installed DOCA yet, route to doca-setup first. If the user is asking "is this an NVMe-oF initiator/host transport?", the answer is no — doca-sta accelerates the target side: it presents NVMe-oF doca_sta_subsystem targets backed by local NVMe-PCI disks; the model lives in CAPABILITIES.md ## Capabilities and modes.

Example questions this skill answers well

The CLASSES of DOCA STA questions this skill is built to answer, each with one worked example. The agent should treat the class as the load-bearing piece — the worked example is a single instance.

• "How do I bring up an NVMe-oF target that uses the BlueField to accelerate the storage data path?" — worked example: "define a doca_sta_subsystem (NQN) with one namespace backed by a local NVMe-PCI disk (doca_sta_be) and accept NVMe-over-RDMA connections from a remote initiator". Answered by the target-model-and-lifecycle workflow in TASKS.md ## configure + CAPABILITIES.md ## Capabilities and modes target-object table.
• "Can this BlueField accelerate an NVMe-oF target at all?" — worked example: "my data center is RoCE end-to-end; does this device support DOCA STA target acceleration?". STA transport is RDMA-only (there is no NVMe-over-TCP path). Answered by the capability-query rule (doca_sta_cap_is_supported against a doca_devinfo) in CAPABILITIES.md ## Capabilities and modes
  • the discovery step in TASKS.md ## configure.
• "How deep can I size my I/O queues, and how many I/O queues per connection?" — worked example: "I want 16 I/O queues at depth 1024 each — does this device support that?". Answered by the queue-sizing capability surface in CAPABILITIES.md ## Capabilities and modes
  • the queue-sizing step in TASKS.md ## configure which gates on the matching doca_sta_get_max_* query (e.g. doca_sta_get_max_qps, doca_sta_get_max_io_queue_size).
• "Which other DOCA libraries do I need alongside doca-sta?" — worked example: "do I need doca-rdma directly, or does doca-sta hide it from me?". Answered by the substrate-library rule in CAPABILITIES.md ## Safety policy
  • the env-prep checklist in TASKS.md ## configure step 1, which routes the steering side to doca-flow and the RDMA substrate to doca-rdma.
• "Is this STA capability available on my installed DOCA?" — worked example: "is STA target acceleration supported on this BlueField + DOCA version?". Answered by the version-and-device overlay in CAPABILITIES.md ## Version compatibility, which cross-links the canonical detection chain in doca-version and adds the STA-specific cap-query rule (pkg-config --modversion doca-sta is the build-time anchor; the runtime doca_sta_cap_is_supported query is the truth).
• "What does this DOCA_ERROR_* from a STA call mean and which layer caused it?" — worked example: "DOCA_ERROR_IO_FAILED on a submitted NVMe read I/O against a target I can ping". Answered by the STA overlay on the cross-library taxonomy in CAPABILITIES.md ## Error taxonomy
  • the layered ladder in TASKS.md ## debug that escalates to doca-debug.

Audience

This skill serves external developers building NVMe-over-Fabrics storage targets that consume DOCA STA on BlueField — i.e., users whose code calls doca_sta_* (directly in C/C++, or through FFI/bindings from another language) to accelerate the target-side data path of an NVMe-oF target on the BlueField hardware: presenting doca_sta_subsystem targets (NQN + namespaces) backed by local NVMe-PCI disks (doca_sta_be) to remote initiators over RDMA. The skill is not for NVIDIA developers contributing to DOCA STA itself, and it is not for initiator/host-side NVMe stacks.

Language scope. DOCA STA ships as a C library with pkg-config module name doca-sta. DOCA STA ships no public samples — it is absent from the DOCA libraries / extension_libraries sample profiles — so the worked examples in TASKS.md build against the public headers directly rather than modify a shipped sample. C and C++ consumers are the canonical case. Other-language consumers (Rust, Go, Python, …) consume the same *.so through FFI or language-specific bindings; the skill's contribution in that case is to keep the target-model, lifecycle, capability-discovery, queue-pair shape, substrate-dependency, and error-taxonomy guidance language-neutral, and to route the agent to the public C ABI as the authoritative surface that any wrapper will eventually call.

When to load this skill

Load this skill when the user is doing hands-on DOCA STA work, in any language. Concretely:

• Initializing a doca_sta instance on a doca_dev opened against a BlueField PF / SF and configuring the NVMe-oF target subsystems before doca_ctx_start().
• Defining target resources — doca_sta_subsystem (NQN + namespaces) and doca_sta_be backend controllers (local NVMe-PCI disks) — and accepting NVMe-oF connections (admin queue plus N I/O queues per connection) on the target side as remote initiators connect over RDMA CM.
• Reading or setting STA properties via the doca_sta_set_* family, checking device support via doca_sta_cap_is_supported, and querying sizing limits via the doca_sta_get_max_* family (max I/O queue depth, max number of queue pairs, max I/O size, max subsystems, max namespaces per subsystem, max backends).
• Wiring the NVMe-over-RDMA transport — STA's only transport; it lands on the doca-rdma substrate and uses RDMA CM for connection establishment — for the target's I/O queues.
• Wiring DOCA Flow rules so that NVMe-oF traffic actually reaches the STA-managed queues — the steering boundary is doca-flow, not doca-sta.
• Debugging a DOCA_ERROR_* returned from a STA call (lifecycle vs. capability vs. transport-layer I/O failure vs. driver-below) and the per-queue events on the DOCA Core progress engine.
• Designing or extending non-C bindings (Rust, Go, Python, …) that wrap the DOCA STA C ABI — for the lifecycle, queue-pair, cap-query, and substrate-dependency rules the wrapper must honor.

Do not load this skill for general DOCA orientation, install of DOCA itself, raw RDMA data movement (use doca-rdma), raw packet I/O on Ethernet queues (use doca-eth), flow-rule programming (use doca-flow), or initiator/host-side NVMe stack development (SPDK or kernel-nvme own that, not this skill). For DOCA documentation orientation, use doca-public-knowledge-map.