Mehrere klassische Linux-Paketsammel-Engines

Dieser Artikel listet vier klassische Linux-Paketsammel-Engines auf. Wenn es andere gibt, die Ihrer Meinung nach in Ordnung sind, können Sie eine Nachricht hinterlassen. Diese vier sind:

• libpcap/libpcap-mmap
• PF_RING
• DPDK
• xdp

libpcap

Der Paketerfassungsmechanismus von

libpcap befindet sich auf der Datenverbindungsschicht. Fügen Sie einen Bypass hinzu Eine Verarbeitung, die die Verarbeitung des systemeigenen Netzwerkprotokollstapels nicht beeinträchtigt, wird durch den Linux-Kernel gefiltert und gepuffert und schließlich direkt an die Anwendung der oberen Ebene weitergeleitet.

1. Das Datenpaket kommt am Netzwerkkartengerät an.
2. Das Netzwerkkartengerät führt DMA-Vorgänge entsprechend der Konfiguration aus. ("Erste Kopie": Netzwerkkartenregister -> vom Kernel für die Netzwerkkarte zugewiesener Ringpuffer)
3. Die Netzwerkkarte sendet einen Interrupt und weckt den Prozessor auf.
4. Die Treibersoftware liest aus dem Ringpuffer und füllt die Kernel-Skbuff-Struktur ( „Zweite Kopie“ : Kernel-Netzwerkkartenpuffer-Ringpuffer-> Kernel-spezifische Datenstruktur skbuff)
5. Rufen Sie dann die Funktion netif_receive_skb auf:

• 5.1 Wenn ein Paketerfassungsprogramm vorhanden ist, geben Sie den BPF-Filter über die Netzwerk-Subschnittstelle ein und kopieren Sie die Pakete, die den Regeln entsprechen, in den Systemkerncache ( "3. Kopie). „ ). BPF ordnet jedem Paketerfassungsprogramm, das gewartet werden muss, einen Filter und zwei Puffer zu. BPF weist Puffer zu und beträgt normalerweise 4 KB. Der Speicherpuffer wird zum Empfangen von Daten vom Adapter verwendet. Der Haltepuffer wird zum Kopieren von Paketen in die Anwendung verwendet.
• 5.2 Verarbeiten Sie die Überbrückungsfunktion der Datenverbindungsschicht.
• 5.3 Bestimmen Sie das Protokoll der oberen Schicht gemäß dem Feld skb->protocol und senden Sie es zur Verarbeitung an die Netzwerkschicht, geben Sie den Netzwerkprotokollstapel ein und Führen Sie eine Verarbeitung auf hoher Ebene durch.
• libpcap umgeht die Verarbeitung des Protokoll-Stack-Teils des Linux-Kernel-Paketerfassungsprozesses und ermöglicht es der User-Space-API, den Socket PF_PACKET direkt aufzurufen, um eine Kopie des Datenpakets vom Link-Layer-Treiber abzurufen und es vom zu puffern Der Kernelbereich wird in den User-Space-Puffer kopiert ( „Die 4. Kopie“)

libpcap-mmap

libpcap-mmap ist eine Verbesserung gegenüber der alten libpcap-Implementierung und wird grundsätzlich in der neuen verwendet Versionen des libpcap packet_mmap-Mechanismus. PACKET_MMAP reduziert eine Speicherkopie durch mmap ( „Die vierte Kopie ist weg“ ), reduziert häufige Systemaufrufe und verbessert die Effizienz der Paketerfassung erheblich.

PF_RING

Wir haben gesehen, dass libpcap zuvor 4 Speicherkopien hatte. libpcap_mmap verfügt über 3 Speicherkopien. Die von PF_RING vorgeschlagene Kernlösung besteht darin, die Anzahl der Nachrichtenkopien während der Übertragung zu reduzieren.

Wir können sehen, dass pfring im Vergleich zu libpcap_mmap es dem Benutzerraumspeicher ermöglicht, mmap direkt mit rx_buffer zu erstellen. Dadurch wird eine weitere Kopie reduziert ( „Die zweite Kopie von libpcap_mmap“ : rx_buffer->skb)

PF-RING ZC implementiert die DNA-Technologie (Direct NIC Access Direct Network Card Access), um den Speicherplatz des Benutzers dem Speicher des Treibers zuzuordnen Platz, damit die Anwendung des Benutzers direkt auf die Register und Daten der Netzwerkkarte zugreifen kann.

Auf diese Weise wird die Pufferung von Datenpaketen im Kernel vermieden und eine Kopie reduziert („Die erste Kopie von libpcap“, DMA zur Kernel-Pufferkopie). Dies ist eine völlige Nullkopie.

Der Nachteil besteht darin, dass jeweils nur eine Anwendung den DMA-Ring öffnen kann (beachten Sie, dass heutige Netzwerkkarten mehrere RX/TX-Warteschlangen haben können, sodass sich eine Anwendung gleichzeitig in jeder Warteschlange befinden kann), kurz gesagt , müssen mehrere Anwendungen im Benutzermodus miteinander kommunizieren, um Datenpakete zu verteilen.

DPDK

pf-ring Sowohl zc als auch dpdk können eine Nullkopie von Datenpaketen erreichen. Beide umgehen den Kernel, aber die Implementierungsprinzipien sind etwas unterschiedlich. PF-Ring ZC übernimmt die Datenpakete über den ZC-Treiber (auch auf Anwendungsebene), und DPDK wird basierend auf UIO implementiert.

1 UIO+mmap implementiert Zero Copy

UIO (Userspace I/O) ist eine I/O-Technologie, die im Userspace ausgeführt wird. Im Allgemeinen werden Treibergeräte in Linux-Systemen im Kernelbereich ausgeführt und können von Anwendungen im Benutzerbereich aufgerufen werden. UIO führt jedoch einen kleinen Teil des Treibers im Kernelbereich aus und implementiert den größten Teil des Treibers im Benutzerbereich. Funktion. Mithilfe des von Linux bereitgestellten UIO-Mechanismus kann der Kernel umgangen werden und die gesamte Paketverarbeitungsarbeit wird im Benutzerbereich ausgeführt.

2 UIO+PMD reduziert Interrupts und CPU-Kontextwechsel.

Der UIO-Treiber von DPDK blockiert von der Hardware ausgegebene Interrupts und verwendet dann aktive Abfragen im Benutzermodus. Dieser Modus wird als PMD (Poll Mode Driver) bezeichnet.

Im Vergleich zu DPDK verwendet pf-ring (kein Zc) NAPI-Abfrage und Abfrage auf Anwendungsebene, während pf-ring zc DPDK ähnelt und nur Abfrage auf Anwendungsebene verwendet.

3 HugePages reduzieren TLB-Fehler

Nach der Einführung von MMU (Memory Management Unit) im Betriebssystem muss die CPU zweimal auf den Speicher zugreifen, um die Speicherdaten zu lesen. Das erste Mal besteht darin, die Seitentabelle abzufragen, um die logische Adresse in eine physische Adresse umzuwandeln, und dann auf die physische Adresse zuzugreifen, um Daten oder Anweisungen zu lesen.

Um das Problem der langen Abfragezeit, die durch zu viele Seiten und zu große Seitentabellen verursacht wird, zu verringern, wurde TLB (Translation Lookaside Buffer) eingeführt, der als Adressübersetzungspuffer übersetzt werden kann. Der TLB ist eine Speicherverwaltungseinheit, die im Allgemeinen in einem Register gespeichert ist und einen kleinen Teil der Seitentabelleneinträge speichert, auf die aktuell am wahrscheinlichsten zugegriffen wird.

Nachdem der TLB eingeführt wurde, geht die CPU zunächst zum TLB, um ihn zu adressieren. Da der TLB im Register gespeichert ist und nur einen kleinen Teil der Seitentabelleneinträge enthält, ist die Abfragegeschwindigkeit sehr hoch. Wenn die Adressierung im TLB erfolgreich ist (TLB-Treffer), besteht keine Notwendigkeit, die Seitentabelle im RAM abzufragen. Wenn die Adressierung im TLB fehlschlägt (TLB-Fehler), müssen Sie die Seitentabelle im RAM abfragen. Die Seite wird im TLB aktualisiert.

DPDK verwendet HugePages, das Seitengrößen von 2 MB und 1 GB unter x86-64 unterstützt, wodurch die Gesamtzahl der Seiten und die Größe der Seitentabelle erheblich reduziert werden, wodurch die Wahrscheinlichkeit eines TLB-Fehlers erheblich verringert und die CPU-Adressierungsleistung verbessert wird.

4 Weitere Optimierungen

• SNA (Shared-nothing Architecture), die Softwarearchitektur ist dezentralisiert, versucht globales Teilen zu vermeiden, führt zu globalem Wettbewerb und verliert die Fähigkeit zur horizontalen Expansion. Im NUMA-System wird der Speicher nicht remote über Knoten hinweg verwendet.
• SIMD (Single Instruction Multiple Data), vom frühesten mmx/sse bis zum neuesten avx2, haben die Fähigkeiten von SIMD zugenommen. DPDK verwendet die Stapelverarbeitung mehrerer Pakete gleichzeitig und verwendet dann die Vektorprogrammierung, um alle Pakete in einem Zyklus zu verarbeiten. Memcpy verwendet beispielsweise SIMD, um die Geschwindigkeit zu erhöhen.
• CPU-Affinität: CPU-Affinität

XDP

Datenverarbeitungsebene, xdp erstellt eine datenschnelle Ebene in der Treiberebene. Das Datenpaket wird verarbeitet, bevor die Daten von der Netzwerkkarten-Hardware in den Speicher übertragen und Skb zugewiesen werden.

Bitte beachten Sie, dass XDP keinen Kernel-Bypass für die Datenpakete durchführt, sondern nur eine kleine Vorabprüfung durchführt.

Im Vergleich zu DPDK bietet XDP folgende Vorteile:

• Keine Notwendigkeit für Codebibliotheken und Lizenzen von Drittanbietern
• Unterstützt sowohl abgefragte als auch unterbrechungsbasierte Netzwerke
• Keine Notwendigkeit, große Seiten zuzuweisen
• Keine dedizierte CPU erforderlich
• Keine Notwendigkeit Definieren Sie neue sichere Netzwerkmodelle. Zu den XDP-Nutzungsszenarien gehören: DDoS-Abwehr, Firewall, XDP_TX-basierter Lastausgleich, Netzwerkstatistiken
Komplexe Netzwerk-Probenahme
• Hochgeschwindigkeits-Handelsplattform
• OK, das Obige ist die heutige Freigabe. Wenn Sie der Meinung sind, dass es andere Paketsammel-Engines gibt, können Sie eine Nachricht zum Teilen hinterlassen.

Das obige ist der detaillierte Inhalt vonMehrere klassische Linux-Paketsammel-Engines. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!