7 min
La spécification du protocole MCTP (Management Component Transport Protocol), publiée par l’organisme de normalisation DMTF, fait partie intégrante de nombreuses architectures informatiques et de serveurs, car elle définit la manière dont un contrôleur de gestion système peut communiquer avec des périphériques gérés, tels que les cartes d’extension PCIe et les disques durs.
Le protocole MCTP est un système de messagerie aligné sur les octets qui s’appuie sur une couche physique et/ou un protocole de communication existant. C’est pourquoi on le qualifie de « couche de transport » : il définit uniquement les octets constituant un message (de gestion et de contrôle), sans préciser la manière dont ces octets sont transmis. Ce concept est illustré visuellement à la figure 1.
Les sections en gris correspondent aux en-têtes et pieds de page typiques d’une couche physique sous-jacente telle que PCI Express (PCIe). Les sections en orange et en vert correspondent aux octets de charge utile définis par le protocole MCTP. Pour la couche physique sous-jacente, les paquets MCTP ne sont que des octets de charge utile, et ils suivent les mêmes schémas de codage et de mappage que la couche physique.
Pour mieux comprendre ce principe, imaginez une carte mère équipée d’un disque SSD (Solid-State Drive) connecté via un emplacement PCIe. Le SSD est un périphérique géré dans le cadre du protocole MCTP. Les messages de contrôle MCTP peuvent être transmis entre le processeur et le SSD via le protocole PCIe lui-même. Ceci est illustré schématiquement à la figure 2.
Or, si vous avez déjà utilisé le PCIe, vous savez qu’il s’agit d’un bus très performant et très complexe ; il est donc préférable de l’utiliser pour effectuer des transferts critiques (comme la lecture de fichiers volumineux à partir d’un disque SSD) à vitesse maximale, plutôt que pour la gestion du système. C’est pourquoi, dans de nombreuses implémentations pratiques, le protocole MCTP s’appuie souvent sur d’autres couches physiques plus simples, telles que le SMBus ou l’I2C. Et désormais, grâce à la récente interface I3C, le protocole MCTP s’appuie sans problème sur une couche physique I3C ! Voir la figure 3.
Dans ce cas, toutes les transactions de paquets MCTP prennent la forme de transactions d’écriture SMBus afin d’envoyer des messages de requête ou de réponse entre les périphériques. Par conséquent, chaque périphérique présent sur le bus (y compris le contrôleur) doit disposer d’une adresse afin de pouvoir être la cible de la transaction.
La figure 4 présente le format de paquet MCTP sur SMBus/I2C, avec l’ajout de quatre octets (octet 1 à octet 4) définissant l’en-tête spécifique au support. Les octets 1 à 3 (adresse de l’esclave de destination, code de commande, nombre d’octets) sont des champs SMBus. L’octet 4 (adresse de l’esclave source) a été introduit par le protocole MCTP en tant qu’octet supplémentaire afin de faciliter le transfert des messages de réponse vers l’expéditeur. Les octets restants (octets 5 à N-1) correspondent à l’en-tête de transport et aux octets de charge utile habituels (illustrés à la figure 1). Notez qu’une fois le paquet MCTP complet, l’octet de code d’erreur de paquet (PEC) est envoyé ; celui-ci est simplement requis par le protocole MCTP pour garantir la robustesse du système.
Comme indiqué précédemment pour le protocole MCTP via SMBus/I2C, toutes les transactions prennent la forme de transferts en écriture, quel que soit le sens de la communication. Toutefois, dans le cas d’une liaison I3C, le transfert de paquets prend des formes différentes selon le sens de la communication :
Dans un article précédent, nous avons montré comment les commandes d’écriture et de lecture MCTP sont construites sur I3C; la figure 5 est reproduite ici pour plus de commodité. Poursuivez votre lecture pour découvrir à quel point le SV6E-X est un outil simple à utiliser pour effectuer ce type de tests aussi bien sur I3C que sur SMBus/I2C.
Le module de test numérique à moyenne fréquence SV6E-X est la solution primée d’Introspect destinée au test et à la validation des interfaces I2C, I3C et de celles qui en découlent. Il prend bien entendu en charge sans difficulté le protocole MCTP.
Par exemple, pour utiliser le SV6E-X comme contrôleur (périphérique principal) et générer des messages MCTP via I3C à destination d’un périphérique géré soumis à un test, il vous suffit d’utiliser une commande telle que :
Les arguments de la commande permettent de définir facilement les champs du paquet MCTP conformément au format de message illustré à la figure 1. Veuillez noter que l’octet PEC est calculé automatiquement et que l’utilisateur n’a pas à le calculer lui-même.
De même, le SV6E-X peut servir de cible (périphérique secondaire) pour tester des périphériques principaux. Dans ce cas, le transfert de messages MCTP du périphérique secondaire vers le périphérique principal via I3C en mode IBI peut être effectué à l’aide de l’exemple de code suivant :
Enfin, le SV6E-X peut être utilisé comme analyseur de protocole et comme oscilloscope en temps réel, et toutes ces fonctionnalités sont disponibles pour les tests MCTP. Les figures 6 et 7 présentent deux exemples de décodage d’un transfert MCTP à l’aide de l’analyseur de protocole.
Dans cet article, nous avons décrit le protocole MCTP et la manière dont il est encapsulé sur SMBus/I2C ou sur le protocole MIPI I3C. Nous avons illustré comment les octets des paquets MCTP peuvent être formatés pour créer des messages envoyés d’un dispositif principal vers un dispositif secondaire, et nous avons également montré comment un dispositif secondaire peut renvoyer des messages de réponse au dispositif principal. Enfin, nous avons présenté le module de test numérique à moyenne fréquence SV6E-X et montré comment il prend naturellement en charge les tests MCTP, ce qui facilite la conception, le débogage et la caractérisation du dispositif MCTP soumis aux tests.
