Även om det tekniskt sett fortfarande är det nya barnet på blocket, har Compute Express Link-standarden (CXL) för värd-till-enhet-anslutning snabbt fått fäste på servermarknaden. Designad för att erbjuda en rik uppsättning I/O-funktioner byggd ovanpå de befintliga PCI-Express-standarderna – framför allt cache-koherens mellan enheter – CXL förbereds för användning i allt från bättre anslutningsprocessorer till acceleratorer i servrar, till att kunna anslut DRAM och icke-flyktig lagring över vad som fysiskt fortfarande är ett PCIe-gränssnitt. Det är en ambitiös och ändå brett uppbackad färdplan som på tre korta år har gjort CXL till de facto avancerade enhetsinterconnect-standarden, vilket leder till rivaliserande standarder Gen-Z, CCIX, och från och med igår OpenCAPI, som alla hoppade av loppet.
Och medan CXL-konsortiet tar ett snabbt segervarv den här veckan efter att ha vunnit sammankopplingskrigen, finns det mycket mer arbete att göra av konsortiet och dess medlemmar. På produktfronten levereras de första x86-processorerna med CXL knappt – till stor del beroende på vad du vill kalla det limbotillstånd som Intels Sapphire Ridge-chip befinner sig i – och på funktionalitetsfronten ber enhetsleverantörer om mer bandbredd och fler funktioner än i de ursprungliga 1.x-versionerna av CXL. Att vinna sammankopplingskrigen gör CXL till kungen av sammankopplingar, men i processen betyder det att CXL måste kunna ta itu med några av de mer komplexa användningsfallen som rivaliserande standarder designades för.
För det ändamålet, på Flash Memory Summit 2022 denna vecka, är CXL Consortium på mässan för att tillkännage nästa fullständiga version av CXL-standarden, CXL 3.0. Efter uppföljningen av 2.0-standarden, som släpptes i slutet av 2020 och introducerade funktioner som minnespooling och CXL-switchar, fokuserar CXL 3.0 på stora förbättringar inom ett par kritiska områden för sammankopplingen. Den första är den fysiska sidan, där CXL fördubblar sin genomströmning per fil till 64 GT/sekund. Samtidigt, på den logiska sidan av saken, utökar CXL 3.0 de logiska funktionerna i standarden kraftigt, vilket möjliggör komplexa anslutningstopologier och strukturer, såväl som mer flexibla minnesdelning och minnesåtkomstlägen inom en grupp CXL-enheter.
CXL 3.0: Byggd ovanpå PCI-Express 6.0
Från och med de fysiska aspekterna av CXL levererar den nya versionen av standarden den efterlängtade uppdateringen för att införliva PCIe 6.0. Båda tidigare versionerna av CXL, det vill säga 1.x och 2.0, byggdes ovanpå PCIe 5.0, så det är första gången sedan CXLs introduktion 2019 som dess fysiska lager har uppdaterats.
I sig en stor uppdatering av PCI-Express-standardens inre funktioner, PCIe 6.0 fördubblade återigen mängden tillgänglig bandbredd över bussen till 64 GT/sekund, vilket för ett x16-kort fungerar till 128GB/sek. Detta åstadkoms genom att övergå PCIe från att använda binär (NRZ) signalering till quad-state (PAM4) signalering och inkorporera ett fast paket (FLIT) gränssnitt, vilket gör det möjligt för den att dubbla hastigheterna utan nackdelarna med att arbeta vid ännu högre frekvenser. Eftersom CXL i sin tur är byggt ovanpå PCIe, innebar detta att standarden behövde uppdateras för att ta hänsyn till operativa förändringar av PCIe.
Slutresultatet för CXL 3.0 är att det ärver de fulla bandbreddsförbättringarna av PCIe 6.0 – tillsammans med alla roliga saker som forward error correction (FEC) – som fördubblar CXLs totala bandbredd jämfört med CXL 2.0.
Noterbart, enligt CXL Consortium har de kunnat åstadkomma allt detta utan att öka latensen. Detta var en av utmaningarna som PCI-SIG ställdes inför vid utformningen av PCIe 6.0, eftersom den nödvändiga felkorrigeringen skulle lägga till latens till processen, vilket resulterade i att PCI-SIG använde en form av FEC med låg latens. Ändå tar CXL 3.0 saker ett steg längre i försöken att minska latensen, vilket resulterar i att 3.0 har samma latens som CXL 1.x/2.0.
Förutom den grundläggande PCIe .60-uppdateringen har CXL Consortium också justerat sin FLIT-storlek. Medan CXL 1.x/2.0 använde ett relativt litet paket på 68 byte, höjer CXL 3.0 detta upp till 256 byte. Den mycket större FLIT-storleken är en av de viktigaste kommunikationsförändringarna med CXL 3.0, eftersom den ger standarden många fler bitar i huvudet FLIT, som i sin tur behövs för att möjliggöra de komplexa topologier och tyger som 3.0-standarden introducerar. Men som en extra funktion erbjuder CXL 3.0 också ett “variant” FLIT-läge med låg latens som bryter upp CRC i 128 byte “sub-FLIT granulära överföringar”, vilket är utformat för att mildra lagring och vidarebefordran omkostnader i det fysiska lagret .
Noterbart är att FLIT-storleken på 256 byte håller CXL 3.0 i överensstämmelse med PCIe 6.0, som i sig använder en 256 byte FLIT. Och precis som det underliggande fysiska lagret stöder CXL användningen av den stora FLIT inte bara med den nya överföringshastigheten på 64 GT/sek, utan även 32, 16 och 8 GT/sek, vilket i huvudsak tillåter de nya protokollfunktionerna att användas med långsammare överföringshastigheter .
Slutligen är CXL 3.0 helt bakåtkompatibel med tidigare versioner av CXL. Så enheter och värdar kan nedgradera efter behov för att matcha resten av hårdvarukedjan, även om de förlorar nyare funktioner och hastigheter i processen.
CXL 3.0-funktioner: förbättrad koherens, minnesdelning, multi-level topologier och tyger
Förutom att ytterligare förbättra den totala I/O-bandbredden, har de ovannämnda protokollförändringarna för CXL också implementerats för att möjliggöra nya funktioner inom standarden. CXL 1.x föddes som en (relativt) enkel värd-till-enhet-standard, men nu när CXL är det dominerande enhetssammankopplingsprotokollet för servrar måste det utöka sina möjligheter både för att rymma mer avancerade enheter och i slutändan för att rymma större användningsfall.
För att komma igång på funktionsnivå är den största nyheten här att standarden har uppdaterat cachekoherensprotokollet för enheter med minne (Type-2 och Type-3, på CXL-språk). Förbättrad koherens, som CXL kallar det, gör det möjligt för enheter att säkerhetskopiera ogiltig data som cachelagras av en värd. Detta ersätter den fördomsbaserade koherensmetoden som användes i tidigare versioner av CXL, som för att hålla saker kort, bibehöll koherensen inte så mycket genom att dela kontroll över ett minnesutrymme, utan snarare genom att antingen låta värden eller enheten ansvara för att kontrollera åtkomsten. Återinvalidering, däremot, är mycket närmare en äkta delad/symmetrisk metod, vilket gör att CXL-enheter kan informera en värd när enheten har gjort en förändring.
Inkluderandet av bakåtinvalidering öppnar också dörren till ny peer-to-peer-anslutning mellan enheter. I CXL 3.0 kan enheter nu direkt komma åt varandras minne utan att behöva gå via en värd, med hjälp av den förbättrade koherenssemantiken för att informera varandra om deras tillstånd. Att hoppa över värden är inte bara snabbare ur ett latensperspektiv, utan i en installation som involverar en switch betyder det att enheter inte äter upp dyrbar värd-till-switch-bandbredd med sina förfrågningar. Och även om vi kommer in på topologier lite senare, går dessa förändringar hand i hand med större topologier, vilket gör att enheter kan organiseras i virtuella hierarkier, där alla enheter i en hierarki delar en koherensdomän.
Tillsammans med tweaking cache-funktionalitet introducerar CXL 3.0 också några viktiga uppdateringar för minnesdelning mellan värdar och enheter. Medan CXL 2.0 erbjöd minnespooling, där flera värdar kunde komma åt en enhets minne men var och en måste tilldelas sitt eget dedikerade minnessegment, introducerar CXL 3.0 sann minnesdelning. Genom att utnyttja den nya förbättrade koherenssemantiken kan flera värdar ha en sammanhängande kopia av ett delat segment, med bakåtinvalidering som används för att hålla alla värdar synkroniserade om något skulle förändras på enhetsnivå.
Det bör dock noteras att detta inte helt ersätter pooling. Det finns fortfarande användningsfall där CXL 2.0-stil pooling skulle vara att föredra (bibehålla koherens kommer med kompromisser), och CXL 3.0 stöder blandning och matchning av de två lägena efter behov.
Genom att ytterligare förstärka denna förbättrade värdenhetsfunktionalitet tar CXL 3.0 bort de tidigare begränsningarna för antalet Type-1/Type-2-enheter som kan anslutas nedströms om en enda CXL-rotport. Medan CXL 2.0 endast tillät en enda av dessa bearbetningsenheter att finnas nedströms om en rotport, lyfter CXL 3.0 dessa begränsningar helt. Nu kan en CXL-rotport stödja en komplett mix-and-match-inställning av Typ-1/2/3-enheter, beroende på en systembyggares mål. Detta innebär framför allt att kunna koppla flera acceleratorer till en enda switch, förbättra densiteten (fler acceleratorer per värd) och göra de nya peer-to-peer-överföringsfunktionerna mycket mer användbara.
Den andra stora funktionsändringen för CXL 3.0 är stöd för flernivåväxling. Detta bygger på CXL 2.0, som introducerade stöd för CXL-protokollswitchar, men som bara tillät en enda switch att ligga mellan en värd och dess enheter. Flernivåväxling, å andra sidan, tillåter flera lager av switchar – det vill säga switchar som matas in i andra switchar – vilket avsevärt ökar typen och komplexiteten hos nätverkstopologier som stöds.
Även med bara två lager av switchar är detta tillräckligt med flexibilitet för att möjliggöra icke-trädtopologier, såsom ringar, maskor och andra tyginställningar. Och de individuella noderna kan vara värdar eller enheter, utan några begränsningar för typer.
Under tiden, för verkligt exotiska inställningar, kan CXL 3.0 till och med stödja ryggrads-/bladarkitekturer, där trafik dirigeras genom ryggradsnoder på toppnivå vars enda uppgift är att dirigera trafik tillbaka till lägre nivåer (löv) som i sin tur innehåller faktiska värdar. /enheter.
Slutligen kan alla dessa nya minnes- och topologi-/tygfunktioner användas tillsammans i det som CXL-konsortiet kallar Global Fabric Attached Memory (GFAM). GFAM tar i ett nötskal CXLs idé för minnesexpansionskort (Typ-3) till nästa nivå genom att ytterligare disaggregera minne från en given värd. En GFAM-enhet är i det avseendet funktionellt en egen delad minnespool som värdar och enheter kan nå ut till vid behov. Och en GFAM-enhet kan innehålla både flyktigt och icke-flyktigt minne tillsammans, såsom DRAM och flashminne.
GFAM är i sin tur det som gör att CXL kan användas för att effektivt stödja stora multi-nodsinställningar. Som konsortiet använder i ett av sina exempel tillåter GFAM CXL 3.0 att erbjuda nödvändig prestanda och effektivitet för att implementera MapReduce över ett kluster av CXL-anslutna maskiner. MapReduce är naturligtvis en mycket populär algoritm för användning med acceleratorer, så att utöka CXL för att bättre hantera en arbetsbelastning som är gemensam för klustrade acceleratorer är ett uppenbart (och utan tvekan nödvändigt) nästa steg för standarden. Även om det suddar ut gränserna lite mellan var en lokal sammankoppling som CXL slutar, och en nätverksanslutning som InfiniBand börjar.
I slutändan kan den största skillnaden vara antalet noder som stöds. CXL:s adresseringsmekanism, som konsortiet kallar Port Based Routing (PBR), stöder upp till 2^12 (4096) enheter. Så en CXL-inställning kan bara skalas så långt, särskilt som acceleratorer, anslutet minne och andra enheter snabbt äter upp portar.
Att slå ihop saker, den färdiga CXL 3.0-standarden släpps för allmänheten idag, den första dagen av FMS 2022. Officiellt erbjuder konsortiet ingen vägledning om när man kan förvänta sig att CXL 3.0 dyker upp i enheter – det är upp till utrustningstillverkarna – men det är rimligt att säga att det inte kommer att ske direkt. Med CXL 1.1-värdar som just nu skickas – strunt i CXL 2.0-värdar – släpar den faktiska produktionen av CXL efter standarderna med ett par år, vilket är typiskt för dessa standarder för sammankoppling av stora industrier.
