Receive Side Scaling Version 2 (RSSv2)
Empfangsseitige Skalierung verbessert die Systemleistung im Zusammenhang mit der Verarbeitung von Netzwerkdaten auf Multiprozessorsystemen. NDIS 6.80 und spätere Versionen unterstützen RSS Version 2 (RSSv2), das RSS erweitert, indem es eine dynamische Verteilung von Warteschlangen pro Port bietet.
Überblick
Im Vergleich zu RSSv1 verkürzt RSSv2 die Zeit zwischen der Messung der CPU-Auslastung und der Aktualisierung der Indirektionstabelle, wodurch eine Verlangsamung in Situationen mit hohem Datenverkehr vermieden wird. Um dies zu erreichen, führt RSSv2 seine Aktionen bei IRQL = DISPATCH_LEVEL im Prozessorkontext der Anforderungsverarbeitung aus und arbeitet nur an einer Teilmenge von Indirektionstabelleneinträgen, die auf den aktuellen Prozessor verweisen. Dies bedeutet, dass RSSv2 den Empfang von Warteschlangen über mehrere Prozessoren dynamisch verteilen kann, viel reaktionsfähiger als RSSv1.
Zwei OIDs, OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 und OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES, wurden in RSSv2 für Miniport-Treiber eingeführt, um die richtigen RSS Funktionalitäten festzulegen bzw. die Indirection-Tabelle zu steuern. OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 ist eine reguläre OID, während OID_GEN_RSS_SET_INDIRECTION_ENTRIES eine synchrone OID ist, die nicht NDIS_STATUS_PENDING zurückgeben kann. Weitere Informationen zu diesen OIDs finden Sie auf den einzelnen Referenzseiten. Weitere Informationen zu synchronen OIDs finden Sie unter Synchrone OID-Anforderungsschnittstelle in NDIS 6.80.
RSSv2-Terminologie
In diesem Artikel werden die folgenden Begriffe verwendet:
| Begriff | Definition |
|---|---|
| RSSv1 | Der Mechanismus für Receive Side Scaling der ersten Generation. Verwendet OID_GEN_RECEIVE_SCALE_PARAMETERS. |
| RSSv2 | Die zweite Generation erhält den in Windows 10, Version 1803 und höher, unterstützten Parallelskalierungsmechanismus, der in diesem Artikel beschrieben wird. |
| Skalierende Entität | Der Miniportadapter selbst im nativen RSS-Modus oder ein VPort im RSSv2-Modus. |
| ITE | Ein Indirection Table Entry (ITE) einer bestimmten Skalierungsentität. Die Gesamtzahl der ITEs pro VPort darf NumberOfIndirectionTableEntriesPerNonDefaultPFVPort oder NumberOfIndirectionTableEntriesForDefaultVPort im VMQ-Modus oder 128 im Fall von Native RSS nicht überschreiten. NumberOfIndirectionTableEntriesPerNonDefaultPFVPort und NumberOfIndirectionTableEntriesForDefaultVPort sind Mitglieder der Struktur NDIS_NIC_SWITCH_CAPABILITIES. |
| Skalierungsmodus | Die vmswitch-Richtlinie pro Port, die steuert, wie die ITEs zur Laufzeit behandelt werden. Dies kann statisch sein (keine ITE-Verschiebungen aufgrund von Laständerungen) oder dynamisch (Erweiterung und Zusammenwachsen je nach aktueller Datenverkehrslast). |
| Warteschlange | Ein zugrunde liegendes Hardwareobjekt (Warteschlange), das einen ITE unterstützt. Je nach Hardware und Indirection-Tabelle kann die Warteschlange mehrere ITEs unterstützen. Die Gesamtzahl der Warteschlangen, einschließlich einer, die von der Standardwarteschlange verwendet wird, darf den von einem Administrator in der Regel festgelegten vorkonfigurierten Grenzwert nicht überschreiten. |
| Standardprozessor | Ein Prozessor, der Pakete empfängt, für die der Hash nicht berechnet werden kann. Jeder VPort verfügt über einen Standardprozessor. |
| Primärer Prozessor | Ein Prozessor, der als ProcessorAffinity--Mitglied der NDIS_NIC_SWITCH_VPORT_PARAMETERS-Struktur bei der VPort-Erstellung angegeben wurde. Dieser Prozessor kann zur Laufzeit aktualisiert werden und gibt an, wo VMQ-Datenverkehr weitergeleitet wird. |
| Quellprozessor | Der Prozessor, dem der ITE derzeit zugeordnet ist. |
| Ziel-CPU | Der Prozessor, dem der ITE neu zugeordnet wird (mit RSSv2). |
| Akteur-CPU | Der Prozessor, auf dem RSSv2-Anforderungen gestellt werden. |
Ankündigung der RSSv2 Funktionalität in einem Miniport-Treiber
Miniport-Treiber kündigen RSSv2-Unterstützung an, indem sie das CapabilitiesFlags Mitglied der NDIS_RECEIVE_SCALE_CAPABILITIES Struktur mit dem NDIS_RSS_CAPS_SUPPORTS_INDEPENDENT_ENTRY_MOVE Flag festlegen. Diese Funktionalitäten sind erforderlich, um die RSSv2-Funktion für den CPU- Load-Balancing zu aktivieren, zusammen mit dem Flag NDIS_RECEIVE_FILTER_DYNAMIC_PROCESSOR_AFFINITY_CHANGE_SUPPORTED, das den dynamischen Load-Balancing von RSSv1 für nicht standardmäßige VPorts (VMQs) ermöglicht.
Anmerkung
Protokolle der oberen Ebene gehen davon aus, dass der primäre Prozessor des Standard-VPorts für RSSv2-Miniporttreiber verschoben werden kann.
Wenn ein Miniportadapter keine RSSv2-Funktion angibt, bleiben alle VMQ-fähigen VPorts im statischen Verbreitungsmodus, auch wenn diese VPorts aufgefordert werden, eine dynamische Verbreitung durchzuführen. Der RSSv1-OID für die Konfiguration von RSS-Parametern, OID_GEN_RECEIVE_SCALE_PARAMETERS, wird für diese VPorts verwendet, die sich noch im statischen Verteilungsmodus befinden.
Miniporttreiber müssen nur einen RSS-Steuerungsmechanismus implementieren – entweder RSSv1 oder RSSv2. Wenn der Treiber die RSSv2-Unterstützung angibt, konvertiert NDIS RSSv1 OIDs bei Bedarf in RSSv2 OIDs, um die Verteilung per VPort zu konfigurieren. Der Miniporttreiber muss die beiden neuen OIDs unterstützen und das Verhalten des RSSv1 OID_GEN_RECEIVE_SCALE_PARAMETERS OID wie folgt ändern:
- OID_GEN_RECEIVE_SCALE_PARAMETERS wird nur für Abfrageanforderungen in RSSv2 und nicht zum Festlegen von RSS-Parametern verwendet.
- OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 ist eine Abfrage- und eine Set-OID, die für die Konfiguration der Parameter der skalierenden Entität verwendet wird, wie z. B. die Anzahl der Warteschlangen, die Anzahl der ITEs, die Aktivierung/Deaktivierung von RSS und die Aktualisierung von Hash-Keys.
- OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES ist eine Methoden-OID, die für die Änderung von Indirection-Tabellen-Einträgen verwendet wird.
Verarbeitung von RSSv2 OIDs
OID_GEN_RECEIVE_SCALE_PARAMETERS wird nur verwendet, um die aktuellen RSS-Parameter einer bestimmten Skalierungsentität abzufragen. In RSSv1 wird dieses OID verwendet, um Parameter festzulegen. Bei RSSv2-fähigen Miniporttreibern führt NDIS diese Rollenkonvertierung automatisch für den Treiber aus und gibt stattdessen die folgenden beiden OIDs aus, um Parameter festzulegen.
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 ist eine reguläre OID und wird genauso behandelt wie die OID_GEN_RECEIVE_SCALE_PARAMETERS OID in RSSv1 behandelt wurde. Diese OID ist für NDIS Light-Weight-Filter-Treiber (LWFs) vor NDIS 6.80 nicht sichtbar.
OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES ist jedoch eine Synchronous OID, die nicht NDIS_STATUS_PENDING zurückgeben kann. Diese OID muss im Prozessorkontext ausgeführt und abgeschlossen werden, aus dem die OID stammt. Wie OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 ist sie auch für NDIS LWFs vor NDIS 6.80 nicht sichtbar. LWFs in NDIS 6.80 und höher dürfen dieses OID nicht verzögern oder auf einen anderen Prozessor verschieben. Der Payload enthält eine Reihe einfacher "move ITE"-Aktionen, von denen jede einen Befehl zum Verschieben eines einzelnen ITE für eine skalierende Entität auf eine andere Ziel-CPU enthält. Elemente des Arrays können auf unterschiedliche Skalierungsentitäten (VPorts) verweisen.
Jeder NDIS-Treibertyp, Miniport, Filter und Protokoll verfügen über Einstiegspunkte zur Unterstützung der Synchronen OID-Anforderungsschnittstelle:
| NDIS-Treibertyp | Synchrone OID Handler(s) | Funktion zum Erzeugen synchroner OIDs |
|---|---|---|
| Miniport | MiniportSynchronousOidRequest | N/A |
| Filter | NdisFSynchronousOidRequest | |
| Protokoll | N/A | NdisSynchronousOidRequest |
RSS-Zustandsübergänge, ITE-Updates und primäre/Standardprozessoren
Lenkungsparameter
In RSSv2 werden verschiedene Parameter verwendet, um den Datenverkehr je nach RSS-Zustand (aktiviert oder deaktiviert) auf die richtige CPU zu lenken. Wenn RSS deaktiviert ist, wird nur der primäre Prozessor zum Weiterleiten von Datenverkehr verwendet. Wenn RSS aktiviert ist, werden sowohl der Standardprozessor als auch alle ITEs zum Weiterleiten von Datenverkehr verwendet. Diese Lenkparameter werden als "aktiv" oder "inaktiv" bezeichnet, zusammengefasst in der folgenden Tabelle:
| Steuerungsparameter | RSS deaktiviert | RSS aktiviert |
|---|---|---|
| Primärer Prozessor | Aktiv | Inaktiv |
| Standardprozessor | Inaktiv | Aktiv |
| ITE[0..N] | Inaktiv | Aktiv |
Wenn sich ein Lenkparameter im aktiven Zustand befindet, leitet er den Verkehr. Ab dem Moment eines RSS-Statusübergangs, der einen Parameter inaktiv macht, müssen Miniport-Treiber Änderungen an dem Parameter verfolgen, bis der umgekehrte Übergang ihn wieder aktiviert. Dies bedeutet, dass ein Miniporttreiber alle Aktualisierungen der Standardprozessor- und Dereferenzierungstabelleneinträge nachverfolgen muss, während RSS für diese Skalierungsentität deaktiviert ist. Wenn RSS aktiviert ist, sollte der aktuelle erfasste Zustand für den Standardprozessor und die Indirektionstabelle wirksam werden.
Betrachten Sie beispielsweise das Szenario, wenn Software-vRSS bereits aktiviert ist. In diesem Fall ist die Dereferenzierungstabelle bereits im Protokoll der oberen Ebene vorhanden und wird aktiv vom Softwareverteilungscode der oberen Ebene verwendet. Wenn während der Aktivierung des RSS durch die Hardware alle Einträge auf den primären Prozessor zeigen, bevor die Aktualisierungen der Indirection-Tabelleneinträge verschieben an die Hardware ausgegeben und von dieser ausgeführt werden, kann es zu einem kurzen Stau im primären Prozessor kommen. Wenn der Miniporttreiber die Informationen zu Standardeinstellungen des Prozessors und ITE nachverfolgt hat, kann er den Datenverkehr an die Stelle leiten, an der er von der oberen Ebene bereits erwartet wird.
Miniport-Treiber müssen zwar alle Aktualisierungen inaktiver Steuerungsparameter verfolgen, sollten aber die Validierung dieser Parameter aufschieben, bis die RSS-Statusänderung versucht, diese Parameter active zu machen. Wenn z. B. Software verbreitet wird, während Hardware-RSS deaktiviert ist, können Protokolle der oberen Ebene jeden Prozessor für die Verbreitung verwenden (einschließlich außerhalb des RSS-Satzes des Adapters). Die oberen Ebenen stellen sicher, dass im Moment des RSS-Zustandsübergangs alle inaktiven Parameter für den neuen RSS-Zustand gültig sind. Der Miniport-Treiber sollte die Parameter dennoch validieren und den RSS-Statuswechsel ablehnen, wenn er feststellt, dass ein verfolgter inactive Steuerungsparameter ungültig ist.
Anfangszustand und Aktualisierungen der Steuerungsparameter
In der folgenden Tabelle wird der Anfangszustand der Skalierungsentität nach der Erstellung (z. B. nach der Erstellung von VPort) sowie die Aktualisierung der Parameter beschrieben:
| Parameter | Beschreibung |
|---|---|
| Primärer Prozessor |
|
| Standardprozessor |
|
| Indirection-Tabelle |
|
Aktualisierungen der ITEs und der primären/default Prozessoren (unter Verwendung von OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES) werden von dem Prozessor aufgerufen, auf den der entsprechende Eintrag aktuell zeigt. Für einen bestimmten VPort stellt die obere Schicht sicher, dass unter diesen Umständen keine OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES OIDs zum Verschieben von ITEs oder Festlegen der primären/standardmäßigen Prozessoren ausgegeben werden:
- Während OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 in Bearbeitung ist.
- Nachdem die VPort-Löschungssequenz eingeleitet wurde. Zum Beispiel gibt die obere Schicht das Set filter OID erst aus, nachdem die letzte OID zum Verschieben von ITEs abgeschlossen ist.
RSS-Deaktivierung
Während der RSS-Deaktivierung kann sich das Protokoll der oberen Ebene entscheiden, entweder alle ITEs auf den primären Prozessor zu verweisen und dann den OID auszugeben, um RSS zu deaktivieren, oder es kann sich entscheiden, die Umleitungstabelle as-is zu belassen und RSS zu deaktivieren. In beiden Fällen sollte der Empfangsdatenverkehr auf den primären Prozessor ausgerichtet sein.
RSSv2 behält eine Anforderung von RSSv1 bei, die es dem Protokoll der oberen Ebene ermöglicht, einen VPort zu löschen, ohne zuerst RSS zu deaktivieren. Die obere Ebene kann den Empfangsfilter für den VPort auf Null festlegen, wodurch sichergestellt wird, dass kein Empfangsdatenverkehr über den VPort fließt, und fahren Sie dann mit dem Löschen von VPort fort, ohne RSS zu deaktivieren. Die obere Schicht garantiert, dass während oder nach der VPort-Löschung keine OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES OIDs ausgegeben werden.
Sowohl bei der Deaktivierung von RSS als auch bei der Löschung von VPorts sollte sich der Miniport-Treiber um alle anstehenden internen Vorgänge kümmern, die aufgrund früherer Warteschlangenverschiebungen bestehen könnten.
RSSv2-Invarianten
Das Protokoll der oberen Ebene stellt sicher, dass wichtige Invarianten nicht verletzt werden, bevor Verwaltungsfunktionen oder ITE-Verschiebungen ausgeführt werden. Zum Beispiel:
- Bevor die Anzahl der Warteschlangen verringert wird, stellt die obere Schicht sicher, dass die Indirektionstabelle nicht mehr Prozessoren referenziert als die neue Anzahl von Warteschlangen für einen VPort.
- Die obere Ebene sollte keine Aktualisierung der Umleitungstabelle anfordern, die gegen die aktuell konfigurierte Anzahl von Warteschlangen für einen VPort verstößt. Der Miniport-Treiber sollte diese Regel durchsetzen und einen Fehler zurückgeben.
- Bevor Sie die Anzahl der Einträge in der Indirection-Tabelle für VMMQ-RESTRICTED-Adapter ändern, stellt die obere Schicht sicher, dass der Inhalt der Indirection-Tabelle auf eine Potenz von 2 normalisiert ist.
Verwandte Links
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2