What does this skill do, and when should you use it?
This skill is for external developers using the DOCA Comch C library to exchange control or data messages between a host process and a BlueField agent over PCIe. It covers DPU-server and host-client roles, connection lifecycle, slow-path versus fast-path choices, capability discovery, permission issues, and DOCA_ERROR_* troubleshooting. It assumes DOCA is already installed and uses CAPABILITIES.md and TASKS.md for detailed guidance. It does not cover DOCA installation, firmware bring-up, non-Comch libraries, or large-scale deployment.
Reads the local pkg-config doca-comch installation information and inspects /opt/mellanox/doca/{lib,include,samples,applications}. It guides configuration of doca_comch_server, doca_comch_client, receive callbacks, producers/consumers, and connection callbacks; queries maximum message size, maximum clients, and queue properties; and provides configure, build, modify, run, test, and debug workflows. It classifies DOCA_ERROR_* failures across lifecycle, permission, capability, and would-block layers.
- A host-and-BlueField developer needs to bring up a Comch channel with the DPU as server, the host as client, and exchange an initial control message.
- A developer moving higher-throughput data needs to choose between the slow send-task/recv-callback path and the fast producer/consumer path.
- A developer needs to check whether a Comch capability exists in the installed DOCA version, including the DOCA 2.5 Comm Channel rename.
- A developer is diagnosing an invisible representor, `DOCA_ERROR_NOT_PERMITTED`, `DOCA_ERROR_AGAIN`, or a connection callback that never fires.
- A Rust, Go, or Python FFI maintainer needs language-neutral guidance for the Comch C ABI lifecycle, roles, permissions, and capabilities.
How do you install this skill?
- Add explicit user confirmation, privilege scoping, and output-redaction requirements before running sudo, mlxconfig, dmesg, or device-diagnostic commands.
- The client connection-state callback description is inconsistent; verify the API against the installed DOCA headers and official documentation before use.
- Do not treat the benchmark's unreproducible results as independent test evidence; add committed, repeatable tests and CI.
- Unify and populate the license, version, signature, and maintenance metadata.
- Shell / CLI
- Local filesystem
DOCA SDK installed at /opt/mellanox/docaLinux host + BlueField pairpkg-config
Install the individual skill with the default skills CLI: npx skills add nvidia/skills --skill doca-comch --yes. The README does not specify another required destination; the CLI prompts for the installation target.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/doca-comch" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Ensure that the Linux host and BlueField pair already have the DOCA SDK installed. Then give the agent a concrete request such as: Configure a DOCA Comch channel between the host and BlueField DPU, with the DPU as server and the host as client, and exchange one control message. For configure, build, modify, run, test, or debug tasks, the skill uses TASKS.md; for capability questions, it uses CAPABILITIES.md.
What are this skill's strengths and limitations?
- Covers Comch roles, lifecycle, slow-path and fast-path communication.
- Includes capability queries, connection observability, permission policy, and layered error diagnosis.
- Applies to C/C++ and other languages using the same C ABI through FFI.
- Clearly routes DOCA installation, firmware bring-up, and non-Comch questions elsewhere.
- Requires an existing DOCA SDK, Linux host, and BlueField pair; it does not install DOCA or handle firmware bring-up.
- It is a thin loader and does not include buildable application source, bindings, sample subtrees, or standalone build manifests.
- The supplied SKILL.md does not include the full contents of CAPABILITIES.md or TASKS.md, and provides no concrete test results.
- It mentions sudo as an expected DPU-side privilege for host-representor visibility but does not document validation across all hardware and platform combinations.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| DOCA Comch Host–DPU Messaging this page ✓ NVIDIA · Official | 53 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA Environment Setup ✓ NVIDIA · Official | 57 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA Programming Guide ✓ NVIDIA · Official | 54 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA RDMA Programming Guide ✓ NVIDIA · Official | 56 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
| DOCA SHA Acceleration ✓ NVIDIA · Official | 56 · Use with care | ★ 3.6k | 13d ago | Apache-2.0 |
How did FollowSkills review this skill?
The skill clearly scopes itself to an already-installed DOCA environment and a host/BlueField pair, separates host/DPU roles, requires representor, PCIe, and capability checks, and warns against secret disclosure. However, it includes sudo, mlxconfig, device, and kernel-diagnostic commands without explicit confirmation gates, least-privilege limits, sensitive-data handling, rollback, or recovery procedures, so points are deducted.
The documents provide a fairly complete lifecycle, error taxonomy, progress-engine guidance, and layered debugging flow, with a static benchmark report. Nothing was executed here, so key-path reliability rests on textual consistency. The files also contain inconsistent descriptions of client connection callbacks, several overly strong “always/most often” claims, and no reproducible abnormal-input examples; the score remains below the static ceiling.
Triggers, audience, environment, slow/fast-path selection, and out-of-scope boundaries are explicit, including C/C++ and FFI consumers. There is no Chinese-language guidance or terminology mapping, and mainland-China network fit is not discussed. The core function also depends on local Linux, the DOCA SDK, BlueField hardware, and representor availability, limiting general applicability.
The SKILL.md loader and CAPABILITIES.md/TASKS.md split provide useful progressive disclosure, dependency notes, version handling, command guidance, limitations, related skills, evaluation material, and issue contacts. However, the benchmark identifies missing recommended Instructions/Examples sections; author, version, signature, and signing fields remain TBD; and license declarations differ across files, leaving governance and maintenance details incomplete.
The intended tasks, role split, capability queries, build, run, test, and debugging workflows are concrete enough to support the core use case. However, the skill ships no runnable examples or templates, depends on local samples and companion skills, and was not executed in this review. The benchmark reports effectiveness but its dataset is unavailable, so only a conservative static score is justified.
Evidence includes concrete API symbols, commands, error mappings, cross-links, eval definitions, and a benchmark report. The evaluation dataset, CI/test suite, and independent reproduction materials are absent; SKILLCARD signature and scan fields are also TBD. Many technical claims therefore cannot be cross-checked from the supplied files, warranting a low score.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →