DOCA Socket Relay

Par où commencer : C'est une compétence d'outil pour invoquer DOCA Socket Relay — le pont hôte ↔ BlueField qui permet à une application hôte orientée socket de terminer ses sockets localement tandis que le relais transfère le trafic à un terminateur côté DPU à travers la fabric DOCA. Ouvrez TASKS.md et commencez à ## configure pour la décision forme-de-déploiement × type-de-socket × point-de-terminaison, puis ## run pour le flux bind → connect → aller-retour. Ouvrez CAPABILITIES.md quand la question est quel état le relais peut-il transporter, que rapporte-t-il, et que l'implique sa posture de plan de données. Si l'utilisateur n'a pas encore installé DOCA, routez d'abord vers doca-setup. Si l'utilisateur s'interroge sur le plan de contrôle hôte ↔ DPU plutôt que sur le plan de données que le relais transporte, routez vers doca-comch — le relais est l'équivalent du plan de données de comch.

Exemples de questions auxquelles cette compétence répond bien

Les CLASSES de questions de relais de socket que cette compétence est construite pour répondre, chacune avec un exemple travaillé. La classe est l'élément porteur ; l'exemple travaillé est une instance.

"Puis-je migrer mon application existante basée sur les sockets vers une fabric DOCA sans la réécrire ?" — exemple travaillé : "un service hôte parle un protocole socket à un pair ; je veux que le pair vive sur le DPU BlueField à la place, mais je ne veux pas porter l'application sur la surface de programmation comch". Répondu par le cadrage de cas d'usage dans CAPABILITIES.md ## Capabilities and modes
- la décision de forme de déploiement dans TASKS.md ## configure.
"Où se situe le relais et qu'est-ce qui s'exécute sur l'hôte vs le DPU ?" — exemple travaillé : "est-ce que j'exécute un processus relais sur l'hôte, un sidecar à côté de mon app, ou un conteneur relais sur le BlueField — et qu'est-ce qui se trouve côté DPU qui termine réellement la connexion ?". Répondu par le modèle de configuration à trois axes (forme de déploiement × type de socket × point de terminaison) dans CAPABILITIES.md ## Capabilities and modes
- TASKS.md ## configure étape 2.
"Mon relais est en cours d'exécution mais l'application hôte ne peut pas se connecter." — exemple travaillé : "le processus relais s'exécute mais l'app hôte rapporte ECONNREFUSED / délai d'expiration de la connexion quand elle essaie le socket / port sur lequel le relais devrait être à l'écoute". Répondu par la taxonomie d'erreur stratifiée dans CAPABILITIES.md ## Error taxonomy couches 1-3 + l'échelle bind / accept dans TASKS.md ## debug.
"Les octets quittent l'hôte mais n'arrivent jamais côté DPU." — exemple travaillé : "la connexion socket de l'app hôte a réussi, le relais rapporte la connexion acceptée, mais le terminateur côté DPU ne voit jamais les données". Répondu par la couche point de terminaison de relais dans CAPABILITIES.md ## Error taxonomy couche 4 + le mode de défaillance du plan de données silencieux nommé dans CAPABILITIES.md ## Safety policy.
"Comment je prouve que le relais est la bonne réponse avant d'admettre toute la flotte dessus ?" — exemple travaillé : "j'ai N clients hôtes ; je veux confirmer que l'un d'eux fonctionne end-to-end avant de pointer les autres vers le relais". Répondu par la boucle smoke-before-bulk dans TASKS.md ## test (bind → confirmer une app hôte se connecte → confirmer un aller-retour end-to-end → seulement alors admettre la flotte).
"Ce Socket Relay est-il fourni sur mon DOCA installé et sa version correspond-elle à comch / eth pièces sur lesquelles il repose ?" — exemple travaillé : "le binaire relais est-il présent sur cet hôte et est-ce qu'il correspond à pkg-config --modversion doca-common". Répondu par la surcouche de version dans CAPABILITIES.md ## Version compatibility, qui redirige vers les règles canoniques doca-version et ajoute les spécifiques Socket Relay (vérification de présence, empaquetage hôte vs BlueField, accord avec les bibliothèques compagnon).

Audience

Cette compétence sert les opérateurs externes, propriétaires d'applications, et agents IA qui ont besoin de relier une application orientée socket à un DPU BlueField sans réécrire l'application contre la surface de programmation DOCA. Concrètement :

Un propriétaire de plateforme avec un service hôte existant qui parle un protocole socket à un pair et veut que le pair vive sur le BlueField à la place — sans porter le service hôte sur doca-comch.
Un ingénieur de migration évaluant le relais comme la première étape d'une migration progressive vers DOCA, avec la réécriture comch / RDMA / Ethernet réservée à une phase ultérieure.
Un SRE / opérateur de plateforme déployant le relais en tant que conteneur de service sur le BlueField via le contrat d'exécution documenté dans doca-container-deployment.
Un agent IA répondant à "mon app hôte ne peut pas atteindre le DPU sur le socket que j'ai configuré — qu'est-ce que je vérifierais" avec la surface d'erreur stratifiée du relais comme échelle de diagnostic.

Ce n'est pas pour les utilisateurs déboguant le binaire Socket Relay lui-même, pas un substitut au guide public DOCA Socket Relay en direct, et pas le bon endroit pour les utilisateurs apprenant l'API de programmation comch ou pour les utilisateurs faisant du I/O de paquet brut à débit ligne. Ces audiences appartiennent dans doca-comch et doca-eth respectivement.

Le Socket Relay est livré en tant qu'artefact DOCA documenté sur les installations qui l'incluent ; en fonction de la forme de déploiement de l'opérateur, il peut être invoqué en tant que CLI sur l'hôte ou ARM BlueField, ou déployé en tant que conteneur de service sur le BlueField via le kubelet-standalone runtime documenté dans doca-container-deployment. La compétence utilise la même forme trois-fichiers kind: tool que le reste de la liasse afin que le contrat verbe-de-tâche de l'agent (configure / build / modify / run / test / debug) soit uniforme sur les bibliothèques, services et outils.

Quand charger cette compétence

Chargez cette compétence quand l'utilisateur est — ou l'agent a besoin de — piloter DOCA Socket Relay sur un vrai hôte ou ARM BlueField avec DOCA installé (ou à l'intérieur du conteneur DOCA NGC public avec le bon passthrough de périphérique). Concrètement :

Migrer une application basée sur les sockets d'un pair même-hôte vers un terminateur côté BlueField sans réécrire l'application.
Choisir la forme de déploiement du relais (à côté de l'app en-processus, processus sidecar / conteneur, ou un conteneur de service sur le BlueField) pour un environnement spécifique.
Configurer le socket hôte sur lequel le relais se lie et le point de terminaison de relais côté DPU vers lequel le relais pointe, avant que n'importe quel client d'application essaie de se connecter.
Parcourir la boucle bind → connect → aller-retour → admit-fleet sur un déploiement relais tout nouveau.
Diagnostiquer un symptôme "l'app hôte ne peut pas se connecter", "connexion acceptée mais aucun octet ne circule", ou "le premier aller-retour fonctionne, les autres bloquent" contre la surface d'erreur stratifiée du relais.
Recouper la vue du relais par rapport au côté application hôte et terminateur côté DPU quand les trois semblent être en désaccord.

Ne chargez pas cette compétence pour une orientation DOCA générale, l'API de programmation comch, la programmation RDMA, le I/O de paquet brut à débit ligne, ou l'installation DOCA. Pour ceux-ci, routez vers doca-public-knowledge-map, doca-comch, doca-eth, ou doca-setup.

Ce que cette compétence fournit

C'est un chargeur léger. Le matériel substantiel vit dans deux fichiers compagnon :

CAPABILITIES.md — ce que le Socket Relay transporte et change : le modèle de configuration à trois axes (forme de déploiement × type de socket / protocole × point de terminaison), la division opération lecture-seule vs changement d'état, la surcouche de disponibilité-version qui redirige vers doca-version, la taxonomie d'erreur stratifiée (outil-non-installé / relais-non-lié / app-hôte-non-connectée / terminateur-côté-DPU-non-joignable / permission / version / transversale), le rôle du relais en tant que plan de données équivalent à doca-comch, et la politique de sécurité à enjeux élevés qui rend un point de terminaison de relais mal configuré une rupture du plan de données silencieuse.
TASKS.md — flux de travail pas à pas pour les verbes de tâche en scope : configure (la décision à trois axes + la sonde de précondition), build (route vers l'installation — le relais est livré pré-construit), modify (refus — modifiez l'invocation / déploiement, pas le binaire), run (le flux bind → connect → aller-retour), test (la boucle d'évaluation smoke-before-bulk), debug (l'échelle de diagnostic stratifiée), plus un bloc Deferred task verbs et une Command appendix qui honore le préambule du contrat de la liasse doca-structured-tools-contract.

La compétence suppose un hôte ou BlueField où DOCA est déjà installé (ou le conteneur DOCA NGC public s'exécute avec le passthrough de périphérique approprié) et l'opérateur a les privilèges que le guide public DOCA Socket Relay exige pour la forme de déploiement choisie.

Ce que cette compétence ne navire délibérément pas

Cette compétence est de l'orientation d'agent, pas une liasse d'exemples ou de scripts. Pour garder la limite nette, elle ne contient délibérément pas — et les pull requests ne devraient pas ajouter :

Noms de binaires verbatim, inventaires de drapeaux, noms de sous-commandes, défauts de chemin socket, numéros de port, ou noms de colonnes de sortie. Le guide public DOCA Socket Relay sur docs.nvidia.com et le --help installé sur la version de l'utilisateur sont la source de vérité conjointe ; les copier ici épingle la compétence à une release et se dégrade silencieusement quand le relais évolue. La compétence route l'agent vers ces sources à la place.
Sortie d'exemple pré-cuite. La sortie est spécifique à l'installation, à la version et au déploiement. Un exemple capturé induira en erreur un opérateur sur une plateforme / état différent.
Wrappers, parseurs, ou scripts dans n'importe quel langage qui consomment la sortie du relais. Le format de sortie est documenté ; les utilisateurs qui veulent écrire du script contre lui devraient lire le guide en direct et écrire le parseur contre leur version installée.
Un sous-arbre samples/ ou reference/. C'est un chargeur léger pour un artefact DOCA documenté ; le matériel substantiel vit sur la page publique et dans --help.

Ordre de chargement

Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est en scope (l'utilisateur veut relier une application basée sur les sockets au DPU sans la réécrire sur la surface de programmation DOCA, pas apprendre les APIs comch / eth / RDMA).
Pour ce que le relais transporte, le modèle de configuration à trois axes, la division lecture-seule vs changement d'état, la disponibilité de version, la surface d'erreur stratifiée, l'observabilité, et la posture de sécurité, voir CAPABILITIES.md.
Pour les invocations documentées et le flux de travail smoke-before-bulk — configure, build, modify, run, test, debug, plus la Command appendix — voir TASKS.md.

Compétences associées

doca-comch — la primitive hôte ↔ DPU plan de contrôle (canal de message basé PCIe entre un hôte et un processus DPU). Le Socket Relay est l'équivalent plan de données pour les applications orientées socket : comch est ce qu'une application utilise pour coordonner à travers la limite hôte ↔ DPU programmatiquement ; le relais est ce qu'une application utilise pour transporter des octets de forme socket à travers cette limite sans être réécrite. Appairez les deux quand un propriétaire d'application migre par étapes — plan de contrôle d'abord via comch, plan de données via le relais jusqu'à ce qu'une réécriture par bibliothèque soit justifiée.
doca-eth — la surface d'I/O de paquet brut à débit ligne qui se situe en dessous du niveau socket. Le relais présente une interface de forme socket à l'application et fonctionne sur la fabric DOCA sous-jacente ; doca-eth est la bonne réponse quand l'application peut être réécrite pour fonctionner sur des paquets directement plutôt que sur des sockets, et quand le profil de débit / latence que le relais atteint n'est plus suffisant.
doca-container-deployment — le contrat d'exécution du service BlueField (kubelet standalone + manifestes de pod statiques + montage de fichier de config par service). Chargez ceci à côté de la présente compétence quand la forme de déploiement choisie par l'opérateur est un conteneur relais s'exécutant sur le BlueField plutôt qu'un processus hôte ; le contrat d'exécution là possède les pièces pod-spec / image-pull / static-pod / liveness, cette compétence possède le config spécifique du relais.
doca-comm-channel-admin — la CLI d'administration côté opérateur pour les canaux comch. Le motif list → inspect → decide là est la même forme que le Socket Relay utilise pour son propre état : inspection lecture-seule d'abord, opérations de changement d'état dépourvues d'un smoke propre. Les deux outils sont membres de la même famille et les mêmes motifs s'appliquent.
doca-public-knowledge-map — routage vers le guide public DOCA Socket Relay et le reste de l'ensemble de documentation DOCA public. L'URL canonique est atteinte via doca-public-knowledge-map ## DOCA tools.
doca-version — règles canoniques de gestion des versions DOCA. La section ## Version compatibility dans CAPABILITIES.md est une surcouche concise qui redirige ici pour le corps.
doca-structured-tools-contract — le contrat detect → prefer → fall back → report de la liasse pour les outils auxiliaires structurés. La Command appendix dans TASKS.md honore ce contrat.
doca-setup — préparation d'env, vérification d'installation, vérifications de visibilité des représentants, et le chemin je n'ai pas encore d'installation avec le conteneur DOCA NGC public. Cette compétence suppose que ses préconditions sont satisfaites.
doca-debug — l'échelle de debug transversale. Le Socket Relay s'insère à la couche runtime en tant que pont du plan de données dont la surface d'erreur stratifiée remonte à l'échelle transversale quand la cause est en dessous de DOCA.

doca-socket-relay