Einige unserer Vorbehalte gegenüber dem DPDK

Unser erster Satz von RUST-Treibern für Intel 1G-, 10G- und 40G-Boards ist fertig (wir werden noch etwas mehr darüber schreiben, aber unsere Benchmarks sind wirklich brillant!) Wir lassen sie im Userspace laufen, wie unsere Probe!
Eine Frage, die uns während der letzten FIC (2022) oft gestellt wurde, war:

"Warum haben Sie nicht das DPDK benutzt?",

Verstehen:

"Gibt es, abgesehen von einer masochistischen Seite, einen triftigen Grund?

Als Intel, der Erfinder von DPDK, uns als eines der 10 Start-ups auswählte, die im Rahmen des Intel Ignite Programms 2022 gefördert werden sollten, wurde uns von unseren Gesprächspartnern immer wieder dieselbe Frage gestellt.
Es ist nun an der Zeit, die Vorbehalte zu äußern, die wir gegenüber DPDK in unserem Kontext haben, und die Gründe zu nennen, die uns dazu bewogen haben, einen anderen Weg zu wählen.

Die Antwort auf diese Frage könnte man so zusammenfassen: "Wir machen alles in RUSTWir sind so sehr an das Leiden gewöhnt, dass die Entwicklung unserer eigenen NIC-Treiber ein Spaziergang im Park war. Also, ja, es gibt definitiv eine Anziehungskraft von Schmerz.

Als wir unsere Netzwerksonde mit dem Ziel entwickelt haben, 100 Gbit/s zu erreichen, haben wir festgestellt, dass die Verwendung des DPDK viele Probleme verursacht. Vor allem, wenn unser Ziel darin bestand, Netzwerke für Cybersicherheitszwecke zu analysieren.

Das DPDK ist eine ziemlich revolutionäre Open-Source-Technologie. Sie wurde ursprünglich von Intel für Linux-Umgebungen entwickelt und dann vorgeschlagen. Ihr Ziel ist es, Data Plane-Bibliotheken und -Treiber für die Verwaltung von Netzwerkkarten bereitzustellen.

Für diejenigen, die mit dem DPDK nicht vertraut sind: Diese Technologie wurde 2010 eingeführt, um den veralteten und nicht sehr effizienten Linux-Netzwerkstack zu erneuern.

Wie funktioniert DPDK?

Beim Starten ruft eine Netzwerksoftware den Kernel auf, um eine Paketerfassungsmethode zu konfigurieren. Es gibt mehrere Technologien, von denen die beliebtesten sicherlich AF_Packet (nativ in Linux), AF_XDP, DPDK oder Netmap sind.

Mit DPDK wird der Kernel standardmäßig vollständig umgangen und ein anderer Treiber verwendet, der für die Verwaltung der Netzwerkkarte zuständig ist. Dadurch konnte sich das DPDK schnell als Ersatz für den traditionellen Kernel/Linux-Netzwerkstack etablieren.

Das DPDK verwendet mehrere Strategien, um eine maximale Leistung zu erreichen. Die Zuweisung dedizierter CPU-Kerne durch das DPDK garantiert eine bessere Leistung von "Netzwerkanwendungen" (im Hinblick auf die Verarbeitung von Millionen von Paketen pro Sekunde). Die"hugepages" sorgen für einen gleichmäßigeren Zugriff auf die Speicherressourcen(Speicherpool) in der Zeit, wodurch die Anzahl der"TLB misses"(translation lookaside buffer) reduziert wird. Es gibt natürlich noch viele andere Optimierungstechniken (z. B. die Wiederherstellung von Paketen per Stapelverarbeitung oder die Umgehung des Kernels, was ebenfalls zu einer Verringerung der Kopier-/Wiederherstellungsvorgänge auf der Pufferebene führt).

Im Allgemeinen können durch die geringere Belastung des Prozessors oft interessante Leistungen erzielt werden. Und wie Intel hervorhebt,

"Das DPDK beseitigt einige der Engpässe, die bei der Paketverarbeitung auftreten. Durch die Verlagerung von Speicherpuffern in den Userspace und die Durchführung von Polling anstelle von interruptbasierter Verarbeitung ist das DPDK in der Lage, die Leistung bei kleinen Paketgrößen zu verbessern." R-IOV für NFV-Lösungen - Praktische Überlegungen und Gedanken Technischer Brief - Autoren: Patrick Kutch Cloud Solutions Architect Solutions Enabling Team, Intel Brian Johnson Solutions Architect Networking Division, Intel).

In einer Hypervisor-Umgebung ist es heute dank der Verwendung von DPDK, Open vSwitch (OVS) und Virtual Function Management möglich, von mehreren interessanten Optimierungen zu profitieren, insbesondere bei der Paketübertragung zwischen virtuellen Maschinen (d. h. VMs auf einer einzigen physischen Maschine).

Warum also bestraft ihr euch selbst, könnte man fragen?

Während unserer Experimente haben wir festgestellt, dass das DPDK auch gewisse Einschränkungen aufweist, die die Leistung von Lösungen, die auf der Protokollanalyse basieren, stark beeinträchtigen. Unter diesen Einschränkungen haben wir 4 Hauptgründe ausgemacht, die uns veranlasst haben, diese Technologie nicht für unsere Lösung zu verwenden:

• Herausforderungen bei der Kompilierung/Pflege,
• Schwierigkeiten bei der Konfiguration/Einführung,
• (bisher) keine Kompatibilität mit RUST,
• Rahmen, der eigene Threads vorschreibt.

Letzteres bedeutet, dass es nicht nur als Paketlese-Backend verwendet werden kann. Eine Lösung, die DPDK verwendet, kann nur DPDK verwenden, aber wir wollten eine breitere Kompatibilität haben.

Dies sind nicht die einzigen Einschränkungen, auf die wir gestoßen sind, obwohl sie ausschlaggebend dafür waren, dass wir diese Technologie aufgegeben haben. Unter den anderen Punkten, die uns irritiert haben, können wir die folgenden Beispiele nennen.

DPDK ist aufgrund seiner Altsysteme ein komplexes Framework, was die Anpassung an komplexe Netzwerkumgebungen noch schwieriger macht.

Wenn DPDK aktualisiert wird, geht die Kompatibilität mit zuvor kompatibler Hardware verloren.

Die Implementierung auf der Ebene der Netzschnittstellenkarten ist komplex.

DPDK verwaltet seine eigenen Threads, die aus dem Kernel ausgelagert sind. Es hat also seinen eigenen Scheduler. Da er beim Booten initialisiert wird, ist es nicht möglich, Änderungen vorzunehmen, außer durch einen Neustart des gesamten Systems. Dies wirkt sich auf die dynamische Skalierbarkeit jeder auf DPDK aufbauenden Lösung aus.

Bei unseren Forschungs- und Entwicklungsarbeiten ist es uns nie gelungen, mit DPDK einen Durchsatz von 100 Gbit/s (148.800.000 Pakete pro Sekunde) mit kleinen Paketgrößen (64 Byte) zu erreichen, obwohl die Community diese Leistung angekündigt hatte. Wir haben dies mit mehreren verschiedenen Netzwerkkarten versucht.

Die in DPDK implementierten Netzwerkkartentreiber haben ihre eigenen Threads (von CPU-Kernen), was je nach Anwendungsfall manchmal zu Rückrufsystemen führt, die bei der Registrierung von Paketen in PCAP einen erheblichen Overhead an Prozessorressourcen verursachen können.

Und schließlich haben wir ein Plateau festgestellt, wenn bestimmte DPDK-basierte Lösungen mehr als 30 Kerne verwenden müssen.

Wir möchten betonen, dass sich diese Punkte jedoch weiterentwickeln können, da DPDK regelmäßig aktualisiert wird und einige davon seit der letzten DPDK-Implementierung, die wir ausprobiert haben, behoben worden sein könnten.

Das Ziel der NANO Corp ist eine einheitliche Beobachtbarkeit, d. h. die Möglichkeit, sowohl physische als auch Cloud-Netzwerke mit derselben Plattform zu überwachen. Bei der Entwicklung unserer Cloud-Sonden (Spoiler-Alarm: große Ankündigung in Kürze) mussten wir die potenziellen Auswirkungen von DPDK in diesen Umgebungen vorhersehen.

Obwohl wir dies aufgrund anderer Entwicklungsentscheidungen nicht erlebt haben, wurde in virtualisierten Umgebungen auch festgestellt, dass das DPDK Schwierigkeiten haben kann, die Paketverarbeitung skalierbar zu machen. Wie hier angegeben:

"OVS-DPDK zeigt in unseren Testumgebungen eine sehr ähnliche Leistung. Es skaliert linear für die ersten VNFs, erreicht dann aber ein Plateau im Systemdurchsatz, wenn mehr VNFs hinzugefügt werden. Wir zeigen, dass dieses Plateau eine Funktion der CPU-Ressourcen ist, die den virtuellen Schaltfunktionen von OVS-DPDK zugewiesen werden." Pitaev et al., 2018 Characterizing the Performance of Concurrent Virtualized Network Functions with OVS-DPDK, FD(.)IO VPP and SR-IOV.

Daher befürchteten wir, dass die Lösung für die Protokollanalyse umso schneller gesättigt sein würde, je mehr virtuelle Maschinen der Hypervisor zu verwalten hatte. Diese Hypothese hat sich im Laufe unserer Forschung bestätigt. Eine Sättigung, die zu umgehen nicht sinnvoll war, solange sich diese Technologie nicht weiterentwickelt hatte.

Angesichts all dieser Vorbehalte haben wir beschlossen, das DPDK zu umgehen und eine Lösung zu entwickeln, die vollständig im Userspace arbeitet, einschließlich der NIC-Treiber. Ein Artikel zu diesem Thema folgt noch.

Wenn Sie auf ähnliche Probleme gestoßen sind oder wenn Sie diese Analyse nicht teilen, werden unsere Forscher und internen Entwickler gerne mit Ihnen über das Thema diskutieren.

Bitte sprechen Sie uns an, wir freuen uns auf ein Gespräch!