Processorarkitekturen


Nätverksprocessorn har i huvudsak fyra delar: trafikinterface med in- och utgångar till optiska moduler, själva pipelinen med alla processorkärnor och åtkomst till hårdvaruacceleratorer och minne, samt de interna switch- och traffic-management-delarna.

In- och utgångar
Linjegränssnitten ansluter mot inkommande media, lämpligen optofiber, medan systemgränssnitten ansluter mot switchkonstruktionens bakplan. Båda hanterar givetvis Ethernet, men anslutningen mot bakplanet är alltid koppar.

SerDes är en serie-parallellomvandlare som serialiserar en inkommande parallel dataström vilket sparar ledare på kretskortet. Åt andra hållet parallelliserar den datat för vidare behandling i NPUn. Datat går vidare till olika typer av Phys och Media Access Controllers (MAC) som kodar signalen till det aktuella mediet (optisk eller koppar) för den aktuella bandbredden och identifierar start och slut på paketen som skickas över länken. Det finns 12 inbyggda 10G Ethernet MACar och hela 48 inbyggda MACar för Gigabit Ethernet. Dessutom finns tre Interlaken-gränssnitt som används för att ansluta till bakplan och externa Phy/MAC som inte stöds direkt på NPUn. Ett exempel är 40/100GE Phy/MAC som idag finns som separata kretsar. När dataströmmen lämnar trafikgränssnitten är trafiken alltså snyggt strukturerad som paketdata. Paketen har då precis börjat sitt liv i nätverksprocessorn.

Alla paket går först igenom en klassificeringsenhet som identifierar strömmar av paket. Denna funktion används till exempel för att kunna överallokera bandbredden till processorn, till exempel i system för bredbandsaccess där användarna delar på stor bandbredd. I händelse av kraftig belastning vill man kunna slänga icke-prioriterad trafik. Från klassificeringsenheten går sedan trafiken till en Shared Memory Switch, en slags intern korskopplingsenhet mellan de logiska blocken som processorn har - den programmerbara pipelinen, Traffic Managern och trafikgränssnitten.


Ett olustigt problem som man måste komma förbi är att det bara går 6,6 ns mellan varje 64-bytes ethernetpaket vid 100 Gbps, medan en access till externt DRAM-minne tar 50 nanosekunder. Det går alltså inte att lagra paketets datadel i externt minne.

Från Shared Memory Switch växlas de första 256 bytarna in i pipelinen. Om paketet är större än 256 byte, buffras datadelen, som kan vara flera tusen byte i Shared Memory Switch. Datadelen av paketet bearbetas inte alls av delprocessorerna i pipen.

Det betyder dock inte att databussen mellan processorerna är 256 byte bred, utan paketdata klockas fram mellan dem 64 byte åt gången.

Programmerbar pipeline

Data hanteras alltså inte av en enda processor utan av en hel pipeline med 448 delprocessorer som var och en utför sin lilla del av klassningsarbetet, med maximalt fem instruktioner per processor, inte mer. Tidsbegränsningarna är mycket hårda.

I en carrier-ethernet-tillämpning behöver varje datapaket ett dussin tabelluppslag för klassificering och forwardering varför man behöver i runda slängar 1000-2000 instruktioner för varje paket. Då är det bra att ha väldigt många processorer. Istället för att försöka utföra allt detta i en generell processor använder man sig av en hel rad seriekopplade delprocessorer som fungerar enligt löpande band-principen. Den första processorn tar normalt reda på vad det är för sorts paket, utför en parsning, om det är Ethernet eller MPLS, eller vad? När den är klar med detta, tar den pakethuvudet, registerfiler, flaggor mm, det som kallas ”execution context”, och skickar till nästa processor, glömmer bort saken och gör om samma operation på nästa paket.

Börjar man med att hantera ethernetframen, så kan man ett par processorer längre ned ägna sig åt MPLS-paketet inuti denna och sedan IP-paketet inuti detta. Datapaketet skalas av som en lök, ungefär. Pipelinen kan också öka paketets storlek för att till exempel få plats med tunnelinformation eller klassificeringsdata som ska vidare till bakplanet.

Paketet kommer också att färgmarkeras (rött, grönt eller gult) för att kunna hanteras korrekt mot interna resurser där flaskhalsar kan uppstå. Paketet tillhör typiskt en ström av data från en användare som har ett kontrakt som beskriver hur trafiken ska hanteras i form av garanterad bandbredd, tillåtna paketförluster, fördröjningsvariationer etc. Detta omsätts i praktik genom att mäta och räkna paketen. Färgkodningen av paket ligger sedan till grund för vid vilken grad av överbelastning paketet kastas. Paket från strömmar som bryter mot sitt kontrakt löper större risk att kastas än paket från strömmar som beter sig väl.

Hårdvaruacceleratorer och externt minne

Efter var sextonde delprocessor når man en Engine Access Point (EAP) där processorn kan ta kontakt med olika acceleratorer i maskinvara, som exempelvis en hashmotor, eller kan gå ut och slå i tabeller, antingen lagrade internt på kretsen eller i ett externt minne, för att utföra klassificering, forwarding eller uppslag i Access Control-listor. Mycket av intelligensen i en NPU handlar om hur man effektivt kan utnyttja olika minnen. Kretsen arbetar med flera olika typer av externa minnen. TCAM är till exempel ett innehållsadresserat minne som kan lagra en forwardingtabell. I minnet stoppar man in IP-adressen och får ut en nätverksport. Det interna SRAMet är snabbt och används för paketräknare eller för att mäta bandbredd hos trafikströmmarn. Drop Engine ger möjlighet att fråga Traffic Manager om status i kösystemet.

Processorn har också funktion för att stödja OAM som står för Operation, Administration and Monitoring i paketnät. En vanlig tillämpning är att skapa ett kontrollpaket ungefär var tredje millisekund. Kontrollpaketen används för att undersöka status på länkar till andra enheter, genom att kontinuerligt fråga om de ”lever”. Paketet skapas i början av pipelinen och vandrar genom denna och hanteras som vilket annat paket som helst. Utifrån kommande OAM-paket undersöks i pipelinen och hanteras som alla andra ethernetpaket.

Shared Memory Switch och Traffic Manager
Traffic Manager är funktion som mellanlagrar datapaket i form av 65.500 utgående paketköer i en gigantisk trädstruktur i externt DRAM. Strukturen utgör en djup buffert som fångar upp trafik och man kan därigenom undvika att tappa paket när många vill skicka mycket trafik ut på en länk med låg kapacitet.
Den interna korskopplaren, Shared Memory Switch, har en struktur som liknar Traffic Managern, men den har enbart intern buffert. På det sättet kan även denna enhet för hålla trafik inom kontrakterad bandbredd.

Det Xelerateds nätverksprocessor gör är i princip inget nytt. Alla switchar och routrar undersöker paket, byter adress på paket, buffrar paket, klassificerar paket, för statistisk över paket och slänger paket om trafiken är för hög. Det intressanta är hur fort och elegant Xelerated kan göra det, och att det görs i programmerbar logik. Dagens snabbaste generella dataprocessorer går i 2 GHz ungefär, medan Xelerated kan klocka sin processor i måttliga 300 MHz och dra motsvarande mindre effekt. Men pipelineprocessorn är mycket effektivare. Alla instruktioner tar en klockcykel och är specialinriktade på nätverkshantering, alltså ren bitmanipulering. Flyttal finns till exempel inte alls.

Programmering i Xelerated Language


Program utvecklas i Xelerated Langugage, en sorts blandning mellan assembler och högnivåspråk, i utvecklingsmiljön Xelerated SDK. Alla filer som ingår i projektet finns organiserade i en trädstruktur (1). Redigeraren fungerar med flikar och färgkoder på olika språkelement (2). Dessutom finns möjlighet att följa funktioner, söka osv. Redigeraren har också en simulator för symbolisk avlusning. Automatiska kontroller visas (watches, 3). Koden i datapaketen kan visas i hexadecimal form eller avkodade i en protokollanalysator (4).

Mjukvarumässigt går det relativt fort att utveckla koden för nätverksprocessorn. Det tar ungefär ett manår att utveckla det programmet. En utmaning för kunderna kan istället vara att integrera hårdvaran mot sin befintliga kontrollmjukvara och operativsystem.

Här följer ett programkodsexempel i Xelerated Language som styr en vanlig situation i en switch, att skicka ut ett mottaget paket på rätt port. Programmet undersöker destinationsadressen i headern i ett ethernetpaket (DstAddr) och skickar det till MAC-adressen för den switchport som anges i routingtabellen i TCAM (det innehållsadresserade minnet, Content Addressable Memory), genom att haka på en parameter som följer med paketet (destPort) genom processor-pipelinen och ut på bakplanet.

/* Program start for incoming packet */
sequence switch_start  
   
/* Ethernet header is a C language struct located at beginning of incoming packet */
   var ethernetHeader : struct EthernetHeaderType at pkt[0]

  /* destPort and lookupData is automatically allocated to available Register Files by Xelerated SDK builder */
   var destPort : uint16_t
   var lookupData :
uint64_t

  ld pro, &ethernetHeader.DstAddr //Load DstAddr location into packet read offset register to enable reading here
   mov lookupData, ethernetHeader.DstAddr // Move DstAddr from packet into register file

  /* Use an Engine Access Point to access external TCAM to search for destination port for corresponding DAMAC.
      Constant time is used by TCAM operation, i.e. O(1) */

eap EAP_1
   {
       DAMAC_lookup:
       call NSE0(operation = LATCAM_LOOKUP_80, response = destPort, request = lookupData)
   }

  //destPort now contains result from TCAM lookup, translate port # to a Shared Memory Switch queue number by multiplying by 2 and add 512.
   sla destPort, destPort, 1 //Shift destPort 1 step left arithmetic, i.e. multiply by 2
   add dr.destination, destPort, 512 //Add 512 to destPort and put result into Device Register Destination (queue).

  bra end //Branch unconditionally to end of program and send out the packet!
}

Om man nu ska tvinga igenom 150 megapaket per sekund, hur ser man till att programmerarna inte skriver för sega program?

Programmeraren skriver bara ett program för varje pakettyp han vill hantera, VLAN till exempel, och vilka Access Control-listor han ska slå i osv. Han behöver inte tänka på att det är 448 kärnor. Efter att programmet är kompilerat och klart tar utvecklingsmiljön det och välter omkull det 90 grader moturs och sprider ut det jämnt över alla de 448 processorerna.

Varje processor kan bara exekvera fem instruktioner, vilket ger ett maximum på 2240 stycken. Skriver programmeraren fler än så, får han en varning. Det är enligt Xelerated oerhört sällsynt att man når upp över det antalet, men skulle en funktion kräva fler instruktioner än så får man skicka tillbaka paketet till början av pipelinen och köra ett varv till, sk loopback. Varje processor lagrar alltså flera uppsättningar av fem instruktioner.

Prestanda är inbyggd i arkitekturen och behandlingstiden är deterministisk. Det är arkitekturen som ser till att behandlingen alltid kommer gå med ”wire speed”. Får programmet plats i processorerna vet man att det kommer att gå tillräckligt fort eftersom varje instruktion klaras av på en klockcykel. Någon optimering är inte nödvändig. Det här är naturligtvis ett resultat av att Xelerated har gjort systemeringen ordentligt. Det finns färdiga drivrutiner och resursmodeller och det finns färdiga regler för tabeller och när uppslag mot dem bör ske.

All programvara är sekvenser i programminnet. Program kan till exempel hoppa. När ett paket går in i pipelinen startar exekveringen av en sekvens som kan ha många grenar genom pipelinens programminne. Resultatet av bearbetningen i en processor resulterar i en instruktionspekare som följer med till nästa processor, som pekar ut vilken uppsättning av fem instruktioner som ska användas för paketet, till exempel resultatet av ett hopp. Därför är det lätt att implementera situationen när paketet kommer tillbaka andra gången: med följer bara en pekare till en ny uppsättning instruktioner, som väljs istället för standardprogrammet.

Pipelinen hanterar flera flöden av paket, där loopback-gränssnitttet är ett, system-gränssnitttet från bakplanet ett annat, trafik-gränssnitttet mot fibrerna ett tredje osv.

Varje PISC (Packet Instruction Set Computer) innehåller flera olika minnen. Efter kompileringen laddas alla uppsättningar av fem instruktioner som processorn kan utföra in i instruktionsminnet. De fem instruktioner som ska utföras härnäst lagras i VLIW (Very Long Instruction Word). Var och en tar en klockcykel att genomföra. Minnet Execution Context är ett närminne för parametrar, vilka vandrar längs pipelinen tillsammans med headern.

Sida 2 / 4

Innehållsförteckning