Port-Konfigurationen

Die Abbildung oben zeigt das Blockdiagramm des Bausteins. Im Wesentlichen besteht er aus 4 Serdes-Gruppen mit unterschiedlichen Port/Lane-Konfiurationsmöglichkeiten, einer nicht blockierenden Switch- Fabric, 8 NTB-Funktionen und 2 DMAEngines. Jeder der 24 Ports unterstützt Linkbreiten-Negotiation (das Aushandeln der Linkbreite mit dem Gegenüber), automatisches Lane-Reversal (richtige Zuordnung der Lanes mit dem Gegenüber) sowie Crosslink (einfache Möglichkeit zur Inter-Domain-Kommunikation). Hier einige Eigenschaften im Überblick:

• Die Ports sind konfigurierbar als x8, x4, x2, x1 (Dynamische Portbreite)
• Switch-Partitioning: Bis zu 8 vollständig unabhängige Partitionen
• Dynamische Rekonfi guration der Switch-Partitionen ist möglich.
• Non-Transparent Bridge (NTB): Bis zu 8 NT-Endpoints Konfi gurierbar zum Endpoint- oder Upstream-Mode, wahlweise mit DMA
• 64 Master und 6 BARs pro NT-Endpoint • LUT oder Direct-Address-Translation
• Multi-Port SSC Clocking • Unterstützt Referenztakt 100 MHz und 125 MHz
• Ports können durch einen unabhängigen SSC-Clock getaktet werden (Spread Spectrum Clocking), durch einen gemeinsamen gobalen Takt oder durch einen unabhängigen globalen Takt.

Switches im Switch – das Partitioning

Das Switch-Partitioning, also die Aufteilung eines Switch-Bausteins in mehrere unabhängige kleinere Switches durch dynamische oder statische Konfiguration, ist ein innovatives Feature von IDT und ermöglicht beim PES32NT24G2 die Realisierung von bis zu 8 Partitionen. Jeder der Ports lässt sich als Upstreamoder Downstream-Port einsetzen und jedem Root können beliebig viele Downstream-Ports zugeordnet werden. Die Aufteilung kann statisch durch EEPROMKonfiguration erfolgen oder dynamisch durch entsprechendes Setzen der Register.

Zusammen mit der dynamischen Konfiguration zeigt sich auch der Clou des Partitionings, lassen sich damit doch je nach aktueller Leistungsanforderungen Ressourcen eines Systems gezielt zuweisen, wie es beim „Load Balancing“ notwendig ist. So können z.B. in Multi-Root-Systemen wie Blade-Server bei statischer Zuordnung der I/O-Ressourcen recht unausgewogene Lastsituationen auftreten, d.h. einige Strecken sind wenig ausgelastet während andere möglicherweise am Limit arbeiten. Dies lässt ich durch dynamische Rekonfiguration der Switch-Partitionen ändern, wie es beispielhaft in der Abbildung oben rechts, dargestellt ist. Hier erhalten die beiden mittleren „Sub-Switches“ zusätzlich
Downstream-Ports und damit höheren Durchsatz.

Pakete für alle - Multicast

Wie es in Ethernet oder RapidIO schon seit jeher üblich ist, erlaubt die PCIe-Spezifi - kation jetzt auch das Multicasten von Paketen, d.h. die Zustellung gleicher Dateninhalte an verschiedene Adressaten durch Replizieren. Ohne Multicast musste bislang die CPU jeden Adressaten einzeln mit den gleichen Inhalten versorgen, was natürlich zu einer hohen Bandbreite ohne echten Nutzen führte. Multicast zählt damit zu den PCIe Accelerator-Features und verbessert die Systemperformance vor allem in solchen Anwendungen, in denen große Datenmengen gleichzeitig an mehrere Ziele transportiert werden müssen, wie z.B. beim Storage- Mirroring, bei redundanten Applikationen oder beim Updaten von Tabellen in Kommunikationssystemen. Der IDTSwitch PES- 32NT24G2 unterstützt die PCI-SIG Multicast ECN (ECN = Engineereing Change Note der PCI Special Interest Group). Der Baustein kann bis zu 64 Multicast-Gruppen verwalten und erlaubt das Multicasten von Daten auch über NTBs hinweg.

Hilfe vom Nachbar - Failover

Zur Realisierung besonders ausfallsicherer Systeme werden zentrale Komponenten üblicherweise redundant (d.h. doppelt oder mehrfach) ausgelegt. Im Falle eine Falles muss dann der Fehler erkannt und auf die redundante Funktionsgruppe, etwa ein zweiter Server-Blade, umgeschaltet werden. Abbildung 8 zeigt ein solches System vor und nach dem Failover. Im normalen Betrieb ist die erste CPU aktiv und dient als Root Complex für alle Downstream- Linecards. Die zweite CPU ist auf Standby, kann aber sofort einspringen, wenn auf der ersten CPU Fehlfunktionen auftreten oder aus Wartungsgründen abgeschaltet wird.

Die primäre und sekundäre CPU kann den NTB-Link verwenden, um Management- Informationen auszutauschen wie etwa Heart-Beat-Signale oder Statusmeldungen. Sobald die Entscheidung für ein Failover vorliegt kann jede der beiden CPUs diesen Prozess einleiten. Sobald der Prozess vollzogen ist, übernimmt die sekundäre CPU die Funktion des Root-Complex für alle Downstream Linecards.

Ein Failover kann durch Software initiiert werden, durch ein externes Signal auf einem Pin oder durch den Watchdog-Timer. In der Software-Variante muss das sog. Failover- Trigger-Register beschrieben werden, entweder von der primären CPU, der sekundären CPU oder von einer der Linecards.

Grundsätzlich muss natürlich ermittelt werden, wann eine CPU bzw. ein Host noch funktionstüchtig ist. Dazu wird ein Watchdog-Counter auf einen Startwert gesetzt und mit einer gewissen Rate automatisch dekrementiert. Der aktive Host muss nun regelmäßig wieder den Startwert des Zählers setzen, muss also verhindern, dass der Zähler die „0“ erreicht. Solange er das schafft, wird Funktionstüchtigkeit unterstellt, schafft er es nicht und der Zähler erreicht früher oder später den Stand „0“, ist dies das Kriterium für den Switch, automatisch den Failover-Prozess einzuleiten.

Event-Signalisierung

In einem Multi-Host-System ist es notwendig, dass globale Switch-Events kommuniziert werden können. Zudem müssen auch Hosts selbst in der Lage sein, solche Events an andere Hosts mitzuteilen. Daher bieten die neuen IDT Switches die Möglichkeit, verschiedene Events zu erfassen und durch einen Interrupt zu signalisieren. Die im Folgenden aufgelisteten globalen Events können von jedem Host im System erfasst werden:

• Port-Link Up / Down Event
• Port AER Error
• Ein fundamentaler oder ein Hot-Reset in einer Partition
• Failover Mode-Änderung initiiert oder abgeschlossen Sobald eine der genannten Ereignisse (Events) auftritt, wird es mittels eines 32- bit Wertes an solche Hosts signalisiert, die ihren Event-Monitor für diesen speziellen Event aktiviert haben. Die Hosts können dann beim Eintreffen der Benachrichtigung z.B. mit der Fehlerbereinigung beginnen.

Dem Verkehrsstau vorbeugen - Request Metering

Üblicherweise wird die Linkbreite, d.h. die Performance des US-Ports eines Switches so festgelegt, dass die zu erwartende maximale Übertragungsbandbreite darüber abgewickelt werden kann. Dies führt aber gerade bei sehr unsymmetrisch ausgelegten DS-Ports dazu, dass ein „Static Rate Mismatch“ entsteht, also eine extreme Fehlanpassung von DSund US-Port. In der linken Darstellung in Abbildung 9 ist dieser Fall wiedergegeben: Endpoint „A“ ist als x1-Port ausgelegt, Endpoint „B“ als x8-Port und der Upstream Port mit einer Linkbreite von x8. Memory- Read-Requests von EP A führen durch die 8-fach höhere Kapazität des US-Ports zu einer kompletten Füllung des Ausgangsbuffers und damit auch zu einer Beeinträchtigung der Transaktionen auf EP B.

Mit dem Feature “Request Metering” lässt sich die Rate der Read-Requests steuern, die von einem Port ausgehen und damit die zu erwartende Transferbelastung auf das machbare Maß reduzieren. Damit löst sich der Stau auf und auch Beeinträchtigungen höher performanter Nachbar-Ports haben ein Ende. Abbildung 10 zeigt das Beispiel eines Endpoints, der 3 Read-Requests abschickt. Ohne das Metering (oben) würde der Switch die Anfragen ohne Verzögerung weiterleiten und damit fast ebenso schnell die Antworten erhalten, was hier zu einem Stau führen könnte. Mit dem Request-Metering (unten) fügt der Switch zwischen den Anfragen Verzögerungszeiten ein, die der erwarteten Completion-Time entsprechen.

Der PES32NT24G2 unterstützt das Request Metering auf allen seinen Ports. Der zugrunde liegende Algorithmus basiert auf einigen Annahmen, um die Completion- Zeiten zu ermitteln und daraus die Verzögerungen einzustellen. Diese Annahmen führen möglicherweise in bestimmten Systemen zu falschen Berechnungen. Daher ist es möglich, alle Parameter des Request Meterings anwenderseitig zu verändern und damit eine optimale Anpassung an jedes individuelle System zu erzielen.