DOCA Comch

Par où commencer : Cette skill suppose que DOCA est déjà installé et que l'utilisateur fait du travail pratique avec Comch sur une paire BlueField + host avec DOCA. Ouvrez TASKS.md si l'utilisateur veut faire quelque chose (configurer / construire / modifier / exécuter / tester / déboguer) ; ouvrez CAPABILITIES.md quand la question porte sur ce que Comch peut exprimer sur cette version. Si l'utilisateur n'a pas encore installé DOCA, routez vers doca-setup d'abord. Si l'utilisateur se demande « Comch est-il même présent sur ce DOCA » parce que la documentation qu'il a lue mentionne doca-comm-channel, routez vers CAPABILITIES.md ## Version compatibility pour la renomination 2.5.

Exemples de questions auxquelles cette skill répond bien

Les CLASSES de questions Comch que cette skill est construite pour répondre, chacune avec un exemple travaillé. L'agent doit traiter la classe comme la partie essentielle — l'exemple travaillé n'est qu'une instance unique.

« Comment établir un canal Comch entre le host et le DPU ? » — exemple travaillé : « côté serveur sur le DPU, côté client sur le host, échanger un premier message de contrôle ». Répondu par le workflow de sélection de rôle + cycle de vie dans TASKS.md ## configure + CAPABILITIES.md ## Capabilities and modes tableau serveur-vs-client.
« Comment transférer des données en masse sur Comch avec peu de CPU ? » — exemple travaillé : « diffuser un chunk de 64 KiB tous les 100 µs du pilote host vers un agent DPU ». Répondu par le chemin rapide producteur / consommateur décrit dans CAPABILITIES.md ## Capabilities and modes
- le workflow de configuration de canal dans TASKS.md ## configure étape 4, avec la règle de sélection « chemin lent vs chemin rapide ».
« Quelle est la taille maximale d'un message que je peux envoyer ? » — exemple travaillé : « puis-je envoyer un message de contrôle de 4 MiB d'un seul coup ? ». Répondu par la règle de requête de capacité (doca_comch_cap_get_max_msg_size) dans CAPABILITIES.md ## Capabilities and modes
- le workflow de configuration de propriété dans TASKS.md ## modify.
« Pourquoi le côté DPU ne voit-il pas le representor ? » — exemple travaillé : « doca_comch_server_create retourne DOCA_ERROR_NOT_PERMITTED sur un BlueField fraîchement imagé ». Répondu par le representor + overlay de permission dans CAPABILITIES.md ## Safety policy
- la checklist de préparation d'env dans TASKS.md ## configure étape 1, qui route les questions d'env côté representor vers doca-setup.
« Cette capacité Comch est-elle sur ma version DOCA installée ? » — exemple travaillé : « doca_comch_producer est-il dans DOCA 2.6.0, ou dois-je toujours utiliser l'ancienne API de chemin lent ? ». Répondu par l'overlay de compatibilité de version dans CAPABILITIES.md ## Version compatibility, qui renvoie vers la chaîne de détection canonique dans doca-version et ajoute la règle de renomination spécifique à Comch 2.5.
*« Qu'est-ce que ce `DOCAERRORd'un appel Comch signifie et quelle couche l'a causé ? »** — exemple travaillé : *«DOCA_ERROR_AGAIN lors de la soumission d'unedoca_comch_task_sendviadoca_task_submit»*. Répondu par l'overlay Comch sur la taxonomie inter-bibliothèques dans [CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)
- l'échelle en couches dans TASKS.md ## debug qui escalade vers doca-debug.

Audience

Cette skill sert les développeurs externes qui construisent des applications consommant la bibliothèque DOCA Comch — c.-à-d. les utilisateurs dont le code appelle doca_comch_* (directement en C/C++, ou via FFI/bindings depuis un autre langage) pour échanger des messages de contrôle ou de données entre un processus host et un agent BlueField sur PCIe. Elle n'est pas pour les développeurs NVIDIA contribuant à DOCA Comch lui-même.

Portée des langages. DOCA Comch est fourni comme une bibliothèque C avec le nom de module pkg-config doca-comch. Les exemples fournis sont écrits en C. Les consommateurs C et C++ sont le cas canonique ; les exemples travaillés dans TASKS.md supposent ce chemin. Les autres consommateurs de langages (Rust, Go, Python, …) consomment les mêmes *.so via FFI ou des bindings spécifiques au langage ; la contribution de cette skill dans ce cas est de maintenir la guidance sur la division des rôles, le cycle de vie, la découverte de capacité, les permissions et la taxonomie des erreurs indépendante du langage, et de router l'agent vers l'ABI C public comme la surface faisant autorité que tout wrapper appellera finalement.

Quand charger cette skill

Chargez cette skill quand l'utilisateur fait du travail pratique avec DOCA Comch, dans n'importe quel langage. Concrètement :

Initialiser un doca_comch_server côté DPU ou un doca_comch_client côté host, sur un representor ou une adresse PCIe que le host peut atteindre.
Configurer au moins l'un des : un callback recv pour les messages de chemin lent, un producteur pour les données de chemin rapide sortantes, un consommateur pour les données de chemin rapide entrantes, avant doca_ctx_start().
Lire ou définir les propriétés comch via doca_comch_set_* et doca_comch_cap_get_* — taille max d'un message, nombre max de clients (côté serveur), dimensionnement de la file du producteur / consommateur.
Établir une connexion entre les deux côtés et réagir aux transitions d'état de connexion via les callbacks de connexion enregistrés avant le démarrage.
Choisir entre le chemin lent (send-task / recv-callback, orienté message, débit inférieur, simplicité en un seul appel) et le chemin rapide (producteur / consommateur, asynchrone, débit bien supérieur, configuration deux-contextes).
Déboguer un DOCA_ERROR_* retourné d'un appel Comch (violations de cycle de vie vs. permission vs. capacité vs. would-block) et la machine d'état de connexion sur la paire host / DPU.
Concevoir ou étendre les bindings non-C (Rust, Go, Python, …) qui enveloppent l'ABI C Comch — pour le cycle de vie, la division des rôles, les règles de permission et de capacité que le wrapper doit respecter.

Ne chargez pas cette skill pour l'orientation générale de DOCA, l'installation de DOCA lui-même, ou les questions sur des bibliothèques autres que Comch. Pour ceux-ci, utilisez doca-public-knowledge-map.

Ce que cette skill fournit

C'est un chargeur léger. Le corps ne garde que l'orientation nécessaire pour choisir le bon fichier suivant. Le matériel substantif spécifique à Comch réside dans deux fichiers complémentaires :

CAPABILITIES.md — ce que Comch peut exprimer sur cette version : la division de rôle serveur vs client, la surface send-task / recv-callback de chemin lent, la surface producteur / consommateur de chemin rapide, la surface de requête de capacité (doca_comch_cap_get_*), la taxonomie des erreurs Comch (mappée sur l'ensemble inter-bibliothèques DOCA_ERROR_*), la surface d'observabilité (callbacks d'état de connexion, callbacks d'achèvement de tâche), et la politique de sécurité qui contrôle les décisions representor et permission.
TASKS.md — workflows pas à pas pour les six verbes Comch en scope : configure, build, modify, run, test, debug. Plus un bloc Deferred task verbs qui pointe les questions hors scope vers la bonne skill suivante.

La skill suppose une paire host + BlueField où DOCA est déjà installé à l'emplacement standard et l'utilisateur dispose des privilèges que son profil d'installation public attend (en particulier, sudo côté DPU pour voir le representor host). Elle ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup.

Ce que cette skill ne fournit intentionnellement pas

Cette skill est une guidance pour l'agent, pas un paquet d'exemples ou de modèles. Pour garder la frontière claire, elle ne contient intentionnellement pas — et les pull requests ne doivent pas ajouter :

Code source d'application DOCA Comch pré-écrit, dans n'importe quel langage. Le code source Comch vérifié est les exemples C fournis à /opt/mellanox/doca/samples/doca_comch/<name>/. Le travail de l'agent est de router l'utilisateur vers ces fichiers et de prescrire une modification minimum-diff sur eux via le workflow universel modify-a-sample dans doca-programming-guide, en couches avec les overrides spécifiques à Comch dans TASKS.md ## modify.
Manifests de construction autonomes (meson.build, CMakeLists.txt, Cargo.toml, …) garés à l'intérieur de la skill. L'agent construit le manifest de construction dans le répertoire du projet de l'utilisateur contre le DOCA installé de l'utilisateur, où pkg-config --modversion doca-comch est la source de vérité.
Un sous-arbre samples/, bindings/, ou reference/ d'aucune sorte. Un artefact factice ou incomplet dans l'arbre de cette skill, même s'il est étiqueté « reference », est trompeur : les utilisateurs le liront comme construisible.

Ordre de chargement

Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est en scope.
Pour la matrice de capacité Comch, la division des rôles, les surfaces de chemin lent / rapide, la politique de permission, la taxonomie des erreurs, l'observabilité et la politique de sécurité, voir CAPABILITIES.md.
Pour les workflows pas à pas — configure, build, modify, run, test, debug — voir TASKS.md.

Les deux fichiers complémentaires se renvoient mutuellement, doca-version pour les règles canoniques de gestion de version, et doca-public-knowledge-map chaque fois que la bonne réponse est « consultez la documentation publique ou la disposition du paquet installé » plutôt que « guidance spécifique à Comch ».

Skills associées

doca-public-knowledge-map — la table de routage pour chaque source de documentation DOCA publique et la disposition sur disque d'un paquet DOCA installé. Le slug URL Comch est DOCA-Comch (DOCA 2.5+), pas doca-comm-channel.
doca-setup — préparation d'env, vérification d'installation, vérifications de visibilité du representor, et le chemin je n'ai pas encore d'installation avec le container NGC DOCA public. Cette skill suppose que ses préconditions sont satisfaites.
doca-version — règles canoniques de gestion de version DOCA. Le ## Version compatibility de cette skill renvoie vers la règle de correspondance quatre voies et ajoute l'overlay de renomination spécifique à Comch 2.5.
doca-structured-tools-contract — la règle de précédence structured-tools du paquet (detect / prefer / fall back / report). L'appendice Command dans TASKS.md respecte ce contrat.
doca-programming-guide — patterns de programmation DOCA généraux partagés par chaque bibliothèque : le pattern de construction pkg-config + meson canonique, le workflow universel modify-a-shipped-sample pour la première app, le cycle de vie universel, la taxonomie inter-bibliothèques DOCA_ERROR_*, et l'ordre de debug côté programme. Cette skill ajoute les spécificités Comch par-dessus.
doca-debug — l'échelle de debug transversale (install / version / build / link / runtime / program / driver). Le debug spécifique à Comch (violations de cycle de vie, visibilité du representor, symptômes de file pleine de chemin lent vs rapide) s'ajoute au-dessus de cette échelle.