DOCA Rivermax

Par où commencer : Cette compétence suppose que DOCA est déjà installé, ET que le NVIDIA Rivermax SDK est installé séparément avec une licence Rivermax valide présente sur l'hôte. La PREMIÈRE action de l'agent sur toute question Rivermax est de confirmer les deux — sans Rivermax SDK + licence, doca-rmax ne peut pas fonctionner quel que soit l'état du code côté DOCA, et c'est la source de confusion #1 pour les premières applis (DOCA ne regroupe pas Rivermax ; il l'enveloppe). Ouvrir TASKS.md si l'utilisateur veut faire quelque chose (configurer / compiler / modifier / exécuter / tester / déboguer) ; ouvrir CAPABILITIES.md quand la question porte sur ce que DOCA Rivermax peut exprimer sur cette version + cette installation Rivermax. Si l'utilisateur n'a pas encore installé DOCA, le rediriger vers doca-setup d'abord ; pour l'installation du Rivermax SDK + licence elle-même, le rediriger vers le guide public DOCA Rivermax (slug DOCA-Rivermax) via doca-public-knowledge-map. Si l'utilisateur demande « comment faire en sorte que les paquets arrivent sur mon flux d'entrée Rivermax ? », la réponse est en couches : doca-rmax est la surface d'intégration Rivermax, doca-eth est la surface de file qui porte les paquets, et doca-flow est la surface de routage qui les dirige.

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

Les CLASSES de questions DOCA Rivermax que cette compétence est conçue pour répondre, chacune avec un exemple travaillé. L'agent devrait traiter la classe comme la partie structurante — l'exemple travaillé est une instance unique.

« Puis-je même utiliser doca-rmax sur cet hôte ? » — exemple travaillé : « la documentation publique mentionne doca-rmax ; est-ce utilisable sans rien faire d'autre ? ». Répondu par la règle de précondition Rivermax-SDK + licence dans CAPABILITIES.md ## Safety policy
- la liste de vérification de préparation d'env dans TASKS.md ## configure étape 1, qui redirige la question côté installation vers le guide public Rivermax via doca-public-knowledge-map et refuse de recommander un repli sur doca-eth seul qui perdrait silencieusement les propriétés de synchronisation.
« Comment configurer un flux de réception vidéo SMPTE ST 2110 ? » — exemple travaillé : « aligner un flux Rivermax entrant sur un représentant d'un port BlueField pour un test de première exécution ». Répondu par le cycle de vie de l'objet par flux dans TASKS.md ## configure + CAPABILITIES.md ## Capabilities and modes tableau de capacité de flux d'entrée.
*« Quelle requête `doca_rmaxget_supporteddois-je appeler avant de choisir un type de flux / taille de trame / débit de paquet ? »** — exemple travaillé : *« ce périphérique + cette installation Rivermax peut-il porter un flux vidéo 1080p60 au débit que je veux ? »*. Répondu par la règle de requête de capacité dans [CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)
- étape 3 dans TASKS.md ## configure.
« Mon flux est configuré mais aucun paquet n'arrive — pourquoi ? » — exemple travaillé : « l'objet flux Rivermax a démarré correctement mais aucun événement recv ne se déclenche ». Répondu par la matrice de précondition dans CAPABILITIES.md ## Safety policy
- la liste de vérification de préparation d'env dans TASKS.md ## configure étape 1, qui redirige le côté routage vers doca-flow, le côté file vers doca-eth, et le côté licence vers la précondition côté Rivermax.
« Cette capacité d'intégration Rivermax est-elle disponible sur mon périphérique + mon DOCA installé + mon Rivermax SDK ? » — exemple travaillé : « ce périphérique + cette version Rivermax annoncent-ils le type de flux dont j'ai besoin ? ». Répondu par la règle de requête de capacité dans CAPABILITIES.md ## Capabilities and modes
- la surcouche de version et périphérique dans CAPABILITIES.md ## Version compatibility, qui ajoute la règle la version Rivermax côté Rivermax est un second axe sur la chaîne de gestion de version DOCA canonique dans doca-version.
*« Que signifie ce `DOCAERRORd'un appel Rivermax et quelle couche l'a causé ? »** — exemple travaillé : *DOCA_ERROR_NOT_PERMITTEDà la première création de flux Rivermax »*. Répondu par la surcouche Rivermax sur la taxonomie inter-bibliothèques dans [CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)
- l'escalier en couches dans TASKS.md ## debug qui remonte vers doca-debug, et qui souligne que _NOT_PERMITTED sur Rivermax signifie fréquemment « licence Rivermax manquante / expirée / non lisible », pas le manque habituel d'accès périphérique côté DOCA.

Audience

Cette compétence sert les développeurs externes construisant des applications qui consomment l'intégration DOCA Rivermax — c'est-à-dire les utilisateurs dont le code appelle doca_rmax_* (directement en C/C++, ou via FFI/liaison depuis un autre langage) pour piloter des flux media-sur-IP précis en synchronisation (SMPTE ST 2110, données marché en temps réel, flux d'instruments scientifiques à haut débit) sur un NVIDIA Rivermax SDK installé séparément sur un hôte BlueField ou ConnectX. Ce n'est pas pour les développeurs NVIDIA contribuant à DOCA Rivermax lui-même, et ce n'est pas pour les utilisateurs qui veulent des E/S de paquet au mieux — pour cela, rediriger vers doca-eth directement.

Portée du langage. DOCA Rivermax est livré en tant que bibliothèque C avec le nom de module pkg-config doca-rmax. Les exemples livrés vivent sous /opt/mellanox/doca/samples/doca_rmax/ et sont écrits en C. Les consommateurs C et C++ sont le cas canonique ; les exemples travaillés dans TASKS.md supposent ce chemin. Les consommateurs d'autres langages (Rust, Go, Python, …) consomment le même *.so via FFI ou les liaisons spécifiques au langage ; la contribution de la compétence dans ce cas est de garder la règle de précondition (Rivermax SDK + licence), le cycle de vie par flux, la découverte de capacité, les conseils de discipline de permission, de planification et de taxonomie d'erreurs indépendants du langage, et de rediriger l'agent vers l'ABI C public comme surface autoritaire que tout enveloppe appelera finalement.

Quand charger cette compétence

Charger cette compétence quand l'utilisateur fait du travail DOCA Rivermax pratique, dans n'importe quel langage. Concrètement :

Confirmer que le NVIDIA Rivermax SDK et une licence Rivermax valide sont présents sur l'hôte avant que tout code côté DOCA ne soit écrit — c'est une précondition obligatoire, pas un chemin d'erreur ; sans cela la réponse est « doca-rmax ne peut pas être utilisé ; choisir une autre bibliothèque », pas « essayons et voyons ce qui échoue ».
Initialiser le moteur DOCA Rivermax global avec doca_rmax_init() / doca_rmax_release(), puis créer un contexte doca_rmax_in_stream (réception) avec doca_rmax_in_stream_create() sur un doca_dev ouvert contre un port physique, un représentant, ou un SF, et le convertir via doca_rmax_in_stream_as_ctx() avant doca_ctx_start(). L'API publique DOCA Rivermax est réception seule — il n'y a pas d'objet flux transmis/sortie.
Configurer un flux d'entrée Rivermax pour l'audio + vidéo SMPTE ST 2110 sur IP, les flux de données marché en temps réel, ou un flux d'instrument scientifique — avec conscience que le type de flux, la taille de trame, et le débit de paquet que l'utilisateur veut sont tous dépendants du périphérique et de Rivermax et conditionnent la requête doca_rmax_get_*_supported correspondante.
Lire ou définir les propriétés de flux Rivermax via doca_rmax_in_stream_set_* et interroger la capacité périphérique + Rivermax via la famille doca_rmax_get_*_supported avant d'assumer qu'un type de flux / taille de trame / débit de paquet spécifique est supporté.
Associer le flux Rivermax à la surface de file doca-eth qui porte les paquets et les règles doca-flow qui les dirigent — Rivermax ne programme pas le routage lui-même.
Concevoir la discipline de planification temps réel pour les fils d'exécution en flux (la pile Rivermax sous-jacente s'attend à une priorité temps réel pour un jitter submicrosecondes ; les conseils de planification canoniques vivent dans la documentation DOCA Rivermax SDK accessible via doca-public-knowledge-map).
Déboguer un DOCA_ERROR_* retourné par un appel Rivermax (cycle de vie vs. licence / permission vs. capacité vs. pilote-dessous) où la cause peut vivre dans l'enveloppe côté DOCA, la pile Rivermax sous-jacente, ou la couche de licence.
Concevoir ou étendre les liaisons non-C (Rust, Go, Python, …) qui enveloppent l'ABI C DOCA Rivermax — pour la règle de précondition, le cycle de vie, la capacité, la permission, et les règles de planification que l'enveloppe doit honorer.

Ne pas charger cette compétence pour l'orientation générale DOCA, pour installer DOCA lui-même, pour installer le Rivermax SDK ou gérer le fichier licence Rivermax (ceux-ci vivent dans le guide public Rivermax SDK accessible via doca-public-knowledge-map), pour les E/S de paquet au mieux sans exigences de synchronisation (utiliser doca-eth directement), ou pour le pur traitement de données côté hôte sans réseautage. Pour l'orientation documentation DOCA, utiliser doca-public-knowledge-map.

Ce que cette compétence fournit

Ceci est un chargeur mince. Le corps garde seulement l'orientation nécessaire pour choisir le bon fichier suivant. Le matériel substantif spécifique à Rivermax vit dans deux fichiers compagnons :

CAPABILITIES.md — ce que DOCA Rivermax peut exprimer sur cette version et cette installation Rivermax SDK : la règle Rivermax-comme-dépendance-dure, le modèle d'objet doca_rmax_in_stream réception seule, la surface de requête de capacité (doca_rmax_get_*_supported), la taxonomie d'erreur Rivermax (mappée sur l'ensemble DOCA_ERROR_* inter-bibliothèques, avec les causes spécifiques à Rivermax appelées par ligne), la surface d'observabilité (événements du moteur de progression par flux, instantanés de capacité, état licence + pilote côté Rivermax), et la politique de sécurité qui conditionne la Rivermax-SDK-present / licence-present / accès-périphérique / préconditions de discipline de planification.
TASKS.md — flux de travail étape par étape pour les six verbes Rivermax en scope : configure, build, modify, run, test, debug. Plus un bloc Deferred task verbs qui pointe les questions hors scope (installer Rivermax, gérer la licence, programmer le routage, programmer la file sous-jacente) vers la bonne compétence suivante, et un Command appendix des commandes récurrentes que l'agent utilise.

La compétence suppose un hôte ou BlueField où DOCA est déjà installé à l'emplacement standard, le NVIDIA Rivermax SDK est installé à son emplacement attendu avec une licence valide, et l'utilisateur a les privilèges que son profil d'installation public attend (typiquement sudo ou appartenance au groupe mlnx pour ouvrir un doca_dev contre un port). Elle ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup. Elle ne couvre pas l'installation de Rivermax ou de sa licence — ce chemin passe par le guide public Rivermax SDK accessible via doca-public-knowledge-map.

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

Cette compétence est un guidance d'agent, pas un ensemble de samples ou de modèles. Pour garder la limite nette, elle ne contient délibérément pas — et les pull requests ne doivent pas ajouter :

Code source d'application DOCA Rivermax pré-écrit, dans n'importe quel langage. Le code source Rivermax vérifié est les samples C livrés à /opt/mellanox/doca/samples/doca_rmax/<name>/. Le travail de l'agent est de rediriger l'utilisateur vers ces fichiers et prescrire une modification diff minimal sur eux via le flux de travail universel modifier-un-sample dans doca-programming-guide, en couches avec les surcharges spécifiques à Rivermax dans TASKS.md ## modify.
Manifestes de compilation autonomes (meson.build, CMakeLists.txt, Cargo.toml, …) garés à l'intérieur de la compétence. L'agent construit le manifeste de compilation dans le répertoire de projet de l'utilisateur contre le DOCA installé de l'utilisateur, où pkg-config --modversion doca-rmax est la source de vérité.
*Noms de symboles Rivermax cités au-delà du motif de famille public (`doca_rmaxget_supportedpour la découverte de capacité, objets de sessiondoca_rmax_in_stream` réception seule pilotés par le cycle de vie de contexte Core DOCA standard).** Les noms de symboles Rivermax exacts sont liés à l'installation et liés à la version Rivermax SDK ; l'agent devrait les lire depuis les en-têtes installés à $(pkg-config --variable=includedir doca-common) et depuis le guide public DOCA Rivermax plutôt que de s'appuyer sur la mémoire de l'agent.
Un sous-arbre samples/, bindings/, ou reference/ d'une sorte. Un artefact fictif ou incomplet dans l'arbre de cette compétence, même étiqueté « reference », est trompeur : les utilisateurs le liront comme compilable.

Ordre de chargement

Lire d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est en scope ET que la précondition Rivermax-SDK + licence a été considérée.
Pour la matrice de capacité Rivermax, le modèle de flux d'entrée réception seule, les règles de requête de capacité, la taxonomie d'erreur, l'observabilité, et la politique de sécurité, voir CAPABILITIES.md.
Pour les flux de travail étape par étape — configure, build, modify, run, test, debug — voir TASKS.md.

Les deux fichiers compagnons se renvoient mutuellement, doca-version pour les règles de gestion de version DOCA canoniques (Rivermax ajoute un axe version-Rivermax-SDK par-dessus), doca-eth pour la surface de file qui porte les paquets, doca-flow pour le côté routage qui décide quels paquets arrivent à quelle file, et doca-public-knowledge-map chaque fois que la bonne réponse est « look it up in the public Rivermax SDK guide or the installed package layout » plutôt que « Rivermax-integration-specific guidance ».

Compétences associées

doca-public-knowledge-map — la table de routage pour chaque source de documentation publique DOCA et la disposition sur disque d'un paquet DOCA installé. Le slug URL Rivermax est DOCA-Rivermax ; le guide public Rivermax SDK (produit séparé) est accessible depuis la même table de routage quand l'utilisateur demande comment installer Rivermax ou sa licence.
doca-setup — préparation env, vérification d'installation, contrôles d'état de port (devlink dev show, ip link), requirements de permission et d'appartenance au groupe pour ouvrir un doca_dev. Cette compétence suppose que ses préconditions sont satisfaites ; les préconditions Rivermax-SDK + licence sont en couches par-dessus.
doca-version — règles de gestion de version DOCA canoniques. Le ## Version compatibility de cette compétence renvoie la règle de correspondance quatre-voie et ajoute la surcouche spécifique à Rivermax (la version Rivermax SDK est un second axe ; l'ensemble de capacité sur cet hôte est l'intersection des résultats de requête de capacité côté DOCA et des capacités côté Rivermax).
doca-structured-tools-contract — la règle de précédence des outils structurés du paquet (détecter / préférer / revenir / signaler). L'appendice Command dans TASKS.md honore ce contrat.
doca-programming-guide — motifs de programmation DOCA généraux partagés par chaque bibliothèque : le motif de compilation pkg-config + meson canonique, le flux de travail universel première-app modifier-un-sample-livré, le cycle de vie universel, la taxonomie DOCA_ERROR_* inter-bibliothèques, et l'ordre de debug côté programme. Cette compétence superpose des spécificités Rivermax par-dessus.
doca-eth — la surface de file qui porte les paquets qu'un flux Rivermax produit ou consomme. DOCA Rivermax ne programme pas la file sous-jacente lui-même ; il s'intègre à la file programmée via doca-eth. Les cycles de vie des deux compétences sont indépendants.
doca-flow — la surface de routage qui décide quels paquets arrivent à quelle file. DOCA Rivermax ne programme pas le routage lui-même ; un flux d'entrée Rivermax vide signifie presque toujours une règle Flow manquante ou incorrecte (ou une licence Rivermax manquante), pas un bug Rivermax.
doca-debug — l'escalier de debug inter-coupes (installation / version / compilation / liaison / runtime / programme / pilote). Le debug spécifique à Rivermax (lacunes de précondition de licence, incohérences de capacité type-de-flux / débit-de-paquet, symptômes de jitter de discipline de planification) superpose par-dessus cet escalier.