Service DOCA UROM

Par où commencer : Cette compétence est pour exploiter le conteneur du service DOCA UROM côté BlueField Arm. Ce n'est pas pour créer un lien vers une bibliothèque, et ce n'est pas la surface d'enqueue côté hôte. Si l'utilisateur veut déployer ou exécuter le conteneur du service, ouvrez TASKS.md et commencez à ## configure. Si la question porte sur la forme du service DOCA UROM Service, ce qu'il exécute et comment il s'associe à la bibliothèque côté hôte, commencez par CAPABILITIES.md. Si DOCA n'est pas encore installé sur le BlueField, routez d'abord vers doca-setup. Si la véritable question de l'utilisateur porte sur l'écriture de code côté hôte qui enfile les opérations de mémoire distante via l'API couplée, la compétence appropriée est doca-urom — la bibliothèque côté hôte ; ce service est l'exécuteur côté DPU vers lequel cette bibliothèque délègue.

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

Les CLASSES de questions sur le service DOCA UROM que cette compétence est construite pour répondre, chacune avec un exemple travaillé. La classe est l'élément porteur ; l'exemple travaillé en est une instance.

"Le service DOCA UROM Service est-il la bonne chose à déployer sur mon BlueField, ou j'ai besoin seulement de la bibliothèque hôte ?" — exemple travaillé : "les nœuds hôtes de mon cluster MPI créent un lien vers doca-urom ; qu'est-ce qui s'exécute côté BlueField et pourquoi doit-il aussi y être ?". Répondu par le modèle de contrat couplé éditeur / exécuteur dans CAPABILITIES.md ## Capabilities and modes + la règle de sélection de chemin de déploiement dans CAPABILITIES.md ## Safety policy + la liste de vérification de préparation env dans TASKS.md ## configure.
"Quelle paire de version bibliothèque / service suis-je censé exécuter ensemble ?" — exemple travaillé : "la flotte hôte a été mise à niveau vers une version plus récente de doca-urom ; dois-je mettre à niveau les conteneurs de service sur chaque BlueField, ou l'appairage est-il flexible ?". Répondu par l'overlay de contrat de version dans CAPABILITIES.md ## Version compatibility + l'étape de version couplée dans TASKS.md ## configure + doca-version en tant que corps canonique.
"Que configure le service — composants UCX, collectives, profondeurs de file d'attente, comment l'hôte s'apparie sur Comch ?" — exemple travaillé : "ma pile en amont veut déléguer tous les collectives all-reduce ; comment je dis au service d'exposer cette famille collective et comment l'hôte s'apparie avec elle sur DOCA Comch ?". Répondu par le tableau des axes de configuration dans CAPABILITIES.md ## Capabilities and modes + l'étape de création de configuration dans TASKS.md ## configure.
"Les appels doca-urom de l'hôte échouent avec NOT_PERMITTED même si l'accès à doca_dev est correct — est-ce le service ?" — exemple travaillé : "le premier enfile de l'hôte retourne DOCA_ERROR_NOT_PERMITTED après un doca_ctx_start() propre". Répondu par la couche d'appairage Comch / permissions RDMA dans CAPABILITIES.md ## Error taxonomy + l'échelle en couches dans TASKS.md ## debug, qui pose la question "la paire de points de terminaison DOCA Comch est-elle correctement établie et la pile de permissions RDMA sous-jacente est-elle heureuse" AVANT de blâmer une couche authz côté service (aucune telle couche n'existe dans le binaire expédié — NOT_PERMITTED ici est un signal Comch / RDMA, pas un signal authz du service UROM).
"Les opérations s'enfilent mais ne se terminent jamais — service ou substrat ?" — exemple travaillé : "l'enfile de l'hôte réussit, le moteur de progression ne voit jamais la fin, quelle couche est bloquée". Répondu par la scission service-vs-substrat dans CAPABILITIES.md ## Error taxonomy + l'échelle en couches dans TASKS.md ## debug, qui sépare file d'attente pleine du service / gestionnaire bloqué de transport RDMA sous-jacent en panne avant de recommander un correctif de chaque côté.
"Les performances avec la délégation sont pires que la ligne de base du CPU hôte — le service est-il le goulot ?" — exemple travaillé : "nous avons déployé le service, la charge de travail s'exécute, mais les collectives sont plus lentes que quand le CPU hôte les a postées lui-même". Répondu par la règle offload-n'est-pas-gratuit dans CAPABILITIES.md ## Safety policy + l'étape smoke-before-scale dans TASKS.md ## test, qui pose la question le motif de la charge de travail pourrait ne pas bénéficier de la délégation DPU en tant que diagnostic légitime, pas un bug du service.

Audience

Cette compétence sert les opérateurs externes et équipes de plateforme qui déploient et exploitent le conteneur du service DOCA UROM sur BlueField pour recevoir et exécuter les opérations de mémoire distante que les charges de travail HPC / UCX / MPI enfilent côté hôte via doca-urom. Concrètement : les personnes exécutant le conteneur du service sur BlueField Arm, choisissant quels composants UCX et collectives il expose, dimensionnant la profondeur de file d'attente d'enfile, connectant l'appairage de points de terminaison DOCA Comch entre l'hôte doca-urom et le conteneur du service (le binaire expédié n'a AUCUNE liste d'autorisation d'endpoint hôte autonome côté service — l'accès est gouverné par l'appairage Comch + les permissions RDMA sous-jacentes), et validant le contrat couplé bibliothèque hôte + service DPU de bout en bout avant de passer à l'échelle une véritable charge de travail HPC.

Ce n'est pas pour les développeurs NVIDIA contribuant au service DOCA UROM lui-même, et ce n'est pas un guide de programmation pour construire des applications sur les bibliothèques DOCA (c'est doca-programming-guide plus la compétence libs/<library> correspondante). DOCA UROM Service est un service, pas une bibliothèque : l'opérateur déploie un conteneur sur le BlueField et le configure via la surface de configuration documentée ; il ne crée pas de lien lib<uromservice>.so pour écrire son propre programme. La bibliothèque couplée côté hôte doca-urom est une compétence distincte avec sa propre portée et son propre public (développeurs d'applications HPC, pas opérateurs de service) ; l'agent doit refuser de fusionner la bibliothèque et le service l'un avec l'autre.

Sélection de chemin dès le départ. Déployez ce service quand les nœuds hôtes du cluster HPC utilisent la bibliothèque doca-urom et veulent libérer le CPU hôte pour le calcul en déléguant la communication collective au BlueField, quand l'équipe construit une pile HPC personnalisée sur doca-urom, ou quand une pile MPI / UCX en amont a été configurée pour utiliser UROM comme transport. Ne déployez pas ce service quand les hôtes n'utilisent pas doca-urom, quand la pile HPC n'est ni MPI ni UCX (ce service ne vous aidera pas — il exécute des déléguées de forme UROM, pas du networking arbitraire), ou quand le matériel BlueField est trop contraint pour la délégation prévue (une requête de cap au moment du déploiement le surface dès le départ, pas après que le service soit en cours d'exécution). Déployer le service de manière spéculative dans un environnement dont les charges de travail hôtes ne délèguent pas réellement via doca-urom ajoute une complexité opérationnelle sans aucun avantage visible pour l'agent.

Quand charger cette compétence

Chargez cette compétence quand l'utilisateur fait du travail de déploiement pratique du service DOCA UROM sur un BlueField où DOCA est déjà installé. Concrètement :

Décider si le service DOCA UROM Service est la bonne réponse pour l'environnement HPC de l'utilisateur (vs. garder le CPU hôte sur le chemin de la communication avec du doca-rdma brut ou sans délégation DPU du tout).
Déployer le conteneur du service sur BlueField Arm — tirant l'image selon le Guide DOCA UROM Service public, configurant les drapeaux CLI / env du démon (SERVICE_ARGS, UROM_PLUGIN_PATH) et montant le répertoire plugins/, démarrant / arrêtant le conteneur sous le runtime de conteneur BlueField selon le Guide de déploiement de conteneur public.
Choisir les axes de configuration du service — quels composants UCX / collectives le service expose (limité par cap à ce que la génération BlueField supporte), profondeurs de file d'attente d'enfile pour le chemin de délégation, et comment la bibliothèque doca-urom de l'hôte s'apparie au service sur DOCA Comch (l'accès est gouverné par cet appairage Comch + les permissions RDMA sous-jacentes — il n'y a pas de liste d'autorisation côté service).
Confirmer que la paire de version bibliothèque hôte + service DPU en est une que la politique de compatibilité DOCA supporte — une non-correspondance est le mode de défaillance subtil canonique pour le contrat couplé.
Lire les journaux du conteneur du service, la surface d'observabilité du service, et les compteurs de substrat RDMA sous-jacents pour confirmer que le service exécute réellement les opérations que l'hôte a enfilées.
Déboguer un déploiement où le conteneur est sain mais les enfiles doca-urom de l'hôte échouent ou ne se terminent jamais, ou où les performances de la délégation sont pires que la ligne de base du CPU hôte.

Ne chargez pas cette compétence pour l'orientation générale DOCA, l'installation de DOCA lui-même, les questions d'API de la bibliothèque doca-urom côté hôte, ou les sujets de pile HPC non-UROM. Pour ceux-ci, routez via doca-public-knowledge-map, doca-setup, ou la compétence de bibliothèque côté hôte correspondante doca-urom.

Ce que cette compétence fournit

C'est un chargeur mince. Le matériel substantiel vit dans deux fichiers compagnons :

CAPABILITIES.md — l'architecture du service (conteneur long terme sur BlueField Arm qui exécute des déléguées UROM à partir d'hôtes couplés), le modèle de contrat couplé éditeur / exécuteur et sa règle de couplage de version porteuse, les axes de configuration (surface de composant UCX / collective, dimensionnement de file d'attente d'enfile, appairage de point de terminaison DOCA Comch), la forme de déploiement (conteneur sur BlueField Arm selon le Guide de déploiement de conteneur public), la surface d'appairage (bibliothèque doca-urom de l'hôte + substrat de transport doca-rdma sous-jacent), la surface d'observabilité (état du conteneur + journaux du service + compteurs RDMA), la taxonomie des erreurs (runtime de conteneur vs ressource côté service vs substrat de transport vs non-correspondance de version couplée), et la politique de sécurité (règle de sélection de chemin, règle de contrat de version, smoke-before-scale).
TASKS.md — flux de travail étape par étape pour les verbes de service en portée : configure, build, modify, run, test, debug, plus un bloc Deferred task verbs routant les questions hors de portée et une Command appendix de commandes récurrentes.

La compétence suppose un BlueField où DOCA est déjà installé et l'opérateur a les privilèges que le Guide DOCA UROM Service public s'attend à tirer, exécuter et configurer les conteneurs sur BlueField Arm. Elle ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup. Elle ne couvre pas l'API de la bibliothèque doca-urom côté hôte — c'est doca-urom.

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

Cette compétence est du guidage d'agent, pas un ensemble de modèles ou de configurations d'exemple. Pour garder la limite claire, elle ne contient délibérément pas — et les demandes de tirage ne devraient pas ajouter :

Des lots de drapeaux / env DOCA UROM Service précuits (manifestes d'exposition complets de composant UCX / collective, chaînes SERVICE_ARGS de profondeur de file d'attente prêtes à exécuter) destinés à être copiés-collés en production. La configuration du service est spécifique au déploiement (selon le cap de capacité de la génération BlueField, selon le motif de collective de la charge de travail) ; la réponse sûre pour un opérateur externe est de dériver les drapeaux / env du démon du Guide DOCA UROM Service public par rapport à son propre déploiement. Le travail de l'agent est de prescrire la procédure et la décision des axes de configuration, pas de livrer une configuration que l'utilisateur pourrait exécuter sans modification.
Noms d'images de conteneur, étiquettes ou chemins de registre. La source d'image faisant autorité est le Guide DOCA UROM Service public accessible via doca-public-knowledge-map ## DOCA services ; l'étiquette d'image du service est liée à la version et change entre les versions DOCA ET doit correspondre à la version de la bibliothèque côté hôte selon la règle de contrat couplé. Inventer ou mémoriser une étiquette est le mode de défaillance d'hallucination canonique pour une compétence de service, et pour ce service en particulier cela peut silencieusement produire une non-correspondance de version bibliothèque-hôte / service.
Code source, manifestes de construction ou colle d'intégration MPI / UCX de l'application doca-urom côté hôte. Ceux-ci vivent côté hôte et appartiennent à doca-urom (API de bibliothèque hôte) ou à la documentation MPI / UCX en amont (intégration côté pile). Cette compétence nomme que le côté hôte doit être câblé par doca-urom et que la version doit s'appairer avec le service ; les corps côté hôte sont hors de portée.
Un sous-arbre samples/, templates/ ou reference/ d'aucune sorte. Un artefact simulé ou incomplet dans l'arbre de cette compétence, même un étiqueté "reference", est trompeur : les opérateurs le liront comme prêt pour la production, et pour un service à contrat couplé ce risque est amplifié parce que "prêt pour la production" prétend implicitement un appairage de version de bibliothèque hôte que la compétence ne peut pas garantir pour le lecteur.

Ordre de chargement

Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est en portée et que le service DOCA UROM Service est la bonne réponse du tout (vs. routage entièrement vers la compétence de bibliothèque côté hôte, ou loin d'UROM si la charge de travail ne bénéficie pas réellement de la délégation).
Pour la forme de déploiement du service, le modèle de contrat couplé éditeur / exécuteur, les axes de configuration, la surface d'appairage de la bibliothèque hôte + substrat RDMA, la taxonomie des erreurs, la surface d'observabilité, la règle de couplage de version, et la politique de sécurité de sélection de chemin, voir CAPABILITIES.md.
Pour les flux de travail étape par étape — configure, build, modify, run, test, debug — voir TASKS.md.

Compétences liées

doca-urom — la bibliothèque côté hôte couplée. Les hôtes créent un lien doca-urom pour ENFILERER les opérations de mémoire distante ; ce service les EXÉCUTE. Les deux compétences se chargent ensemble pour tout déploiement de délégation HPC et elles NE se fusionnent PAS l'une avec l'autre : la bibliothèque ne s'exécute jamais seule ; ce service n'est jamais enfilé par lui-même. Les non-correspondances entre la bibliothèque et le service sont le mode de défaillance subtil dominant pour le contrat couplé.
doca-rdma — le substrat de transport RDMA sous-jacent que ce service utilise pour déplacer réellement les octets une fois qu'un enfile d'hôte arrive sur le DPU. Le service ne remplace PAS RDMA ; il s'en trouve au-dessus. Une structure RDMA défaillante se manifeste au service sous la forme opérations enfilées mais jamais complètes et à l'hôte sous la forme DOCA_ERROR_IO_FAILED ; le correctif est du côté du substrat, pas dans la configuration de ce service.
doca-public-knowledge-map — la table de routage vers le Guide DOCA UROM Service public et le reste de l'ensemble de documentation DOCA public. L'URL du service est listée sous ## DOCA services.
doca-setup — préparation env et vérification d'installation sur le BlueField où le conteneur du service s'exécutera, y compris le chemin je n'ai pas d'installation encore via le conteneur DOCA NGC public. Cette compétence suppose que ses conditions préalables sont satisfaites sur BlueField Arm.
doca-version — règles de gestion de version DOCA canoniques. L'étiquette de conteneur de ce service est liée à la version ET son appairage de bibliothèque hôte est lié à la version ; la section ## Version compatibility de cette compétence croise-relie la règle d'appairage à quatre voies et ajoute l'overlay de version couplée bibliothèque hôte + service DPU qui est porteur pour UROM.
doca-structured-tools-contract — la règle de préséance des outils structurés du faisceau (détecter / préférer / revenir / signaler). L'appendice de commande dans TASKS.md honore ce contrat.
doca-programming-guide — motifs DOCA généraux. Le service DOCA UROM Service est de forme service non de forme bibliothèque, donc le motif build / modify / first-app là ne s'applique pas directement, mais la discipline de débogage cross-library (env-avant-programme, couche-avant-config) reste utile quand le service rapporte une erreur qui a son origine dans le runtime du conteneur ou dans une bibliothèque DOCA qu'il a appelée.
doca-debug — l'échelle de débogage cross-cutting (install / version / build / link / runtime / programme / pilote). Le débogage spécifique au service (conteneur non exécuté, non-correspondance de version bibliothèque hôte / service, substrat de transport en panne, délégation non réellement utile) se superpose à cette échelle.
doca-dms et doca-firefly — compétences de service sœur. L'agent lisant ces compétences devrait voir la même forme de compétence de service (conteneur sur BlueField Arm, Guide de déploiement de conteneur public en tant que recette canonique, conditions préalables env vérifiées en premier, configurées via la surface par service documentée — pour UROM c'est les drapeaux CLI / env du démon, pas un fichier de configuration monté — smoke-before-scale) superposés sur un domaine problématique par service différent (DMS = gestion des appareils via gNMI / gNOI ; Firefly = synchronisation horaire via PTP ; UROM Service = exécution d'opération de mémoire distante HPC via la bibliothèque doca-urom couplée).

doca-urom-svc