TCP avlastningsmotor - TCP offload engine

TCP offload engine ( TOE ) er en teknologi som brukes i nettverkskort (NIC) for å avlaste behandlingen av hele TCP/IP -stakken til nettverkskontrolleren. Den brukes hovedsakelig med høyhastighets nettverksgrensesnitt, for eksempel gigabit Ethernet og 10 Gigabit Ethernet , der prosesseringskostnader for nettverksstakken blir betydelige.

Begrepet TOE brukes ofte for å referere til selve NIC, selv om kretskortingeniører bare kan bruke det til å referere til den integrerte kretsen som er inkludert på kortet som behandler TCP -overskriftene ( Transmission Control Protocol ). TOE -er foreslås ofte som en måte å redusere omkostningene knyttet til lagringsprotokoller for Internet Protocol (IP) som iSCSI og Network File System (NFS).

Hensikt

Opprinnelig var TCP designet for upålitelige lavhastighetsnettverk (for eksempel tidlige oppringte modemer ), men med internettets vekst når det gjelder ryggradshastighet (ved bruk av optisk bærer , Gigabit Ethernet og 10 Gigabit Ethernet- koblinger) og raskere og mer pålitelig tilgang mekanismer (for eksempel DSL- og kabelmodem ) den brukes ofte i datasentre og stasjonære PC -miljøer med en hastighet på over 1 Gigabit per sekund. TCP -programvareimplementeringene på vertssystemer krever omfattende datakraft. På begynnelsen av 2000-tallet kan full dupleks gigabit TCP-kommunikasjon forbruke mer enn 80% av en 2,4 GHz Pentium 4- prosessor (se frigjorte CPU-sykluser ), noe som resulterer i små eller ingen behandlingsressurser igjen for programmene å kjøre på systemet.

TCP er en tilkoblingsorientert protokoll som legger til kompleksitet og behandlingskostnader. Disse aspektene inkluderer:

  • Tilkoblingsetablering ved hjelp av "3-veis håndtrykk" (SYNchronize; SYNchronize-ACKnowledge; ACKnowledge).
  • Godkjenning av pakker som de mottas i ytterste ende, og legger til meldingsflyten mellom endepunktene og dermed protokollbelastningen.
  • Sjekksum og sekvensnummerberegninger - igjen en belastning for en generell CPU å utføre.
  • Skyvevindu beregninger for pakke erkjennelse og metningskontroll .
  • Tilkobling avsluttes .

Ved å flytte noen eller alle disse funksjonene til dedikert maskinvare, en TCP -avlastningsmotor, frigjør systemets hoved -CPU for andre oppgaver. Fra og med 2012 er det svært få forbrukernettverkskort som støtter TOE.

I stedet for å erstatte TCP-stakken med en TOE helt, er det alternative teknikker for å laste av noen operasjoner i samarbeid med operativsystemets TCP-stabel. TCP -kontrollsumavlastning og stort segmentavlastning støttes av flertallet av dagens Ethernet -nettverkskort. Nyere teknikker som stor mottaksavlastning og avlastning av TCP-bekreftelse er allerede implementert i noen avansert Ethernet-maskinvare, men er effektive selv når de implementeres rent i programvare.

Frigjorte CPU-sykluser

En allment akseptert tommelfingerregel er at 1 Hertz CPU -behandling er nødvendig for å sende eller motta 1 bit/s TCP/IP. For eksempel krever 5 Gbit/s (625 MB/s) nettverkstrafikk 5 GHz CPU -behandling. Dette innebærer at to hele kjerner i en 2,5 GHz flerkjerners prosessor vil være nødvendig for å håndtere TCP/IP-behandlingen knyttet til 5 Gbit/s TCP/IP-trafikk. Siden Ethernet (10GE i dette eksemplet) er toveis, er det mulig å sende og motta 10 Gbit/s (for en samlet gjennomstrømning på 20 Gbit/s). Ved å bruke 1 Hz/(bit/s) regelen tilsvarer dette åtte 2,5 GHz kjerner.

Mange av CPU-syklusene som brukes til TCP/IP-behandling, blir "frigjort" av TCP/IP-avlastning og kan brukes av CPU (vanligvis en server- CPU) til å utføre andre oppgaver, for eksempel filsystembehandling (i en filserver) eller indeksering (i en backup -mediaserver). Med andre ord kan en server med TCP/IP -offload gjøre mer serverarbeid enn en server uten TCP/IP -offload -NIC -er.

Reduksjon av PCI -trafikk

I tillegg til protokolloverheadene som TOE kan løse, kan den også løse noen arkitektoniske problemer som påvirker en stor prosentandel av vertsbaserte (server og PC) endepunkter. Mange eldre sluttpunktverter er PCI -bussbaserte, som gir et standard grensesnitt for tillegg av visse eksterne enheter, for eksempel nettverksgrensesnitt til servere og PCer. PCI er ineffektivt for å overføre små utbrudd av data fra hovedminnet, over PCI -bussen til nettverksgrensesnittets IC -er, men effektiviteten forbedres etter hvert som databasestørrelsen øker. Innen TCP -protokollen opprettes et stort antall små pakker (f.eks. Bekreftelser), og ettersom disse vanligvis genereres på verts -CPU og overføres over PCI -bussen og ut av det fysiske nettverksgrensesnittet, påvirker dette vertsmaskinens IO -gjennomstrømning.

En TOE -løsning, som ligger på nettverksgrensesnittet, er plassert på den andre siden av PCI -bussen fra CPU -verten, slik at den kan løse dette I/O -effektivitetsproblemet, ettersom dataene som skal sendes over TCP -tilkoblingen kan sendes til TOE fra CPU over PCI -bussen ved bruk av store datastrømstørrelser uten at noen av de mindre TCP -pakkene må krysse PCI -bussen.

Historie

Et av de første patentene på denne teknologien, for UDP -avlastning, ble utstedt til Auspex Systems i begynnelsen av 1990. Auspex -grunnlegger Larry Boucher og en rekke Auspex -ingeniører grunnla Alacritech i 1997 med ideen om å utvide konseptet med nettstabelavlastning til TCP og implementere den i tilpasset silisium. De introduserte det første parallelle-stabelen full-offload nettverkskortet i begynnelsen av 1999; selskapets SLIC (Session Layer Interface Card) var forgjengeren til det nåværende TOE -tilbudet. Alacritech har en rekke patenter innen TCP/IP -lossing.

I 2002, da fremveksten av TCP-basert lagring som iSCSI vekket interesse, ble det sagt at "Minst et dusin nykommere, de fleste grunnlagt mot slutten av dot-com-boblen, jakter på muligheten for handelsleders halvlederakseleratorer for lagring protokoller og applikasjoner, som kjemper med et halvt dusin forankrede leverandører og interne ASIC-design. "

I 2005 lisensierte Microsoft Alacritechs patentbase, og sammen med Alacritech opprettet den delvise TCP -avlastningsarkitekturen som har blitt kjent som TCP skorsteinsavlastning. TCP skorsteinsavlastning sentrerer seg om Alacritech "Communication Block Passing Patent". Samtidig oppnådde Broadcom også lisens til å bygge TCP skorsteinsflis.

Typer av TCP/IP -avlastning

Parallell-stabel full avlastning

Parallell-stack full offload får navnet sitt fra konseptet med to parallelle TCP/IP-stabler. Den første er hovedvertsbunken som er inkludert i verts -operativsystemet. Den andre eller "parallelle stakken" er koblet mellom applikasjonslaget og transportlaget (TCP) ved hjelp av en "vampyrkran". Vampyrkranen fanger opp TCP -tilkoblingsforespørsler fra applikasjoner og er ansvarlig for TCP -tilkoblingsadministrasjon så vel som TCP -dataoverføring. Mange av kritikkene i den følgende delen angår denne typen TCP -avlastning.

HBA full avlastning

HBA (Host Bus Adapter) full avlastning finnes i iSCSI -vertskort som presenterer seg som diskkontrollere til vertssystemet mens de kobles (via TCP/IP) til en iSCSI -lagringsenhet. Denne typen TCP -avlastning laster ikke bare ned TCP/IP -behandling, men laster også ned iSCSI -initiatorfunksjonen. Fordi HBA vises for verten som en diskkontroller, kan den bare brukes med iSCSI -enheter og er ikke egnet for generell TCP/IP -avlastning.

TCP skorstein delvis avlastning

TCP skorsteinsavlastning adresserer den store sikkerhetskritikken om parallellstabel full avlastning. Ved delvis avlastning styrer hovedsystembunken alle tilkoblinger til verten. Etter at det er etablert en forbindelse mellom den lokale verten (vanligvis en server) og en utenlandsk vert (vanligvis en klient), overføres forbindelsen og tilstanden til TCP -avlastningsmotoren. Tunge løft av dataoverføring og mottak håndteres av losseanordningen. Nesten alle TCP -avlastningsmotorer bruker en eller annen type TCP/IP -maskinvareimplementering for å utføre dataoverføringen uten vert -CPU -inngrep. Når tilkoblingen er stengt, returneres tilkoblingstilstanden fra avlastningsmotoren til hovedsystembunken. Ved å opprettholde kontrollen over TCP -tilkoblinger kan hovedsystembunken implementere og kontrollere tilkoblingssikkerheten.

Stor mottaksavlastning

Stort motta avlasting ( LRO ) er en teknikk for å øke inngående gjennomstrømning av høy- båndbredde nettverksforbindelser ved reduksjon sentral prosesseringsenhet (CPU) overhead. Det fungerer ved å samle flere innkommende pakker fra en enkelt strøm til en større buffer før de sendes høyere opp i nettverksstakken, og reduserer dermed antallet pakker som må behandles. Linux -implementeringer bruker vanligvis LRO i forbindelse med New API (NAPI) for også å redusere antall avbrudd .

Ifølge benchmarks kan selv implementering av denne teknikken helt i programvare øke nettverksytelsen betydelig. Fra april 2007 støtter Linux -kjernen bare LRO for TCP i programvare. FreeBSD 8 støtter LRO i maskinvare på adaptere som støtter den.

LRO bør ikke operere på maskiner som fungerer som rutere, da det bryter ende-til-ende-prinsippet og kan påvirke ytelsen betydelig.

Generisk motta avlastning

Generisk mottaksavlastning ( GRO ) implementerer en generalisert LRO i programvare som ikke er begrenset til TCP/ IPv4 eller har problemene som er opprettet av LRO.

Stor utsendelse

I datanettverk , stor sendeavlastning ( LSO ) er en teknikk for å øke utgang gjennomstrømning av høy- båndbredde nettverksforbindelser ved å redusere CPU overhead. Det fungerer ved å sende en flerpakkebuffer til nettverkskortet (NIC). NIC deler deretter denne bufferen i separate pakker. Teknikken kalles også TCP segmentering offload ( TSO ) eller generic segmentation offload ( GSO ) når den brukes på TCP . LSO og LRO er uavhengige, og bruk av det ene krever ikke bruk av det andre.

Når et system må sende store deler av data ut over et datanettverk, må bitene først brytes ned i mindre segmenter som kan passere gjennom alle nettverkselementene som rutere og bytter mellom kilde- og destinasjonsdatamaskinene. Denne prosessen kalles segmentering . Ofte utfører TCP -protokollen i vertsmaskinen denne segmenteringen. Å laste dette arbeidet til NIC kalles TCP segmentation offload (TSO).

For eksempel blir en enhet på 64 KiB (65 536 byte) data vanligvis segmentert til 45 segmenter på 1460 byte hver før den sendes gjennom NIC og over nettverket. Med litt intelligens i NIC kan verts-CPUen overlevere 64 KB data til NIC i en enkelt overføringsforespørsel, NIC kan dele dataene ned i mindre segmenter på 1460 byte, legge til TCP, IP og data lenke lagprotokolloverskrifter - i henhold til en mal levert av vertens TCP/IP -stabel - til hvert segment, og sende de resulterende bildene over nettverket. Dette reduserer arbeidet som utføres av CPU -en betydelig. Fra 2014 støtter mange nye NIC på markedet TSO.

Noen nettverkskort implementerer TSO generisk nok til at det kan brukes til lossing av fragmentering av andre transportlagsprotokoller , eller for å gjøre IP -fragmentering for protokoller som ikke støtter fragmentering av seg selv, for eksempel UDP .

Støtte i Linux

I motsetning til andre kjerner, inkluderer Linux -kjernen ikke støtte for TOE -maskinvare. For ikke å forveksle med andre lignende avlastninger, som TCP Segmentation Offload som støttes i stor utstrekning. Selv om det er oppdateringer fra maskinvareprodusentene som Chelsio eller Qlogic som legger til støtte, er Linux -kjerneutviklerne imot denne teknologien av flere årsaker, inkludert

  • Sikkerhet - fordi TOE er implementert i maskinvare, må oppdateringer brukes på TOE -fastvaren , i stedet for bare programvare, for å løse eventuelle sikkerhetsproblemer som finnes i en bestemt TOE -implementering. Dette blir ytterligere forsterket av nyheten og leverandørspesifisiteten til denne maskinvaren, sammenlignet med en godt testet TCP/IP-stabel som finnes i et operativsystem som ikke bruker TOE.
  • Begrensninger i maskinvare - fordi tilkoblinger blir bufret og behandlet på TOE -brikken, kan det lettere oppstå sult i ressurser sammenlignet med den sjenerøse CPU og minne som er tilgjengelig for operativsystemet.
  • Kompleksitet - TOE bryter antagelsen som kjerner gjør om å ha tilgang til alle ressurser til enhver tid - detaljer som minne som brukes av åpne tilkoblinger er ikke tilgjengelige med TOE. TOE krever også svært store endringer i en nettverksstabel for å kunne støttes på riktig måte, og selv når det er gjort, fungerer funksjoner som tjenestekvalitet og pakkefiltrering vanligvis ikke.
  • Proprietær - TOE implementeres ulikt av hver maskinvareleverandør. Dette betyr at mer kode må skrives om for å håndtere de forskjellige TOE -implementeringene, på bekostning av den ovennevnte kompleksiteten og muligens sikkerheten. Videre kan ikke TOE-fastvaren enkelt endres siden den er lukket kilde.
  • Forældelse - Hver TOE NIC har en begrenset levetid for bruk, fordi systemmaskinvare raskt når opp til TOE -ytelsesnivåer og til slutt overskrider TOE -ytelsesnivåer.

Leverandører

Mye av dagens arbeid med TOE -teknologi er produsenter av 10 Gigabit Ethernet -grensesnittkort, for eksempel Broadcom , Chelsio Communications , Emulex , Mellanox Technologies , QLogic .

Se også

Referanser

Eksterne linker