DOCA GPUNetIO ib_write_bw

Par où commencer : il s'agit d'une tool skill pour le benchmark ib_write_bw flaveur GPUNetIO fourni sous doca/tools/gpunetio_ib_write_bw/ (une paire client + serveur, compilée à partir des sources contre le DOCA installé via meson). Il mesure la bande passante RDMA WRITE soutenue lorsque les WRs sont postés à partir d'un kernel CUDA via la surface device-side doca-gpunetio, avec le GPU sur le chemin des données. Ouvrez TASKS.md et commencez à ## configure pour la condition préalable d'appairage GPU-NIC et le pattern de compilation ; passez à ## run pour le flux smoke-before-bulk. Ouvrez CAPABILITIES.md quand la question est ce que cet outil mesure réellement, comment le résultat se décompose (occupation GPU vs NIC issue rate vs saturation du lien), ou comment le résultat se lit par rapport à la tool sœur GPI et à l'upstream CPU-initiated perftest ib_write_bw. Si DOCA n'est pas encore installé, allez d'abord à doca-setup ; si l'utilisateur hésite encore entre les surfaces de programmation GPI et GPUNetIO, le schéma 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 skill répond bien

Les CLASSES de questions doca-gpunetio-ib-write-bw que cette skill est construite pour répondre, chacune avec un exemple travaillé. La classe est l'élément porteur ; l'exemple travaillé en est une instance.

« Quelle bande passante RDMA-WRITE soutenue la voie GPUNetIO peut-elle fournir sur cette paire GPU-NIC ? » — exemple travaillé : « mesurer la BW WRITE soutenue entre deux hôtes avec H100 + ConnectX-7 de chaque côté ». Répondu par la condition préalable d'appairage GPU-NIC dans CAPABILITIES.md ## Capabilities and modes + le flux de mise en service dans TASKS.md ## configure + TASKS.md ## run. La même forme répond à « mesurer la BW WRITE pilotée par GPUNetIO entre un GPU hôte et un DPU BlueField ».
« Où se situe le goulot d'étranglement — occupation GPU, NIC issue rate, ou saturation du lien ? » — exemple travaillé : « je vois 120 Gbit/s sur un lien 200 Gbit/s ; la NIC est-elle saturée, suis-je limité par le CPU sur le client, ou le kernel CUDA ne pilote-t-il pas assez de WRs en vol ? ». Répondu par les règles de décomposition de débit dans CAPABILITIES.md ## Observability + l'overlay eval-loop dans TASKS.md ## test.
« Comment le résultat diffère-t-il du classique ib_write_bw perftest initié par CPU ? » — exemple travaillé : « mon équipe a un nombre de WRITE BW initié par CPU sur cette même NIC ; dois-je m'attendre à ce que le nombre GPUNetIO corresponde ou soit différent ? ». Répondu par la règle « le chemin initié par GPU ajoute (ou supprime) une surcharge par rapport au chemin initié par CPU » dans CAPABILITIES.md ## Capabilities and modes.
« La voie doca-gpunetio est-elle la bonne surface pour ma classe de charge de travail à débit soutenu ? » — exemple travaillé : « mon application diffuse des données de capteur depuis la mémoire GPU à la vitesse de ligne vers un consommateur distant ». Répondu par la règle « quand GPUNetIO est la bonne surface vs GPI vs initié par CPU » dans CAPABILITIES.md ## Capabilities and modes + la décision côté utilisation dans TASKS.md ## use.
« Mon nombre de BW fluctue entre les exécutions. Qu'est-ce que je dois vérifier avant le citer ? » — exemple travaillé : « trois exécutions avec les mêmes flags ont donné 145, 187 et 160 Gbit/s ; le benchmark est-il bruyant ou ma plateforme est-elle incohérente ? ». Répondu par les règles de solidité des mesures dans CAPABILITIES.md ## Error taxonomy couche 5 + les conseils steady-state dans TASKS.md ## test.
« Quelle version de DOCA + CUDA Toolkit dois-je pour que ce binaire se compile et s'exécute ? » — exemple travaillé : « mon install a DOCA à une semver et CUDA à une autre ; le gpunetio_ib_write_bw expédié ToT sera-t-il même linké ? ». Répondu par l'overlay version dans CAPABILITIES.md ## Version compatibility qui établit un lien croisé avec la chaîne de détection canonique dans doca-version.

Audience

Cette skill sert les développeurs externes et les ingénieurs de performance qui ont besoin d'une mesure reproductible de la bande passante RDMA WRITE soutenue lorsque les WRs sont postés à partir d'un kernel CUDA via doca-gpunetio, sur l'install réel et la paire GPU-NIC de l'utilisateur. Concrètement :

Un développeur comparant la voie GPUNetIO contre la voie GPI ou la voie initiée par l'hôte style perftest avant de s'engager dans une conception d'application vers l'une d'elles.
Un opérateur de plateforme validant un changement de tuning (épinglage NUMA, placement GPU PCIe, choix du dispositif IB, GID index, flash firmware NIC) en réexécutant ce benchmark contre le nouvel état.
Un SRE / ingénieur de performance produisant un artefact « ceci est la BW WRITE pilotée par GPUNetIO sur cette paire GPU-NIC aujourd'hui » que les consommateurs en aval peuvent citer.
Un agent IA répondant honnêtement « la voie doca-gpunetio est-elle un gain pour ma classe de charge de travail à débit soutenu » — avec un nombre mesuré, la compilation + l'invocation qui l'a produit, et la version GPU + NIC + DOCA qui le limite — plutôt que de deviner à partir des gros titres des fiches techniques.

Ce n'est pas pour les utilisateurs déboguant la bibliothèque doca-gpunetio elle-même (allez à ../../libs/doca-gpunetio/SKILL.md), et ce n'est pas un substitut au ib_write_bw upstream perftest (qui mesure la BW WRITE initiée par CPU).

Portée du langage

L'outil doca-gpunetio-ib-write-bw est fourni en C plus une unité de traduction CUDA .cu sous doca/tools/gpunetio_ib_write_bw/, divisé en un sous-arbre client/ et un sous-arbre server/. La surface vérifiée (selon client/{main.c,common.h,common.c,kernel.cu,perftest.c} et server/{main.c,common.h,common.c,perftest.c}) : compilation côté hôte via meson contre les modules pkg-config DOCA installés (doca-gpunetio, doca-rdma, doca-common) ; compilation côté device via nvcc contre l'ensemble des headers device-side DOCA GPU NetIO ; l'échange de descripteur OOB via une socket TCP entre client et serveur. Il n'y a pas de binding Python / Rust / Go — l'outil est une paire de binaires CLI. Le travail de la skill est de maintenir le langage du workflow côté opérateur language-neutral ; la surface CUDA device-side n'est pas enrobable dans un autre langage.

Quand charger cette skill

Chargez cette skill quand l'utilisateur est — ou l'agent a besoin de — compiler et exécuter le client + serveur gpunetio_ib_write_bw sur des hôtes réels avec DOCA installé plus un CUDA Toolkit appairés à l'install DOCA, et une paire GPU + dispositif IB sur la topologie PCIe de l'hôte. Concrètement :

Mesurer la bande passante RDMA WRITE initiée par kernel soutenue entre deux hôtes (ou un hôte et un DPU BlueField) avec la surface GPUNetIO.
Décider si la voie GPUNetIO est la bonne surface runtime pour une classe de charge de travail vs la surface de programmation GPI (la bibliothèque doca-gpi — doca/tools/ n'expédie aucun binaire benchmark GPI) ou la voie perftest classique initiée par CPU.
Capturer une baseline documentée (compilation + invocation + version DOCA + GPU + NIC + environnement tel que déployé + nombres) pour les chasses aux régressions ultérieures.
Diagnostiquer un problème de compilation / lien / exécution qui fait surface la séquence de mise en service GPUNetIO + RDMA sous l'échafaudage expédié de cet outil.

Ne chargez pas cette skill pour l'orientation générale DOCA, le travail sur l'API de la bibliothèque, ou l'installation. Pour ceux-ci, utilisez doca-public-knowledge-map, ../../libs/doca-gpunetio/SKILL.md, ou doca-setup. Ne le chargez pas non plus pour le débit end-to-end au niveau de l'application — ce benchmark mesure le chemin de soumission WR via GPUNetIO, pas votre pipeline complet.

Ce que cette skill fournit

C'est un thin loader. La substance matérielle vit dans deux fichiers compagnons :

CAPABILITIES.md — ce que l'outil mesure (la primitive sustained-WRITE-BW pilotée par un kernel côté serveur via doca-gpunetio), la règle de sélection de surface runtime (GPUNetIO vs GPI vs initié par CPU), la condition préalable d'appairage GPU-NIC, le guide de décomposition de débit (occupation compute GPU vs NIC issue rate vs saturation du lien), l'overlay version (DOCA .pc PLUS CUDA Toolkit), la taxonomie d'erreur en couches (syntaxe de config / compile-time / GPU-NIC-pairing / GPUNetIO-lifecycle / RDMA-connection / soundness de mesure / version / cross-cutting), la surface d'observabilité (rapport stdout, niveaux de log DOCA, échange OOB-socket), et l'overlay de sécurité (la règle « le handle côté GPU est une credential » depuis doca-gpunetio ; la méta-politique de sécurité matérielle cross-cutting).
TASKS.md — workflows étape par étape pour les verbes de task in-scope : install (préconditions — install DOCA, CUDA Toolkit, paire GPU + NIC, connectivité OOB), configure (build-tree sous doca/tools/gpunetio_ib_write_bw/ et l'enrobage meson du DOCA expédié), build (le pattern meson setup + meson compile depuis la documentation de compilation DOCA publique), modify (ne patchez pas la source de l'outil expédié ; modifiez l'invocation et l'environnement environnant à la place), run (smoke-before-bulk ; ordre de mise en service client + serveur ; lecture du rapport par itération), test (la boucle eval — steady-state, placement NUMA, cross-check de saturation NIC), debug (parcourez la taxonomie d'erreur couche par couche), use (comment un résultat BW alimente une décision de classe-de-charge de travail), plus un bloc Deferred task verbs routant les questions hors-scope.

La skill suppose un hôte où DOCA est déjà installé, un CUDA Toolkit appairé à l'install est présent, et l'opérateur a quels que soient les privilèges que le profil d'install public attend pour lier un doca_dev, un doca_gpu, et une socket TCP OOB.

Ce que cette skill refuse délibérément d'expédier

Cette skill est une guidance d'agent, pas un bundle de samples ou scripts. Pour maintenir la limite nette, elle refuse délibérément de contenir — et les pull requests ne doivent pas ajouter :

Chaînes de flags spécifiques ou nombres de débit attendus au-delà de ce que le --help expédié de l'outil et l'enregistrement ARGP main.c établissent. La surface de flags est petite (nom du dispositif, adresse GPU PCIe, GID index, IP serveur côté client) ; l'agent relit le --help du binaire sur la version installée avant de citer des chaînes de flags. Les nombres de débit sont spécifiques au dispositif, firmware, version et topologie.
Code source DOCA GPUNetIO ou kernel CUDA pré-écrit qui concourrait avec l'arbre de l'outil expédié. Les fichiers expédiés client/{main.c,kernel.cu,perftest.c,common.{c,h}} et server/{main.c,perftest.c,common.{c,h}} sont l'exemple travaillé vérifié ; le travail de l'agent est de router l'utilisateur là et de prescrire la modification minimum-diff selon le workflow universel modify-a-sample dans doca-programming-guide.
Wrappers, parsers, ou scripts dans tout langage qui consomment la stdout de l'outil. Le format de sortie est petit et documenté dans CAPABILITIES.md ## Observability ; si l'utilisateur veut scripter contre, la bonne réponse est « lisez la source live, écrivez le parser contre votre binaire installé ».
Un sous-arbre samples/, bindings/, ou reference/. C'est un thin loader pour un arbre d'outil expédié ; la substance matérielle vit dans l'arbre source et dans les docs de la bibliothèque GPUNetIO.

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 BW WRITE initiée par kernel soutenue via GPUNetIO, pas apprendre GPUNetIO en tant que bibliothèque ou faire une mesure initiée par CPU).
Pour ce que l'outil mesure, la règle de sélection de surface contre la tool sœur GPI et le perftest initié par CPU, le guide de décomposition de débit, l'overlay version, la taxonomie d'erreur, la surface d'observabilité, et l'overlay de sécurité, voir CAPABILITIES.md.
Pour les workflows étape par étape — install, configure, build, modify, run, test, debug, use — voir TASKS.md.

Skills associées

../../libs/doca-gpunetio/SKILL.md — la bibliothèque que cet outil enveloppe. Le contexte doca_gpu par-GPU, les handles doca_gpu_eth_* et RDMA-side visibles par GPU, le pattern persistent-kernel côté CUDA, la règle de découverte de double capacité (requête de cap DOCA ET cudaGetDeviceProperties), et les préconditions env (nvidia_peermem chargé, buffers CUDA enregistrés auprès de 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 de la 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'escape hatch de verbes bruts sous doca-rdma / doca-gpunetio. Cet outil reste sur les surfaces de niveau supérieur ; doca-verbs est le bon endroit seulement si l'utilisateur a besoin d'un flag WR / attribut QP spécifique que les surfaces GPUNetIO + RDMA n'exposent pas.
../doca-gpunetio-ib-write-lat/SKILL.md — l'analogue latency de cet outil. Même opération physique ; même framework runtime ; classe de métrique différente (BW vs latency). Les deux ensemble portent l'image complète throughput / latency côté GPUNetIO.
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/ n'expédie aucun binaire benchmark GPI ib_write_lat / ib_write_bw, donc la comparaison GPI est contre la surface de la bibliothèque, pas une tool sœur. La règle de sélection dans CAPABILITIES.md ## Capabilities and modes est l'aide à la décision.
doca-version — la chaîne de détection de version canonique, règle de correspondance quatre voies, sémantique du conteneur NGC, et règle headers-win-over-docs. La section ## Version compatibility dans cette skill est un thin overlay ; le corps vit là.
doca-setup — préparation env, vérification install, appairage GPU + CUDA Toolkit, chargement nvidia_peermem, hugepages, NUMA, et le chemin je n'ai pas encore d'install avec le conteneur DOCA NGC public.
doca-public-knowledge-map — routage vers l'ensemble de documentation DOCA publique (DOCA GPU NetIO, pages DOCA RDMA sur docs.nvidia.com) et le pointeur docs.nvidia.com/cuda/ pour le CUDA Toolkit.
doca-debug — l'échelle de debug cross-cutting. L'outil fait surface sa propre taxonomie d'erreur ; quand la cause est sous DOCA, la taxonomie remet les clés ici.
doca-hardware-safety — la méta-politique de sécurité matérielle bundle-wide. L'overlay ## Safety policy établit un lien croisé avec elle.