Introdusert med 4. generasjons Xeon-skalerbare”Sapphire Rapids”-prosessorer er forskjellige nye akseleratorer tilgjengelig på utvalgte SKU-er eller via Intel On Demand-tilbudet. En av de første utfordringene der er imidlertid støttebegrensningene for tidlig akseleratorprogramvare og mange oppstrøms åpen kildekode (eller til og med bare utbredt) programvare som ennå ikke er aktivert for å bruke disse nye akseleratorene. En av forbedringene på den fronten har vært Intel-ingeniører som jobber med en IAA-kryptokomprimeringsdriver for kjernen, slik at In-Memory Analytics Accelerator kan være transparent tilgjengelig for kjernefunksjoner som bruker krypto-API.
De siste månedene har IAA Crypto Compression Driver for Linux-kjernen gått gjennom et halvt dusin revisjoner så langt som den jobber seg mot hovedlinjen. Denne nye driveren gjør Intel IAA-akseleratoren tilgjengelig via kjernekrypto-API og kan igjen brukes av kjernekode som er rettet mot det API-et, for eksempel Zswap og zRAM. Driveren gir både synkroniserings-og asynkronversjoner av DEFLATE-algoritmen implementert av maskinvaren.
Selv om denne driveren vil åpne opp kjernebrukssaker for IAA-akseleratoren, erkjenner sjåførlappnotatene den første hodepinen rundt å sette opp Sapphire Rapids-akseleratorene, dvs. den vil fortsatt ikke være klar når du starter opp en dyktig Linux-programvarestabel:
“IAA-maskinvaren er ganske kompleks og krever generelt en kunnskapsrik administrator med tilstrekkelig detaljert forståelse av maskinvaren for å sette den opp før den kan brukes. Som nevnt i dokumentasjonen, krever dette vanligvis bruk av et spesielt verktøy kalt accel-config for å telle opp og konfigurere IAA-arbeidskøer, motorer osv., selv om dette også kan gjøres med kun sysfs-filer.
Driften av driveren gjenspeiler dette kravet og tillater bare tilgang til maskinvaren via kryptolaget når maskinvaren er konfigurert og bundet til IAA kryptodriveren. Som en IDXD underdriver tar IAA kryptodriveren i hovedsak eierskap til maskinvaren til den blir gitt opp eksplisitt av administratoren. Dette skjer automatisk når administratoren aktiverer den første IAA-arbeidskøen eller deaktiverer den siste; iaa_crypto (synkronisering og async) algoritmene registreres når den første arbeidskøen er aktivert, og avregistreres når den siste er deaktivert.
Den normale operasjonssekvensen vil normalt være:
konfigurer maskinvaren ved å bruke accel-config eller sysfs
konfigurer iaa kryptodriveren (se nedenfor)
konfigurer undersystemet f.eks. zswap/zram for å bruke iaa_crypto algo
kjør arbeidsmengden”
Men når alt er satt opp og går med denne foreslåtte driveren, er ytelsesresultatene ganske dramatiske med IAA bruk sammenlignet med ren programvare:
Tidligere denne måneden en v6 patch-serie for denne kjernedriveren ble sendt ut for gjennomgang. Selv om gitt timingen og ennå ikke er plukket opp av cryptodev.git-grenen, er det lite sannsynlig at denne driveren vil være klar i tide for den kommende Linux v6.5-syklusen. En annen hindring ble potensielt oppdratt forrige uke av vedlikeholder av Linux-kryptodelsystem Herbert Xu:
Så du sa at hermetikk ikke er kompatibelt med den generiske deflateringsalgoritmen. Betyr det at det ikke er noen måte for den å dekomprimere noe komprimert av den generiske deflatealgoritmen, og omvendt kan dens komprimerte utgangen ikke dekomprimeres ved generisk deflate ?
Vi legger ikke til en algoritme til Crypto API hvis den eneste implementeringen er med maskinvare. IOW hvis du legger til en ny algoritme, må en programvareversjon være den første oppdateringen.
Denne forskjellen i Intels deflate-implementering ser ut til å være ekte. ClickHouse-utviklere advarte tidligere i sin Intel QPL-støtte om at hvis du ønsker å flytte Intel IAA-akselererte databaser mellom verter, må du først konvertere alle dataene før du tar dem av serveren. I så fall, hvis denne driveren skal bli mainlined, må Intel også levere en programvareimplementering for kjernen.
