Aktivieren Sie NetQ Receive Side Scaling, damit vNIC-Anforderungen an eine physische Netzwerkkarte ausgelagert werden können. Die Leistung bei der Paketverarbeitung der empfängerseitigen Daten wird dadurch verbessert.

Wenn eine physische Netzwerkkarte Pakete an einen Host sendet, wird der erweiterte Netzwerkstapel (Enhanced Network Stack, ENS), der als Host-Switch ausgeführt wird, auf dem betreffenden Host im Modus Erweiterter Datenpfad konfiguriert und verteilt Daten über verschiedene logische Kerne hinweg auf NUMA-Knoten. Für die Konfiguration von RSS-Engines gibt es diverse Möglichkeiten.

Wenn Sie als Netzwerkadministrator die Durchsatzleistung bei der Paketverarbeitung empfängerseitiger Daten verbessern möchten, könnten Sie eine dieser Möglichkeiten in Betracht ziehen, um RSS so zu konfigurieren, dass die Vorteile genutzt werden.
Es handelt sich um die folgenden beiden Modi:
  • Die RSS-Engine ist für eine einzelne vNIC-Warteschlange dediziert: Eine dedizierte RSS-Engine verlagert jede Anforderung von einer vNIC vollständig auf die physische Netzwerkkarte. In diesem Modus ist eine einzelne RSS-Engine für eine einzelne vNIC-Warteschlange dediziert. Die Durchsatzleistung wird dadurch verbessert, da die pNIC die empfängerseitigen Daten verwaltet und unter den verfügbaren Hardware-Warteschlangen freigibt, um die Anforderung zu bedienen. Die vNIC-Warteschlangen befinden sich auf demselben logischen Kern oder Fastpath wie pNIC-Warteschlangen.
  • Die RSS-Engine wird von mehreren vNIC-Warteschlangen gemeinsam genutzt: In diesem Modus werden mehrere Hardware-Warteschlangen für vNIC-Warteschlangen zur Verfügung gestellt. Die vNIC-Verarbeitungsflows sind jedoch unter Umständen nicht auf die physische Hardware-Warteschlange abgestimmt, die die Daten verarbeiten soll. Dies bedeutet, dass es keine Garantie dafür gibt, dass vNIC und physische Netzwerkkarten aufeinander abgestimmt sind.
Hinweis: Wenn Default Queue Receive Side Scaling (DRSS) auf der Netzwerkkarte aktiviert ist, deaktivieren Sie es.

Voraussetzungen

  • Hosts müssen ESXi Version 7 Update 3 oder höher ausführen.
  • Stellen Sie sicher, dass die Netzwerkkarte die RSS-Funktionalität unterstützt.
  • Unterstützte Treiber: Intel40en (asynchroner Treiber). Überprüfen Sie anhand der Dokumentation zum Treiber, ob dieser über eine ENS-kompatible RSS-Implementierung verfügt.

Prozedur

  1. Aktivieren Sie NetQ/RSS mit der folgenden Syntax: esxcli system module parameters set -m -i40en_ens -p DRSS=0,0 RSS=1,0,

    wobei DRSS=0,0 angibt, dass DRSS auf beiden Netzwerkkartenports deaktiviert ist.

    RSS=1,0 gibt an, dass NetQ RSS auf einem der Netzwerkkartenports aktiviert ist.

  2. Führen Sie vmkload_mod -u i40en_ens aus, um das Laden des Treibers zu beenden.
  3. Führen Sie vmkload_mod i40en_ens aus, um den Treiber erneut zu laden, damit die RSS-Einstellung wirksam wird.
  4. Halten Sie den Gerätemanager an, um PCI FastConnect auszulösen, damit es Geräte prüfen und den Treiber einer Netzwerkkarte zuordnen kann.

    Führen Sie kill -HUP 'ps | grep mgr | awk '{print $1}' aus.

  5. Um mehrere RSS-Engines so zu konfigurieren, dass sie für RSS-Anforderungen von vNICs verfügbar sind, konfigurieren Sie die folgenden Parameter in der .vmx-Datei der VM:

    ethernet.pnicfeatures = '4': gibt an, dass die RSS-Funktion von vNICs angefordert wird.

    ethernet.ctxPerDev = '3': gibt an, dass Mehrfachkontexte (mehrere logische Kerne) für die Verarbeitung der einzelnen vNICs aktiviert sind. Die mit dem vSphere Switch verbundenen VMs sind für mehrere Warteschlangen konfiguriert. Dies bedeutet, dass mehrere logische Kerne eines NUMA-Knotens den von vNICs stammenden Tx- und Rx-Datenverkehr verarbeiten können.

    Wenn mehrere vNICs die RSS-Verlagerung anfordern, verlagert der erweiterte Netzwerkstapel (Enhanced Network Stack, ENS) ihre RSS-Anforderungen nicht auf die pNIC, sondern die gemeinsam genutzte RSS-Engine verarbeitet ihre Anforderungen. Für gemeinsam genutztes RSS sind mehrere RSS-Warteschlangen verfügbar, aber es wird nicht garantiert, dass sich eine vNIC- oder eine pNIC-Warteschlange an demselben Speicherort befindet.

  6. Konfigurieren Sie die folgenden Parameter in der .vmx-Datei der VM, um eine dedizierte RSS-Engine zum Verarbeiten von Anforderungen von einer vNIC zu konfigurieren:

    ethernet.rssoffload=True,

    Wenn die vorherige Konfiguration aktiviert ist, werden RSS-Anforderungen von einer vNIC auf die physische Netzwerkkarte verlagert. Nur eine einzige vNIC kann ihre Anforderungen auf eine RSS-Engine verlagern. In diesem Modus sind die vNIC-Warteschlangen auf die pNIC-Warteschlangen abgestimmt.

  7. Stellen Sie sicher, dass der Paketfluss auf die von der RSS-Engine bereitgestellten Hardware-Warteschlangen verteilt wird.

    Führen Sie die folgenden Befehle aus.

    vsish

    get /net/pNics/vmnicX/stats

    Beispielausgabe:

    rxq0: pkts=0 bytes=0 toFill=2047 toProc=0 noBuf=0 csumErr=0
rxq1: pkts=0 bytes=0 toFill=2047 toProc=0 noBuf=0 csumErr=0
rxq2: pkts=0 bytes=0 toFill=2047 toProc=0 noBuf=0 csumErr=0
rxq3: pkts=0 bytes=0 toFill=2047 toProc=0 noBuf=0 csumErr=0
rxq4: pkts=0 bytes=0 toFill=2047 toProc=0 noBuf=0 csumErr=0
rxq5: pkts=0 bytes=0 toFill=2047 toProc=0 noBuf=0 csumErr=0
rxq6: pkts=0 bytes=0 toFill=2047 toProc=0 noBuf=0 csumErr=0
rxq7: pkts=0 bytes=0 toFill=2047 toProc=0 noBuf=0 csumErr=0
txq0: pkts=0 bytes=0 toFill=0 toProc=0 dropped=0
txq1: pkts=0 bytes=0 toFill=0 toProc=0 dropped=0
txq2: pkts=0 bytes=0 toFill=0 toProc=0 dropped=0
txq3: pkts=0 bytes=0 toFill=0 toProc=0 dropped=0
txq4: pkts=0 bytes=0 toFill=0 toProc=0 dropped=0
txq5: pkts=0 bytes=0 toFill=0 toProc=0 dropped=0
txq6: pkts=0 bytes=0 toFill=0 toProc=0 dropped=0
txq7: pkts=0 bytes=0 toFill=0 toProc=0 dropped=0