DOCA RDMA Initiator
Guides accelerator-initiated one-sided RDMA development on the DPA datapath.
The documentation clearly scopes operation to a local DOCA installation, explains DPA-handle lifetime, remote-memory-operation risk, experimental APIs, and hardware-change safety boundaries, with no evidence of malware, credential theft, or covert exfiltration. Points are deducted because user confirmation, sensitive-data handling, least-privilege requirements, and executable rollback procedures remain incomplete; license metadata also conflicts between SKILL.md and the skill cards.
SKILL.md, CAPABILITIES.md, and TASKS.md provide a fairly complete install, configure, build, run, test, and debug path with diagnosable failure classes. Static calibration caps this dimension at 10; points are deducted because nothing was executed, the workflow depends on specific BlueField/DPA hardware, DOCA versions, and a remote responder, and command or symbol correctness cannot be confirmed from the files alone.
The audience, trigger phrases, supported DPA one-sided RDMA scenarios, and routing boundaries to doca-rdma, doca-dpa, and related skills are explicit; C, FFI, and DPA-toolchain scope is also stated. Points are deducted for no practical Chinese-language examples or mainland-China reachability evidence, and because core use depends on local DOCA hardware and installation conditions.
The skill uses a thin loader plus CAPABILITIES.md and TASKS.md progressive-disclosure structure, with examples, dependencies, limitations, version policy, safety policy, and related skills. Points are deducted because BENCHMARK.md reports missing recommended Instructions/Examples sections and an author field, while version, signature, source-repository, and license metadata conflict across SKILL.md, SKILLCARD.yaml, and skill-card.md; maintenance and update ownership are not fully specified.
For users with DOCA installed and suitable hardware, the skill supplies actionable pkg-config checks, capability discovery, sample discovery, lifecycle guidance, completion observability, and debugging workflows for core RDMI tasks. Static calibration caps this dimension at 7; points are deducted because no runnable sample or verified output is included, DPA implementation is delegated elsewhere, and end-to-end success still requires the user's hardware, network, and remote responder.
The files provide concrete APIs, commands, lifecycle conditions, error classifications, and version-check rules, while identifying installed headers and public documentation as authorities. Static calibration caps this dimension at 5; points are deducted because the benchmark claims passing results without supplying the source dataset, committed coverage tests, or independently reproducible third-party execution evidence.
- This is a low-confidence static review; no commands, builds, or hardware tests were executed. Do not treat the PASS claims in BENCHMARK.md as independent reproduction evidence.
- Recheck every experimental symbol and lifecycle rule against the target DOCA installation's headers, libraries, and pkg-config metadata before use.
- For remote-memory writes, DPA handles, or hardware-state changes, confirm the target, authorization, responder, and recovery plan first; the skill does not make user confirmation a complete mandatory gate.
- Reconcile license, source, version, signature, and maintenance metadata across SKILL.md, SKILLCARD.yaml, and skill-card.md.
What does this skill do, and when should you use it?
This skill provides hands-on guidance for NVIDIA DOCA RDMI, targeting one-sided RDMA operations initiated by a BlueField DPA toward a remote responder. It helps developers choose doca-rdmi versus doca-rdma, configure connections and posters, attach completion contexts, and hand DPA handles to kernels. It also covers EXPERIMENTAL symbol checks, DOCA_ERROR_* diagnosis, and safety boundaries. It assumes DOCA is already installed and does not install DOCA itself.
It reads local installation information through pkg-config doca-rdmi, doca-common, doca-verbs, and doca-dpa, and inspects /opt/mellanox/doca/{lib,include,samples}. It guides creation of doca_rdmi_connection or doca_rdmi_poster, attachment of doca_dpa_completion or doca_verbs_cq, configuration before doca_ctx_start(), retrieval of DPA-side handles, and receive-completion acknowledgment. It also identifies EXPERIMENTAL symbols for the installed version and analyzes DOCA_ERROR_* returns across configuration, lifecycle, device-capability, and lower-layer causes. It provides install, configure, build, modify, run, test, debug, use, and rollback workflows, but does not ship compilable RDMI source, DPA kernel templates, or standalone build manifests.
- A developer building a BlueField DPA kernel that must initiate RDMA writes or reads against a remote responder.
- A DOCA user deciding whether a new one-sided RDMA workload belongs on doca-rdmi or doca-rdma.
- A developer creating an RDMI connection, attaching a DPA completion context, and passing its handle to a kernel.
- An application developer whose application both receives work requests and posts RDMA writes, requiring the connection-versus-poster model.
- A developer checking whether installed RDMI symbols are EXPERIMENTAL or diagnosing a DOCA_ERROR_* return.
What are this skill's strengths and limitations?
- Focused specifically on DPA-initiated one-sided RDMA, with explicit scope and routing boundaries.
- Covers connections, posters, DPA handles, completions, version checks, and error diagnosis in one workflow.
- Uses the user's installed DOCA package and `pkg-config --modversion doca-rdmi` as the version source of truth.
- Explicitly refuses to author potentially changing EXPERIMENTAL RDMI source from prose documentation.
- Requires DOCA to be installed and suitable Linux, BlueField, or ConnectX hardware to be available.
- Does not provide compilable application source, DPA kernel templates, samples, bindings, or standalone build files.
- The source provides no concrete test coverage, supported-version matrix, or performance data.
- The DPA programming model, kernel build, and execution model are primarily delegated to doca-dpa.
How do you install this skill?
Install the named skill with the NVIDIA skills CLI:npx skills add nvidia/skills --skill doca-rdmi --yes
The CLI prompts for the installation destination; the skill becomes available when the agent encounters a relevant task. The source does not require manually copying the skills/doca-rdmi directory.
How do you use this skill?
On a Linux host or BlueField with DOCA installed, trigger the skill with a concrete task such as: My DPA kernel needs to post RDMA writes to a remote responder; should I use doca-rdmi or doca-rdma? You can also ask how to configure a doca_rdmi_connection, attach a doca_dpa_completion, check whether doca_rdmi_poster_post is stable, or diagnose DOCA_ERROR_BAD_STATE. Missing or mismatched DOCA prerequisites, DOCA installation, host-CPU two-sided RDMA, GPU-initiated RDMA, and general RDMA concepts should be routed elsewhere.
How does this skill compare with similar options?
Compared with doca-rdma, doca-rdmi is the focused surface for DPA-initiated one-sided RDMA; two-sided or host-CPU-initiated RDMA belongs to doca-rdma. Compared with doca-gpi, doca-rdmi targets the DPA while doca-gpi targets GPU-kernel RDMA initiation. The DPA programming model itself belongs to doca-dpa.