Introduits avec les processeurs « Sapphire Rapids » évolutifs Xeon de 4e génération, divers nouveaux accélérateurs sont disponibles sur certaines références ou via l’offre Intel On Demand. L’un des premiers défis réside cependant dans les limitations de la prise en charge des premiers accélérateurs et de nombreux logiciels open source en amont (ou même simplement répandus) qui ne sont pas encore capables d’utiliser ces nouveaux accélérateurs. L’une des améliorations sur ce front a été que les ingénieurs d’Intel ont travaillé sur un pilote de compression crypto IAA pour le noyau afin que l’accélérateur d’analyse en mémoire puisse être accessible de manière transparente aux fonctionnalités du noyau utilisant l’API crypto.
Au cours des derniers mois, le pilote de compression IAA Crypto pour le noyau Linux a subi une demi-douzaine de révisions jusqu’à ce qu’il progresse vers la ligne principale. Ce nouveau pilote rend l’accélérateur Intel IAA disponible via l’API de chiffrement du noyau et peut à son tour être utilisé par le code du noyau ciblant cette API, comme Zswap et zRAM. Le pilote fournit à la fois des versions synchrones et asynchrones de l’algorithme DEFLATE implémenté par le matériel.
Alors que ce pilote ouvrira des cas d’utilisation du noyau pour l’accélérateur IAA, les notes de mise à jour du pilote reconnaissent les maux de tête initiaux liés à la configuration des accélérateurs Sapphire Rapids, c’est-à-dire qu’il ne sera toujours pas prêt à l’emploi lors du démarrage d’une pile logicielle Linux capable :
“Le matériel IAA est assez complexe et nécessite généralement un administrateur compétent avec une compréhension suffisamment détaillée du matériel à configurer avant de pouvoir l’utiliser. Comme mentionné dans la documentation, cela nécessite généralement l’utilisation d’un outil spécial appelé accel-config pour énumérer et configurer les files d’attente de travail IAA, les moteurs, etc., bien que cela puisse également être fait en utilisant uniquement les fichiers sysfs.
Le fonctionnement du pilote reflète cette exigence et ne permet d’accéder au matériel via la couche de cryptage qu’une fois que le matériel a été configuré et lié au pilote de cryptage IAA. En tant que sous-pilote IDXD, le pilote de cryptage IAA prend essentiellement possession de le matériel jusqu’à ce qu’il soit explicitement abandonné par l’administrateur. Cela se produit automatiquement lorsque l’administrateur active la première file d’attente IAA ou désactive la dernière ; les algorithmes iaa_crypto (sync et async) sont enregistrés lorsque la première file d’attente est activée, et désenregistrés lorsque la dernière est désactivée.
La séquence normale des opérations serait normalement :
configurez le matériel en utilisant accel-config ou sysfs
configurez le pilote de chiffrement iaa (voir ci-dessous)
configurez le sous-système, par ex. zswap/zram pour utiliser l’algo iaa_crypto
exécuter la charge de travail”
Mais lorsque tout est configuré et fonctionne avec ce pilote proposé, les résultats de performance sont assez spectaculaires avec IAA utilisation par rapport à un logiciel pur :
Plus tôt ce mois-ci, une série de correctifs v6 pour ce pilote de noyau a été envoyé pour examen. Bien que le timing et la branche cryptodev.git n’aient pas encore été récupérés, il est peu probable que ce pilote soit prêt à temps pour le prochain cycle Linux v6.5. Un autre obstacle a été potentiellement levé la semaine dernière par le mainteneur du sous-système crypto Linux Herbert Xu :
Donc, vous avez dit que la mise en conserve n’est pas compatible avec l’algorithme de déflation générique. Cela signifie-t-il qu’il n’y a aucun moyen pour lui de décompresser quelque chose de compressé par l’algorithme de déflation générique, et vice versa, sa sortie compressée ne peut pas être décompressée par le dégonflage générique ?
Nous n’ajoutons pas d’algorithme à l’API Crypto si la seule implémentation est matérielle. IOW si vous ajoutez un nouvel algorithme, alors une version du logiciel doit être le premier correctif.
Cette différence dans l’implémentation de deflate d’Intel semble être authentique. Les développeurs de ClickHouse ont précédemment averti dans leur prise en charge Intel QPL que si vous souhaitez déplacer des bases de données accélérées par Intel IAA entre des hôtes, vous devez d’abord convertir toutes les données avant de les retirer du serveur. Dans ce cas, si ce pilote doit être intégré, Intel devra également fournir une implémentation logicielle pour le noyau.
