Unser erstes RUST-Treiberset für Intel 1G, 10G und 40G ist fertig (wir schreiben ein wenig mehr über dieses Thema, aber unsere Bänke sind wirklich brillant!) Wir werden sie im Userspace betreiben, wie unsere Sonde!

Voici l'une des questions qui nous a régulièrement été posé lors du dernier FIC (International Cybersecurity Forum) 2022 :

Warum haben Sie DPDK noch nicht benutzt?

Comprendre :

Gibt es für einen Masochisten einen triftigen Grund, DPDK nicht zu benutzen?

Als Intel, der Erfinder des DPDK im Jahr 2010, uns als eines von 10 Start-ups auswählte, die an seinem Beschleunigungsprogramm Intel Ignite im Jahr 2022 teilnehmen sollten, wurde uns von unseren Gesprächspartnern immer wieder dieselbe Frage gestellt.

Unsere Beziehung zur DPDK: "Es ist kompliziert".

Il est maintenant temps d'exprimer les réserves que nous avons sur le DPDK, dans notre cas bien précis, et les raisons qui nous ont motivé à choisir une autre voie.

Die Antwort auf diese Frage könnte folgendermaßen lauten: "Wir entwickeln bereits alles in Rust! Nous sommes tellement habitués à souffrir que décider de développer nos propres drivers de carte réseau n'a été qu'une décision comme une autre". Du coup, oui, il y a définitivement un attrait pour la douleur.

Die Realität ist jedoch die folgende: Als wir unser Netzwerk mit dem Ziel entwickelt haben,die 100Gbit/s zu erreichen, haben wir festgestellt, dass der Einsatz von DPDK zahlreiche Probleme aufwirft. Insbesondere dann, wenn unser Ziel darin bestand, die Netze unter dem Aspekt der Cybersicherheit zu analysieren.

Das DPDK ist eine quelloffene, aber dennoch revolutionäre Technologie. Sie wurde zunächst von Intel für Linux-Umgebungen entwickelt und dann vorgeschlagen. Ihr Ziel ist die Bereitstellung von Data-Plane-Librairien und von Piloten, die die Datenübertragungen steuern.

Für diejenigen, die mit DPDK nicht vertraut sind, ist diese Technologie seit 2010 verfügbar und sollte das bestehende, sehr alte und nicht sehr leistungsfähige Linux-Stack-System ersetzen.

Die DPDK, wie funktioniert sie?

Während des Ausbaus des Netzes ruft eine Netzlogik das Netz auf, um eine Methode zur Erfassung von Paketen zu konfigurieren. Es gibt mehrere Technologien, von denen die bekanntesten sicherlich AF_Packet (nativ in Linux), AF_XDP, DPDK oder auch Netmap sind.

Mit dem DPDK wird das Netz zum Teil vollständig umgestellt und ein anderer Pilot (Treiber) verwendet, der für die Verwaltung des Netzes zuständig ist. Dies hat es dem DPDK ermöglicht, das traditionelle Kernel/Linux-Ressourcenpaket schnell zu ersetzen.

Das DPDK setzt mehrere Strategien ein, um eine maximale Leistung zu erzielen. Die Zuteilung von dedizierten CPU-Kernen durch das DPDK garantiert eine optimale Leistung der "Netzanwendungen" (in Bezug auf die Verarbeitung von Millionen von Paketen pro Sekunde). Die "großen Speicherseiten" (hugepages) gewährleisten einen schnelleren und einheitlicheren Zugriff auf die Speicherressourcen (memory pool), was die Anzahl der "TLB miss" (translation lookaside buffer) reduziert. Es gibt natürlich noch viele andere Optimierungstechniken (z.B. die Wiederaufnahme von Paketen in Stapeln oder auch die Kontinuität des Speichers, die ebenfalls zu einer Verringerung der Kopier- und Wiederaufnahmevorgänge auf dem Niveau des Speicherpools führt).

Generell ermöglicht die geringere Belastung des Prozessors oft eine interessante Leistung. Und wie Intel sagt: "Le DPDK unterstützt einige der bei der Verarbeitung von Paquets eingesetzten Entkopplungselemente. Indem es die Tampons in den Benutzerraum verlagert und Abfragen statt einer auf Unterbrechungen basierenden Verarbeitung durchführt, ist das DPDK in der Lage, die Leistung bei kleinen Paquets zu verbessern." (R-IOV für NFV-Lösungen - Praktische Erwägungen und Überlegungen - Technischer Brief - Autoren: Patrick Kutch Cloud Solutions Architect Solutions Enabling Team, Intel Brian Johnson Solutions Architect Networking Division, Intel).

Heute ist es in einer hypervisuellen Umgebung dank der Verwendung von DPDK, Open vSwitch (OVS) und der Verwaltung virtueller Funktionen möglich, von einer Vielzahl interessanter Optimierungen zu profitieren, vor allem bei der Übertragung von virtuellen Paquets zwischen Maschinen (d. h. VM auf einer einzigen Maschine).

Du coup, pourquoi pas le DPDK ?

Im Laufe unserer Erfahrungen haben wir festgestellt, daß DPDK auch gewisse Einschränkungen aufweist, die sich erheblich auf die Leistung von Lösungen auswirken können, die auf der Protokollanalyse basieren. Unter diesen Beschränkungen haben wir 4 Hauptbeschränkungen ausgemacht, die uns veranlasst haben, unsere Lösung nicht auf diese Technologie umzustellen:

• 1 : Die Schwierigkeit der Erstellung/Wartung von DPDK
• 2: Schwierigkeiten bei der Konfiguration und Nutzung von DPDK
• 3 : Fehlende Kompatibilität mit Rust (bis heute)
• 4 : Son framework qui impose d'avoir ses propres threads.

Dieser letzte Punkt bedeutet, dass man ihn nicht nur als Backend für die Vorlesung eines Pakets verwenden kann. Eine Lösung, die das DPDK nutzt, kann nur das DPDK nutzen: Wir wünschen uns eine große Kompatibilität.

Dies sind nicht die einzigen Hindernisse oder Beschränkungen, die wir erfahren haben, obwohl sie für unsere Entscheidung, diese Technologie zu nutzen, ausschlaggebend waren. Parmi les autres points qui nous ont contrarié, nous pourrions mentionner à titre d'exemple :

• Das DPDK ist ein kompliziertes System (Framework), das aufgrund der vorhandenen Systeme (Legacy) beibehalten werden muss, was die Anpassung an komplexe Umgebungen noch schwieriger macht.
• Bei der Inbetriebnahme des DPDK wurden bei den sonst kompatiblen Materialien Rechenschwächen festgestellt.
• Die Umsetzung auf der Ebene der Netzkarten ist ebenfalls sehr komplex
• Das DPDK erstellt seine eigenen Threads, die außerhalb des Netzwerks liegen. Er hat also seinen eigenen Scheduler (Ordnungshüter). Da er beim Start initialisiert wird, ist es nicht möglich, Änderungen vorzunehmen, es sei denn, das gesamte System wird neu gestartet. Dies hat Auswirkungen auf die dynamische Skalierbarkeit aller auf dem DPDK basierenden Lösungen.
• Im Rahmen unserer Forschungs- und Entwicklungsarbeit sind wir noch nie in der Lage gewesen, eine Übertragungsrate von 100 Gbit/s (148.800.000 Pakete pro Sekunde) mit kleinen Paketen (64 Oktette) mit DPDK zu erreichen. Und das bei mehreren unterschiedlichen Netzbetreibern. Das Leistungsniveau ist übrigens das gleiche wie im DPDK-Rahmenwerk angegeben.
• Die im DPDK enthaltenen Netzwerktreiber verfügen über eigene Threads (von Cœur CPU), was je nach Anwendungsfall zu Rückrufsystemen (Rappel-Funktion) führen kann, die einen Overhead bei den Prozessorressourcen verursachen können, der bei der Registrierung von Paquets in PCAP wichtig ist.
• Wir haben festgestellt, dass ein Plateau entsteht, wenn bestimmte Lösungen auf der Basis von DPDK mehr als 30 Cœurs verwenden müssen.

Diese Punkte können sich jedoch ändern: Da die DPDK regelmäßig aktualisiert wird, kann es sein, dass einige davon gelöst werden, wenn Sie diesen Artikel lesen.

Das Ziel der NANO Corp. ist die einheitliche Beobachtung, d.h. die Fähigkeit, physische Netzwerke wie die Cloud mit einer gemeinsamen Plattform zu überwachen. Die Entwicklung unserer Cloud-Sonden (Spoiler-Alarm: große Ankündigung in Kürze) erforderte es, die möglichen Auswirkungen von DPDK in diesen Umgebungen zu prüfen.

Auch wenn wir die Erfahrung nicht gemacht haben, weil wir andere Entwicklungsoptionen in einer virtualisierten Umgebung gewählt haben, wurde festgestellt, dass das DPDK Schwierigkeiten haben kann, die Bearbeitung von Paketen skalierbar zu machen. Comme il est dit ici : "OVS-DPDK funktioniert in unseren Testumgebungen sehr ähnlich und entwickelt sich linear für die ersten VNFs, erreicht aber anschließend ein Systemplateau, wenn weitere VNFs hinzugefügt werden. Nous montrons que ce plateau est fonction des ressources CPU allouées aux fonctions de commutation virtuelle de OVS-DPDK ". (Pitaev et al., 2018 Characterizing the Performance of Concurrent Virtualized Network Functions with OVS-DPDK, FD(.)IO VPP and SR-IOV). Wir folgern daraus: Je mehr virtuelle Maschinen der Hyperviseur hat, desto schneller ist die Lösung zur Analyse der Protokolle gesättigt. Eine Hypothese, die im Rahmen unserer Forschungen überprüft wurde. Eine Sättigung, die es nicht zu erforschen gilt, da sich diese Technologie noch nicht weiterentwickelt hat.

Angesichts dieser Schwierigkeiten haben wir uns entschlossen, das DPDK weiter zu verwenden und eine Lösung zu entwickeln, die vollständig im Userspace funktioniert, einschließlich der Treiber für die Netzwerkkarte. Artikel folgt zum Thema.

Wenn Sie ähnliche Probleme haben oder wenn Sie diese Analyse nicht teilen, freuen sich unsere Forscher und Entwickler darauf, sich mit Ihnen über das Thema auszutauschen.

N'hésitez pas à prendre contact !