Introduceret med 4. generation af Xeon-skalerbare”Sapphire Rapids”-processorer er forskellige nye acceleratorer tilgængelige på udvalgte SKU’er eller via Intel On Demand-tilbuddet. En af de indledende udfordringer der er dog de tidlige accelerator-softwareunderstøttelsesbegrænsninger og mange upstream open source (eller endda bare udbredt) software, der endnu ikke er aktiveret til at gøre brug af disse nye acceleratorer. En af forbedringerne på den front har været Intel-ingeniører, der arbejder på en IAA-kryptokomprimeringsdriver til kernen, så In-Memory Analytics Accelerator kan være transparent tilgængelig for kernefunktioner, der gør brug af krypto-API’en.
I de seneste måneder har IAA Crypto Compression Driver til Linux-kernen gennemgået et halvt dusin revisioner, så vidt det arbejder sig hen imod hovedlinjen. Denne nye driver gør Intel IAA-acceleratoren tilgængelig via kernel crypto API og kan igen bruges af kernekode, der er målrettet mod den API, såsom Zswap og zRAM. Driveren leverer både synkroniserede og asynkrone versioner af DEFLATE-algoritmen implementeret af hardwaren.
Mens denne driver åbner kernebrugssager for IAA-acceleratoren, anerkender driverens patch-noter den første hovedpine omkring opsætning af Sapphire Rapids-acceleratorerne, dvs. den vil stadig ikke være klar, når du starter en kompatibel Linux-softwarestak:
“IAA-hardwaren er ret kompleks og kræver generelt en kyndig administrator med tilstrækkelig detaljeret forståelse af hardwaren til at indstille det op, før det kan bruges. Som nævnt i dokumentationen, kræver dette typisk brug af et særligt værktøj kaldet accel-config til at opregne og konfigurere IAA-arbejdskøer, motorer osv., selvom dette også kan gøres ved kun at bruge sysfs-filer.
Driften af driveren afspejler dette krav og tillader kun at få adgang til hardwaren via kryptolaget, når hardwaren er blevet konfigureret og bundet til IAA kryptodriveren. Som en IDXD underdriver tager IAA kryptodriveren i det væsentlige ejerskab af hardwaren, indtil den udtrykkeligt opgives af administratoren. Dette sker automatisk, når administratoren aktiverer den første IAA-arbejdskø eller deaktiverer den sidste; iaa_crypto (synkronisering og async) algoritmerne registreres, når den første arbejdskø er aktiveret, og afregistreres, når den sidste er deaktiveret.
Den normale rækkefølge af operationer vil normalt være:
konfigurer hardwaren ved hjælp af accel-config eller sysfs
konfigurer iaa kryptodriveren (se nedenfor)
konfigurer undersystemet f.eks. zswap/zram for at bruge iaa_crypto algo
kør arbejdsbyrden”
Men når alt er sat op og kører med denne foreslåede driver, er ydeevneresultaterne ret dramatiske med IAA brug sammenlignet med ren software:
Tidligere på måneden en v6 patch-serie for denne kernedriver blev sendt ud til gennemgang. Selvom timingen taget i betragtning og endnu ikke er blevet opfanget af cryptodev.git-grenen, er det usandsynligt, at denne driver vil være klar i tide til den kommende Linux v6.5-cyklus. Endnu en hindring blev potentielt rejst i sidste uge af Linux-kryptoundersystemvedligeholder Herbert Xu:
Så du sagde, at konserves ikke er kompatibel med den generiske deflateringsalgoritme. Betyder det, at der ikke er nogen måde for den at dekomprimere noget komprimeret af den generiske deflate-algoritme, og omvendt kan dets komprimerede output ikke dekomprimeres ved generisk deflate ?
Vi tilføjer ikke en algoritme til Crypto API, hvis den eneste implementering er med hardware. IOW, hvis du tilføjer en ny algoritme, så skal en softwareversion være den første patch.
Denne forskel i Intels deflate-implementering ser ud til at være ægte. ClickHouse-udviklere advarede tidligere i deres Intel QPL-support om, at hvis du ønsker at flytte Intel IAA-accelererede databaser mellem værter, skal du først konvertere alle data, før du fjerner dem fra serveren. I så fald, hvis denne driver skal være mainlined, skal Intel også levere en softwareimplementering til kernen.
