DOCA STA Storage Target Acceleration
Build and debug RDMA NVMe-oF storage targets accelerated by DOCA STA on BlueField.
The files clearly scope the skill to target-side work, declare dependencies, require capability checks, permission checks, user confirmation, and layered escalation. No credential theft, covert exfiltration, or destructive default is evident. Deductions apply because rollback and recovery procedures are not explicit, hardware/storage risk boundaries depend on other skills, and license/source metadata is inconsistent.
Configuration, build, test, and debug workflows are structured and include prerequisites, error taxonomy, and escalation paths. The static-review ceiling applies because key paths were not executed; several API, path, and version claims cannot be independently confirmed from the supplied material, so points are deducted for limited reproducibility, test coverage, and runtime failure evidence.
Audience, trigger phrases, capability boundaries, and out-of-scope cases are unusually explicit, with coverage for C/C++ and FFI consumers. Deductions apply because Chinese-language support is asserted rather than demonstrated, the hardware/DOCA/RDMA prerequisites are demanding, and mainland-China reachability of external documentation is not addressed.
The skill uses a layered SKILL.md, CAPABILITIES.md, and TASKS.md structure with loading order, dependencies, limitations, related skills, version checks, and maintenance contacts. Points are deducted for missing explicit authorship, changelog, and stable versioning; the benchmark notes missing recommended Instructions/Examples sections, and the supplied skill-card has path, license, and placeholder metadata inconsistencies.
The workflow can directly guide target modeling, capability discovery, queue sizing, building, and layered troubleshooting, so the core task appears useful. Static review did not verify representative outputs or end-to-end behavior; the benchmark reports PASS but does not include its underlying dataset, warranting only a conservative core-task score.
The material provides symbols, commands, error mappings, evaluation metrics, and audit contacts, but the evaluation dataset is unavailable and no committed CI/test suite covering key paths is supplied. The assessment therefore rests mainly on the skill's own claims and cannot receive multi-source or independently reproducible evidence credit.
- Do not treat the API names, version-match rules, or DOCA behavior in the skill as execution-verified; defer to the installed headers, pkg-config results, and runtime capability queries.
- Before changing hardware, storage, Flow steering, permissions, or the data path, confirm user intent, exact scope, and a recovery plan.
- License, path, version, and evaluation metadata are inconsistent across SKILL.md, BENCHMARK.md, SKILLCARD.yaml, and skill-card.md; reconcile them and add reproducible test evidence before publication.
- The core function depends on NVIDIA DOCA, BlueField/ConnectX hardware, and RDMA; Chinese-language behavior and documentation reachability from mainland-China networks are not demonstrated.
What does this skill do, and when should you use it?
This engineering skill guides developers who build NVMe-over-Fabrics storage targets with DOCA STA on a BlueField DPU or ConnectX NIC. It covers target subsystems, namespaces, local NVMe-PCI backend disks, RDMA transport, queue-capacity queries, and error diagnosis. It is limited to target-side acceleration and excludes DOCA installation, raw RDMA, Flow rule implementation, and initiator-side host NVMe stacks. It is intended for environments where DOCA is already installed and a remote initiator can reach the target.
The skill directs the agent to inspect the local DOCA installation with pkg-config and relevant directories, then guides creation and configuration of a doca_sta Core context, doca_sta_subsystem targets, namespaces, and doca_sta_be backends. It uses doca_sta_cap_is_supported and doca_sta_get_max_* queries to assess device support and queue limits. It explains NVMe-over-RDMA integration, the DOCA Flow steering boundary, and layered diagnosis of DOCA_ERROR_* results and per-queue progress events. It routes users to CAPABILITIES.md and TASKS.md, but does not ship buildable source code, samples, bindings, or standalone build manifests.
- An NVMe-oF target developer needs to expose namespaces backed by local NVMe-PCI disks through a BlueField device.
- A storage engineer in an RDMA or RoCE environment needs to verify whether a device supports DOCA STA target acceleration.
- A developer needs to size per-connection I/O queues, queue depth, I/O size, or the number of supported subsystems and backends.
- A target connection fails or an NVMe read returns DOCA_ERROR_IO_FAILED, requiring separation of STA, transport, and driver causes.
- A Rust, Go, or Python developer needs to design bindings around the public DOCA STA C ABI.
What are this skill's strengths and limitations?
- Clearly scoped coverage of the NVMe-oF target object model, lifecycle, capability discovery, queue sizing, and error taxonomy.
- Explicitly separates STA, the RDMA substrate, and DOCA Flow responsibilities.
- Useful for C/C++ projects and for other languages using FFI or bindings to the public C ABI.
- Includes guidance for version checks, device capabilities, permissions, and the local DOCA layout.
- Requires DOCA to be installed in advance, plus compatible BlueField or ConnectX hardware and local NVMe-PCI disks.
- Supports NVMe-over-RDMA only; it does not cover NVMe-over-TCP.
- Does not provide runnable DOCA STA samples, templates, bindings, or standalone build files.
- Excludes initiator-side host NVMe stacks, DOCA installation, raw RDMA, and detailed Flow rule implementation.
How do you install this skill?
Install the skill from the NVIDIA/skills collection with: npx skills add nvidia/skills --skill doca-sta --yes. To target an agent, for example: npx skills add nvidia/skills --skill doca-sta --agent codex. The skill loads when the agent encounters a relevant task. The source does not document DOCA SDK installation; it requires DOCA to already be installed at /opt/mellanox/doca.
How do you use this skill?
After installation, ask for a concrete target-side task, such as: “Configure a DOCA STA subsystem on BlueField backed by a local NVMe-PCI disk and accepting remote NVMe-over-RDMA connections.” Other suitable prompts include: “Does this device support 16 I/O queues at depth 1024?” and “How should I diagnose DOCA_ERROR_IO_FAILED on an NVMe read?” Load TASKS.md for configure, modify, build, run, test, or debug workflows, and CAPABILITIES.md for capability questions.
How does this skill compare with similar options?
Unlike doca-rdma, this skill focuses on the NVMe-oF storage-target layer while doca-rdma provides the RDMA substrate. Unlike doca-flow, it does not implement packet steering. Unlike SPDK or kernel-nvme host stacks, it addresses target-side acceleration rather than initiator-side or host-side NVMe work.