L’une des normes de connectivité les plus intéressantes de l’année dernière a été la CXL. Construit sur une base physique PCIe, CXL est une norme de connectivité conçue pour gérer bien plus que ce que fait PCIe – en plus d’agir simplement comme un transfert de données d’hôte à périphérique, CXL a trois branches à prendre en charge, appelées IO, Cache et Memory . Tel que défini dans les normes CXL 1.0 et 1.1, ces trois éléments constituent la base d’une nouvelle façon de connecter un hôte à un périphérique. La nouvelle norme CXL 2.0 va encore plus loin.

CXL 2.0 est toujours basé sur la même norme physique PCIe 5.0, ce qui signifie qu’il n’ya pas de mises à jour de bande passante ou de latence, mais ajoute des fonctionnalités indispensables auxquelles les clients sont habitués avec PCIe. Au cœur de CXL 2.0 se trouvent les mêmes intrinsèques CXL.io, CXL.cache et CXL.memory, traitant de la façon dont les données sont traitées et dans quel contexte, mais avec des capacités de commutation supplémentaires, un cryptage supplémentaire et la prise en charge de la mémoire persistante.

Commutation CXL 2.0

Pour les utilisateurs qui ne sont pas familiers avec les commutateurs PCIe, ceux-ci se connectent à un processeur hôte avec un certain nombre de voies, telles que huit voies ou seize voies, puis prennent en charge beaucoup plus de voies en aval pour augmenter le nombre de périphériques pris en charge. Un commutateur PCIe standard, par exemple, peut se connecter avec 16 voies au processeur, mais offrir 48 voies PCIe en aval pour activer six GPU connectés à x8 chacun. Il y a un goulot d’étranglement en amont, mais pour les charges de travail qui reposent sur le transfert GPU-GPU, en particulier sur les systèmes avec des voies CPU limitées, l’utilisation d’un commutateur est la meilleure solution. CXL 2.0 active désormais la norme de commutation.

Les commutateurs PCIe modernes font plus que simplement «ajouter des voies». En cas de défaillance de l’un des périphériques d’extrémité (comme un SSD NVMe), le commutateur garantit que le système peut toujours fonctionner et désactiver cette voie afin qu’elle n’affecte pas le reste du système. Les commutateurs actuels sur le marché prennent également en charge la connectivité de commutateur à commutateur, permettant à un système d’évoluer les périphériques en aval.

L’une des mises à jour les plus importantes des produits de commutation récents a été la prise en charge de plusieurs hôtes en amont, de sorte qu’en cas de panne d’un hôte, les périphériques en aval ont toujours un autre hôte auquel se connecter. Combiné à une connectivité de commutateur à commutateur, un système peut avoir une série d’hôtes et de périphériques mis en pool. Chaque périphérique peut fonctionner spécifiquement avec un hôte du pool dans une relation 1: 1, ou les périphériques peuvent fonctionner avec de nombreux hôtes. La nouvelle norme, avec les API CXL Switching Fabric, permet à jusqu’à 16 hôtes d’utiliser un périphérique CXL en aval à la fois. En plus de cela, la qualité de service (QoS) fait partie de la norme, et afin de permettre cela, l’unité de transfert de données par paquet / FLIT standard est inchangée, avec certains des bits inutilisés de CXL 1.1 étant utilisés (c’est à quoi servent les bits supplémentaires!).

Le seul élément non présent dans CXL 2.0 est les topologies de commutateurs multicouches. À l’heure actuelle, la norme et l’API ne prennent en charge qu’une couche plate. Dans notre briefing, les membres du consortium (dont certains créent déjà des tissus de commutation PCIe multicouches) ont déclaré qu’il s’agissait de la première étape de l’activation de la mécanique des commutateurs et que la feuille de route se développerait en fonction des besoins des clients.

Mémoire persistante CXL 2.0

Un autre cran de l’informatique d’entreprise au cours des dernières années est la mémoire persistante – quelque chose presque aussi rapide que la DRAM mais stockant des données comme NAND. Il a toujours été question de savoir où se situerait une telle mémoire: soit en tant que petit stockage rapide via une interface de type stockage, soit en tant que mémoire lente à haute capacité via une interface DRAM. Les normes CXL initiales ne supportaient pas directement la mémoire persistante, sauf si elle avait déjà un périphérique attaché, dans la norme CXL.memory. Cette fois, cependant, CXL 2.0 permet une prise en charge PMEM distincte dans le cadre d’une série de ressources mises en commun.

Les API permettant au logiciel de gérer la prise en charge PMEM sont intégrées dans la spécification, ce qui permet d’accéder aux pools de mémoire persistante soit en mode «App Direct» en tant que niveau de stockage distinct, soit en mode «Memory Direct» qui étend le pool DRAM hôte. L’objectif ici est davantage lié à la gestion du stockage à plusieurs niveaux, quelle que soit la manière dont les clients membres du consortium CXL ont besoin pour leur application.L’objectif est donc que la norme prenne en charge autant que possible, puis améliore au fil du temps ceux qui gagnent en popularité.

L’aspect Mémoire persistante établit des parallèles avec les produits Intel DC Persistent Memory Optane, et le but ici est de les utiliser plus ou moins de la même manière, sauf que cette fois, il y a un support direct via les interfaces CXL et les commutateurs CXL, ce qui rend les pools de la mémoire ou le stockage disponible dans tout le système, plutôt que sur un seul hôte (ou via une interface PCIe vers un pool).

Sécurité CXL 2.0 (en option)

La dernière mise à jour de fonctionnalités, mais sans doute la plus importante pour certains, est la sécurité point à point pour tout lien CXL. La norme CXL 2.0 prend désormais en charge le chiffrement des communications de tout à tout grâce à l’utilisation de l’accélération matérielle intégrée aux contrôleurs CXL. Il s’agit d’un élément facultatif de la norme, ce qui signifie que les fournisseurs de silicium n’ont pas à l’intégrer, ou s’il est intégré, il peut être activé / désactivé, mais dans le briefing, on m’a dit qu’il est prévu que la plupart si tout l’écosystème qui s’appuie sur CXL 2.0 ne l’utilisera pas – ou du moins l’aura comme option à activer.

Interrogé sur les hits à la latence, j’ai été informé qu’il y avait un hit à la latence, mais cela dépendra du cas d’utilisation exact s’il est activé. Aucun chiffre précis n’a été donné, mais on m’a dit que les clients qui ont besoin de la latence la plus élevée, qui peuvent assurer la sécurité du système, le verront probablement désactivé, tandis que ceux qui en ont besoin pour se conformer aux demandes des clients ou pour un serveur à serveur. communications, sont susceptibles de l’utiliser.

Feuille de route CXL 2.0 et CXL

La première partie de la discussion sur CXL 2.0 avec deux des membres du consortium a commencé par expliquer que la feuille de route CXL est conçue pour répondre à la fois aux demandes et aux tendances du marché, tout en respectant les demandes des clients des membres du consortium. Cela signifie que les tendances en matière de désagrégation des serveurs, ou plus de bande passante de stockage, ont conduit à des fonctionnalités telles que la commutation et la prise en charge de la mémoire persistante. CXL s’est engagé à permettre des normes industrielles ouvertes, même si elles couvrent la nouvelle génération de CXL.

J’ai posé des questions sur ce lien de couche physique avec PCIe, et où le consortium voit cela évoluer. On m’a dit qu’actuellement, il n’était pas prévu de s’écarter de la spécification physique PCIe – il devrait y avoir une forte attraction et un fort besoin de construire une autre topologie de couche physique, ce qui briserait également la rétrocompatibilité (ce qui est apparemment un pierre angulaire de CXL). Il convient de noter que tous les périphériques CXL sont censés avoir une solution de secours PCIe, mais certaines / la plupart / toutes les fonctionnalités clés du mode PCIe peuvent être perdues, selon le produit.

Nous n’avons pas encore vu de produits CXL arriver sur le marché, même 1.0 / 1.1, principalement en raison de l’exigence d’avoir une interface physique PCIe 5.0. Intel a déjà déclaré que Sapphire Rapids prendrait en charge CXL 1.1, mais cela est encore loin. S’adressant aux contacts de notre consortium, ils ont déclaré que pour tout membre du consortium cherchant à créer un hôte, un appareil ou un commutateur CXL aujourd’hui, il est prévu qu’ils suivront la spécification CXL 2.0. Pour de nombreux membres du consortium, il y a encore des apprentissages à faire avec le silicium CXL – des preuves de concepts sont toujours en cours. Il convient de noter que tout produit CXL 2.0 est rétrocompatible avec CXL 1.0 / 1.1 – la norme est conçue de cette façon.

La semaine prochaine aura lieu la conférence annuelle Supercomputing, axée sur le calcul haute performance. Ce serait une arène clé pour certains membres du consortium CXL pour faire des annonces, si l’un d’entre eux commençait à parler de produits CXL ou de feuilles de route CXL 2.0.

Lecture connexe