DOCA STA (Storage Target Acceleration)

Par où commencer : Ce skill suppose que DOCA est déjà installé et que l'utilisateur fait du travail pratique sur des cibles de stockage NVMe-over-Fabrics sur un appareil de classe BlueField avec DOCA. Ouvrez TASKS.md si l'utilisateur veut faire quelque chose (configurer / construire / modifier / exécuter / tester / déboguer) ; ouvrez CAPABILITIES.md quand la question porte sur ce que DOCA STA peut exprimer dans cette version. Si l'utilisateur n'a pas encore installé DOCA, dirigez-le d'abord vers doca-setup. Si l'utilisateur demande « est-ce un transport initiateur/hôte NVMe-oF ? », la réponse est non — doca-sta accélère le côté cible : il présente des cibles NVMe-oF doca_sta_subsystem soutenues par des disques NVMe-PCI locaux ; le modèle se trouve dans CAPABILITIES.md ## Capabilities and modes.

Exemples de questions auxquelles ce skill répond bien

Les CATÉGORIES de questions DOCA STA auxquelles ce skill est conçu pour répondre, chacune avec un exemple travaillé. L'agent doit traiter la catégorie comme la partie décisive — l'exemple travaillé est une seule instance.

« Comment configurer une cible NVMe-oF qui utilise le BlueField pour accélérer le chemin de données de stockage ? » — exemple travaillé : « définir un doca_sta_subsystem (NQN) avec un namespace soutenu par un disque NVMe-PCI local (doca_sta_be) et accepter des connexions NVMe-over-RDMA depuis un initiateur distant ». Répondu par le workflow du modèle et du cycle de vie de la cible dans TASKS.md ## configure + le tableau des objets cible CAPABILITIES.md ## Capabilities and modes.
« Ce BlueField peut-il accélérer une cible NVMe-oF ? » — exemple travaillé : « mon centre de données est RoCE bout en bout ; cet appareil supporte-t-il l'accélération de cible DOCA STA ? ». Le transport STA est RDMA uniquement (il n'y a pas de chemin NVMe-over-TCP). Répondu par la règle de requête de capacité (doca_sta_cap_is_supported contre un doca_devinfo) dans CAPABILITIES.md ## Capabilities and modes + l'étape de découverte dans TASKS.md ## configure.
« Jusqu'à quel point puis-je dimensionner mes files d'attente d'I/O, et combien de files d'attente d'I/O par connexion ? » — exemple travaillé : « je veux 16 files d'attente d'I/O de profondeur 1024 chacune — cet appareil supporte-t-il cela ? ». Répondu par la surface de capacité de dimensionnement des files d'attente dans CAPABILITIES.md ## Capabilities and modes + l'étape de dimensionnement des files d'attente dans TASKS.md ## configure qui dépend de la requête doca_sta_get_max_* correspondante (par exemple doca_sta_get_max_qps, doca_sta_get_max_io_queue_size).
« Quelles autres bibliothèques DOCA ai-je besoin à côté de doca-sta ? » — exemple travaillé : « ai-je besoin de doca-rdma directement, ou doca-sta me l'abstrait-il ? ». Répondu par la règle de bibliothèque de substrat dans CAPABILITIES.md ## Safety policy + la checklist de préparation de l'environnement dans TASKS.md ## configure étape 1, qui oriente le côté steering vers doca-flow et le substrat RDMA vers doca-rdma.
« Cette capacité STA est-elle disponible sur mon DOCA installé ? » — exemple travaillé : « l'accélération de cible STA est-elle supportée sur cette version BlueField + DOCA ? ». Répondu par l'overlay de version et d'appareil dans CAPABILITIES.md ## Version compatibility, qui crée des liaisons croisées vers la chaîne de détection canonique dans doca-version et ajoute la règle de requête de capacité spécifique à STA (pkg-config --modversion doca-sta est l'ancrage au moment de la construction ; la requête doca_sta_cap_is_supported à l'exécution est la source de vérité).
*« Que signifie ce `DOCAERRORd'un appel STA et quelle couche l'a provoqué ? »** — exemple travaillé : *«DOCA_ERROR_IO_FAILEDsur un I/O de lecture NVMe soumis contre une cible que je peux faire un ping »*. Répondu par l'overlay STA sur la taxonomie inter-bibliothèques dans [CAPABILITIES.md ## Error taxonomy](CAPABILITIES.md#error-taxonomy) + l'échelle en couches dans [TASKS.md ## debug](TASKS.md#debug) qui remonte vers [doca-debug`](../../doca-debug/SKILL.md).

Audience

Ce skill sert les développeurs externes construisant des cibles de stockage NVMe-over-Fabrics qui consomment DOCA STA sur BlueField — c'est-à-dire, les utilisateurs dont le code appelle doca_sta_* (directement en C/C++, ou via FFI/bindings depuis un autre langage) pour accélérer le chemin de données du côté cible d'une cible NVMe-oF sur le matériel BlueField : présentant des cibles doca_sta_subsystem (NQN + namespaces) soutenues par des disques NVMe-PCI locaux (doca_sta_be) aux initiateurs distants via RDMA. Ce skill n'est pas pour les développeurs NVIDIA contribuant à DOCA STA lui-même, et il n'est pas pour les piles NVMe côté initiateur/hôte.

Portée du langage. DOCA STA est livré comme une bibliothèque C avec le nom de module pkg-config doca-sta. DOCA STA ne livre aucun exemple public — il est absent des profils d'exemples des bibliothèques / extension_libraries — ainsi les exemples travaillés dans TASKS.md construisent contre les en-têtes publics directement plutôt que de modifier un exemple livré. Les consommateurs C et C++ sont le cas canonique. Les consommateurs d'autres langages (Rust, Go, Python, …) consomment le même *.so via FFI ou des bindings spécifiques au langage ; la contribution de ce skill dans ce cas est de garder le modèle cible, le cycle de vie, la découverte de capacités, la forme des paires de files d'attente, la dépendance de substrat, et la guidance de taxonomie d'erreurs indépendants du langage, et de diriger l'agent vers l'ABI C public comme la surface faisant autorité que tout wrapper finira par appeler.

Quand charger ce skill

Chargez ce skill quand l'utilisateur fait du travail pratique DOCA STA, dans n'importe quel langage. Concrètement :

Initialiser une instance doca_sta sur un doca_dev ouvert contre un BlueField PF / SF et configurer les subsystèmes cible NVMe-oF avant doca_ctx_start().
Définir les ressources cible — doca_sta_subsystem (NQN + namespaces) et contrôleurs backend doca_sta_be (disques NVMe-PCI locaux) — et accepter les connexions NVMe-oF (file d'attente admin plus N files d'attente d'I/O par connexion) du côté cible pendant que les initiateurs distants se connectent via RDMA CM.
Lire ou définir les propriétés STA via la famille doca_sta_set_*, vérifier le support de l'appareil via doca_sta_cap_is_supported, et interroger les limites de dimensionnement via la famille doca_sta_get_max_* (profondeur max de file d'attente d'I/O, nombre max de paires de files d'attente, taille d'I/O max, subsystèmes max, namespaces max par subsystème, backends max).
Câbler le transport NVMe-over-RDMA — le seul transport de STA ; il atterrit sur le substrat doca-rdma et utilise RDMA CM pour l'établissement de connexion — pour les files d'attente d'I/O de la cible.
Câbler les règles DOCA Flow pour que le trafic NVMe-oF atteigne réellement les files d'attente gérées par STA — la limite de steering est doca-flow, pas doca-sta.
Déboguer un DOCA_ERROR_* retourné par un appel STA (cycle de vie vs. capacité vs. défaillance d'I/O au niveau du transport vs. driver en dessous) et les événements par file d'attente sur le moteur de progression DOCA Core.
Concevoir ou étendre des bindings non-C (Rust, Go, Python, …) qui enveloppent l'ABI C DOCA STA — pour les règles de cycle de vie, de paire de files d'attente, de requête de capacité, et de dépendance de substrat que le wrapper doit honorer.

Ne chargez pas ce skill pour une orientation générale de DOCA, l'installation de DOCA lui-même, le mouvement de données RDMA brut (utilisez doca-rdma), le I/O brut de paquets sur les files d'attente Ethernet (utilisez doca-eth), la programmation de règles de flux (utilisez doca-flow), ou le développement de pile NVMe côté initiateur/hôte (SPDK ou kernel-nvme en sont responsables, pas ce skill). Pour l'orientation de la documentation DOCA, utilisez doca-public-knowledge-map.

Ce que ce skill fournit

C'est un thin loader. Le corps ne garde que l'orientation nécessaire pour choisir le bon fichier suivant. Le matériel substantiel spécifique à STA vit dans deux fichiers d'accompagnement :

CAPABILITIES.md — ce que DOCA STA peut exprimer dans cette version : le modèle d'objet cible (doca_sta_subsystem / namespaces / disques backend NVMe-PCI doca_sta_be), la forme de paire de files d'attente NVMe (file d'attente admin + files d'attente d'I/O via RDMA), le transport RDMA uniquement, la surface de requête de capacité (doca_sta_cap_is_supported plus les requêtes de dimensionnement doca_sta_get_max_*), la taxonomie d'erreur STA (mappée à l'ensemble DOCA_ERROR_* inter-bibliothèques), la surface d'observabilité (événements du moteur de progression par file d'attente, snapshots de capacité), et la politique de sécurité qui contrôle les préconditions de bibliothèque de substrat, de permission, et de steering.
TASKS.md — workflows pas à pas pour les six verbes STA dans la portée : configure, build, modify, run, test, debug. Plus un bloc Deferred task verbs qui pointe les questions hors de portée vers le bon skill suivant, et une Command appendix des commandes récurrentes que l'agent utilise.

Ce skill suppose un BlueField (avec DOCA installé à l'emplacement standard) plus un initiateur NVMe-oF distant accessible sur le fabric pour se connecter à la cible accélérée, et un ou plusieurs disques NVMe-PCI locaux pour soutenir les namespaces de la cible. Il ne couvre pas l'installation de DOCA — ce chemin passe par doca-setup. Il ne couvre pas les piles NVMe côté initiateur/hôte (SPDK bdev_nvme, kernel nvme host) ou la sémantique du protocole NVMe au-dessus du chemin de données de cible accélérée — ceux-ci sont hors de portée.

Ce que ce skill ne livre délibérément pas

Ce skill est une guidance pour agent, pas un bundle de samples ou de templates. Pour garder la frontière claire, il ne contient délibérément pas — et les pull requests ne devraient pas ajouter :

Code source d'application DOCA STA pré-écrit, dans n'importe quel langage. DOCA STA ne livre aucun exemple public — il n'y a pas de répertoire /opt/mellanox/doca/samples/doca_sta/, et STA est absent des profils d'exemples des bibliothèques / extension_libraries. La surface faisant autorité est les en-têtes publics sous $(pkg-config --variable=includedir doca-common) plus le guide public DOCA STA ; l'agent construit contre ceux-ci directement plutôt que de modifier un exemple livré, selon le workflow TASKS.md ## modify.
Glu de pile NVMe côté initiateur/hôte. SPDK bdev_nvme, le kernel nvme host, et toute pile NVMe côté initiateur sont des projets amont hors de portée pour ce skill — DOCA STA est l'accélération côté cible, pas un fournisseur de transport d'initiateur.
Manifestes de construction autonomes (meson.build, CMakeLists.txt, Cargo.toml, …) stationnés dans le skill. L'agent construit le manifeste de construction dans le répertoire du projet de l'utilisateur contre le DOCA installé de l'utilisateur, où pkg-config --modversion doca-sta est la source de vérité.
Un sous-arbre samples/, bindings/, ou reference/ de quelque sorte. Un artefact simulé ou incomplet dans l'arbre de ce skill, même un étiqueté « reference », est trompeur : les utilisateurs le liront comme constructible.

Ordre de chargement

Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est dans la portée.
Pour la matrice de capacité STA, le modèle d'objet cible, la forme de paire de files d'attente, le transport RDMA uniquement, 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 workflows pas à pas — configure, build, modify, run, test, debug — voir TASKS.md.

Les deux fichiers d'accompagnement créent des liaisons croisées entre eux, doca-version pour les règles de gestion de version canoniques, doca-rdma pour le substrat RDMA sur lequel le transport NVMe-over-RDMA atterrit, doca-flow pour les règles de steering qui dirigent le trafic NVMe vers les files d'attente gérées par STA, et doca-public-knowledge-map quand la bonne réponse est « cherchez-la dans les docs publics ou la disposition du paquet installé » plutôt que « guidance spécifique à STA ».

Skills connexes

doca-public-knowledge-map — la table de routage pour chaque source de documentation DOCA publique et la disposition sur disque d'un paquet DOCA installé. Le slug d'URL STA est DOCA-STA.
doca-setup — préparation de l'environnement, vérification de l'installation, vérifications du mode BlueField, et les exigences de permission / appartenance au groupe pour ouvrir un doca_dev. Ce skill suppose que ses préconditions sont satisfaites.
doca-version — règles canoniques de gestion des versions DOCA. Le ## Version compatibility de ce skill crée des liaisons croisées vers la règle de correspondance quatre voies et ajoute seulement l'overlay spécifique à STA (fenêtres de disponibilité d'accélération de cible STA, support conditionnel par appareil de jeu de fonctionnalités NVMe-oF).
doca-structured-tools-contract — règle de précédence des structured-tools du bundle (détecter / préférer / tomber en arrière / rapporter). La Command appendix 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 construction canonique pkg-config + meson, le workflow universel de modification d'un exemple livré pour la première application, le cycle de vie universel, la taxonomie inter-bibliothèques DOCA_ERROR_*, et l'ordre de debug côté programme. Ce skill ajoute des spécificités STA par-dessus.
doca-rdma — le substrat RDMA sur lequel le transport NVMe-over-RDMA atterrit. STA abstrait la plupart des détails de paire de files d'attente RDMA du consommateur, mais l'utilisateur a toujours besoin que doca-rdma soit lié et que les capacités RDMA de l'appareil soient découvrables pour que le chemin NVMe-over-RDMA fonctionne.
doca-eth — la forme de paire de files d'attente que le modèle de files d'attente par connexion de STA fait écho. Arrivez ici si l'utilisateur pose des questions générales sur la façon dont DOCA expose les paires de files d'attente qui n'ont pas de réponse spécifique à STA.
doca-flow — la surface de steering qui décide quels paquets NVMe-oF atterrissent sur quelle file d'attente gérée par STA. DOCA STA ne programme pas le steering lui-même ; une cible NVMe-oF dont les connexions ne se lèvent jamais est souvent une règle Flow manquante ou incorrecte, pas un bug STA.
doca-debug — l'échelle de debug inter-coupes (installation / version / construction / liaison / exécution / programme / driver). Le debug spécifique à STA (incompatibilités de type de transport, file d'attente d'I/O surdimensionnée, erreurs d'I/O ayant échoué au transport) se superpose à cette échelle.