Heim > Artikel > Betrieb und Instandhaltung > 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 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.
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.
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.
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.
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.
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.
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.
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:
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!