TCP-Offload-Engine - TCP offload engine

Die TCP-Offload-Engine ( TOE ) ist eine Technologie, die in Netzwerkschnittstellenkarten (NIC) verwendet wird, um die Verarbeitung des gesamten TCP/IP- Stack auf den Netzwerkcontroller auszulagern. Es wird hauptsächlich mit Hochgeschwindigkeits-Netzwerkschnittstellen wie Gigabit-Ethernet und 10 Gigabit-Ethernet verwendet , bei denen der Verarbeitungsaufwand des Netzwerkstapels erheblich wird.

Der Begriff TOE wird oft verwendet, um sich auf die NIC selbst zu beziehen, obwohl Leiterplatteningenieure ihn verwenden können, um sich nur auf die integrierte Schaltung zu beziehen, die auf der Karte enthalten ist, die die Header des Transmission Control Protocol (TCP) verarbeitet. TOEs werden oft vorgeschlagen, um den Overhead zu reduzieren, der mit Internet Protocol (IP)-Speicherprotokollen wie iSCSI und Network File System (NFS) verbunden ist.

Zweck

Ursprünglich wurde TCP für unzuverlässige Niedriggeschwindigkeitsnetzwerke (wie frühe DFÜ- Modems ) entwickelt, aber mit dem Wachstum des Internets in Bezug auf Backbone- Übertragungsgeschwindigkeiten (mit Optical Carrier- , Gigabit-Ethernet- und 10-Gigabit-Ethernet- Verbindungen) und schnelleren und zuverlässigeren Zugriffen Mechanismen (wie DSL- und Kabelmodems ) wird es häufig in Rechenzentren und Desktop- PC- Umgebungen mit Geschwindigkeiten von über 1 Gigabit pro Sekunde verwendet. Die TCP-Software-Implementierungen auf Host-Systemen erfordern umfangreiche Rechenleistung. In den frühen 2000er Jahren konnte die Vollduplex-Gigabit-TCP-Kommunikation mehr als 80% eines 2,4-GHz- Pentium-4- Prozessors verbrauchen (siehe freigesetzte CPU-Zyklen ), was zu geringen oder gar keinen Verarbeitungsressourcen für die Ausführung der Anwendungen auf dem System führte.

TCP ist ein verbindungsorientiertes Protokoll, das die Komplexität und den Verarbeitungsaufwand erhöht. Zu diesen Aspekten gehören:

  • Verbindungsaufbau über den "3-Wege-Handshake" (SYNchronize; SYNchronize-ACKnowledge; ACKnowledge).
  • Bestätigung von Paketen, wenn sie von der Gegenseite empfangen werden, was den Nachrichtenfluss zwischen den Endpunkten und damit die Protokolllast erhöht.
  • Prüfsummen- und Folgenummernberechnungen – wiederum eine Belastung für eine Allzweck-CPU.
  • Gleitfensterberechnungen für Paketbestätigung und Staukontrolle .
  • Verbindungsabbruch .

Durch das Verschieben einiger oder aller dieser Funktionen auf dedizierte Hardware, eine TCP-Offload-Engine, wird die Haupt- CPU des Systems für andere Aufgaben frei. Ab 2012 unterstützen nur sehr wenige Consumer-Netzwerkschnittstellenkarten den TOE.

Anstatt den TCP-Stack vollständig durch einen TOE zu ersetzen, gibt es alternative Techniken, um einige Operationen in Zusammenarbeit mit dem TCP-Stack des Betriebssystems auszulagern. TCP-Prüfsummen-Offload und Large-Segment-Offload werden von den meisten heutigen Ethernet-NICs unterstützt. Neuere Techniken wie Large Receive Offload und TCP Acknowledgement Offload sind bereits in einigen High-End-Ethernet-Hardware implementiert, sind aber selbst bei reiner Softwareimplementierung effektiv.

Freigesetzte CPU-Zyklen

Eine allgemein akzeptierte Faustregel besagt, dass 1 Hertz CPU-Verarbeitung erforderlich ist, um 1 Bit/s TCP/IP zu senden oder zu empfangen . Beispielsweise erfordern 5 Gbit/s (625 MB/s) Netzwerkverkehr 5 GHz CPU-Verarbeitung. Dies impliziert, dass 2 ganze Kerne eines 2,5-GHz -Mehrkernprozessors erforderlich sind, um die TCP/IP-Verarbeitung zu bewältigen, die mit 5 Gbit/s TCP/IP-Datenverkehr verbunden ist. Da Ethernet (in diesem Beispiel 10GE) bidirektional ist, können 10 Gbit/s gesendet und empfangen werden (bei einem Gesamtdurchsatz von 20 Gbit/s). Bei der 1-Hz/(bit/s)-Regel entspricht dies acht 2,5-GHz-Kernen.

Viele der für die TCP/IP-Verarbeitung verwendeten CPU-Zyklen werden durch TCP/IP-Offload "freigegeben" und können von der CPU (normalerweise einer Server- CPU) verwendet werden, um andere Aufgaben wie die Dateisystemverarbeitung (in einem Dateiserver) auszuführen. oder Indizierung (in einem Backup-Medienserver). Mit anderen Worten, ein Server mit TCP/IP-Offload kann mehr Serverarbeit leisten als ein Server ohne TCP/IP-Offload-NICs.

Reduzierung des PCI-Verkehrs

Zusätzlich zum Protokoll-Overhead, den TOE bewältigen kann, können auch einige Architekturprobleme behoben werden, die einen großen Prozentsatz hostbasierter Endpunkte (Server und PC) betreffen. Viele ältere Endpunkt-Hosts basieren auf dem PCI- Bus, der eine Standardschnittstelle für das Hinzufügen bestimmter Peripheriegeräte wie Netzwerkschnittstellen zu Servern und PCs bietet . PCI ist ineffizient, um kleine Datenbursts vom Hauptspeicher über den PCI-Bus zu den Netzwerkschnittstellen-ICs zu übertragen, aber seine Effizienz verbessert sich, wenn die Datenburstgröße zunimmt. Innerhalb des TCP-Protokolls wird eine große Anzahl kleiner Pakete erzeugt (zB Bestätigungen) und da diese typischerweise auf der Host-CPU erzeugt und über den PCI-Bus und aus der physischen Netzwerkschnittstelle übertragen werden, wirkt sich dies auf den E/A-Durchsatz des Host-Computers aus.

Eine TOE-Lösung, die sich auf der Netzwerkschnittstelle befindet, befindet sich auf der anderen Seite des PCI-Busses vom CPU-Host, um dieses Problem der E/A-Effizienz zu beheben, da die über die TCP-Verbindung zu sendenden Daten an die TOE von der CPU über den PCI-Bus unter Verwendung großer Datenburst-Größen, wobei keines der kleineren TCP-Pakete den PCI-Bus durchlaufen muss.

Geschichte

Eines der ersten Patente für diese Technologie für UDP-Offload wurde Anfang 1990 an Auspex Systems erteilt . Auspex-Gründer Larry Boucher und eine Reihe von Auspex-Ingenieuren gründeten Alacritech 1997 mit der Idee, das Konzept des Network Stack-Offloads zu erweitern zu TCP und implementieren es in benutzerdefiniertem Silizium. Sie führten Anfang 1999 die erste Parallel-Stack-Full-Offload-Netzwerkkarte ein; Die SLIC (Session Layer Interface Card) des Unternehmens war der Vorgänger seiner aktuellen TOE-Angebote. Alacritech hält eine Reihe von Patenten im Bereich TCP/IP-Offload.

Im Jahr 2002, als das Aufkommen von TCP-basiertem Speicher wie iSCSI das Interesse weckte, wurde gesagt, dass "mindestens ein Dutzend Newcomer, die meisten gegen Ende der Dotcom-Blase gegründet, die Gelegenheit verfolgen, Halbleiterbeschleuniger für Handelsunternehmen für die Speicherung zu kaufen". Protokolle und Anwendungen, die mit einem halben Dutzend etablierter Anbieter und hauseigener ASIC-Designs konkurrieren."

Im Jahr 2005 lizenzierte Microsoft die Patentbasis von Alacritech und schuf zusammen mit Alacritech die partielle TCP-Offload-Architektur, die als TCP-Schornstein-Offload bekannt wurde. TCP Schornstein-Offload konzentriert sich auf das "Communication Block Passing Patent" von Alacritech. Gleichzeitig erhielt Broadcom auch eine Lizenz zum Bau von TCP-Schornstein-Offload-Chips.

Arten von TCP/IP-Offload

Parallel-Stack-Full-Offload

Parallel-Stack Full Offload hat seinen Namen vom Konzept zweier paralleler TCP/IP-Stacks. Der erste ist der Haupthoststapel, der im Hostbetriebssystem enthalten ist. Der zweite oder "parallele Stack" wird zwischen dem Application Layer und dem Transport Layer (TCP) über einen "Vampire Tap" verbunden. Der Vampir-Tap fängt TCP-Verbindungsanfragen von Anwendungen ab und ist für das TCP-Verbindungsmanagement sowie die TCP-Datenübertragung verantwortlich. Viele der Kritikpunkte im folgenden Abschnitt beziehen sich auf diese Art von TCP-Offload.

Vollständige HBA-Abladung

Die vollständige HBA-Abladung (Host Bus Adapter) findet sich in iSCSI- Hostadaptern, die sich dem Hostsystem als Plattencontroller präsentieren, während sie eine Verbindung (über TCP/IP) mit einem iSCSI- Speichergerät herstellen. Diese Art von TCP-Offload entlastet nicht nur die TCP/IP-Verarbeitung, sondern auch die iSCSI-Initiatorfunktion. Da der HBA dem Host als Plattencontroller erscheint, kann er nur mit iSCSI-Geräten verwendet werden und ist nicht für die allgemeine TCP/IP-Abladung geeignet.

Teilweise Abladung des TCP-Schornsteins

TCP-Schornstein-Offload adressiert die Hauptsicherheitskritik der Parallel-Stack-Full-Offload. Beim teilweisen Offload steuert der Hauptsystemstapel alle Verbindungen zum Host. Nachdem eine Verbindung zwischen dem lokalen Host (normalerweise ein Server) und einem fremden Host (normalerweise ein Client) hergestellt wurde, werden die Verbindung und ihr Status an die TCP-Offload-Engine übergeben. Die schwere Arbeit beim Senden und Empfangen von Daten übernimmt das Offload-Gerät. Fast alle TCP-Offload-Engines verwenden eine Art von TCP/IP-Hardwareimplementierung, um die Datenübertragung ohne Eingreifen der Host-CPU durchzuführen. Wenn die Verbindung geschlossen wird, wird der Verbindungsstatus von der Offload-Engine an den Hauptsystemstapel zurückgegeben. Die Beibehaltung der Kontrolle über TCP-Verbindungen ermöglicht es dem Hauptsystemstapel, die Verbindungssicherheit zu implementieren und zu kontrollieren.

Große Empfangsabladung

Large Receive Offload ( LRO ) ist eine Technik zur Erhöhung des eingehenden Durchsatzes von Netzwerkverbindungen mit hoher Bandbreite durch Reduzierung des Overheads der Zentraleinheit (CPU). Es funktioniert, indem mehrere eingehende Pakete aus einem einzelnen Stream in einen größeren Puffer aggregiert werden, bevor sie weiter oben im Netzwerkstapel weitergeleitet werden, wodurch die Anzahl der zu verarbeitenden Pakete reduziert wird. Linux- Implementierungen verwenden im Allgemeinen LRO in Verbindung mit der New API (NAPI), um auch die Anzahl der Interrupts zu reduzieren .

Laut Benchmarks kann sogar die vollständige Implementierung dieser Technik in Software die Netzwerkleistung erheblich steigern. Seit April 2007 unterstützt der Linux-Kernel LRO für TCP nur in Software. FreeBSD 8 unterstützt LRO in Hardware auf Adaptern, die es unterstützen.

LRO sollte nicht auf Maschinen betrieben werden, die als Router fungieren, da dies das End-to-End-Prinzip durchbricht und die Leistung erheblich beeinträchtigen kann.

Generisches Empfangen Offload

Generic Receive Offload ( GRO ) implementiert ein generalisiertes LRO in Software, die nicht auf TCP/ IPv4 beschränkt ist oder die Probleme durch LRO verursacht hat.

Große Send-Offload

In Computernetzwerken , großer send Offload ( LSO ist) eine Technik zur Erhöhung des Austritts - Durchsatz von Hochbandbreiten - Netzwerk - Verbindungen durch Reduktion von CPU - Overhead. Es funktioniert, indem es einen Multipacket-Puffer an die Netzwerkschnittstellenkarte (NIC) übergibt . Die NIC teilt diesen Puffer dann in separate Pakete auf. Die Technik wird auch als TCP Segmentation Offload ( TSO ) oder Generic Segmentation Offload ( GSO ) bezeichnet, wenn sie auf TCP angewendet wird . LSO und LRO sind unabhängig und die Verwendung des einen erfordert nicht die Verwendung des anderen.

Wenn ein System große Datenmengen über ein Computernetzwerk senden muss, müssen die Datenblöcke zuerst in kleinere Segmente zerlegt werden, die alle Netzwerkelemente wie Router und Switches zwischen den Quell- und Zielcomputern passieren können. Dieser Vorgang wird als Segmentierung bezeichnet . Häufig führt das TCP-Protokoll im Host-Computer diese Segmentierung durch. Das Auslagern dieser Arbeit auf die NIC wird als TCP-Segmentierungs-Offload (TSO) bezeichnet.

Beispielsweise wird eine Dateneinheit von 64 KiB (65.536 Byte) normalerweise in 45 Segmente von jeweils 1460 Byte segmentiert, bevor sie durch die NIC und über das Netzwerk gesendet wird. Mit etwas Intelligenz in der NIC kann die Host-CPU die 64 KB Daten in einer einzigen Sendeanforderung an die NIC übergeben, die NIC kann diese Daten in kleinere Segmente von 1460 Byte aufteilen, TCP, IP und Daten hinzufügen Link-Layer-Protokoll-Header – gemäß einer vom TCP/IP-Stack des Hosts bereitgestellten Vorlage – an jedes Segment und senden die resultierenden Frames über das Netzwerk. Dies reduziert die von der CPU geleistete Arbeit erheblich. Ab 2014 unterstützen viele neue NICs auf dem Markt TSO.

Einige Netzwerkkarten implementieren TSO so generisch, dass es zum Auslagern der Fragmentierung anderer Transportschichtprotokolle oder zum Ausführen der IP-Fragmentierung für Protokolle verwendet werden kann, die selbst keine Fragmentierung unterstützen, wie z. B. UDP .

Unterstützung unter Linux

Im Gegensatz zu anderen Kerneln bietet der Linux-Kernel keine Unterstützung für TOE-Hardware. Nicht zu verwechseln mit anderen ähnlich benannten Offloads, wie TCP Segmentation Offload, das umfassend unterstützt wird. Während es Patches von Hardwareherstellern wie Chelsio oder Qlogic gibt , die Unterstützung hinzufügen, lehnen die Linux-Kernel-Entwickler diese Technologie aus mehreren Gründen ab, darunter

  • Sicherheit – Da der TOE in Hardware implementiert ist, müssen Patches auf die TOE- Firmware und nicht nur auf Software angewendet werden , um alle Sicherheitsschwachstellen zu beheben, die in einer bestimmten TOE-Implementierung gefunden werden. Dies wird durch die Neuheit und Herstellerspezifität dieser Hardware im Vergleich zu einem gut getesteten TCP/IP-Stack, wie er in einem Betriebssystem ohne TOE zu finden ist, noch verstärkt.
  • Einschränkungen der Hardware – da Verbindungen auf dem TOE-Chip gepuffert und verarbeitet werden, kann es im Vergleich zu der großzügigen CPU und dem verfügbaren Speicher des Betriebssystems leichter zu einem Ressourcenmangel kommen.
  • Komplexität – TOE bricht die Annahme, dass Kernel jederzeit Zugriff auf alle Ressourcen haben – Details wie der von offenen Verbindungen verwendete Speicher sind bei TOE nicht verfügbar. TOE erfordert auch sehr große Änderungen an einem Netzwerk-Stack, um ordnungsgemäß unterstützt zu werden, und selbst wenn dies getan ist, funktionieren Funktionen wie Dienstqualität und Paketfilterung normalerweise nicht.
  • Proprietär – TOE wird von jedem Hardwareanbieter unterschiedlich implementiert. Dies bedeutet, dass mehr Code neu geschrieben werden muss, um mit den verschiedenen TOE-Implementierungen umzugehen, auf Kosten der oben genannten Komplexität und möglicherweise Sicherheit. Darüber hinaus kann die TOE-Firmware nicht einfach geändert werden, da sie Closed Source ist.
  • Obsoleszenz – Jede TOE-NIC hat eine begrenzte Lebensdauer, da die Systemhardware schnell das TOE-Leistungsniveau erreicht und schließlich das TOE-Leistungsniveau übertrifft.

Lieferanten

Ein Großteil der aktuellen Arbeiten zur TOE-Technologie stammt von Herstellern von 10-Gigabit-Ethernet-Schnittstellenkarten wie Broadcom , Chelsio Communications , Emulex , Mellanox Technologies , QLogic .

Siehe auch

Verweise

Externe Links