Émulation de dispositif DOCA

Par où commencer : Cette skill suppose que DOCA est déjà installé sur l'hôte ET sur le BlueField, l'utilisateur effectue des travaux pratiques d'émulation de dispositif PCIe depuis le côté DPU (écriture du backend avec lequel le pilote du noyau de l'hôte communiquera via la surface PCIe émulée), et l'utilisateur sait quelle CLASSE de dispositif émulé il veut construire. Ouvrez TASKS.md si l'utilisateur veut faire quelque chose (configurer / construire / modifier / exécuter / tester / déboguer) ; ouvrez CAPABILITIES.md quand la question est ce que l'émulation de dispositif peut exprimer sur cette version DOCA + cette génération BlueField + ce firmware. Si l'utilisateur n'a pas encore installé DOCA, dirigez-le d'abord vers doca-setup. Avant toute chose, l'agent doit diriger l'utilisateur vers la bonne sous-bibliothèque — l'émulation de dispositif DOCA est un parapluie qui couvre PCI Generic (émulation de dispositif PCIe brut), virtio-net (dispositif de réseau virtio émulé), et virtio-fs (dispositif de système de fichiers virtio émulé) ; chaque sous-bibliothèque a son propre contexte, son propre module pkg-config, et sa propre surface de capacité. La règle de sélection de la sous-bibliothèque se trouve dans CAPABILITIES.md ## Capabilities and modes. Si l'utilisateur veut une solution empaquetée plutôt qu'une bibliothèque (par ex. « je veux NVMe SNAP sur mon hôte sans écrire le backend moi-même », ou « je veux un daemon virtio-net géré »), dirigez-le via doca-public-knowledge-map vers les guides DOCA SNAP Service / DOCA Virtio-net Service — ces services sont construits au-dessus de cette bibliothèque et constituent un artefact différent de celui que cette skill couvre.

Audience

Cette skill sert les développeurs externes qui créent des applications consommant la bibliothèque DOCA Device Emulation — c'est-à-dire les utilisateurs dont le code côté DPU appelle doca_devemu_pci_*, doca_devemu_virtio_*, ou doca_devemu_vfs_* (directement en C / C++, ou via FFI / bindings d'un autre langage) pour exposer un dispositif PCIe émulé à l'hôte que les pilotes du noyau existants de l'hôte peuvent piloter comme s'il s'agissait d'un vrai périphérique PCIe. Ce n'est pas pour les développeurs NVIDIA contribuant à Device Emulation lui-même, et ce n'est pas l'artefact approprié pour les utilisateurs qui veulent un daemon de dispositif émulé empaquetté dont ils ne doivent pas écrire le backend (les DOCA SNAP Service et DOCA Virtio-net Service sont les options empaquetées qui s'appuient sur cette bibliothèque).

Portée linguistique. DOCA Device Emulation est expédié en tant que bibliothèque C avec trois modules pkg-config publics — un par sous-bibliothèque — sélectionnés selon la classe d'émulation que l'utilisateur construit (voir le tableau de sélection de sous-bibliothèque dans CAPABILITIES.md ## Capabilities and modes). Les exemples expédiés sous /opt/mellanox/doca/samples/doca_devemu/ sont écrits en C. Les consommateurs C et C++ sont le cas canonique et les exemples détaillés dans TASKS.md supposent ce chemin. Les consommateurs dans d'autres langages (Rust, Go, Python, …) consomment les mêmes fichiers *.so via FFI ou des bindings spécifiques au langage ; la contribution de la skill dans ce cas est de maintenir la sélection de sous-bibliothèque, le cycle de vie de l'umbrella, la découverte de capacité, la permission et la taxonomie d'erreur neutre au langage, et de diriger l'agent vers l'ABI C public comme surface faisant autorité que tout wrapper finira par appeler.

Quand charger cette skill

Chargez cette skill quand l'utilisateur effectue des travaux pratiques DOCA Device Emulation depuis le côté DPU, dans n'importe quel langage. Concrètement :

• Décider quelle sous-bibliothèque Device Emulation (PCI Generic, virtio-net, virtio-fs) l'utilisateur a besoin — la question de sélection du parapluie est le premier mouvement chargé de cette skill.
• Initialiser le contexte DOCA Core par sous-bibliothèque sur le DPU (un contexte par dispositif émulé par sous-bibliothèque) et configurer les primitives doorbell / DMA avec lesquelles le pilote PCIe de l'hôte interagira.
• Lire la surface de capacité par sous-bibliothèque via les familles de requêtes doca_devemu_pci_cap_*, doca_devemu_virtio_cap_*, ou doca_devemu_vfs_cap_* contre le doca_devinfo actif AVANT de supposer qu'un bit de caractéristique ou une caractéristique de dispositif particulière est disponible.
• Choisir entre écrire le backend avec doca-devemu vous-même et adopter un service empaquetté (DOCA SNAP Service / DOCA Virtio-net Service) qui enveloppe déjà cette bibliothèque.
• Déboguer une DOCA_ERROR_* retournée par un appel doca_devemu_* — en particulier pour distinguer le type d'émulation au niveau du firmware n'est pas activé de la génération BlueField ne supporte pas du tout cette sous-bibliothèque de le processus côté DPU manque de privilèges de le pilote du noyau côté hôte ne s'est pas lié.
• Concevoir ou étendre des bindings non-C (Rust, Go, Python, …) qui enveloppent une des sous-bibliothèques d'émulation de dispositif — pour la sélection de sous-bibliothèque, le cycle de vie de l'umbrella, la découverte de capacité, la permission, et les règles de taxonomie d'erreur que le wrapper doit respecter.

Ne chargez pas cette skill pour l'orientation générale de DOCA, l'installation de DOCA lui-même, le pilote du noyau côté hôte pour la classe de dispositif émulé (les pilotes du noyau virtio-net / virtio-blk / virtio-fs sont expédiés avec le noyau de l'hôte et ne font pas partie de DOCA), les services SNAP / Virtio-net empaquetés (ce sont des artefacts distincts avec leurs propres guides de service), ou pour le comportement standard du NIC sur le chemin de données BlueField (utilisez doca-flow + doca-eth à la place — Device Emulation est pour les dispositifs émulés personnalisés, pas pour façonner la personnalité NIC intégrée du BlueField).

Ce que cette skill fournit

C'est un chargeur allégé. Le corps ne conserve que l'orientation nécessaire pour choisir le prochain fichier correct. Le matériel substantiel spécifique à Device Emulation se trouve dans deux fichiers complémentaires :

• CAPABILITIES.md — ce que Device Emulation peut exprimer sur cette version + cette génération BlueField + ce firmware : l'architecture du parapluie (l'hôte voit un dispositif PCIe émulé ; le DPU exécute le backend), la règle de sélection de sous-bibliothèque (PCI Generic vs virtio-net vs virtio-fs), la forme du contexte Core par sous-bibliothèque, les primitives doorbell / DMA qui relient hôte ↔ DPU, la famille de requête de capacité par sous-bibliothèque (doca_devemu_*_cap_*), le nom du module pkg-config par sous-bibliothèque, la taxonomie d'erreur de Device Emulation mappée sur l'ensemble transversal DOCA_ERROR_*, la surface d'observabilité, la règle de sélection de chemin bibliothèque-vs-service-empaquetté, et la politique de sécurité qui contrôle les préconditions d'env (privilèges côté DPU, activation du type d'émulation au niveau du firmware BlueField, génération BlueField supportant réellement la classe d'émulation).
• TASKS.md — workflows pas à pas pour les six verbes Device Emulation en scope : configure, build, modify, run, test, debug. Plus un bloc Deferred task verbs qui pointe les questions hors scope vers la bonne skill suivante.

La skill suppose une paire hôte + BlueField où DOCA est déjà installé à l'emplacement standard des deux côtés, le firmware BlueField a le type d'émulation que l'utilisateur veut construire activé, l'utilisateur a les privilèges que son profil d'installation publique s'attend (en particulier, sudo côté DPU pour effectuer l'émulation au niveau PCIe), et le noyau de l'hôte expédie le pilote standard pour la classe de dispositif émulé que l'utilisateur construit. Elle ne couvre pas l'installation de DOCA, le basculement de la configuration au niveau du firmware, ou l'installation des pilotes du noyau côté hôte — ces chemins passent par doca-setup.

Ordre de chargement

1. Lisez d'abord ce SKILL.md pour confirmer que la question de l'utilisateur est en scope (dispositif PCIe émulé personnalisé construit sur la bibliothèque doca-devemu, pas les services SNAP / Virtio-net empaquetés, pas le pilote du noyau côté hôte, pas le comportement standard du NIC).
2. Pour l'architecture du parapluie, la règle de sélection de sous-bibliothèque (PCI Generic vs virtio-net vs virtio-fs), la forme du contexte Core par sous-bibliothèque, les primitives doorbell / DMA, la règle de requête de capacité par sous-bibliothèque, les modules pkg-config par sous-bibliothèque, la règle de sélection de chemin bibliothèque-vs-service-empaquetté, la taxonomie d'erreur, la surface d'observabilité, et la politique de sécurité, voir CAPABILITIES.md.
3. Pour les workflows pas à pas — configure, build, modify, run, test, debug — voir TASKS.md.

Les deux fichiers complémentaires se renvoient mutuellement, doca-version pour les règles canoniques de gestion des versions DOCA (avec la couche Device Emulation que le module pkg-config de la sous-bibliothèque choisie plus le slot d'émulation au niveau du firmware plus la requête doca_devemu_*_cap_* font tous partie de « cette émulation est-elle supportée ici »), et doca-public-knowledge-map chaque fois que la bonne réponse est « cherchez-le dans le guide public DOCA Device Emulation umbrella, le guide par sous-bibliothèque lié à partir de lui, le guide DOCA SNAP / Virtio-net Service, ou dans la disposition d'installation sur disque » plutôt que « guidance spécifique à Device Emulation ».

Exemples de questions auxquelles cette skill répond bien

Voir references/details.md.

Ce que cette skill n'expédie délibérément pas

Voir references/details.md.

Skills connexes

Voir references/details.md.