Basisfunktionen der neuen Switch-ASICs (1/2)

Kommentieren Drucken
Teil 2 von 11 aus der Serie "Chip, Chip, Hurra"

Netzwerker hatten in den vergangenen Jahrzehnten keinen Grund, sich mit den Innereien von Geräten und schon gar nicht mit dem Innenleben integrierter Schaltkreise auseinanderzusetzen. Für ein wirkliches Verständnis von Dramatik und Schubkraft der neuen Entwicklungen ist das aber leider jetzt notwendig. In dieser Serie wählen wir für den Zugang zur Funktionalität eine Darstellung, die einerseits so weit von den tatsächlichen Realisierungen in Schaltungen entfernt ist, dass man sie noch versteht, andererseits aber die Erklärung der präzisen Umsetzung erlaubt. Auch Chip-Hersteller verwenden ähnliche Abstraktionen im Rahmen von Hardware-Beschreibungssprachen, mit denen sie letztlich ihre Schaltungen entwickeln.

In Bild 1 sehen wir zunächst die wichtigsten Grundkomponenten eines speicherbasierten Switch-ASICs.

Im Zentrum des Geschehens steht der Speicher. O.B.d.A können wir sagen, dass dies ein frei adressierbarer Registerspeicher in der Bauart eines RAMs einer gewöhnlichen CPU ist. Eine höhere Gliederung in Worte ist möglich, aber für die Funktion nicht wirklich erforderlich. Die Größe des Speichers ist leider beschränkt. Dies ist ein Trade-Off der Konstruktion: je größer ein Speicher wird, desto langsamer wird der Zugriff auf ihn auch tendentiell. Leider führt ein zu kleiner Speicher aber zu ernst zu nehmenden Problemen, wie wir später sehen werden.

Eine weitere wichtige Komponente sind die Ports. Nach außen repräsentieren sie mindestens eine der standardisierten Schnittstellen, wie XGMII, die die Möglichkeit der Verwendung unterschiedlicher elektrischer und optischer Transceiver je nach Einsatzzweck beinhalten. In den ganzen folgenden Darstellungen machen wir die Vereinfachung, dass die blauen Kästchen nur in einer Richtung arbeiten. In der Realität sind die Ports natürlich bidirektional. Also werden in der Realität zwei blaue Kästchen einen Transceiver bilden.

Im Switch-ASIC gibt es viel Arbeit. Für die ist hauptsächlich der Kontrollprozessor zuständig.

Sobald der ASIC „merkt“, dass an einem Port ein Paket ankommt, welches geswitcht werden muss, reserviert er ein Register, in das das Paket wirklich bitweise einlaufen kann. Es gibt vor dem Speicher keine weitere Verzögerung durch irgendwelche organisierenden Warteschlangen oder andere nichtlineare Funktionen. Wir sehen das in Bild 2.

Die folgenden Funktionen wären ohne die jahrzehntelangen Anstrengungen der Standardisierung nicht möglich. In IEEE 802.3 wurden nämlich sämtliche Adressierungen und Funktionen im Paketformat verankert. Sämtliche mit der Zeit hinzugekommenen funktionalen Erweiterungen finden ebenfalls an dieser Stelle ihren Niederschlag. Bis zum heutigen Tage werden alle neuen Funktionen als Anhang zum bereits bestehenden Standardisierungswerk formuliert. Das macht den Standard zwar nicht grade besser lesbar. Vor allem in den letzten fast 10 Jahren seit dem Beginn der Standardisierung von 10 GbE wurde hierauf besonderer Wert gelegt. Und damit wird Folgendes möglich (Bild 3):

Der Kontrollprozessor erzeugt einen Prozess, der den einlaufenden Paketkopf bitweise auswertet. Dazu beobachtet er ihn genau und in diesem Prozess läuft ein abstrakter Kontrollautomat ab. Diese abstrakten Kontrollautomaten wurden von IEEE 802 definiert, um die wirklich interoperable Bearbeitung von Funktionen zu ermöglichen. Der Programmierer eines Prozesses muss genau diesen Kontrollautomaten implementieren, sonst funktioniert es nicht richtig. Solange man es noch mit Firmware zu tun hatte, waren Fehler korrigierbar. Switch-ASICs benutzen für alle Aufgaben, die wirklich schnell gehen müssen, aber komplett integrierte elektronische Schaltwerke. Eine sichere Konstruktion eines komplexen Schaltwerks ist aber nur auf der Grundlage eines abstrakten Kontrollautomaten möglich.

Die Entscheidung, an welchen Ausgangsport das Paket nun weitergeleitet wird, geschieht genau dann, wenn der Prozess der Ansicht ist, genug für diese Entscheidung zu wissen. Dafür muss der Prozess keine philosophischen Betrachtungen anstellen, sondern einfach alle vorliegenden Daten des Paketkopfes auswerten, bis keine mehr da sind (Bild 4).

Der Prozess ist jetzt fertig und kann stillgelegt werden, bis wieder ein neues Paket an einem Port ankommt. Das Paket läuft jetzt einfach durch (Bild 5).

Es gibt ein weit verbreitetes Missverständnis im Zusammenhang mit dieser Arbeitsweise. Man ist oft der Meinung, dass das „Cut Through“-Switching sei, was es ja schon früher bei Switches gab. Cut Through-Switching im konventionellen Sinne schneidet jedoch den Paketkopf an einer bestimmten Stelle ab (daher der Name). Was nach dieser Stelle kommt, wird nicht mehr berücksichtigt. Das führt in komplexen Umgebungen (also alles außer einfachem L2-Switching) zu mehr Problemen als es Vorteile hätte. Zu Beginn haben verschiedene Switch-Hersteller, die es vielleicht auch nicht verstanden haben, behauptet, dass ihre latenzarmen Switches mit Cut Through arbeiten. Das ist schlicht falsch.

Ein speicherbasierter Switch-ASIC hat einen weiten Bereich von möglichen Zusatzfunktionen. Insbesondere werden aber DCB und VLANs unterstützt, und zwar beginnend an dieser Stelle. Wir kommen später noch auf Zusatzfunktionen.

Eines ist aber jetzt schon klar: ein speicherbasierter Switch-ASIC hat eine VARIABLE Latenz. In einer reinen L2-Umgebung ohne zusätzliche Funktionen wird er am schnellsten sein. Umso mehr Funktionen erledigt werden müssen, desto langsamer wird er. Allerdings spielt sich das in einem sehr luxuriösen Rahmen ab. Der aktuell geringste Wert für reines L2-Switching liegt bei 170 ns, packt man das volle Arsenal von L2/L3-Funktionen drauf, kommt man in den Bereich um 300 ns.

Man sieht noch etwas: für eine glatte Funktionalität des Switching-ASICs ist es erforderlich, dass das Register im Speicher mindestens so viele Bits umfasst, wie umgerechnet auf die Datenrate und Arbeitsgeschwindigkeit des Kontrollprozessors dieser für seine Wegwahlentscheidung benötigt.

Sobald der Prozess mit seiner Wegwahlentscheidung fertig ist, kann er direkt einen an einem anderen Port neu ankommenden Paketkopf auswerten (Bild 6)

Ein Hersteller von Switch-ASICs wird darum bemüht sein, einen möglichst hohen Parallelitätsgrad für die Bearbeitung bereitzustellen, im Idealfall einen Prozess für jeden Port. So können Pakete, die in dem Sinne unabhängig voneinander sind, dass sie sich nicht um einen einzigen Zielport streiten, auch völlig parallel durchlaufen.

In den letzten Abbildungen ist klammheimlich eine weitere wichtige Komponente hinzugekommen, der Scheduler. Offensichtlich gibt es im Kontrollprozessor viele Prozesse. Damit diese geordnet starten, laufen und beendigt werden können, benötigen wir eine Komponente, die das erledigt.

Bis jetzt hatte der Switch-ASIC leichtes Arbeiten. Das ändert sich sofort, wenn zwei (oder mehr) Pakete, die auf unterschiedlichen Ports ankommen, das gleiche Ziel haben. Wir sehen in Bild 8 die Situation, dass ein Paket bereits in den Zielport einläuft, während ein zweites grade ausgewertet wurde und leider auch diesen Zielport hat. Diese Situation kommt in der Realität leider sehr häufig vor, z.B. wenn viele Clients auf einen Server zugreifen. Das brauchen keine persönlichen PC-Clients zu sein, viel kritischer wären z.B. VMs, die auf ein Volume in einem SAN zugreifen.

Ein herkömmlicher, Cross-Bar basierter Switch-ASIC würde jetzt das zweite Paket einfach in einen Speicher legen oder wegwerfen. Beim speicherbasierten Switch-ASIC geht das aber nicht so einfach, weil ja alles in permanenter Bewegung ist. Also bleibt nichts anderes übrig, als das bisher bestehende Register zu verlängern.

Die Auflösung der Port Contention kann erst dann beginnen, wenn das vorherige Paket völlig abgearbeitet wurde. Dann muss noch die Inter Frame Gap berücksichtigt werden und erst danach kann das zweite Paket weiterlaufen. Hier müssen jetzt natürlich alle Bits durch die Speicherschlange.

Wir sehen allerdings auch, dass Port Contention ein wirklich ernstes Problem für einen speicherbasierten Switch-ASIC darstellt. Im nächsten Absatz diskutieren wir das etwas übergreifender im Zusammenhang mit den Microbursts. Danach werden wir auch sehen, in welcher Weise sich die spaicherbasierten Switch-ASICs mittlerweile weiterentwickelt haben, um mit solchen Situationen besser umzugehen.

Ist der Speicher zu klein, muss der Switch ASIC kurzzeitig aufgeben und Eingangsports sperren. Wir haben in den letzten Jahren häufig über den Einsatz der DCB Congestion Control gesprochen, aber vielfach an der falschen Stelle. Genau hier wird sie benötigt: es entsteht kurzzeitig eine Situation, in der der Switch-ASIC keine weiteren Pakete mehr verarbeiten kann und Ports sperren muss. Das muss an andere Switches kommuniziert werden, damit sie keine Pakete mehr losschicken. Nur so kann ein größerer Paketverlust vermieden werden. Es sei aber direkt vermerkt, dass das ein spezielles Problem von Ethernet ist. Fibre Channel und InfiniBand haben eine Flusskontrolle, die von Ende-zu-Ende wirkt und das mögliche Aufkommen derartiger Situationen damit unterbindet.

Intel/Fulcrum gibt an, dass das Array 2 MB, also 16 Mbit groß ist und man bis zu 200 Warteschlangen organisieren könne. In jede Warteschlange passen dann im Extremfall also nur 80.000 Bits, weniger als 5 Jumbo-Pakete. Ist da der Abfluss auch nur kurz verstopft, sind die Pakete sofort tot. Damit ein solcher Switch überhaupt sinnvoll funktionieren kann, muss er

  • architekturell so eingebunden sein, dass es keinerlei Überbuchung gibt (damit die Wahrscheinlichkeit für eine Congestion extrem gering wird)
  • einen extrem sensiblen Warnmechanismus haben, der ein 802.3X Pause-Kommando oder die Auslösung der Congestion Control beim leisesten Verdacht einer Stausituation veranlasst
  • mit Adapterkarten zusammenarbeiten, die das auch schnell genug umsetzen, bis in die Ebene der VM-Kommunikation hinein

Der Intel FM 4000 Fulcrum ist nur ein Beispiel, es gibt weitere Hersteller solcher ASICs. Sofern sie auf dem gleichen oder einem ähnlichen Funktionsprinzip basieren, gelten gleiche oder ähnliche Randbedingungen.

Solange die ultraschnellen Switches unter sich bleiben und nur mit geeigneten Adapterkarten kommunizieren, kann man diese Probleme als gelöst betrachten. Bei einem Übergang zu Netzkomponenten oder Adapterkarten mit höherer Latenz wird man wohl um die Einbeziehung zusätzlicher externer Puffer kaum herumkommen, was dann natürlich an dieser Stelle die Latenzarmut zerstört. Solche Designaspekte werden wir später aufgreifen.

« Teil 1: Das Potential der neuen Switch-ASICsTeil 3: Basisfunktionen neuen Switch-ASICs (2/2) »


zugeordnete Kategorien: Endgeräte, LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.