Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Empfangsseitige Skalierung der Software

Übersicht

Moderne Netzwerkkarten unterstützen mehrere Empfangs- und Übertragungsdeskriptorwarteschlangen (Multi-Queue). Beim Empfang kann eine Netzwerkkarte verschiedene Pakete an verschiedene Warteschlangen senden, um die Verarbeitung auf die CPUs zu verteilen. Die Netzwerkkarte verteilt Pakete, indem sie auf jedes Paket einen Filter anwendet, der es einem von wenigen logischen Flüssen zuweist. Pakete für jeden Datenstrom werden in eine separate Empfangswarteschlange geleitet, die wiederum von separaten CPUs verarbeitet werden kann. Dieser Mechanismus wird allgemein als empfangsseitige Skalierung (RSS) bezeichnet. Das Ziel der RSS-Technik ist es, die Leistung gleichmäßig zu steigern. RSS wird aktiviert, wenn die Latenz ein Problem darstellt oder wenn die Verarbeitung von Empfangsunterbrechungen einen Engpass darstellt. Durch die Verteilung der Last auf CPUs wird die Warteschlangenlänge verringert. Für Netzwerke mit geringer Latenz ist es optimal, so viele Warteschlangen zuzuweisen, wie CPUs im System vorhanden sind (oder das maximale NIC-Maximum, falls niedriger). Die effizienteste High-Rate-Konfiguration ist wahrscheinlich diejenige mit der geringsten Anzahl von Empfangswarteschlangen, bei der keine Empfangswarteschlange aufgrund einer gesättigten CPU überläuft. Sie können den Bridging-Durchsatz mit der empfangsseitigen Skalierung verbessern.

Gemäß der Flow-Thread-Affinitätsarchitektur fragt jeder Flow-Thread (FLT) Pakete aus der dedizierten Empfangswarteschlange der Netzwerkkarte ab und verarbeitet die Pakete bis zum Abschluss. Daher werden Datenfluss-Threads für die Paketverarbeitung an NIC-Empfangs- (RX) und Sendewarteschlangen (TX) gebunden, um Meinungsverschiedenheiten zu vermeiden. Daher muss die Netzwerkkarte über dieselbe Anzahl von RX- und TX-Warteschlangen verfügen wie über die Anzahl der vSRX Virtual Firewall Data Plane-CPUs, um Multi-Core-vSRX-Virtual Firewall-Varianten zu unterstützen. Software RSS (SWRSS) hebt diese Einschränkung von NIC-Hardware-Warteschlangen auf, um vSRX Virtual Firewall Multi-Core-Varianten auszuführen, indem softwarebasiertes Packet Spraying über verschiedene FLT-Threads implementiert wird.

Software-RSS lagert die Verarbeitung einzelner Datenströme auf einen der mehreren Kernel aus, sodass der Datenfluss-Thread, der die Pakete von der Netzwerkkarte entgegennimmt, mehr Pakete verarbeiten kann. Ähnlich wie bei RSS korreliert die Verbesserung des Netzwerkdurchsatzes bei Verwendung von SWRSS linear mit der CPU-Auslastung.

In SWRSS wird jeder NIC-Port mit einer gleichen oder einer kleineren Anzahl von Hardware-RX/TX-Warteschlangen initialisiert als die von E/A-Threads. E/A-Threads werden auf der Grundlage der gesamten Datenpfad-CPU und der minimalen Anzahl von NIC-Warteschlangen unter allen NIC-Schnittstellen in der virtuellen vSRX-Firewall bestimmt. Wenn beispielsweise der E/A-Thread als 4 berechnet wird, kann die Anzahl der Hardwarewarteschlangen pro NIC-Port kleiner oder gleich 4 Warteschlangen sein.

Wenn NICs nicht über eine ausreichende Anzahl von Warteschlangen als FLT-Threads in unterstützten vSRX Virtual Firewall-Instanzen verfügen, wird Software-RSS (SWRSS) durch den Datenfluss aktiviert. SWRSS implementiert ein Softwaremodell der Paketverteilung über FLTs, nachdem die Pakete aus NIC-Empfangswarteschlangen abgerufen wurden. Durch das Entfernen der NIC-Hardwarewarteschlangenbeschränkung hilft SWRSS bei der Skalierung von vCPUs, indem verschiedene vSRX-Instanztypen der virtuellen Firewall unterstützt werden.

Während des E/A-Vorgangs werden die Pakete aus den Warteschlangen der NIC-Ports geholt und die Paketklassifizierung durchgeführt. Gefolgt von der Verteilung der Pakete an virtuelle Warteschlangen von FLT-Threads. Diese virtuellen Warteschlangen werden über die DPDK-Ringwarteschlange implementiert. Im Übertragungspfad ruft SWRSS die Pakete aus virtuellen Übertragungswarteschlangen von FLT-Threads ab und überträgt diese Pakete zur Übertragung an NIC-Übertragungswarteschlangen.

Die Anzahl der SWRSS-E/A-Threads wird basierend auf der Gesamt-CPU und der Anzahl der NIC-Warteschlangen ausgewählt, die in vSRX-Instanzen der virtuellen Firewall gefunden wurden. Der Mix-Betriebsmodus mit HWRSS und SWRSS wird nicht unterstützt.

Grundlegendes zur Konfiguration der empfangsseitigen Skalierung von Software

Dieses Thema enthält Details zu den Typen der softwareempfangsseitigen Skalierung (SWRSS) und deren Konfiguration.

SWRSS unterstützt zwei Betriebsmodi und wird basierend auf der Anzahl der benötigten Datenpfad-CPUs aktiviert. Diese Modi sind der gemeinsam genutzte E/A-Modus und der dedizierte E/A-Modus. Diese Modi werden basierend auf der Anzahl der benötigten Datenpfad-CPUs aktiviert. Die virtuelle vSRX-Firewall und vSRX3.0 unterstützen nur den dedizierten E/A-Modus.

Im dedizierten E/A-Modus erstellt der Flowd-Prozess dedizierte E/A-Threads für den E/A-Betrieb. Basierend auf der Anzahl der erforderlichen E/A-Threads für die virtuelle vSRX-Firewall wird der E/A-Thread einem dedizierten NIC-Port zugeordnet. Die Empfangs- und Sendewarteschlange der NIC-Ports wird dann im Round-Robin-Verfahren mit jedem E/A-Thread verbunden, um eine gleichmäßige Verteilung zu gewährleisten und E/A-Thread-Sperren zu vermeiden. Jeder dedizierte E/A-Thread ruft die Pakete im Burst-Modus aus der NIC-Empfangswarteschlange ab und verteilt sie auf FLT-Threads und umgekehrt für den TX-Pfad für die Paketübertragung.

SWRSS wird basierend auf der Anzahl der vCPUs aktiviert. Wenn die Netzwerkkarte nicht über eine ausreichende Anzahl von Warteschlangen als Flow-Thread (FLT) in der virtuellen vSRX-Firewall mit unterschiedlichen vCPUs verfügt, wird Software-RSS (SWRSS) durch den Flow-Prozess aktiviert.

SWRSS ist in den folgenden Szenarien nicht aktiviert:

  • Wenn die Netzwerkkarte über eine ausreichende Anzahl von Hardware-Empfangs- oder TX-Warteschlangen für die erforderliche PFE-Datenpfad-CPU verfügt.

  • Wenn die virtuelle vSRX-Firewall (basierend auf der Anzahl der vCPUs) und die Netzwerkkarte die geringere Anzahl von FLT-CPUs ergeben als im nächstgelegenen Hardware-RSS-Modus (HWRSS). In einem solchen Szenario wird die virtuelle vSRX-Firewall mit dem HWRSS-Modus aktiviert, der zu mehr FLT-CPU als zum SWRSS-Modus führt und einen besseren Paketverarbeitungsdurchsatz bietet.

  • SWRSS wird nicht für virtuelle vSRX-Firewalls mit einem bestimmten NIC-Typ empfohlen, der eine geringere Anzahl von NIC-Warteschlangen unterstützt, als zum Ausführen eines dedizierten E/A-Threads erforderlich ist. In solchen Fällen ist SWRSS aktiviert, aber zusätzliche CPUs werden an die FLT-CPU angeschlossen, bis die E/A-CPUs vollständig ausgelastet sind.

Wenn SWRSS nicht aktiviert ist, verwenden Sie den set security forwarding-options receive-side-scaling software-rss mode enable Befehl zum Aktivieren von SWRSS. Wenn Sie diesen Befehl ausführen, wird SWRSS unabhängig von der Netzwerkkarte RSS oder der Anzahl der vCPUs zwangsweise aktiviert. Wenn Sie SWRSS nicht über die CLI aktivieren, wird die automatische Aktivierung von SWRSS basierend auf dem Standardverhältnis von FLT: IO ( 4:1) entschieden.

Verwenden Sie den set security forwarding-options receive-side-scaling software-rss io-thread-number <1-8> Befehl, um die Anzahl der erforderlichen E/A-Threads zu konfigurieren. Verwenden Sie den Befehl, um die tatsächliche Anzahl der vCPUs anzuzeigen, die show security forwarding-options resource-manager E/A-Flow-Threads zugewiesen sind.

Sie können die Aktivierung von SWRSS automatisch oder erzwungen basierend auf der Architektur und Konzeption von E/A-Thread und Worker-Thread entscheiden. Die Aktivierung von SWRSS wirkt sich auf die Leistung aus, daher wird empfohlen, die Anzahl der E/A-Threads nur bei Bedarf und bis zum Erreichen des Engpasses mit den Auswirkungen auf die Leistung zu ändern.