AutoGineer
Generated banner for Doca Comch
Generated logo for Doca Comch

Doca Comch

NVIDIAOfficialCreated by NVIDIA

  • Skill
  • Tool integration
  • Software development
  • Apache-2.0
  • Medium risk
Download ZIP

From the author

Use this skill when the user is doing hands-on DOCA Comch work on a host + BlueField pair — bringing up host ↔ DPU PCIe control-plane messaging, picking server (DPU) vs client (host) roles, choosing slow-path send-task / recv-callback vs fast-path producer / consumer, querying max-msg-size or max-clients capabilities, registering connection callbacks, or debugging DOCA_ERROR_* returns from the Comch API. Trigger even when the user does not explicitly mention "DOCA Comch" or "Comm Channel" (renamed in DOCA 2.5) — typical implicit phrasings include "send a control message from host to BlueField over PCIe", "DPU can't see the host representor", "DOCA_ERROR_NOT_PERMITTED on server_create", "DOCA_ERROR_AGAIN on task_send submit", "connect callback never fires", or "stream bulk data from a host driver to a DPU agent". Refuse and route elsewhere for installing DOCA itself, BFB / firmware bring-up, non-Comch DOCA libraries, or deploying Comch apps at scale — those belong to other skills.
— the description by NVIDIA

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides specialized support for developers building applications that utilize the DOCA Comch library to exchange control or data messages between a host and a BlueField DPU over PCIe. It covers the full lifecycle of Comch development, including role selection (server vs. client), path optimization (slow-path vs. fast-path), connection management, and debugging API errors. The skill is designed to integrate with existing DOCA installations and provides structured workflows for configuring, building, and troubleshooting Comch-based communication channels.

What it does

  • Guides the initialization of Comch servers on DPUs and clients on hosts.
  • Assists in choosing between slow-path (task/callback) and fast-path (producer/consumer) communication modes.
  • Provides workflows for configuring connection callbacks and managing state transitions.
  • Helps debug DOCA_ERROR_* codes specific to the Comch API.
  • Explains how to query and set library capabilities like message sizes and client limits.
  • Maps Comch-specific terminology and versioning changes, such as the 2.5 rename from Comm Channel.

When to use it

  • When implementing PCIe control-plane messaging between a host and a BlueField DPU.
  • When debugging connection failures or representor visibility issues.
  • When optimizing data streaming performance using producer/consumer fast-paths.
  • When needing to understand the Comch error taxonomy and lifecycle requirements.
  • When developing language bindings that wrap the Comch C ABI.

Advantages

  • Provides clear, structured workflows for complex DPU-host communication tasks.
  • Offers specific guidance on performance optimization through path selection.
  • Ensures consistent handling of DOCA versioning and library-specific error codes.
  • Integrates seamlessly with standard DOCA development environments and tools.
  • Reduces development friction by providing clear paths for common configuration and debugging scenarios.

Usage examples

“Send a control message from host to BlueField over PCIe.”
The agent will guide you through selecting the appropriate server/client roles and implementing the necessary send/recv logic using the Comch API.
“Why is doca_comch_server_create returning DOCA_ERROR_NOT_PERMITTED?”
The agent will help you verify representor visibility and DPU-side permissions, routing to setup documentation if environment issues are detected.
“How do I stream bulk data from a host driver to a DPU agent with low CPU?”
The agent will direct you to the fast-path producer/consumer implementation workflow to ensure efficient data transfer.
“Is doca_comch_producer available in my DOCA version?”
The agent will check your installed version and confirm availability, providing guidance on whether to use the new API or the legacy slow-path.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/nvidia/doca-comch/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip doca-comch.zip -d .agents/skills

Documentation by NVIDIA

DOCA Comch

Examples

  • "Send a control message from host to BlueField over PCIe." — this is in scope. Pick server (DPU) vs client (host) and stay on the Comch send/recv path; do not fall back to TCP.

  • "Connect callback never fires." — check role, representor visibility, and the 2.5 rename overlay before rewriting the app as raw verbs.

Instructions

Follow Loading order below. Open the tasks companion for configure / modify / debug. Open the capabilities companion for slow-path vs fast-path and the 2.5 rename. Do not open every companion file.

Where to start: This skill assumes DOCA is already installed and the user is doing hands-on Comch work on a BlueField + host pair with DOCA. Open the tasks companion if the user wants to do something (configure / build / modify / run / test / debug); open the capabilities companion when the question is what can Comch express on this version. If the user has not installed DOCA yet, route to doca-setup/SKILL.md first. If the user is asking "is Comch even on this DOCA" because the docs they read mention doca-comm-channel, route to

Version compatibility

for the 2.5 rename.

Example questions this skill answers well

The CLASSES of Comch 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 a Comch channel between host and DPU?" — worked example: "server side on the DPU, client side on the host, exchange a first control message". Answered by the role-selection + lifecycle workflow in

    configure +

    Capabilities and modes

    server-vs-client table.

  • "How do I move bulk data over Comch with low CPU?" — worked example: "stream a 64 KiB chunk every 100 µs from the host driver to a DPU agent". Answered by the producer / consumer fast-path described in

    Capabilities and modes

    • the channel-setup workflow in

    configure

    step 4, with the "slow-path vs fast-path" selection rule.

  • "What is the maximum message size I can send?" — worked example: "can I send a 4 MiB control message in one shot?". Answered by the capability-query rule (doca_comch_cap_get_max_msg_size) in

    Capabilities and modes

    • the property-set workflow in

    modify.

  • "Why doesn't the DPU side see the representor?" — worked example: "doca_comch_server_create returns DOCA_ERROR_NOT_PERMITTED on a freshly imaged BlueField". Answered by the representor + permission overlay in

    Safety policy

    • the env-prep checklist in

    configure step 1, which

    routes representor-side env questions to doca-setup/SKILL.md.

  • "Is this Comch capability on my installed DOCA version?" — worked example: "is doca_comch_producer in DOCA 2.6.0, or do I still need the old slow-path API?". Answered by the version-compatibility overlay in

    Version compatibility,

    which cross-links the canonical detection chain in doca-version/SKILL.md and adds the Comch-specific 2.5 rename rule.

  • "What does this DOCA_ERROR_* from a Comch call mean and which layer caused it?" — worked example: "DOCA_ERROR_AGAIN on submitting a doca_comch_task_send via doca_task_submit". Answered by the Comch overlay on the cross-library taxonomy in

    Error taxonomy

    • the layered ladder in

    debug that escalates to

    doca-debug/SKILL.md.

Audience

This skill serves external developers building applications that consume the DOCA Comch library — i.e., users whose code calls doca_comch_* (directly in C/C++, or through FFI/bindings from another language) to exchange control or data messages between a host process and a BlueField agent over PCIe. It is not for NVIDIA developers contributing to DOCA Comch itself.

Language scope. DOCA Comch ships as a C library with pkg-config module name doca-comch. The shipped samples are written in C. C and C++ consumers are the canonical case; the worked examples in the tasks companion assume that path. 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 role-split, lifecycle, capability-discovery, permission, 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 Comch work, in any language. Concretely:

  • Initializing a doca_comch_server on the DPU side or a doca_comch_client on the host side, on a representor or PCIe address the host can reach.

  • Configuring at least one of: a recv callback for slow-path messages, a producer for fast-path outbound data, a consumer for fast-path inbound data, before doca_ctx_start().

  • Reading or setting comch properties via doca_comch_set_* and doca_comch_cap_get_* — max message size, max number of clients (server side), producer / consumer queue sizing.

  • Establishing a connection between the two sides and reacting to connection-state transitions via the connection callbacks registered before start.

  • Choosing between the slow-path (send-task / recv-callback, message-oriented, lower throughput, single-call simplicity) and the fast-path (producer / consumer, asynchronous, much higher throughput, two-context setup).

  • Debugging a DOCA_ERROR_* returned from a Comch call (lifecycle vs. permission vs. capability vs. would-block) and the connection state machine across the host / DPU pair.

  • Designing or extending non-C bindings (Rust, Go, Python, …) that wrap the Comch C ABI — for the lifecycle, role-split, permission, and capability rules the wrapper must honor.

Do not load this skill for general DOCA orientation, install of DOCA itself, or non-Comch library questions. For those, use doca-public-knowledge-map/SKILL.md.

What this skill provides

This is a thin loader. The body keeps only the orientation needed to pick the right next file. The substantive Comch-specific material lives in two companion files:

  • the capabilities companion — what Comch can express on this version: the server vs client role split, the slow-path send-task / recv-callback surface, the producer / consumer fast-path surface, the capability-query surface (doca_comch_cap_get_*), the Comch error taxonomy (mapped onto the cross-library DOCA_ERROR_* set), the observability surface (connection state callbacks, task completion callbacks), and the safety policy that gates representor and permission decisions.

  • the tasks companion — step-by-step workflows for the six in-scope Comch verbs: configure, build, modify, run, test, debug. Plus a Deferred task verbs block that points out-of-scope questions at the right next skill.

The skill assumes a host + BlueField pair where DOCA is already installed at the standard location and the user has the privileges their public install profile expects (in particular, sudo on the DPU side to see the host representor). It does not cover installing DOCA — that path goes through doca-setup/SKILL.md.

What this skill deliberately does not ship

This skill is agent guidance, not a samples or templates bundle. To keep the boundary clean, it deliberately does not contain — and pull requests should not add:

  • Pre-written DOCA Comch application source code, in any language. The verified Comch source code is the shipped C samples at /opt/mellanox/doca/samples/doca_comch/<name>/. The agent's job is to route the user to those files and prescribe a minimum-diff modification on them via the universal modify-a-sample workflow in doca-programming-guide/SKILL.md, layered with the Comch-specific overrides in

    modify.

  • Standalone build manifests (meson.build, CMakeLists.txt, Cargo.toml, …) parked inside the skill. The agent constructs the build manifest in the user's project directory against the user's installed DOCA, where pkg-config --modversion doca-comch is the source of truth.

  • A samples/, bindings/, or reference/ subtree of any kind. A mock or incomplete artifact in this skill's tree, even one labeled "reference", is misleading: users will read it as buildable.

Loading order

  1. Read this skill first to confirm the user's question is in scope.

  2. For the Comch capability matrix, role split, slow-path / fast-path surfaces, permission policy, error taxonomy, observability, and safety policy, see the capabilities companion.

  3. For step-by-step workflows — configure, build, modify, run, test, debug — see the tasks companion.

Both companion files cross-link to each other, doca-version/SKILL.md for the canonical version-handling rules, and doca-public-knowledge-map/SKILL.md whenever the right answer is "look it up in the public docs or the installed package layout" rather than "Comch-specific guidance".

Related skills

  • doca-public-knowledge-map/SKILL.md — the routing table for every public DOCA documentation source and the on-disk layout of an installed DOCA package. The Comch URL slug is DOCA-Comch (DOCA 2.5+), not doca-comm-channel.

  • doca-setup/SKILL.md — env preparation, install verification, representor visibility checks, and the I have no install yet path with the public NGC DOCA container. This skill assumes its preconditions are satisfied.

  • doca-version/SKILL.md — canonical DOCA version-handling rules. This skill's ## Version compatibility cross-links the four-way match rule and adds the Comch-specific 2.5 rename overlay.

  • doca-structured-tools-contract/SKILL.md — the bundle's structured-tools precedence rule (detect / prefer / fall back / report). The Command appendix in the tasks companion honors this contract.

  • doca-programming-guide/SKILL.md — general DOCA programming patterns shared by every library: the canonical pkg-config + meson build pattern, the universal modify-a-shipped-sample first-app workflow, the universal lifecycle, the cross-library DOCA_ERROR_* taxonomy, and the program-side debug order. This skill layers Comch specifics on top.

  • doca-debug/SKILL.md — the cross-cutting debug ladder (install / version / build / link / runtime / program / driver). Comch-specific debug (lifecycle violations, representor visibility, slow-path vs fast-path queue-full symptoms) overlays on top of that ladder.

Files

CAPABILITIES.md

DOCA Comch capabilities, version overlay, errors, observability, safety

Where to start: Pick the H2 anchor that matches your question (roles / slow-path / fast-path / capabilities / errors / safety) and read that section end-to-end. The tables in each section are the load-bearing content; the prose around them is interpretation.

Read this file when the loader sent you here from SKILL.md. For the how of executing each pattern (the verbs configure / build / modify / run / test / debug), jump to TASKS.md. For the canonical DOCA version-handling rules that this skill layers a Comch overlay on top of, see doca-version/SKILL.md.

Pattern overview

Every Comch question this skill teaches resolves into one of FIVE patterns. The patterns are CLASSES — they apply across every Comch release and every host / DPU pair.

PatternWhen it applies (class shape)Where the substance lives
1. Pick the roleDecide which side is server (DPU), which is client (host); how many clients to accept## Capabilities and modes role table + TASKS.md ## configure step 2
2. Pick the pathChoose slow-path (send-task / recv-callback) vs fast-path (producer / consumer) for the user's throughput profile## Capabilities and modes slow-vs-fast table + TASKS.md ## configure step 4
3. Discover capabilitiesQuery doca_comch_cap_get_* for max-msg-size, max-clients, transport-type on the active doca_devinfo## Capabilities and modes capability-query rule + TASKS.md ## configure step 3
4. Honor permissionsVerify representor visibility (DPU side) and PCIe address reachability (host side) before any object creation call## Safety policy permission matrix + TASKS.md ## configure step 1
5. Diagnose a Comch errorMap symptom (DOCA_ERROR_BAD_STATE, _AGAIN, _NOT_PERMITTED, _CONNECTION_RESET) to root cause without leaving the Comch layer prematurely## Error taxonomy + TASKS.md ## debug

Two cross-cutting rules that apply to every pattern above:

  • Server is always on the DPU side; client is always on the host side. The Comch channel runs over the RoCE/IB protocol (it is not part of the TCP/IP stack) between the host and the DPU, in an asymmetric server/client model; there is no symmetric peer-to-peer mode. An agent recommending the opposite is wrong for every version of Comch.

  • Slow-path and fast-path are independent objects. A user can run slow-path only, fast-path only, or both — but each adds its own lifecycle to the channel. Conflating them is the most common first-app design error and the cleanest place to fail fast.

Capabilities and modes

The two orthogonal selection axes for any Comch design are role and path. Choose both before writing any code, then drill into the relevant capability-query.

Role split — server vs client. Comch is asymmetric.

RoleSideWhat it doesObjectKey calls
ServerDPU (BlueField Arm)Listens on a host representor; accepts up to the device's per-server connection cap (query with doca_comch_cap_get_max_clients(devinfo) before start); owns the connection-accept callbackdoca_comch_serverdoca_comch_server_create, doca_comch_server_event_connection_status_changed_register
ClientHost (x86 / Arm)Initiates a single connection to a server, identified by its doca_dev_rep (representor on the DPU side surfaced to the host)doca_comch_clientdoca_comch_client_create (no client connection-event register exists — the client tracks connection state via its context state and task callbacks)

Path selection — slow-path vs fast-path. Both paths can coexist on the same channel; choose at least one before doca_ctx_start().

PathWhat it isRight shape forWrong shape for
Slow-pathMessage-oriented send-task / recv-callback API on the connection itself; one DOCA task per outbound message; per-message recv callback on the inbound sideControl plane, low-rate messages, configuration sync, command-response patternsBulk data, line-rate streams — per-message DOCA-task overhead dominates and limits throughput
Fast-pathdoca_comch_producer and doca_comch_consumer are separate context objects on each side; submit/recv-batched asynchronous transfers with smaller per-transfer overheadBulk data, asynchronous streams, telemetry uploads, log shippingOne-shot config messages — the producer / consumer setup overhead is not worth it for a single small message

Capability discovery — the only rule. Before sizing any queue or assuming a message length, call the matching doca_comch_cap_get_* query against the active doca_devinfo:

CapabilityQueryWhy the agent must ask
Maximum slow-path message sizedoca_comch_cap_get_max_msg_size(devinfo)Device-dependent; sending past the cap silently truncates or fails with DOCA_ERROR_INVALID_VALUE
Maximum server connectionsdoca_comch_cap_get_max_clients(devinfo)DPU-side ceiling; oversizing returns DOCA_ERROR_NOT_SUPPORTED at start
Producer / consumer presencedoca_comch_consumer_cap_is_supported(devinfo) / doca_comch_producer_cap_is_supported(devinfo)Fast-path is not on every device; agent must not silently assume it
Maximum send queue depthdoca_comch_cap_get_max_send_tasks(devinfo)Used to size the slow-path outstanding-task budget

Configuration shape. Mandatory configurations before doca_ctx_start(): at least one of (slow-path recv callback, producer attached, consumer attached) per side, and the connection state callback on the server side; the client observes connection state through its context state and task callbacks. Optional configurations on the server side include doca_comch_server_set_max_msg_size(server, …) (and the matching _client_set_max_msg_size); the max-clients value is a device capability (doca_comch_cap_get_max_clients(devinfo)) and is not user-settable via a public setter — the cap is the hard ceiling on what a server is allowed to accept. Query the active capability values with the matching doca_comch_cap_get_* / doca_comch_(consumer|producer)_cap_* queries before start; do not assume a setter exists for every capability.

Version compatibility

For the canonical DOCA version-detection chain, the four-way match rule, NGC container semantics, and the headers-win-over-docs rule, see doca-version/SKILL.md. The body lives there; this skill does not duplicate it.

The Comch-specific overlay is:

  • The library was renamed in DOCA 2.5. Old name: DOCA Comm Channel, pkg-config module doca-comm-channel. New name: DOCA Comch, pkg-config module doca-comch, URL slug DOCA-Comch. On installs ≥ 2.5 the agent must use the new name; on installs < 2.5 the agent must say so explicitly when the user's installed version (per doca-version TASKS.md ## configure (doca-version/TASKS.md#configure)) predates the rename, and route the user to the legacy Comm Channel guide via doca-public-knowledge-map/SKILL.md.

  • doca_comch_producer / doca_comch_consumer are newer than the slow-path. When the user reports "the API I'm reading about isn't on my install", the first hypothesis is that the install pre-dates the fast-path. Confirm via doca_comch_consumer_cap_is_supported(devinfo) / doca_comch_producer_cap_is_supported(devinfo) per the cross-cutting cap-query rule in doca-version CAPABILITIES.md ## Observability (doca-version/CAPABILITIES.md#observability).

  • doca-comch.pc and doca-common.pc must both match doca_caps --version at the four-way-match check (per doca-version CAPABILITIES.md ## Version compatibility (doca-version/CAPABILITIES.md#version-compatibility)). A common partial-install pattern after a 2.4 → 2.5 upgrade is that doca-comm-channel.pc lingers alongside the new doca-comch.pc; the agent must surface that as a partial-install hazard, not as a "both APIs are usable" convenience.

Error taxonomy

Comch-specific overlays on the cross-library DOCA_ERROR_* taxonomy. The cross-library taxonomy itself lives in doca-programming-guide CAPABILITIES.md ## Error taxonomy (doca-programming-guide/CAPABILITIES.md#error-taxonomy); the rows below are the Comch surface meaning that the agent must disambiguate before falling back to the cross-library response.

ErrorComch context where it shows upComch-specific cause
DOCA_ERROR_NOT_PERMITTEDdoca_comch_server_create, _client_createThe representor (DPU side) or PCIe address (host side) is not visible to this process / user. Route to doca-setup CAPABILITIES.md ## Observability (doca-setup/CAPABILITIES.md#observability) for representor enumeration.
DOCA_ERROR_NOT_SUPPORTEDdoca_ctx_start() on the server, fast-path _createThe implied clients count exceeds the device cap reported by doca_comch_cap_get_max_clients(devinfo), or the device does not advertise consumer / producer support. The public Comch API does not ship a setter for max-clients — the device cap is the hard ceiling; agent must surface the cap value and reshape the program, not invent a setter.
DOCA_ERROR_BAD_STATEAny call after doca_ctx_stop() or before doca_ctx_start(); submitting a doca_comch_task_send (via doca_task_submit) before the connection callback reports CONNECTEDLifecycle violation. Walk the call sequence against the lifecycle in doca-programming-guide CAPABILITIES.md ## Capabilities and modes (doca-programming-guide/CAPABILITIES.md#capabilities-and-modes); the most common case is sending before the server-side accept callback has fired.
DOCA_ERROR_AGAINslow-path doca_comch_task_send submit (doca_task_submit); producer submit fast-pathThe send queue is full. This is not a hardware error; the program must drain completions via doca_pe_progress() before re-submitting. Same as the cross-library "would-block, retry after progress" pattern.
DOCA_ERROR_CONNECTION_RESETSlow-path send-task completion, recv callbackThe peer disconnected. The connection state callback will have fired with the matching DISCONNECTED transition; agent must not invent a reconnection policy — defer to the user's higher-level protocol.
DOCA_ERROR_INVALID_VALUE_task_send_alloc_init with oversized messageThe message exceeds doca_comch_cap_get_max_msg_size(devinfo). The fix is to fragment at the application layer or to switch to the fast-path producer / consumer for bulk data.
DOCA_ERROR_TIME_OUTConnection callback never fires after doca_ctx_start()Most often a representor visibility issue on the DPU side, or a wrong PCIe address on the host side. Route to ## Safety policy permission matrix before any code change.
DOCA_ERROR_DRIVERAny submit / completion callThe layer below DOCA reported failure. Capture state and route to env-class debug (doca-setup ## debug (doca-setup/TASKS.md#debug)) — the layer below DOCA is the suspect, not the program.

The agent's rule: never recommend a retry loop on DOCA_ERROR_* without first identifying which of the rows above is the cause. _AGAIN is the only one that wants a retry (after doca_pe_progress()); the others want investigation, not retry.

Observability

Comch observability surface is the set of callbacks and queries that report channel state and per-message status. There is no external "Comch counter" — the visibility comes from the per-API events.

Three primary signals the agent should reach for:

  1. Connection state callbacks. On the server side, registered via doca_comch_server_event_connection_status_changed_register (which takes the connect and disconnect callbacks). There is NO client-side connection-event register — the client observes connection state through its context state and task callbacks. These fire on CONNECTED / DISCONNECTED transitions and are the single most informative signal for "is the channel up".

  2. Task completion callbacks (slow-path). Configured via doca_comch_{server,client}_task_send_set_conf and allocated with _task_send_alloc_init; the send is submitted with the generic doca_task_submit(doca_comch_task_send_as_task(task)). The per-task success / error callback fires on every submitted send; absence of a completion most commonly means doca_pe_progress() is missing from the user's main loop. If progress is running, check submit status, connection state, and callback registration before diagnosing the stall.

  3. Producer / consumer completion callbacks (fast-path). Same shape as the slow-path task callbacks, on the producer and consumer context objects. Per-transfer status flows through here; per-batch ordering is preserved.

For the cross-cutting env-side observability primitives (representor enumeration, devlink dev show, mlnx-bf-cfg) see doca-setup CAPABILITIES.md ## Observability (doca-setup/CAPABILITIES.md#observability). For the cross-library debug-time observability (DOCA_LOG_LEVEL=trace, --sdk-log-level, the trace build flavor) see doca-debug CAPABILITIES.md ## Observability (doca-debug/CAPABILITIES.md#observability).

Safety policy

Overlay on the bundle-wide hardware-safety meta-policy. The rules below are this skill's per-artifact overlay on the cross-cutting rules in doca-hardware-safety CAPABILITIES.md ## Safety policy (doca-hardware-safety/CAPABILITIES.md#safety-policy) (specifically ### Per-artifact overlay pattern (doca-hardware-safety/CAPABILITIES.md#per-artifact-overlay-pattern)). When the two layers disagree, the stricter wins; when either layer says STOP, the agent stops.

Comch's safety surface is permission and representor visibility. The single most common Comch first-app failure is that the DPU-side server cannot see the host representor — and the agent's job is to verify that before any object-creation call, not after the first DOCA_ERROR_NOT_PERMITTED.

The permission matrix the agent must walk for any new Comch setup:

SideWhat must be true before doca_comch_<role>_createHow the agent verifiesWhere to fix
DPU (server)The host representor for the target PF / VF / SF is visible to the DPU process (/sys/class/net/<rep> exists, owned by a user the process can access; user must typically be in the mlnx group or run with sudo)ls /sys/class/net/; id to confirm group membershipdoca-setup/SKILL.md for the env-side; do not modify the program
Host (client)The PCIe address of the BlueField is enumerable from the host (`lspcigrep Mellanox) and the corresponding doca_dev_rep` is opened against it`lspci
BothThe DPU is in the correct mode for the host ↔ DPU pair the user expects (SmartNIC vs DPU vs switch)mlxconfig -d <pcie> q INTERNAL_CPU_MODEL (sudo)doca-setup CAPABILITIES.md ## Capabilities and modes (doca-setup/CAPABILITIES.md#capabilities-and-modes) runtime-modes table

Do not invent a "fallback transport" for Comch. The Comch channel runs over the RoCE/IB protocol (not the TCP/IP stack) and is reached only through the host ↔ DPU representor / device pair — there is no separate Ethernet/TCP fallback path the agent can substitute. When the representor or PCIe address is unavailable, the right answer is to fix the env, not to point the user at a different DOCA library.

Slow-path vs fast-path queues are non-overlapping. Submitting a slow-path send-task on the producer context (or vice versa) is caught at submit time by the runtime, but the user-visible symptom (DOCA_ERROR_BAD_STATE) does not name the conflation. The agent must trace the user's path-selection (per ## Capabilities and modes slow-vs-fast table) before any other diagnosis when the user reports "_submit works on one side and not the other".

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

The author says: Requires DOCA SDK installed at /opt/mellanox/doca on Linux (Ubuntu 22.04/24.04 or RHEL/SLES) on a host + BlueField pair (the Comch channel runs over the RoCE/IB protocol, not the TCP/IP stack). Reads the user's local install via `pkg-config doca-comch` (legacy `doca-comm-channel` on installs <2.5) and inspects /opt/mellanox/doca/{lib,include,samples,applications}. The validation steps require a live DOCA install.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
NVIDIA
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/doca-comch · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download doca-comch.zip