Receive Side Scaling Version 2 (RSSv2)
Empfangsseitige Skalierung verbessert die Systemleistung im Zusammenhang mit der Verarbeitung von Netzwerkdaten auf Multiprozessorsystemen. NDIS 6.80 und höher unterstützen RSS Version 2 (RSSv2), die RSS erweitert, indem dynamische, pro VPort-Verbreitung von Warteschlangen angeboten wird.
Übersicht
Im Vergleich zu RSSv1 verkürzt RSSv2 die Zeit zwischen der Messung der CPU-Auslastung und der Aktualisierung der Dereferenzierungstabelle. Dies verhindert eine Verlangsamung bei Situationen mit hohem Datenverkehr. Um dies zu erreichen, führt RSSv2 seine Aktionen bei IRQL = DISPATCH_LEVEL aus, im Prozessorkontext der Verarbeitung der Anforderung und wird nur für eine Teilmenge von Dereferenzierungstabelleneinträgen ausgeführt, 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 eingeführt, um die richtigen RSS-Funktionen festzulegen und die Dereferenzierungstabelle zu steuern. OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 ist ein reguläres OID, während OID_GEN_RSS_SET_INDIRECTION_ENTRIES ein synchrones OID ist, das NDIS_STATUS_PENDING nicht 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 Thema werden die folgenden Begriffe verwendet:
| Begriff | Definition |
|---|---|
| RSSv1 | Die erste Generation empfängt den Mechanismus für die parallele Skalierung. Verwendet OID_GEN_RECEIVE_SCALE_PARAMETERS. |
| RSSv2 | Die zweite Generation empfängt den in Windows 10, Version 1803 und höher, unterstützten Parallelskalierungsmechanismus, der in diesem Thema beschrieben wird. |
| Skalierungsentität | Der Miniportadapter selbst im nativen RSS-Modus oder ein VPort im RSSv2-Modus. |
| ITE | Ein Dereferenzierungstabelleneintrag (ITE) einer bestimmten Skalierungsentität. Die Gesamtzahl der ITEs pro VPort darf "NumberOfIndirectionTableEntriesPerNonDefaultPFVPort" oder "NumberOfIndirectionTableEntriesForDefaultVPort" im VMQ-Modus oder 128 im nativen RSS-Fall nicht überschreiten. NumberOfIndirectionTableEntriesPerNonDefaultPFVPort und NumberOfIndirectionTableEntriesForDefaultVPort sind Member der NDIS_NIC_SWITCH_CAPABILITIES-Struktur . |
| Skalierungsmodus | Die VMSwitch-Richtlinie pro VPort, die steuert, wie ihre 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 Dereferenzierungstabelle kann die Konfigurationswarteschlange mehrere ITEs zurückstellen. Die Gesamtzahl der Warteschlangen, einschließlich einer, die von der Standardwarteschlange verwendet wird, darf nicht den von einem Administrator festgelegten vorkonfigurierten Grenzwert ü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 während der VPort-Erstellung als ProcessorAffinity-Element der NDIS_NIC_SWITCH_VPORT_PARAMETERS Struktur angegeben wurde. Dieser Prozessor kann zur Laufzeit aktualisiert werden und gibt an, wo VMQ-Datenverkehr weitergeleitet wird. |
| Quell-CPU | Der Prozessor, dem der ITE derzeit zugeordnet ist. |
| Ziel-CPU | Der Prozessor, dem der ITE neu zugeordnet wird (mit RSSv2). |
| Actor CPU | Der Prozessor, auf dem RSSv2-Anforderungen gestellt werden. |
Anzeigen von RSSv2-Funktionen in einem Miniporttreiber
Miniport-Treiber werben für die UNTERSTÜTZUNG von RSSv2, indem sie das CapabilitiesFlags-Element der NDIS_RECEIVE_SCALE_CAPABILITIES Struktur mit der NDIS_RSS_CAPS_SUPPORTS_INDEPENDENT_ENTRY_MOVE-Kennzeichnung festlegen. Diese Funktion ist erforderlich, um das CPU-Lastenausgleichsfeature von RSSv2 zusammen mit dem flag NDIS_RECEIVE_FILTER_DYNAMIC_PROCESSOR_AFFINITY_CHANGE_SUPPORTED zu aktivieren, das RSSv1 dynamischen Balancing für nicht standardmäßige VPorts (VMQs) ermöglicht.
Hinweis
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 Verbreitungsmodus 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 ein Set-OID, das zum Konfigurieren der Parameter der Skalierungsentität verwendet wird, z. B. die Anzahl der Warteschlangen, die Anzahl der ITEs, die RSS-Aktivierung/Deaktivierung und Hashschlüsselaktualisierungen.
- OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES ist ein Methoden-OID, das zum Ändern von Dereferenzierungstabelleneinträgen verwendet wird.
Behandeln 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 ein reguläres OID und wird mit dem OID_GEN_RECEIVE_SCALE_PARAMETERS OID in RSSv1 behandelt. Diese OID ist vor NDIS 6.80 nicht sichtbar für NDIS Light-Weight Filter Drivers (LWFs).
OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES ist jedoch ein synchrones OID, das NDIS_STATUS_PENDING nicht zurückgeben kann. Dieses OID muss im Prozessorkontext ausgeführt und abgeschlossen werden, der das OID stammt. Wie OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 ist es 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. Die Nutzlast enthält ein Array einfacher "Move ITE"-Aktionen, von denen jeder einen Befehl enthält, um einen einzelnen ITE für eine Skalierungsentität auf eine andere Ziel-CPU zu verschieben. 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 | Synchroner OID-Handler(n) | Funktion, die synchrone OIDs stammt |
|---|---|---|
| Miniport | MiniportSynchronousOidRequest | N/V |
| Filter | NdisFSynchronousOidRequest | |
| Protokoll | N/V | 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 Steuerungsparameter 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-Zustandsübergangs, der einen Parameter inaktiv macht, müssen Miniporttreiber Änderungen an dem Parameter nachverfolgen, bis der umgekehrte Übergang sie erneut 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 Überarbeitungsstatus für die Standardprozessor- und Dereferenzierungstabelle 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 Hardware-RSS-Aktivierung alle Einträge auf den primären Prozessor zeigen, bevor die Aktualisierungen zum Verschieben der Dereferenzierungstabelleneinträge an die Hardware ausgegeben und ausgeführt werden, kann der primäre Prozessor einen kurzen Stau erleben. Wenn der Miniporttreiber Die Standardprozessor- und ITE-Informationen nachverfolgt hat, kann er den Datenverkehr an die Stelle leiten, an der er bereits von der oberen Ebene erwartet wird.
Beachten Sie, dass miniport-Treiber zwar alle Aktualisierungen von inaktiven Steuerungsparametern nachverfolgen müssen, aber sie sollten die Überprüfung dieser Parameter zurückstellen, bis der RSS-Zustand versucht, diese Parameter zu aktivieren. 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 Miniporttreiber sollte die Parameter jedoch weiterhin überprüfen und den RSS-Zustandsübergang fehlschlagen, wenn festgestellt wird, dass nachverfolgte inaktive Steuerungsparameter ungültig sind.
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 |
|
| Dereferenzierungstabelle |
|
Updates für ITEs und die primären/Standardprozessoren (mit OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES) werden vom Prozessor aufgerufen, auf den der entsprechende Eintrag derzeit verweist. Für einen bestimmten VPort stellt die obere Ebene sicher, dass keine OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES OIDs zum Verschieben von ITEs oder Festlegen der primären/Standardprozessoren unter diesen Umständen ausgegeben werden:
- Während OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 in Bearbeitung ist.
- Nach dem Initiieren der VPort-Löschsequenz. Beispielsweise gibt die obere Ebene den Setfilter OID erst nach Abschluss des letzten OID zum Verschieben von ITEs aus.
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, dann das OID aus, um RSS zu deaktivieren, oder es kann auswählen, dass die Dereferenzierungstabelle wie vorhanden bleibt und RSS deaktiviert wird. In beiden Fällen sollte der Empfangsdatenverkehr auf den primären Prozessor ausgerichtet sein.
RSSv2 Standard enthält eine Anforderung von RSSv1, die das Protokoll der oberen Ebene erlaubt, 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 Ebene garantiert, dass während oder nach dem Löschen von VPort keine OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES OIDs ausgegeben werden.
Während der RSS-Deaktivierung und beim Löschen von VPort sollte der Miniporttreiber alle ausstehenden internen Vorgänge berücksichtigen, die aufgrund vorheriger Warteschlangenverschiebungen möglicherweise vorhanden sind.
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 Sie die Anzahl der Warteschlangen verringern, stellt die obere Ebene sicher, dass die Dereferenzierungstabelle nicht mehr Prozessoren referenziert als die neue Anzahl von Warteschlangen für einen VPort.
- Die obere Ebene sollte keine Aktualisierung der Dereferenzierungstabelle anfordern, die gegen die aktuell konfigurierte Anzahl von Warteschlangen für einen VPort verstößt. Der Miniporttreiber sollte dies erzwingen und einen Fehler zurückgeben.
- Bevor Sie die Anzahl der Einträge der Dereferenzierungstabelle für VMMQ-RESTRICTED-Adapter ändern, stellt die obere Ebene sicher, dass der Inhalt der Dereferenzierungstabelle auf die Leistung von 2 normalisiert wird.
Verwandte Links
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für