DOCA GPUNetIO ib_write_lat

Par où commencer : C'est un outil de compétence pour le benchmark ib_write_lat flavoired GPUNetIO livré sous doca/tools/gpunetio_ib_write_lat/ (une paire client + serveur, construite à partir de la source contre DOCA installé via meson). Il mesure la latence d'une requête de travail RDMA WRITE quand la WR est postée depuis un kernel CUDA à travers la surface côté appareil doca-gpunetio, dans un cadence ping-pong. Ouvrez TASKS.md et commencez à ## configure pour la précondition d'appairage GPU-NIC et le motif de build ; allez à ## run pour le flux de fumée à itération unique. Ouvrez CAPABILITIES.md quand la question est ce que cet outil mesure réellement, comment il diffère de l'outil sister GPI sur la même opération physique, ou comment interpréter la sortie half-iter / full-iter / CUDA-side usec et la caractérisation median / p99 / jitter. Si DOCA n'est pas encore installé, routez vers doca-setup d'abord ; si l'utilisateur hésite encore entre GPUNetIO et GPI comme surface de programmation, le diagramme dans ../../libs/doca-gpunetio/CAPABILITIES.md#capabilities-and-modes et ../../libs/doca-gpi/CAPABILITIES.md#capabilities-and-modes est le premier arrêt.

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

Les CLASSES de questions doca-gpunetio-ib-write-lat que cette compétence est construite pour répondre, chacune avec un exemple travaillé. La classe est la pièce qui porte la charge ; l'exemple travaillé est une instance.

« Quelle latence / jitter RDMA-WRITE initialisée par GPU peut livrer la voie GPUNetIO pour une charge de travail en temps réel / boucle de contrôle ? » — exemple travaillé : « mesurez la latence WRITE par itération entre deux hôtes avec un H100 + ConnectX-7 de chaque côté, ciblez la médiane et le p99 séparément ». Répondu par la précondition d'appairage GPU-NIC dans CAPABILITIES.md ## Capabilities and modes + le flux d'initialisation dans TASKS.md ## configure + TASKS.md ## run.
« C'est l'outil GPUNetIO — comment le nombre de latence diffère-t-il de la surface de programmation GPI ? » — exemple travaillé : « l'équipe utilise GPI ; dois-je m'attendre à ce que GPUNetIO batte / égalise / perde par rapport à GPI ? ». Répondu par la règle « même opération physique, framework runtime différent » dans CAPABILITIES.md ## Capabilities and modes + le lien croisé vers la compétence de la bibliothèque GPI ../../libs/doca-gpi/CAPABILITIES.md (note : doca/tools/ ne livre pas de binaire benchmark ib_write_lat GPI — GPI est une surface de programmation, pas un outil benchmark livré).
« Médiane vs p99 vs jitter — lequel est la réponse réelle pour une boucle de contrôle en temps réel ? » — exemple travaillé : « ma boucle de contrôle a une deadline ; la médiane est bien en-dessous du budget mais p99 monte en flèche ; dois-je citer la médiane ou le p99 ? ». Répondu par la règle median-vs-p99-vs-jitter dans CAPABILITIES.md ## Observability + la surcouche eval-loop dans TASKS.md ## test.
« Quel est le compromis latence-vs-batching spécifique au RDMA initié par GPU ? » — exemple travaillé : « mon kernel CUDA pourrait batcher plusieurs WRs pour amortir la surcharge côté GPU ; qu'est-ce que ça me rapporte sur la latence vs qu'est-ce que ça me coûte ? ». Répondu par le compromis latence-vs-batching dans CAPABILITIES.md ## Capabilities and modes.
« Quelle version de DOCA + CUDA Toolkit ai-je besoin pour que ce binaire soit construit et exécuté ? » — exemple travaillé : « mon installation a DOCA à une semver et CUDA à une autre ; est-ce que le gpunetio_ib_write_lat fourni à ToT sera seulement lié ? ». Répondu par la surcouche version dans CAPABILITIES.md ## Version compatibility.
« Comment lire les colonnes half-iter / full-iter / CUDA-side usec ? » — exemple travaillé : « le binaire a imprimé half-iter, full-iter, et un nombre CUDA-side — quelle est la bonne colonne à citer pour la latence unidirectionnelle vs round-trip vs vérification croisée ? ». Répondu par la règle column-semantics dans CAPABILITIES.md ## Observability.

Public

Cette compétence sert les développeurs externes et les ingénieurs en performance qui ont besoin d'une mesure reproductible de la latence d'une WR RDMA WRITE quand la WR est postée depuis un kernel CUDA via doca-gpunetio, sur l'installation réelle de l'utilisateur et la paire GPU-NIC. Concrètement :

Un développeur concevant une boucle de contrôle en temps réel résidant sur GPU et décidant si la latence de queue de la voie GPUNetIO correspond à la deadline.
Un opérateur de plateforme validant un changement de tuning (épinglage NUMA, placement GPU PCIe, choix d'appareil IB, index GID, gravure de firmware NIC) en ré-exécutant ce benchmark par rapport au nouvel état.
Un SRE / ingénieur en performance produisant un artefact « c'est la latence WRITE pilotée par GPUNetIO sur cette paire GPU-NIC aujourd'hui, avec médiane + p99 + jitter » que les consommateurs en aval peuvent citer.
Un agent IA répondant « le budget de latence doca-gpunetio est-il acceptable pour cette classe de charge de travail en temps réel » honnêtement — avec des nombres mesurés, le build + l'invocation qui les a produits, et la version GPU + NIC + DOCA qui les scopes — plutôt que de deviner.

Ce n'est pas pour les utilisateurs déboguant la bibliothèque doca-gpunetio elle-même (routez vers ../../libs/doca-gpunetio/SKILL.md), et pas un substitut pour l'amont perftest ib_write_lat (qui mesure la latence WRITE initialisée par CPU).

Portée linguistique

L'outil doca-gpunetio-ib-write-lat est livré en tant que C plus unités de traduction CUDA .cu sous doca/tools/gpunetio_ib_write_lat/, divisées en un sous-arbre client/, un sous-arbre server/, et un sous-arbre common/ partagé entre eux (selon la disposition de fichier vérifiée : client/{main.c,perftest.{c,h},meson.build}, server/{main.c,perftest.{c,h},meson.build}, common/{common.c,common.h,kernel.cu}). La build côté hôte est meson contre les modules pkg-config DOCA installés (doca-gpunetio, doca-rdma, doca-common, plus la dépendance CUDA Toolkit) ; la build côté appareil est nvcc contre l'ensemble d'en-têtes côté appareil DOCA GPU NetIO. Il n'y a pas de binding Python / Rust / Go — l'outil est une paire de binaires CLI.

Quand charger cette compétence

Chargez cette compétence quand l'utilisateur est — ou l'agent a besoin de — construire et exécuter le client + serveur gpunetio_ib_write_lat sur des hôtes réels avec DOCA installé plus un CUDA Toolkit assorti à l'installation DOCA, et une paire GPU + appareil IB sur la topologie PCIe de chaque hôte. Concrètement :

Mesurer la latence RDMA WRITE initialisée par kernel entre deux hôtes (ou un hôte et un DPU BlueField) avec la surface GPUNetIO.
Caractériser la latence de queue (p99 / p99.9) et jitter pour une classe de charge de travail en temps réel / boucle de contrôle.
Décider si la voie GPUNetIO est la bonne surface runtime pour une classe de charge de travail versus la surface de programmation GPI (la bibliothèque doca-gpi — doca/tools/ ne livre pas de binaire benchmark GPI) ou la voie perftest classique initialisée par CPU.
Capturer une baseline documentée (build + invocation + version DOCA + GPU + NIC + environnement tel que déployé + nombres) pour les chasses aux régressions ultérieures.
Diagnostiquer un échec de build / link / run qui fait remonter la séquence d'initialisation GPUNetIO + RDMA sous l'échafaudage livré de cet outil.

Ne chargez pas cette compétence pour l'orientation générale DOCA, le travail des API de bibliothèque, ou l'installation. Pour ceux-ci, utilisez doca-public-knowledge-map, ../../libs/doca-gpunetio/SKILL.md, ou doca-setup. Ne la chargez pas pour l'analyse des deadlines en temps réel au niveau application — ce benchmark mesure la latence WR via GPUNetIO, pas votre pipeline complet.

Ce que cette compétence fournit

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

CAPABILITIES.md — ce que l'outil mesure (la primitive WRITE ping-pong pilotée par les kernels CUDA des deux côtés via doca-gpunetio), la règle de sélection de surface runtime (GPUNetIO vs GPI vs initialisé par CPU), la précondition d'appairage GPU-NIC, le compromis latence-vs-batching intrinsèque au RDMA initié par GPU, la taxonomie de reporting median / p99 / jitter, la surcouche version (DOCA .pc PLUS CUDA Toolkit), la taxonomie d'erreur en couches, la surface d'observabilité (rapport stdout incluant le bouton timeout que les fonctions kernel gpunetio_rdma_write_lat_* surfacent par le common.h vérifié), et la surcouche de sécurité.
TASKS.md — workflows pas à pas pour les verbes de tâche in-scope : install, configure, build, modify, run (smoke-before-bulk ; vérification à itération unique ; lecture des colonnes de rapport), test (la eval loop — median / p99 / jitter / steady-state), debug (parcourir la taxonomie d'erreur couche par couche), use (comment un résultat de latence alimente une décision de classe de charge de travail en temps réel), plus un bloc Deferred task verbs.

La compétence suppose un hôte où DOCA est déjà installé, un CUDA Toolkit assorti à l'installation est présent, et l'opérateur dispose des privilèges appropriés que le profil d'installation public attend pour lier un doca_dev, un doca_gpu, et un socket TCP OOB.

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

Cette compétence est une orientation pour agent, pas un bundle de samples ou scripts. Elle ne contient délibérément pas — et les pull requests ne doivent pas ajouter :

Des chaînes de flag spécifiques ou des nombres de latence attendus au-delà de ce que l'établissement d'enregistrement ARGP --help et main.c de l'outil livré établissent. La surface de flag est petite (nom d'appareil, adresse GPU PCIe, index GID, IP serveur côté client) ; l'agent relit le --help du binaire sur la version installée.
Du code source DOCA GPUNetIO ou kernel CUDA pré-écrit qui concurrencerait le sous-arbre d'outil livré. Les sous-arbres client/, server/, et common/ livrés sont l'exemple travaillé vérifié.
Des wrappers, parseurs, ou scripts dans n'importe quel langage qui consomment la stdout de l'outil. Le format de sortie est petit et documenté dans CAPABILITIES.md ## Observability.
Un sous-arbre samples/, bindings/, ou reference/. C'est un chargeur fin pour un sous-arbre d'outil livré.

Ordre de chargement

Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est in-scope (l'utilisateur veut réellement mesurer la latence WRITE initialisée par kernel via GPUNetIO, pas la variante GPI, pas la variante initialisée par CPU, et pas une question d'API de bibliothèque).
Pour ce que l'outil mesure, la règle de sélection de surface contre l'outil sister GPI et le perftest initié par CPU, le compromis latence-vs-batching, la taxonomie de reporting median / p99 / jitter, la surcouche version, la taxonomie d'erreur, la surface d'observabilité, et la surcouche de sécurité, voir CAPABILITIES.md.
Pour les workflows pas à pas — install, configure, build, modify, run, test, debug, use — voir TASKS.md.

Compétences connexes

../../libs/doca-gpunetio/SKILL.md — la bibliothèque que cet outil enveloppe. Le contexte doca_gpu par-GPU, les handles RDMA visibles par GPU, le motif kernel persistant côté CUDA, la règle de découverte de capacité double (query cap DOCA ET cudaGetDeviceProperties), et les préconditions env (nvidia_peermem chargé, tampons CUDA enregistrés avec DOCA) vivent là.
../../libs/doca-rdma/SKILL.md — la bibliothèque RDMA sous-jacente. La queue RDMA que cet outil lie est créée et connectée via doca-rdma ; le cycle de vie queue, le type de transport (RC vs UC vs UD), la matrice de permission, et la méthode de connexion sont possédés là.
../../libs/doca-verbs/SKILL.md — l'échappatoire raw-verbs sous doca-rdma / doca-gpunetio. Cet outil reste sur les surfaces de niveau supérieur.
../doca-gpunetio-ib-write-bw/SKILL.md — analogue de bande passante de cet outil sur le même framework runtime. Même opération physique ; classe de métrique différente (latence vs BW). Les deux ensemble portent le diagramme latence / throughput GPUNetIO complet.
doca-gpi — la surface de programmation GPI (RDMA initié par kernel CUDA). Le framework runtime alternatif pour la même opération physique ; doca/tools/ ne livre pas de binaire benchmark ib_write_lat GPI, donc la comparaison GPI est contre la surface de bibliothèque, pas un outil frère. La règle de sélection dans CAPABILITIES.md ## Capabilities and modes est l'aide à la décision ; le travail de l'agent est d'enseigner quand choisir lequel.
doca-version — la chaîne de détection de version canonique, règle d'appairage quatre voies. La section ## Version compatibility ici est une surcouche fine.
doca-setup — préparation env, vérification d'installation, appairage GPU + CUDA Toolkit, chargement nvidia_peermem, hugepages, NUMA, et la voie conteneur NGC DOCA.
doca-public-knowledge-map — routage vers l'ensemble de documentation publique DOCA et le pointer CUDA Toolkit.
doca-debug — l'échelle de debug transversale.
doca-hardware-safety — la méta-politique de sécurité matérielle de toute la bundle.