Eine der Funktionen von BittWares SmartNIC Shell und BittWares Loopback-Beispiel ist ein Paket-Parser/Klassifikator, der Protokollfelder aus Paketen extrahiert. In diesem Whitepaper wollen wir nicht nur unseren Parser beschreiben, sondern auch erklären, wie die Verwendung von HLS zur Erstellung und Konfiguration des Parsers zu einer besseren Implementierung geführt hat als die Verwendung der Sprache P4. Der Parser-Code ist auf der BittWare-Entwickler-Website kostenlos für Xilinx UltraScale+-Besitzer als Teil unseres Loopback-Beispiels verfügbar (Verfügbarkeit Januar 2020)
Heute wird die Parser-Komponente der SmartNIC Shell von BittWare mit der Xilinx HLS C++ Entwicklungsumgebung erstellt. Eine frühere Version der SmartNIC Shell von BittWare verwendete jedoch die Sprache P4 über das Xilinx SDNet-Tool.
Ein Grund für die Verwendung von P4 ist, dass es sich um einen aufkommenden Standard handelt, der bei denjenigen beliebt ist, die Software-defined Networking (SDN) auf handelsüblichen Intel-Servern einsetzen. Allerdings hat Xilinx später die Verfügbarkeit von SDNet eingeschränkt. Unsere Verwendung von P4 war speziell für Endbenutzer von SmartNIC Shell gedacht, so dass diese Einschränkung uns veranlasste, nach einer offeneren Lösung zu suchen. Nach dem Erfolg unserer RSS-Implementierung unter Verwendung von HLS waren wir motiviert, den SmartNIC Shell-Parser unter Verwendung desselben HLS-Ansatzes (insbesondere der Xilinx HLS C++-Umgebung) neu zu implementieren.
Die über Ethernet verwendeten Protokolle sind für die Hardware schwierig zu nutzen. Diese Herausforderung besteht darin, dass die Protokolle viele optionale Felder haben. Diese Optionen machen es kompliziert, z. B. den Anfang eines IP-Headers zu finden. Warum ist das so? Im Falle des IP-Headers können null, ein oder zwei VLAN-Tags davor stehen. Es können auch MPLS-Tags vorhanden sein. Daher muss die Hardware das Protokoll gerade so weit verstehen, dass sie den IP-Header findet. Die Hardware benötigt den IP-Header, um IP-Adressen zu finden, die häufig in Hardware-Filtern und -Tabellen verwendet werden. Ähnliche Probleme gibt es auch auf der nächsten Ebene, da der IP-Header selbst optionale Felder enthält.
Der HLS C++-Paketparser von BittWare kann damit umgehen:
Es wird davon ausgegangen, dass die Port-IDs in diesen IP-Protokollen zu finden sind: TCP, UDP, DCCP und STCP
Nachdem wir im Wesentlichen zwei Versionen eines Paketparsers erstellt hatten, stellten wir einige Unterschiede zwischen der Verwendung von P4 und HLS C++ fest. Insgesamt ist der HLS-Flow weniger abstrakt als P4, aber das Tool ist viel ausgereifter.
Einzelheiten zum Ressourcenverbrauch finden Sie in der Tabelle:
| Charakteristisch | P4/SDNet | HLS C++ |
|---|---|---|
| CLBs | 3,185 | 3,391 |
| BRAM | 22 | 0 |
| Register | 10,361 | 5,975 |
| Code-Zeilen | 206 | 1,154 |
Sie können sehen, dass HLS bei allen FPGA-Ressourcen entweder ähnlich oder besser ist. Der Quellcode benötigt zwar mehr Zeilen, aber ein Teil davon wird durch Kommentare und Formatierung beeinflusst. Es stimmt jedoch, dass eine HLS-C++-Implementierung immer mehr Codezeilen benötigt als P4. Das gilt allerdings für einen Paketparser/Klassifikator, der in den Bereich dessen fällt, was P4 beschreiben kann - HLS C++ kann mehr. HLS ist sehr universell einsetzbar und kann so ziemlich alles machen. P4 ist sehr spezialisiert.
Noch besser ist, dass jetzt, da die HLS-Implementierung existiert, jeder weitere Aufwand, sie zu modifizieren, um eine Ethernet-Protokollvariante zu verdauen, ungefähr der gleiche ist, wie die Modifikation in der P4-Sprache durchzuführen. Das liegt daran, dass unsere HLS-C++-Implementierung als eine Folge von Aufrufen von Parser-Funktionen auf niedriger Ebene strukturiert ist, die wir erstellt haben. Dieser Ansatz ist vergleichbar mit der direkten Manipulation der Laufzeitumgebung, die unter P4 läuft.
Wie bereits erwähnt, ist der Quellcode für das Loopback-Beispiel, einschließlich des Parser-Blocks, für Ultrascale++-Besitzer kostenlos über die BittWare Developer Site erhältlich. Es ist ein hervorragendes Beispiel für die Verwendung von AXI-Schnittstellen in HLS-C++-Code. Möchten Sie es sehen, haben aber keine BittWare FPGA-Karte? Setzen Sie sich mit uns in Verbindung, um zu erfahren, wo Sie sie kaufen können.
Die über Ethernet verwendeten Protokolle sind für die Hardware schwierig zu nutzen. Diese Herausforderung besteht darin, dass die Protokolle viele optionale Felder haben. Diese Optionen machen es kompliziert, z. B. den Anfang eines IP-Headers zu finden. Warum ist das so? Im Falle des IP-Headers können null, ein oder zwei VLAN-Tags davor stehen. Es können auch MPLS-Tags vorhanden sein. Daher muss die Hardware das Protokoll gerade so weit verstehen, dass sie den IP-Header findet. Die Hardware benötigt den IP-Header, um IP-Adressen zu finden, die häufig in Hardware-Filtern und -Tabellen verwendet werden. Ähnliche Probleme gibt es auch auf der nächsten Ebene, da der IP-Header selbst optionale Felder enthält.
Der HLS C++-Paketparser von BittWare kann damit umgehen:
Es wird davon ausgegangen, dass die Port-IDs in diesen IP-Protokollen zu finden sind: TCP, UDP, DCCP und STCP
Die P4-Sprache wurde entwickelt, um eine "Packet Forwarding Data Plane" (oder Netzwerk-Switch) per Software zu definieren. Die Sprache ist insbesondere mit dem Hardware-Anbieter Barefoot Networks verbunden. Die P4-Sprache unterscheidet sich von der so genannten "P4 Runtime", die von Google gefördert wird. P4 Runtime stellt eine Standard-Laufzeit-API zur Verfügung, die es ermöglicht, die Steuerungsebene von mit P4 kompilierten Lösungen zu manipulieren.
P4 macht es einfach, einen Paketklassifizierer/Parser für ein neues Protokoll zu definieren. P4 spezifiziert auch einen vollständigen Satz von Funktionen zum Nachschlagen in Tabellen und kann Pakete, die durchlaufen, umschreiben, z. B. durch Eliminierung von VLAN-Tags.
Bedeutet dies, dass die Flexibilität von P4 zur Einführung von FPGAs führen wird? Aus unserer Sicht gibt es mehrere Gründe, die gegen eine solche Entwicklung sprechen.
Es gibt kommerzielle Optionen, um eine Teilmenge von P4 auf FPGA-Hardware bereitzustellen, allerdings sind sie derzeit in ihrem Umfang begrenzt. Wie bereits erwähnt, machen es die kommerziellen Bedingungen für BittWare schwierig, diese zu nutzen, um ein Beispielprogramm zu erstellen, das wir kostenlos mit unseren Produkten anbieten können.
Es ist wichtig zu beachten, dass keine reale FPGA-Anwendung ausschließlich in P4 geschrieben werden kann. Zum Beispiel kann der Receiver Side Scaling (RSS) Block, der in einigen Beispielen auf unseren Parser folgt, nicht in P4 geschrieben werden. Mit HLS C++ können jedoch beide Blöcke oder sogar ein einziger Block, der die beiden Funktionen kombiniert, erstellt werden.
Außerdem sind die P4-Tabellennachschlagefunktionen im Grunde ein Wrapper für hardwarespezifische Laufzeitbibliotheken, die in RTL oder HLS C++ geschrieben wurden. Programmierer können solche Laufzeitbibliotheken direkt von HLS C++ aus aufrufen, ohne dass sie dafür bestraft werden.
Nachdem wir sowohl P4 als auch HLS C++ zur Implementierung eines Parsers verwendet haben, ziehen wir den HLS C++ Ansatz vor. Es ist nicht klar, dass die Nachfrage nach P4 auf FPGAs groß genug sein wird, um ein ausgereiftes Tool zu unterstützen. HLS C++ kann mehr und ist ausgereifter.
Wir hoffen, dass die Erläuterung von zwei Implementierungen eines Paketparsers auf einem FPGA, eine in der Sprache P4 und eine mit HLS C++, bei der Bewertung des richtigen Ansatzes für Sie hilfreich sind.
Ein letzter Hinweis betrifft die Portabilität zwischen unseren FPGA-Karten. Zwischen unseren Xilinx-FPGA-basierten Karten bietet HLS eine einfache Methode, bei der nur wenige, wenn überhaupt, Änderungen erforderlich sind. Für den Wechsel zu einer Intel-basierten Karte, wie z. B. unserer 520N-MX, sind Quellcode-Änderungen erforderlich, insbesondere in Bezug auf Compiler-Pragmas. Die grundlegenden Konzepte sind jedoch identisch. In beiden Fällen strukturieren wir C++ auf der Grundlage unseres Wissens über die Herausforderungen der FPGA-Übersetzung. Beliebiger C++-Code wird in einem FPGA nur sehr schlecht laufen. Allerdings funktioniert umstrukturierter und mit Pragmas gesalbter C++-Code sehr gut. Die für Xilinx oder Intel erforderlichen Änderungen sind sehr ähnlich, nur etwas anders formuliert.
Als Teil der SmartNIC Shell von BittWare hilft unser Parser den Teams, schnell mit der Entwicklung von Anwendungen zur Verarbeitung von Netzwerkpaketen auf unseren FPGA-Karten zu beginnen. Erfahren Sie mehr über SmartNIC für unsere Karten oder setzen Sie sich mit uns in Verbindung, um über Ihre Anwendungsanforderungen zu sprechen.
Das Loopback-Beispiel von BittWare setzt eine Teilmenge der SmartNIC-Shell neu ein, die wir kostenlos anbieten können. Dieser Teilsatz enthält unsere Parser-Bibliothek.
Was Sie auf dieser Seite sehen, ist ein grundlegender Überblick über den Parser, der Teil der SmartNIC Shell ist. In der vollständigen App Note für SmartNIC Shell finden Sie viele weitere Details, und das Beste ist, dass Sie sie KOSTENLOS herunterladen können! Füllen Sie das Formular aus, um Zugang zu einer PDF-Version der vollständigen App Note anzufordern.
"*" kennzeichnet Pflichtfelder
Artikel Homomorphe Verschlüsselungsbeschleunigung FPGA-Beschleunigung ermöglicht diese einzigartige Lösung, die es erlaubt, mit verschlüsselten Daten zu rechnen, ohne sie zu entschlüsseln oder Schlüssel weiterzugeben Traditionelle Verschlüsselung begrenzt die Verschlüsselung
White Paper Einführung in die SmartNIC Shell von BittWare für die Verarbeitung von Netzwerkpaketen Übersicht Die SmartNIC Shell ist eine vollständig funktionierende Netzwerkkarte, die auf einem BittWare
BittWare On-Demand Webinar Using Intel® oneAPI™ to Achieve High-Performance Compute Acceleration with FPGAs Begleiten Sie BittWare und Intel bei der Betrachtung von oneAPI™ mit einem Schwerpunkt auf
PCIe-FPGA-Karte 520R-MX Stratix 10 FPGA-Karte mit HBM2 und optischem Eingang mit 480 Gbps Optimiert für Sensorverarbeitungsanwendungen mit massiven Anforderungen an die Datenerfassung in Echtzeit
