Esitelty 4. sukupolven Xeon Scalable”Sapphire Rapids”-prosessoreilla on useita uusia kiihdyttimiä, jotka ovat saatavilla valikoituihin SKU:ihin tai Intel On Demand-tarjouksen kautta. Yksi ensimmäisistä haasteista on kuitenkin varhaiset kiihdytinohjelmiston tuen rajoitukset ja monet alkupään avoimen lähdekoodin (tai jopa vain laajalle levinnetyt) ohjelmistot, joissa ei ole vielä mahdollista käyttää näitä uusia kiihdyttimiä. Yksi parannuksista tällä alalla on ollut Intelin insinöörit, jotka ovat työskennelleet IAA-salauksenpakkausohjaimen parissa ytimelle, jotta In-Memory Analytics Accelerator voi olla läpinäkyvästi käytettävissä ytimen ominaisuuksille, jotka hyödyntävät kryptosovellusliittymää.
Viime kuukausina Linux-ytimen IAA Crypto Compression-ohjain on käynyt läpi puoli tusinaa versiota, jotta se toimii päälinjaa kohti. Tämä uusi ohjain tuo Intel IAA-kiihdytin saataville ytimen krypto-API:n kautta, ja sitä voidaan puolestaan käyttää kyseiseen API:iin kohdistetun ydinkoodin, kuten Zswapin ja zRAM:n, avulla. Ajuri tarjoaa sekä synkronoidut että asynkroniset versiot laitteiston toteuttamasta DEFLATE-algoritmista.
Vaikka tämä ajuri avaa ytimen käyttötapauksia IAA-kiihdytintä varten, ajurin korjausmuistiinpanot tunnustavat Sapphire Rapids-kiihdytinten käyttöönoton alkuvaiheen päänvaivaa, eli se ei vieläkään ole valmis, kun käynnistetään kykenevä Linux-ohjelmistopino:
“IAA-laitteisto on melko monimutkainen ja vaatii yleensä asiantuntevan järjestelmänvalvojan, jolla on riittävän tarkka käsitys laitteistosta. se on valmis, ennen kuin sitä voidaan käyttää. Kuten dokumentaatiossa mainittiin, tämä vaatii yleensä erikoistyökalua nimeltä accel-config IAA-työjonojen, moottorien jne. luetteloimiseen ja määrittämiseen, vaikka tämä voidaan tehdä myös käyttämällä vain sysfs-tiedostoja.
Ohjaimen toiminta heijastaa tätä vaatimusta ja sallii laitteiston pääsyn salauskerroksen kautta vasta, kun laitteisto on määritetty ja sidottu IAA-salausajuriin. IDXD-aliohjaimena IAA-salausajuri käytännössä ottaa omistukseensa laitteistoa, kunnes järjestelmänvalvoja on nimenomaisesti luovuttanut sen. Tämä tapahtuu automaattisesti, kun järjestelmänvalvoja ottaa käyttöön ensimmäisen IAA-työjonon tai poistaa viimeisen käytöstä. iaa_crypto (synkronointi ja asynkronointi)-algoritmit rekisteröidään, kun ensimmäinen työjono otetaan käyttöön, ja poistetaan rekisteristä, kun viimeinen on poistettu käytöstä.
Normaali toimintojen järjestys olisi normaalisti:
määritä laitteisto accel-configilla tai sysfs:llä
määritä iaa kryptoajuri (katso alla)
määritä alijärjestelmä esim. zswap/zram käyttääksesi iaa_crypto-algoa
suorita työkuormitus”
Mutta kun kaikki on asennettu ja toimii tämän ehdotetun ohjaimen kanssa, suorituskyky on melko dramaattinen IAA:lla. käyttö verrattuna puhtaaseen ohjelmistoon:
Aiemmin tässä kuussa julkaistu v6 korjaustiedostosarja tälle ytimen ohjaimelle lähetettiin tarkistettavaksi. Vaikka ajoitus huomioon ottaen ja cryptodev.git-haara ei ole vielä noutanut sitä, on epätodennäköistä, että tämä ajuri on valmis ajoissa tulevaa Linux v6.5-sykliä varten. Toinen este Linuxin salausalajärjestelmän ylläpitäjä Herbert Xu nosti sen viime viikolla:
>
Joten sanoit, että canned ei ole yhteensopiva yleisen deflatointialgoritmin kanssa. Tarkoittaako se, että se ei voi purkaa jotain, joka on pakattu yleisellä deflatointialgoritmilla, ja päinvastoin sen kompressoitua tulostetta ei voida purkaa yleisellä deflataatiolla ?
Emme lisää algoritmia Crypto API:hen, jos ainoa toteutus on laitteisto. IOW, jos lisäät uuden algoritmin, ohjelmistoversion on oltava ensimmäinen korjaustiedosto.
Tämä ero Intelin deflate-toteutuksessa näyttää olevan aito. ClickHouse-kehittäjät varoittivat aiemmin Intel QPL-tukissaan, että jos haluat siirtää Intel IAA-kiihdytettyjä tietokantoja isäntien välillä, sinun on ensin muunnettava kaikki tiedot ennen niiden poistamista palvelimelta. Siinä tapauksessa, jos tämä ohjain siirtyy päälinjaan, Intelin on tarjottava ohjelmistototeutus myös ytimelle.
