-
Der hierin beschriebene Gegenstand bezieht sich auf die Anpassung von Verarbeitungspipelinesoftware und/oder -vorrichtungen. Insbesondere bezieht sich der hierin beschriebene Gegenstand auf Verfahren, Systeme und computerlesbare Medien zum Anpassen einer Datenebenenpipelineverarbeitung unter Verwendung von Berkeley-Paketfilter-(BPF)-Hakeneintrittspunkten.
-
Gegenwärtig werden softwarebasierte Netzwerk-Paket-Broker (NPBs, Network Packet Brokers) und Netzwerkdatenverkehrsgeneratoren häufig in unterschiedlichen Kommunikationsnetzwerkumgebungen eingesetzt (z. B. Testumgebungen und Echtzeitnetzwerkumgebungen). Bei einigen Implementierungen können diese NPBs und Datenverkehrsgeneratoren in Software als Datenebenenpipelines mit konfigurierbaren Elementen modelliert werden. Das grundlegende Design der Datenebenenpipelines, die dazu verwendet werden, die NPBs und/oder Netzwerkdatenverkehrsgeneratoren zu implementieren, kann größtenteils als Statisches-Modell-Design charakterisiert werden. Während ein Benutzer oder Operator das Verhalten der Netzwerkelemente vor dem Einsatz der Pipeline steuern kann, ist der Benutzer/Operator typischerweise darauf beschränkt, vorgegebene Konfigurationssteuerungen zu nutzen, die durch Begrenzungen eingeschränkt werden, welche durch den Softwarehersteller festgelegt werden. Insbesondere ist es dem Benutzer oder Operator nicht gestattet, die normale Konfigurationsschnittstelle zu nutzen, um neue Arten von angepassten Elementen zu erzeugen und in die Pipeline einzufügen, um neue Verhaltensweisen und/oder Merkmale abzuleiten, die durch die Datenebenenpipeline ausgeführt werden.
-
Im Hinblick auf diese und weitere Schwierigkeiten besteht eine Bedarf nach Verfahren, Systemen und computerlesbaren Medien, die eine Datenebenenpipelineverarbeitung unter Verwendung von BPF-Hakeneintrittspunkten anpassen.
-
Die Aufgabe der vorliegenden Erfindung besteht darin, ein Verfahren zum Anpassen einer Datenebenenpipelineverarbeitung, um Testpakete zu erzeugen, unter Verwendung von Berkeley-Paketfilter-(BPF)-Hakeneintrittspunkten sowie ein System zum Implementieren des Verfahrens mit verbesserten Charakteristika zu schaffen.
-
Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 und ein System gemäß Anspruch 11 gelöst.
-
Hier ist ein Verfahren zum Anpassen einer Datenebenenpipelineverarbeitung unter Verwendung von Berkeley-Paketfilter-(BPF)-Hakeneintrittspunkten beschrieben. Das Verfahren umfasst: Empfangen eines Programmcodeskripts zum Anpassen einer Leistung einer oder mehrerer Stufen einer mehrstufigen Verarbeitungspipelineplattform, die dazu konfiguriert ist, einen Netzwerkoperationsprozess auszuführen, wobei die mehrstufige Verarbeitungspipelineplattform einen oder mehrere vordefinierte Hakeneintrittspunkte umfasst, und Kompilieren des Programmcodeskripts, um eine angepasste Plug-in-Komponente zu erzeugen, die in zumindest einem des einen oder der mehreren vordefinierten Hakeneintrittspunkte der mehrstufigen Verarbeitungspipelineplattform angewendet wird. Das Verfahren umfasst ferner: Initiieren einer Ausführung der angepassten Plug-in-Komponente ansprechend auf eine Auslösung des zumindest einen des einen oder der mehreren vordefinierten Hakeneintrittspunkte eines Stufenelements der mehrstufigen Verarbeitungspipelineplattform, wobei die Ausführung der angepassten Plug-in-Komponente zumindest ein Merkmal des Netzwerkoperationsprozesses auf dynamische Weise während der Laufzeit konfiguriert.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Verfahrens ist der Netzwerkoperationsprozess ein Testpaketerzeugungsprozess.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Verfahrens weist das Verfahren ferner ein Senden von Testpaketen, die während des Netzwerkoperationsprozesses erzeugt werden, zu einem zu testenden System (SUT = System Under Test) gemäß dem zumindest einen Merkmal auf.
-
Gemäß einem weiteren Aspekt des hierin beschriebenen Verfahrens umfasst das Verfahren: Interpretieren, durch eine Orchestrierungssteuerung, eines deklarativen Datenmodells, das repräsentativ ist für die mehrstufige Verarbeitungspipelineplattform und das die angepasste Plug-in-Komponente umfasst, die in die mehrstufige Verarbeitungspipelineplattform eingefügt ist.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Verfahrens ist der Netzwerkoperationsprozess ein Paketüberwachungsoperationsprozess.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Verfahrens umfasst das Verfahren ferner: Senden eines oder mehrerer Pakete gemäß dem zumindest einen Merkmal des Paketüberwachungsoperationsprozesses.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Verfahrens umfasst das Konfigurieren des zumindest einen Merkmals des Paketüberwachungsoperationsprozesses ein Anwenden einer Beeinträchtigung auf ein beobachtetes Paket, das durch die mehrstufige Verarbeitungspipelineplattform gesendet wird.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Verfahrens wird die angepasste Plug-in-Komponente als kompilierter Code, der in einer virtuellen BPF-Maschine läuft, als kompilierter Code, der in einer Hardware-Komponente läuft, als BPF-Code, der in nativen Maschinencode vorkompiliert ist, welcher auf einer zentralen Verarbeitungseinheit (CPU = Central Processing Unit) läuft, oder als bedarfssynchron-(JIT, Just-In-Time)-kompilierter Code ausgeführt, der auf einer CPU abläuft.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Verfahrens umfasst das Konfigurieren zumindest eines Merkmals des Testpaketerzeugungsprozesses ein Anpassen von benutzerdefinierten Feldern (UDF, User Defined Fields), Nutzdaten (bzw. Payloads) oder Zählern in den erzeugten Testpaketen.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Verfahrens löst die Ausführung einer Ereignisstruktur in der angepassten Plug-in-Komponente die Ausführung einer zweiten angepassten Plug-in-Komponente aus.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Verfahrens implementiert ein Element der angepassten Plug-in-Komponente eine Anwendungsprogrammierschnittstelle (API, Application Programming Interface), um mit einem Systemelement zu kommunizieren, das sich außerhalb der mehrstufigen Verarbeitungspipelineplattform befindet.
-
Ein System zum Anpassen einer Datenebenenpipelineverarbeitung, um Testpakete unter Verwendung von BPF-Hakeneintrittspunkten zu erzeugen, ist offenbart. Ein System weist Folgendes auf: einen Prozessor zum Ausführen einer mehrstufigen Verarbeitungspipelineplattform, die zum Ausführen von Netzwerkoperationsprozessen konfiguriert ist, und eine Behälterkomponente, die dazu konfiguriert ist, angepasste Plug-in-Komponente zu speichern, die gestaltet sind, um eine Leistung der mehrstufigen Verarbeitungspipelineplattform zu modifizieren. Das System umfasst ferner eine Mehrzahl von Verarbeitungspipeline-Stufenelementen der mehrstufigen Verarbeitungspipeline, wobei zumindest eines der Mehrzahl von Verarbeitungspipeline-Stufenelementen einen Hakeneintrittspunkt umfasst, der eine Ausführung zumindest einer der angepassten Plug-in-Komponenten auslöst, die zumindest ein Merkmal des Netzwerkoperationsprozesses während der Laufzeit auf dynamische Weise konfiguriert.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Systems ist der Netzwerkoperationsprozess ein Testpaketerzeugungsprozess.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Systems umfasst das System einen Sende-Port zum Senden von Testpaketen, die während des Netzwerkoperationsprozesses erzeugt werden, zu einem SUT gemäß dem zumindest einen Merkmal auf.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Systems umfasst das System eine Orchestrierungssteuerung, die dazu konfiguriert ist, ein deklaratives Datenmodell zu interpretieren, das repräsentativ ist für die mehrstufige Verarbeitungspipelineplattform und das die angepasste Plug-in-Komponente umfasst, die in die mehrstufige Verarbeitungspipelineplattform eingefügt ist.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Systems ist der Netzwerkoperationsprozess ein Paketüberwachungsoperationsprozess.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Systems umfasst das System einen Sende-Port zum Senden eines oder mehrerer Pakete gemäß dem zumindest einen Merkmal des Paketüberwachungsoperationsprozesses.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Systems ist die angepasste Plug-in-Komponente konfiguriert zum Anwenden einer Beeinträchtigung auf ein beobachtetes Paket, das durch die mehrstufige Verarbeitungspipelineplattform gesendet wird.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Systems löst eine Ausführung einer Ereignisstruktur in der angepassten Plug-in-Komponente die Ausführung einer zweiten angepassten Plug-in-Komponente aus.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Systems umfasst der Prozessor eine zentrale Verarbeitungseinheit (CPU, Central Processing Unit), ein feldprogrammierbares Gatterarray (FPGA, Field-Programmable Gate Array) oder eine anwendungsspezifische integrierte Schaltung (ASIC, Application Specific Integrated Circuit).
-
Gemäß einem anderen Aspekt des hierin beschriebenen Systems implementiert ein Element der angepassten Plug-in-Komponente eine Anwendungsprogrammierschnittstelle (API, Application Programming Interface), um mit einem Systemelement zu kommunizieren, das sich außerhalb der mehrstufigen Verarbeitungspipelineplattform befindet.
-
Gemäß einem anderen Aspekt des hierin beschriebenen Systems wird die angepasste Plug-in-Komponente als kompilierter Code, der in einer virtuellen BPF-Maschine läuft, als kompilierter Code, der in einer Hardware-Komponente läuft, als BPF-Code, der in nativen Maschinencode vorkompiliert ist, welcher auf einer zentralen Verarbeitungseinheit (CPU = Central Processing Unit) läuft, oder als bedarfssynchron-(JIT, Just-ln-Time)-kompilierter Code ausgeführt, der auf einer CPU abläuft.
-
Der hierin beschriebene Gegenstand kann in Hardware, Software, Firmware oder in jeglicher Kombination daraus implementiert werden. So beziehen sich die hierin verwendeten Begriffe „Funktion“, „Knoten“ oder „Modul“ auf Hardware, was auch Software- und/oder Firmware-Komponenten umfassen kann, zum Implementieren des beschriebenen Merkmals. Bei einer exemplarischen Implementierung kann der hierin beschriebene Gegenstand unter Verwendung eines computerlesbaren Mediums implementiert werden, auf dem computerausführbare Anweisungen gespeichert sind, die bei Ausführung durch den Prozessor eines Computers den Computer dahingehend steuern, Schritte auszuführen. Exemplarische computerlesbare Medien, die geeignet sind zum Implementieren des hierin beschriebenen Gegenstands, umfassen nichtflüchtige computerlesbare Medien, wie etwa Plattenspeichervorrichtungen, Chipspeichervorrichtungen, programmierbare Logikvorrichtungen und anwendungsspezifische integrierte Schaltungen. Zusätzlich dazu kann sich ein den hierin beschriebenen Gegenstand implementierendes computerlesbares Medium auf einer einzelnen Vorrichtung oder Rechenplattform befinden oder kann über mehrere Vorrichtungen oder Rechenplattformen verteilt sein.
-
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
- 1 ein Blockdiagramm, das ein exemplarisches System zum Anpassen einer Datenebenenpipelineverarbeitung unter Verwendung von BPF-Hakeneintrittspunkten veranschaulicht;
- 2 ein Flussdiagramm, das einen exemplarischen Prozess zum Anpassen einer Datenebenenpipelineverarbeitung zum Erzeugen von Paketdatenverkehr unter Verwendung von BPF-Hakeneintrittspunkten veranschaulicht; und
- 3 ein Flussdiagramm, das einen exemplarischen Prozess zum Anpassen einer Datenebenenpipelineverarbeitung unter Verwendung von BPF-Hakeneintrittspunkten veranschaulicht.
-
Der hierin beschriebene Gegenstand umfasst Verfahren, Systeme und computerlesbare Medien zum Anpassen einer Datenebenenpipelineverarbeitung unter Verwendung von Berkeley-Paketfilter-(BPF)-Hakeneintrittspunkten. Der hierin beschriebene Gegenstand bezieht sich auf mehrere Schwierigkeiten, die für gewöhnlich mit Verarbeitungspipeline-Anpassungen in Verbindung stehen. Im Einzelnen bezieht sich der offenbarte Gegenstand darauf, i) wie eine softwarebasierte Pipelineplattform mehr benutzerdefinierte Anpassung ermöglichen kann, ii) wie neue angepasste Plug-in-Komponenten in einem bestehenden Plattform-Rahmenwerk instanziiert, konfiguriert, überwacht und gesteuert werden können, iii) wie Arbeitsabläufe erzeugt werden können, um die Erzeugung und Nutzung von angepassten Plug-in-Komponenten zu erleichtern (z. B. angepasste BPF-Codekomponenten), iv) wie eine graphische Benutzerschnittstelle (GUI, Graphical User Interface) die angepassten Plug-in-Komponenten nutzen kann, und v) wie Benutzer schnell bestimmen können, ob eine angepasste Plug-in-Komponente kompiliert und/oder leistungsfähig ist.
-
Um diese Probleme zu lösen, umfasst der hierin beschriebene Gegenstand ein System, das es Benutzern ermöglicht, neue Arten von softwarebasierten angepassten Plug-in-Komponenten zu erzeugen, die in Anbringungspunkte (z. B. BPF-Hakeneintrittspunkte) eingefügt werden können, die in einer Pipelineplattform bestehen. Im Einzelnen stellen die angepassten Plug-in-Komponenten einen Mechanismus für einen Benutzer bereit, um das Verfahren einer zugrundeliegenden mehrstufigen Verarbeitungspipelineplattform während der Laufzeit zu modifizieren (ohne den Quellcode der Pipelineplattform rekompilieren zu müssen). Wie hierin verwendet, kann eine angepasste Plug-in-Komponente ein kurzes benutzerspezifiziertes Skript aus Programmiercode (z. B. geschrieben in C, P4 oder einer anderen Programmiersprache) umfassen, das dahingehend zugeschnitten ist, eine einzigartige Aufgabe auszuführen, die nicht ursprünglich durch die feste Pipelineplattform ermöglicht wird. Bei einigen Ausführungsbeispielen kann der Benutzer BPF dazu verwenden, den zugrundeliegenden Code der angepassten Plug-in-Komponente in einer übergeordneten Sprache zu schreiben und/oder zu erzeugen. Das Quellcodeskript kann dann durch eine lokale Kompilierkomponente (z. B. eine Komponente einer BPF-Kompilierer-Sammlung-(BCC, BPF Compiler Collection)-Werkzeugkette und/oder P4-Werkzeugkette) zum Einsatz in der Verarbeitungspipelineplattform in Bytecode (z. B. eine synthetische Maschinensprache) kompiliert werden.
-
Bei einigen Ausführungsbeispielen sind spezifische Punkte in einer mehrstufigen Verarbeitungspipelineplattform als Anbringungspunkte definiert oder bezeichnet, die eine Endbenutzeranpassung ermöglichen können. Die spezifischen Anbringungspunkte oder „Hakeneintrittspunkte“ (bzw. Hook Entry Points) können sich in Benutzerraum-Code oder Kernelbasiertem Code (z. B. in einem Linux-Kernel) befinden. Im Einzelnen kann der offenbarte Gegenstand durch einen Endbenutzer dazu verwendet werden, neue Hakeneintrittspunkte in der mehrstufigen Verarbeitungspipelineplattform zu erzeugen und einzusetzen. Alternativ kann der Endbenutzer bestehende Hakeneintrittspunkte identifizieren, die verbessert werden können. Bei einigen Ausführungsbeispielen sind die Anbringungspunkte BPF-Hakeneintrittspunkte.
-
Wie hierin verwendet, bezieht sich BPF auf eine Technologie, die in Computerbetriebssystem-Kerneln (z. B. Linux-Kernel) dazu verwendet wird, Anwendungsprogramme zu verwalten und zu koordinieren, welche Netzwerkpaketdatenverkehr analysieren. Beispielsweise kann BPF nützliche Werkzeuge zur Eindringungsdetektionsanalyse in Netzwerksichtbarkeitsplattformen bereitstellen, etwa einem Netzwerkpaket-Broker (NPB). Im Einzelnen kann BPF-basierte Filterung dazu verwendet werden, große Paketerfassungen schnell auf einen kleineren Satz von Ergebnissen zu reduzieren, indem ein Filterprozess ausgeführt wird, der auf einer spezifischen Art von Netzwerkdatenverkehr basiert. BPF kann auch Funktionalitäten zur Paketdatenverkehrserzeugung und/oder -analyse für softwarebasierte Netzwerktestvorrichtungen bereitstellen. Zusätzlich dazu wird BPF ferner als Sammelbegriff verwendet, der erweiterte Berkeley-Paketfilter (eBPF) einschließt, die später ausführlich besprochen werden.
-
Bei einigen Ausführungsbeispielen ermöglicht ein BPF-Filtermechanismus es einem Benutzer, Programmiercode in einem Teilsatz der C-Programmiersprache oder anderen übergeordneten Programmiersprachen zu schreiben. Nach dem Schreiben wird der C-basierte Quellcode durch eine Steuerkomponente empfangen, die den Quellcode an eine Kompiliererkomponente weiterleiten kann, welche dazu konfiguriert ist, den Quellcode in Bytecode zu kompilieren und/oder zu transpilieren. Nach dem Kompilieren kann der Bytecode durch den Kernel der Betriebssystem-(OS, Operating System)-Software des Benutzers ausgeführt werden (z. B. interpretativ laufen). Alternativ dazu kann der Bytecode stattdessen in „eBPF“-Bytecode durch einen betriebssynchronen (JIT, Just In Time-) Kompilierer in dem Kernel rekompiliert werden, um ein Format zu erhalten, das mit der nativen Architektur (z. B. x86, ARM, usw.) kompatibel ist. In einigen Fällen führt der JIT-Kompilierer auch eine Verifizierung des Bytecodes aus, um einen Schutz für den Linux-Kernel bereitzustellen und dessen Sicherheit sicherzustellen. Ferner kann der Bytecode durch den JIT-Kompilierer vorab kompiliert werden, um schnellere Installationen zu ermöglichen.
-
Nach dem Ausführen des Kompilierprozesses installiert der Kernel den kompilierten Code (z. B. angepasste Plug-in-Komponenten) in einem Softwareprogramm-Anbringungspunkt, d. h. ein (z. B. durch den Plattform-Provider) kuratierter/beworbener „Hakeneintrittspunkt“, der durch den Operator ausgewählt wird. Der Hakeneintrittspunkt kann einen Funktionsaufruf umfassen, der den Code spezifiziert, der an der Stelle ausgelöst wird. Beispielsweise kann der Hakeneintrittspunkt einen Auslöser für einen Benutzerraum-Funktionsaufruf, einen Kernel-Funktionsaufruf, einen Kernel-Systemaufruf, ein eXpress-Data-Path-(XDP)-Socket-Ereignis, ein Linux-Datenverkehrssteuerungs-(TC, Traffic Controller)-Socket-Ereignis oder dergleichen spezifizieren. Im Einzelnen können die angepassten Plug-in-Komponenten auch diese Arten von Funktionsaufrufen umfassen, die durch den Hakeneintrittspunkt zu aktivieren sind (wie später ausführlich beschrieben wird).
-
Bei einigen Ausführungsbeispielen kann eine angepasste Plug-in-Komponente eine oder mehrere Ereignisstrukturen umfassen, welche BPF-unterstützte Benutzerraum- und/oder Kernel-Raum-Strukturen (z. B. Karten, Ereignis-Ströme, perf-Ströme) umfassen können. Beispielsweise können die Karten (bzw. Maps) und andere Ereignisstrukturen durch die angepasste Plug-in-Komponente dazu verwendet werden, mit dem externen Benutzerraum-Programm zu interagieren. Der Endbenutzer-Operator kann auf diese Ereignisstrukturen in den angepassten Plug-in-Komponenten unter Verwendung von nativen Linux-Verfahren zugreifen, darunter BPF-Bibliotheken und/oder das Linux-Dateisystem. Die Installation einer angepassten Plug-in-Komponente in einen Hakeneintrittspunkt hat einen performanten und tief eingebetteten benutzerdefinierten Code zur Folge. Beispielsweise kann die angepasste Plug-in-Komponente zum Sondieren, Nachverfolgen, Paketfiltern, Lastausgleichen und jegliche andere Anzahl von Zwecken verwendet werden. Die Erzeugung und Nutzung der zuvor erwähnten angepassten Plug-in-Komponenten werden später ausführlich beschrieben. Beispielsweise kann die angepasste Plug-in-Komponente dazu verwendet werden, benutzerdefinierte Felder (UDF, User Defined Fields), Nutzdaten (bzw. Playloads) oder Zähler in den Testpaketen zu modifizieren. Wie hierin verwendet, bezieht sich UDF auf die Implementierung von benutzerdefinierten Paket-Kopfzeilen, Nutzdaten-Feldern oder von anderen angepassten Paketinhalten oder -definitionen, die durch einen Benutzer oder Operator angepasst werden können.
-
1 ist ein Blockdiagramm eines Systems zum Anpassen einer Datenebenenpipelineverarbeitung unter Verwendung von BPF-Hakeneintrittspunkten. Unter Bezugnahme auf 1 kann eine Verarbeitungspipelineplattform 100 jedes geeignete programmierbare Datenbank-Pipeline-System sein. Im Einzelnen kann eine Pipelineplattform 100 als Softwarekomponenten und/oder eine oder mehrere Hardware-Vorrichtungen implementiert sein. Bei einem Beispiel kann eine Pipelineplattform 100 eine Netzwerksichtbarkeitsplattform, etwa ein Netzwerkpaket-Broker, oder eine Netzwerktestplattform sein, etwa ein Datenverkehrsgenerator. Obwohl eine softwarebasierte Paketerzeugungsplattform im Folgenden weitgehend als Beispiel beschrieben ist, ist es beabsichtigt, dass jede Art von Verarbeitungspipelineplattform (z. B. eine hardwarebasierte Verarbeitungspipelineplattform) in dem Schutzumfang des hierin beschriebenen Gegenstands liegt. Beispielsweise kann eine in 1 gezeigte Pipelineplattform 100 auch dazu konfiguriert sein, Pakete zu empfangen, zusätzlich zu oder anstatt der Erzeugung/Aussendung von Paketen. Im Einzelnen kann die Pipelineplattform ein Netzwerkschnittstellenelement (z. B. Schnittstellenelement 152) umfassen, das auf bidirektionale Weise arbeitet (z. B. konfiguriert für einen Tx- oder Rx-Paketfluss). Bei einigen Ausführungsbeispielen kann das Netzwerkschnittstellenelement einen oder mehrere zusammengefasste Baublöcke aufweisen, um eine beliebige Anzahl von Sende- und/oder Empfangspipelines zu unterstützen.
-
Wie in 1 gezeigt ist, kann die Verarbeitungspipelineplattform 100 eine Softwarepaketerzeugerkomponente 102 und eine Betriebssystem-(OS, Operating System)-Softwarekomponente 104 umfassen. Eine OS-Softwarekomponente 104 kann eine Softwarekomponente eines Drittanbieters oder eine quelloffene (bzw. Open-Source-) Softwarekomponente umfassen. Im Einzelnen kann eine Paketerzeugerkomponente 102 eine Mehrzahl von festen Funktionsblöcken 122-130 (z. B. bestehende feste Blöcke aus Code) umfassen, von denen jeder einen oder mehrere BPF-Hakeneintrittspunkte umfasst (z. B. siehe exemplarische Hakeneintrittspunkte 161-166 in 1). Die Hakeneintrittspunkte, die in den festen Funktionsblöcken enthalten sind, werden kuratiert und/oder gegenüber dem Endbenutzer als mögliche Punkte zur Anpassung beworben.
-
Gleichermaßen kann eine OS-Softwarekomponente 104 in einer Pipelineplattform 100 auch eine Anzahl von Systemkomponenten enthalten, darunter Vorrichtungstreiber 140 für den Benutzerraum, Vorrichtungstreiber 142 für den Kernel-Raum, und einen Kernel mit einer oder mehreren unterschiedlichen Bibliotheken 144. Im Einzelnen können die Vorrichtungstreiber 140 und 142 und der Kernel (und Bibliotheken) 144 Hakeneintrittspunkte (z. B. den Hakeneintrittspunkt 165) umfassen. Jedoch sind diese Hakeneintrittspunkte in den OS-Komponenten für gewöhnlich in Linux eingebaut und können Nachverfolgungs- oder Sondierungsfunktionalitäten für Endbenutzer bereitstellen. Ferner kann eine OS-Softwarekomponente 104 ein Netzwerkschnittstellenelement 152 umfassen, das dazu konfiguriert ist, Testnetzwerkpakete oder Echtzeitnetzwerkpakete zu senden oder zu empfangen. Das Netzwerkschnittstellenelement 152 kann entweder eine physische Hardware-Vorrichtung oder eine virtuelle Schnittstellenkomponente sein. Bei einigen Ausführungsbeispieten können die Hakeneintrittspunkte für die Anpassung einer lokalen Anwendung verwendet werden (jedoch nicht notwendigerweise durch den offenbarten Gegenstand kuratiert). Der Kernel 144 und die OS-Komponente 104 können in einem Speicher gespeichert werden und durch einen oder mehrere Prozessoren einer Host-Rechenvorrichtung ausgeführt werden (z. B. siehe 2). Im Einzelnen kann die Host-Rechenvorrichtung eine alleinstehende Rechenvorrichtung, eine Host-Rechenkomponente sein, die zwischen einem oder mehreren Rechenkomponenten in einem Rechen-Cloud-Netzwerk verteilt ist, oder kann durch eine oder mehrere virtuelle Maschinen verkörpert werden.
-
2 ist ein Diagramm, das eine beispielhafte Host-Rechenvorrichtung 200 veranschaulicht, die dazu konfiguriert ist, eine mehrstufige Programmierpipelineplattform (z. B. die in 1 gezeigte Pipelineplattform 100) zu hosten. Die Host-Rechenvorrichtung 200 kann jede geeignete Entität oder alle geeigneten Entitäten (z. B. ein oder mehrere Knoten, Vorrichtungen oder Rechenplattformen) zum Ausführen unterschiedlicher Aspekte repräsentieren, die mit der Anpassung einer Datenebenenpipelineverarbeitung, um Testpakete zu erzeugen, unter Verwendung von einem Berkeley-Paketfilter-(BPF)-Hakeneintrittspunkt in Verbindung stehen. Bei einigen Ausführungsbeispielen kann die Host-Rechenvorrichtung 200 dazu konfiguriert sein, eine beliebige Anzahl von Netzwerkvorrichtungen oder Testmerkmalen bereitzustellen, etwa eine Testpaketerzeugungsfunktionalität oder eine Netzwerkpaket-Broker-Funktionalität.
-
Wie gezeigt ist, kann die Host-Rechenvorrichtung 200 zumindest einen Prozessor 202 und einen Speicher 204 umfassen. Der bzw. die Prozessoren 202 kann bzw. können jede Verarbeitungsvorrichtung umfassen, etwa eine zentrale Verarbeitungseinheit (CPU, Central Processing Unit), eine Mikrosteuerung, einen Mikroprozessor, einen eingebetteten Prozessor oder dergleichen. Der Speicher 204 kann Plattenspeichervorrichtungen, Chip-Speichervorrichtungen, programmierbare Logikvorrichtungen und anwendungsspezifische integrierte Schaltungen umfassen. Bei einigen Ausführungsbeispielen kann der Speicher 204 dazu verwendet werden, ein Betriebssystem 206 zu speichern, das ferner einen Kernel 208 (z. B. einen Linux-Kernel) umfasst. Im Einzelnen kann der Kernel 208 dazu verwendet werden, die hierin beschriebenen angepassten Plug-in-Komponenten sowie Pipelineplattformen auszuführen, etwa die in 1 veranschaulichte Pipelineplattform 100.
-
Die Host-Rechenvorrichtung 200 kann auch einen Behälter 210 aufweisen, der ein beliebiges Speichermedium umfassen kann, das dazu konfiguriert ist, angepasste Plug-in-Komponenten zu speichern und zu behalten. Im Einzelnen kann der Behälter 210 einen Plug-in-Speicher umfassen, der dazu verwendet wird, angepasste Plug-in-Komponenten zu speichern, die durch Endbenutzer erzeugt werden. Dieser Behälter 210 kann auch dazu verwendet werden, vorab vorgehaltene angepasste Plug-in-Komponenten zu speichern. Ferner kann der Behälter 210 dazu konfiguriert sein, Benutzerraum-Anwendungen zu speichern, die mit den angepassten Plug-in-Komponenten zusammenwirken.
-
Wie hierin verwendet, ist der Benutzerraum eine Menge von Positionen, wo normale Nutzeranwendungsprozesse ablaufen (z. B. alle Prozesse außer der Kernel). Beispielsweise können externe Anwendungen, die dazu konfiguriert sind, Statistiken zu sammeln oder Ereignisse zu berichten, in dem Benutzerraum ablaufen. Gleichermaßen besteht die Rolle des Kernels darin, Anwendungen, die in dem Benutzerraum laufen, zu verwalten und zu koordinieren (z. B. um zu verhindern, dass die verwalteten Anwendungen einander und die Host-Maschine stören). Der Kernelraum, wie hierin verwendet, bezieht sich auf eine Position, wo der Softwarecode oder Skripte des Kernels gespeichert sind und ausgeführt werden.
-
Unter erneuter Bezugnahme auf 1 können die festen Funktionsblöcke 122-130 der Paketgeneratorkomponente 102 und die Komponenten der OS-Softwarekomponente 104 direkt oder über eine oder mehrere der angepassten Plug-in-Komponenten 132-138 kommunikativ gekoppelt sein, um eine Pipelinekette zu bilden. Im Einzelnen können neue angepasste Plug-in-Komponenten zum Einsatz in der Verarbeitungspipelineplattform 100 durch Plattformsystemkomponenten erzeugt werden, darunter eine Steuerkomponente 112, eine Kompiliererkomponente 116 (z. B. BCC-/P4-Werkzeugketten-Komponente) und/oder eine GUI-Komponente 118. Beispiele von angepassten Plug-in-Komponenten 132-138 umfassen BPF-Sonden oder BPF-Tracer.
-
Bei einigen Ausführungsbeispielen weisen die angepassten Plug-in-Komponenten Beeinträchtigungs-Plug-ins auf. Im Einzelnen kann eine angepasste Plug-in-Komponente eine Softwarecode-Komponente umfassen, die mit der Anwendung einer netzwerkbasierten und/oder testbasierten Beeinträchtigung, etwa mit einer Zeitverzögerung, einem Paketabfall, einem Paketfehler, usw., auf ein gesendetes Paket in Verbindung steht. Solche Beeinträchtigungsoperationen können an einigen oder allen Paketen ausgeführt werden, die durch die Pipelineplattform 100 gesendet oder erzeugt werden. Bei einigen Ausführungsbeispielen kann ein Benutzer oder Operator eine benutzerdefinierte Beeinträchtigungsoperation definieren und/oder erzeugen, die auf die gesendeten und/oder erzeugten Pakete anzuwenden ist. Insbesondere kann die benutzerdefinierte Beeinträchtigungsoperation gespeichert werden und daraufhin während der Laufzeit implementiert werden als angepasste Plug-in-Komponente. Ferner können mehrere Beeinträchtigungs-Plug-ins in einem Plug-in-Behälter (z. B. dem Behälter 210 in 2) definiert und gespeichert werden, auf den die Pipelineplattform 100 (z. B. ein programmierbares Datenebenen-Prozessor-basiertes Überwachungssystem) zugreift und der durch sie während der Laufzeit angewendet wird.
-
Wie in 1 gezeigt ist, kann ein Quellcodeskript, etwa ein BPF-C-Code-Skript 106 und/oder ein BPF-P4-Code-Skript 108 durch einen Endbenutzer unter Verwendung von BPF geschrieben werden. Bei einigen Ausführungsbeispielen wird das Quellcodeskript unter Verwendung einer Benutzerraum-Anwendung geschrieben, die dazu konfiguriert ist, den Code als Inline-Text einzubetten (der in einem Befehl kompiliert und geladen werden kann). Nach der Erzeugung/nach dem Schreiben wird der Steuerkomponente 112 das Codeskript als Quellcodeskript-Eingang 110 bereitgestellt, was deklarative Datenmodellinformationen umfasst. Im Einzelnen kann der Quellcodeskript-Eingang 110 ein Datenmodell umfassen, das die Konfiguration fester Funktionsblöcke herstellt oder bezeichnet. Zusätzlich dazu kann der Quellcodeskript-Eingang 110 die angepassten Plug-in-Komponenten (die schließlich erzeugt werden) über eine Inline-Deklaration oder durch Referenz (z. B. ein Dateiname oder ein URL, der auf eine entfernt gespeicherte Datei verweist) in Bezug auf zugeordnete Dateien deklarieren. Bei einigen Ausführungsbeispielen sind die Topologiedaten und Skriptinhalte, die in dem Quellcodeskript-Eingang 110 enthalten sind, alle deklarativ und/oder modellbasiert. Bei einigen Ausführungsbeispielen kann eine Orchestrierungssteuerung (z. B. die Steuerungskomponente 112) dazu konfiguriert sein, ein deklaratives Datenmodell zu interpretieren, das repräsentativ ist für die mehrstufige Verarbeitungspipelineplattform und das die zumindest eine der angepassten Plug-in-Komponenten umfasst, die in die mehrstufige Verarbeitungspipelineplattform eingeführt wird. Beispielsweise kann die Steuerungskomponente 112 dazu konfiguriert sein, ein deklaratives Datenmodell zu interpretieren, das sich auf die Verarbeitungspipelineplattform 100 bezieht, darunter eingebetteter oder referenzierter benutzerdefinierter Code (P4, eBPF, usw.), der in die Pipelineplattform eingeführt werden kann.
-
Nach dem Empfangen des Quellcodeskript-Eingangs 110 ist die Steuerungskomponente 112 dazu konfiguriert, das Programmiercode-Skript zu parsen, um die Erzeugung der zugeordneten angepassten Plug-in-Komponenten zu initiieren und zu koordinieren. Beispielsweise ist die Steuerungskomponente 112 dazu konfiguriert, den Quellcodeskript-Eingang 110 an eine Kompiliererkomponente 116 zur Verarbeitung weiterzuleiten. Bei einigen Ausführungsbeispielen umfasst die Kompiliererkomponente 116 einen BCC-Werkzeugketten-Kompilierer, einen P4-Werkzeugketten-Kompilierer, einen Clang-Kompilierer und/oder einen LLVM-Kompilierer. Im Einzelnen kann die Kompiliererkomponente 116 den Quellcodeskript-Eingang 110 dahingehend kompilieren, BPF-Bytecode als Ausgang zu produzieren. in einigen Fällen kann der BPF-Bytecode vorkompiliert werden oder kann in dem Kernel unter Verwendung anderer Techniken geladen/angebracht werden (z. B. Linux-Da-tenverkehrssteuerung-(TC)-Queuing-Discipline (qdisc)).
-
Bei einigen Ausführungsbeispielen kann die Kompiliererkomponente 116 dazu konfiguriert sein, den Quellcodeskript-Eingang 110 in einen erweiterten BPF-(eBPF bzw. extended BPF)-Bytecode zu kompilieren, der mit Virtuelle-Maschine-Komponenten in einer Pipelineplattform 100 kompatibel ist und/oder durch diese nutzbar ist. Sobald derselbe durch die Kompiliererkomponente 116 kompiliert ist, kann der eBPF-Bytecode in den Kernel geladen werden. Bei einigen Ausführungsbeispielen führt der Kernel zuerst einen automatischen verpflichtenden Bytecode-Verifizierungsprozess aus. Im Einzelnen wird nur kompilierter eBPF-Bytecode akzeptiert, bei dem bestimmt wird, dass er sicher ist. Der eBPF-Bytecode kann durch den Kernel auf interpretative Weise ausgeführt werden (z. B. ähnlich zu einer virtuellen Java-Maschine). Alternativ dazu kann der Kernel einen bedarfssynchronen (Just-In-Time bzw. JIT-) Kompilierer verwenden, um den eBPF-Bytecode in nativen Maschinencode (z. B. x86, ARM, und dergleichen) zur vollen Leistung zu transpilieren und/oder kompilieren.
-
Sobald der Kernel den eBPF-Bytecode kompiliert hat, kann der Kernel damit beginnen, die angepassten Plug-in-Komponenten auf der Basis des kompilierten eBPF-Codes (oder Maschinencode) zu instanziieren und die Komponenten in die Pipelineplattform einzubringen. Beispielsweise kann der Kernel eine oder mehrere angepasste Plug-in-Komponenten an ein Ereignis anhängen, etwa an ein Sondierungsereignis, ein Nachverfolgungsereignis, ein Socket, einen Systemaufruf und dergleichen. Bei einigen Ausführungsbeispielen kann der Kernel 114 und/oder die Kompiliererkomponente 116 dazu konfiguriert sein, die angepassten Plug-in-Komponenten dynamisch in die Pipelineplattform einzufügen. Die angepassten Plug-in-Komponenten können Funktionsaufrufe umfassen, auf die zugegriffen wird, wenn feste Funktionsblöcke von der Paketgeneratorkomponente 102 ausgeführt werden. Im Einzelnen spezifizieren die Funktionsaufrufe, die in den Hakeneintrittspunkten der festen Funktionsblöcke enthalten sind, die angepassten Plug-in-Komponenten, die ausgelöst werden. Beispielsweise kann der Funktionsaufruf in dem Hakeneintrittspunkt einen Auslöser umfassen, der eine spezifische angepasste Plug-in-Komponente aktiviert / auf diese zugreift.
-
Beispielsweise umfasst jeder der festen Funktionsblöcke 122-130 eine Mehrzahl von kuratierten und/oder beworbenen Hakeneintrittspunkten (z. B. Hakeneintrittspunkte 160-166), die eine spezifische Endbenutzeranpassung ermöglichen. Im Einzelnen kann ein Hakeneintrittspunkt eine angepasste Plug-in-Komponente (d. h. einen Code) spezifizieren, die durch einen Funktionsaufruf auszulösen ist. Bei einigen Ausführungsbeispielen ruft der Hakeneintrittspunkt die angepasste Plug-in-Komponente auf, die wiederum ihre spezifizierte Funktionalität ausführt. Beispielsweise kann der feste Funktionsblock 126 einen kuratierten oder angeworbenen Hakeneintrittspunkt umfassen, der bei Auslösung eine angepasste Plug-in-Komponente 134 aufruft, die insbesondere kein ursprünglicher Teil der Pipelinekette in der Softwarepaketerzeugerkomponente 102 ist. In solch einem Szenario wird die angepasste Plug-in-Komponente 134 ihre Funktion dynamisch in dem Kernel ausführen, ohne dass der Code für die Softwarepaketgeneratorkomponente 102 rekompiliert werden muss.
-
Bei einigen Ausführungsbeispielen kann eine erste angepasste Plug-in-Komponente mit einer zweiten angepassten Plug-in-Komponente verkettet oder verknüpft sein (z. B. unter Verwendung von Endaufrufen (bzw. Tail Calls)). Unter Bezugnahme auf 1 ist eine angepasste Plug-in-Komponente 134 mit einer angepassten Plug-in-Komponente 136 verkettet. In dem gezeigten Szenario kann nach der Ausführung der angepassten Plug-in-Komponente 134 ein Strukturereignis in der Komponente 134 ausgelöst werden, um die angepasste Plug-in-Komponente 136 aufzurufen. Im Einzelnen umfasst die angepasste Plug-in-Komponente 136 (und jede der angepassten Plug-in-Komponenten 132-140) eine oder mehrere Kernelstrukturen (z. B. Ereignisstrukturen), die dazu verwendet werden können, andere angepasste Plug-in-Komponenten (oder feste Funktionsblöcke in der Pipelinekette) zu aktivieren. Beispielsweise können die Ereignisstrukturen in den angepassten Plug-in-Komponenten BPF-gestützte Benutzerraum-Kernel-Strukturen sein, etwa Karten, Ereignis-ströme oder Perf-Ströme. Bei einigen Ausführungsbeispielen können Endbenutzer auf diese Kernelstrukturen in den angepassten Plug-in-Komponenten unter Verwendung von nativen Linux-Verfahren (z. B. BPF-Bibliotheken und/oder Linux-Dateisystem) zugreifen. Sobald die (zweite) angepasste Plug-in-Komponente 136 ihre Funktionalität ausgeführt hat, verlässt der ausgeführte Pipelineplattformprozess die angepasste Plug-in-Komponente und fährt mit dem nächsten festen Funktionsblock in der Paketgeneratorkomponente 102 fort (d. h. mit dem nächsten festen Funktionsblock, der ursprünglich durch den festen Funktionsblock, der zuletzt in der Pipelinekette ausgeführt wurde, aufgerufen worden wäre).
-
Als praktisches Beispiel wird angenommen, dass ein Stufenelement (z. B. ein Bereich) der Verarbeitungspipelineplattform 100 dazu konfiguriert ist, TCP-Kopfzeilen für den Paketdatenverkehr zu erstellen, der durch die Paketerzeugerkomponente 102 erzeugt wird. Für gewöhnlich wird die Verarbeitungspipelineplattform durch eine vorbestimmte sequenzielle Ausführung fester Funktionsblöcke 122-130 implementiert, um eine Funktion auszuführen (z. B. Erzeugen von TCP-Kopfzeilen für Testpakete). Nachdem beispielsweise der feste Funktionsblock 126 die Ausführung seiner Funktionalität abgeschlossen hat, fährt die Pipelinekette für gewöhnlich ununterbrochen mit dem festen Funktionsblock 128 fort. In dem Szenario, in dem die angepasste Plug-in-Komponente 134 genutzt wird (z. B. wo die angepasste Plug-in-Komponente 134 durch einen Endbenutzer zum Zwecke der Hinzufügung einer speziellen Markierung (bzw. Flag) oder eines numerischen Indikators in der TCP-Kopfzeile der Testpakete erstellt wird), kann der Hakeneintrittspunkt 166 des festen Funktionsblocks 126 dazu konfiguriert sein, einen Funktionsaufruf zu initiieren, der einen „Auslösecode“ aktiviert, der in der angepassten Plug-in-Komponente 134 spezifiziert oder durch dieselbe spezifiziert ist. Bei einigen Ausführungsbeispielen wird dem Endbenutzerprogrammierer eine Kenntnis von und/oder ein Zugriff auf den Funktionsaufruf, der in dem Hakeneintrittspunkt 166 enthalten ist, bereitgestellt. Der Endbenutzer/Programmierer kann daraufhin den Quellcode für die angepasste Plug-in-Komponente 134 erstellen, die den Auslösecode spezifiziert, welcher durch den Funktionsaufruf des Hakeneintrittspunkts 166 aufgerufen und/oder auf den derselbe zugreift. Sobald die angepasste Plug-in-Komponente 134 (sowie die entsprechende Plug-in-Komponente 136) durch den festen Funktionsblock 126 aufgerufen und ausgeführt wurde, wird dieselbe tatsächlich in den festen Pipeline-Code eingebracht, der durch den Kernel ausgeführt wird. Die Einbringung der angepassten Plug-in-Komponenten modifiziert oder erweitert auf dynamische Weise das Verhalten und die Funktionalität zur Erzeugung von Paket-Kopfzeilen (z. B. die Hinzufügung der zuvor genannten Markierung oder des numerischen Indikators) der zugrundeliegenden Paketgeneratorkomponente 102. Insbesondere kann diese Einbringung oder Einführung der angepassten Plug-in-Komponente 134 während der Laufzeit ausgeführt werden, wodurch die Merkmale und/oder Funktionalität der Pipelineplattform sofort modifiziert werden. Genauer gesagt kann die neue angepasste Plug-in-Komponente in die Pipeline über BPF-Hakeneintrittspunkte eingeführt werden, ohne den zugrundeliegenden Softwarecode der Pipelineplattform rekompilieren zu müssen.
-
Als Beispiel kann der maßgeschneiderte Block 134 die TCP-Paketkopfzeilen-Inhalte modifizieren, die ursprünglich 126 (z. B. fester Block 3) gehören / dadurch manipuliert werden, indem Speicherinhalte direkt modifiziert werden, auf die über Speicherzeiger zugegriffen wird, die als Funktionszeiger-Argumente an den Hakeneintrittspunkt 166 weitergegeben werden. Andere Techniken können dazu verwendet werden, Speicherreferenzen an benutzerdefinierte Plug-ins bereitzustellen, beispielsweise „angepinnte“ BPF-Kartenstrukturen, die durch den Festfunktion-Pattformcode erzeugt werden und einem oder mehreren Plug-ins durch einige bekannte Verfahren bereitgestellt werden. Beispielweise kann die „feste“ Pipelineplattform dahingehend gestaltet sein, von Anfang an ergänzbar (bzw. pluggable) zu sein, und kann vordefinierte Hakeneintrittspunkte präsentieren, die ein direktes Mittel bereitstellen, um das Ausgangsverhalten über Plug-ins zu ändern. Das kann beispielsweise bedeuten, dass Dummy-Funktionsaufrufe an den Hakeneintrittspunkten eingefügt werden, die dazu konfiguriert sein können, normalerweise nichts zu tun. Jedoch kann sich das eBPF-Programm des offenbarten Gegenstands in diese Eintrittspunkte einhaken, um das Verhalten zu ändern (z. B. Speicherinhalte oder Funktionsausgabewerte zu modifizieren). Die Funktionen können auch Funktionsargumente bereitstellen, auf die das eBPF-Programm leicht zugreifen kann, um den Programmzustand zu lesen und/oder zu modifizieren.
-
Nachdem die angepasste Plug-in-Komponente 134 in dem Kernel-Raum ausgeführt wird, kehrt die Operation zu dem Benutzerraum zurück, wodurch es ermöglicht wird, dass die angepasste Plug-in-Komponente 134 den Speicher modifiziert, der einem/einen Abschnitt der TCP-Paketkopfzeile entspricht oder diesen darstellt.
-
Obwohl das Beispiel der obigen Modifizierung der TCP-Kopfzeile veranschaulicht, dass angepasste Plug-in-Komponenten durch Hakeneintrittspunkte der festen Funktionsblöcke der Paketgeneratorkomponente 102 aktiviert werden können, können andere Haken in der Gesamtpipelinekette genutzt werden. Beispielsweise können angepasste Plug-in-Komponenten 148-150 an untergeordneten Sockets der OS-Softwarekomponente 104 eingefügt werden (d. h. durch dieselben aufgerufen werden), so dass auf das gesamte Paket in seiner finalen Form zugegriffen werden kann (z. B. vor der Übertragung des Pakets oder sofort bei Empfang des Pakets). Gleichermaßen können angepasste Plug-in-Komponenten durch Hakeneintrittspunkte, die mit Vorrichtungstreibern 140-142 in der OS-Softwarekomponente 104 in Verbindung stehen, aufgerufen werden.
-
Bei einigen Ausführungsbeispielen kann die Pipelineplattform dazu konfiguriert sein, eine externe Anwendungsprogrammierschnittstelle (API, Application Programming Interface) automatisch aufzubereiten (bzw. zu rendern), die es einem Benutzer oder Operator ermöglicht, mit den angepassten Plug-in-Komponenten zu interagieren. Beispielsweise kann die Steuerungskomponente 112 dazu genutzt werden, zumindest eine externe API 115 zu erstellen, die dazu verwendet werden kann, angepasste Plug-in-Komponenten zu modifizieren oder zu steuern (z. B. die in 1 angepasste Plug-in-Komponente 132). Wie oben gezeigt ist, kann die Steuerungskomponente 112 dazu konfiguriert sein, das Datenmodell, das der Pipelineplattform entspricht, unter Verwendung der API 115 zu interpretieren und/oder zu verwalten. Die Steuerungskomponente 112 kann auch dazu konfiguriert sein, die API 115 in Bezug auf die angepassten Plug-in-Komponenten (oder andere BPF-Datenstrukturen) automatisch aufzubereiten. Beispielsweise kann die Steuerungskomponente 112 einen erweiterten Datenverkehrserzeugungs-Proxy umfassen, der dazu konfiguriert ist, eine benutzerdefinierte API, die mit einer oder mehreren angepassten Plug-in-Komponenten in der Paketerzeugerkomponente 102 in Verbindung steht, automatisch aufzubereiten. Bei einigen Ausführungsbeispielen ist die API 115 eine REST-API (REST = Representational State Transfer) oder eine gRPC-API, die durch die Steuerkomponente 112 bereitgestellt wird, wenn dieselbe als Proxy funktioniert und/oder arbeitet.
-
Nach dem Aufbereiten kann die API 115 dann durch die Steuerungskomponente 112 dazu verwendet werden, eine Schnittstelle der angepassten Plug-in-Komponenten in der Pipelineplattform 100 zu delegieren (bzw. zu proxen). Bei einigen Ausführungsbeispielen weist die angepasste Plug-in-Komponente 132 nackten C-Code auf, der Lese-/Schreibe-Register in ihrer nativen Form umfasst. Im Einzelnen können diese Register gegenüber der externen API 115 freigelegt werden, wodurch es der GUI 118 oder der Steuerungskomponente 112 ermöglicht wird, die angepasste Plug-in-Komponente zu modifizieren (z. B. einen Plug-in-Komponenten-Parameter zu ändern) und/oder zu steuern. Beispielsweise kann die GUI 118 eine GUI-Entwicklerumgebung sein, die einem Benutzer interaktive Prozesssteuerungen bereitstellen kann, die dazu verwendet werden können, die angepassten Plug-in-Komponenten einzufügen. Bei einigen Ausführungsbeispielen besteht eine 1:1-Übereinstimmung zwischen GUI(s) 118 und Datenmodellinstanzen. Im Einzelnen kann das Aktualisieren einer GUI die deklarativen Daten des Modells aufbereiten. Gleichermaßen kann eine importierte angepasste BPF-Plug-in-Komponente eine GUI nach der Validierung aufbereiten. Bei einigen Ausführungsbeispielen kann das Rahmenwerk der GUI 118 einem Benutzer eine Echtzeitkompilierung und ein Einhaken von angepassten Plug-in-Komponenten bereitstellen. Beispielsweise können Fehler angezeigt werden und der Benutzer kann Modifizierungen in Echtzeit über eine interaktive Umgebung ausführen (z. B. solch eine Umgebung kann einen erweiterbaren Texteditor oder eine integrierte Entwicklungsumgebung (IDE, Integrated Development Environment) als Rahmenwerk umfassen). Ferner können Linux-Helfer, Komponentenbibliotheken und Assistenten dazu konfiguriert sein, Benutzern und/oder Operatoren zu helfen. Demgemäß könnte die GUI-Umgebung die neue Datenebenenpipelineplattform direkt ausführen, mit dem Benutzer interagieren, eine Leistung messen und/oder Erfassungen anzeigen (z. B. unter Verwendung einer eingebetteten Wireshark-Anwendung).
-
Bei einigen Ausführungsbeispielen kann der offenbarte Gegenstand dazu verwendet werden, eine Verwaltungs-API zu definieren, die dazu verwendet werden kann, auf die angepassten Plug-in-Komponenten zuzugreifen. Im Einzelnen kann die Verwaltungs-API unter Verwendung einfacher Konstruktionen definiert werden, z. B. Erweiterungen in Bezug auf das OTG-Datenmodell (OTG = Open Traffic Generator bzw. offener Datenverkehrserzeuger). Die angepassten Plug-in-Komponenten können entweder i) deklariert und instanziiert (d. h. installiert) oder uninstanziiert werden, ohne das erweiterte Datenmodell zu ändern (d. h. Ein-/Aus-Steuerungen für jede angepasste Plug-in-Komponente). Mehrere Instanzen derselben angepassten Plug-in-Komponente können instanziiert und eindeutig identifiziert und/oder bezeichnet werden.
-
Bei einigen Ausführungsbeispielen kann der offenbarte Gegenstand als Open-Source-Online-Ökosystem implementiert werden, das Beispiele angepasster Plug-in-Komponenten enthält, die über Gemeinschaftsbeiträge bereitgestellt werden. Beispielsweise kann ein neues angepasstes Plug-in-Komponenten-Konstrukt für die Paketgeneratorkomponente Inline-BPF-Code-Komponenten (z. B. kurze Programme) oder eine Referenz in Bezug auf eine externe Datei enthalten, die spezifische Angaben dahingehend umfasst, wohin der BPF-Code-Komponenten-Hakeneintritt seinen Funktionsaufruf richtet (in der Pipelineplattform). Ferner können die angepassten BPF-Plug-in-Komponenten auch die Benutzer-Kernel-Datenstrukturen spezifizieren, etwa Karten, Linux-Ereignisströme und Linux-Perf-Ströme, welche die Steuerungskomponente 112 als native APIs delegieren (bzw. proxen) und erneut aufbereiten kann. Wie oben beschrieben ist, können solche APIs als Vermittler für die angepassten BPF-Plug-in-Komponenten fungieren.
-
Bei einigen Ausführungsbeispielen kann die mehrstufige Verarbeitungspipelineplattform zusammen mit ihren zugrundliegenden festen Komponenten und angepassten Plug-in-Komponenten (z. B. BPF-Code) in einer physischen Rechenvorrichtung ausgeführt werden, etwa in einem feldprogrammierbaren Gatterarray (FPGA), das in einer Hardware-Datenebene funktioniert. Beispielsweise kann das FPGA dazu konfiguriert sein, als Hardware-Paketgenerator zu funktionieren. Im Einzelnen kann die mehrstufige Verarbeitungspipelineplattform und/oder die angepassten Plug-in-Komponenten durch eine virtuelle FPGA-BPF-Maschine ausgeführt werden, die BPF-Bytecode ausführt, der aus C-Quellcode kompiliert wird. Bei einigen Ausführungsbeispielen kann die mehrstufige Verarbeitungspipelineplattform und/oder die angepassten Plug-in-Komponenten bedarfssynchron (JIT) oder offline in einen FPGA-„Nativ“-Code niedrigerer Ebene kompiliert/transpiliert werden (z. B. transpiliert in FPGA-Logik-Block-Konfigurationen, die eine Reihe performanter Operationen ermöglichen würden).
-
3 ist ein Flussdiagramm, das einen Beispielprozess zum Anpassen einer Datenebenenpipelineverarbeitung unter Verwendung von BPF-Hakeneintrittspunkten gemäß einem Ausführungsbeispiel des hierin beschriebenen Gegenstands veranschaulicht. Bei einigen Ausführungsbeispielen ist das in 3 veranschaulichte Verfahren 300 ein Algorithmus, ein Programm oder ein Skript, der bzw. das in dem Speicher gespeichert ist, wobei der- bzw. dasselbe bei Ausführung durch einen Prozessor die in Blöcken 302-306 genannten Schritte ausführt. Bei einigen Ausführungsbeispielen stellt das Verfahren 300 eine Liste von Schritten (oder Änderungen in Schritten) dar, die in einer virtuellen Maschine (z. B. über eine Software-Code-Programmierung oder über einen Regelsatz) und/oder in einer Logik einer Hardware-Vorrichtung verkörpert werden.
-
In Block 302 wird ein Programmcodeskript zum Anpassen einer Leistung einer oder mehrerer Stufen einer mehrstufigen Verarbeitungspipelineplattform, die zum Ausführen eines Testpaketerzeugungsprozesses konfiguriert ist, empfangen. Bei einigen Ausführungsbeispielen schreibt ein Endbenutzer BPF-Quellcode in einer übergeordneten Sprache (z. B. C-Programmiersprache oder ein verwandter Teilsatz), der an eine Steuerungskomponente bereitgestellt wird, die mit der mehrstufigen Verarbeitungspipelineplattform in Verbindung steht. Insbesondere entspricht der Quellcode einer angepassten Plug-in-Komponente, die dazu verwendet werden wird, ein Merkmal (d. h. eine Stufe) der Verarbeitungspipelineplattform zu modifizieren. Bei einigen Ausführungsbeispielen umfasst die mehrstufige Verarbeitungspipelineplattform eine Mehrzahl von vordefinierten Hakeneintrittspunkten.
-
In Block 304 wird das Programmcodeskript kompiliert, um eine angepasste Plug-in-Komponente zu erzeugen, die in einem oder mehreren der vordefinierten Hakeneintrittspunkte der mehrstufigen Verarbeitungspipelineplattform eingesetzt wird. Bei einigen Ausführungsbeispielen parst die Steuerungskomponente das Programmcodeskript und stellt dasselbe an eine Kompiliererkomponente bereit (z. B. einem BCC-Werkzeugkette-Kompilierer). Die Kompiliererkomponente ist dazu konfiguriert, den Quellcode in BPF-Bytecode zu kompilieren und/oder zu transpilieren. Bei einigen Ausführungsbeispielen kann der Bytecode stattdessen durch einen JIT-Kompilierer in dem Kernel in eBPF-Bytecode rekompiliert werden, um ein Format zu erzeugen, das mit der nativen Architektur kompatibel ist. Nach der Kompilierung kann der Bytecode durch den System-Kernel genutzt werden, um eine angepasste Plug-in-Komponente in der Pipelineplattform einzusetzen.
-
In Block 306 wird eine Ausführung der angepassten Plug-in-Komponente ansprechend auf eine Auslösung des einen oder der mehreren vordefinierten Hakeneintrittspunkte eines Stufenelements der mehrstufigen Verarbeitungspipelineplattform initiiert, wobei die Ausführung der angepassten Plug-in-Komponente zumindest ein Merkmal des Testpaketerzeugungsprozesses während der Laufzeit dynamisch konfiguriert. Bei einigen Ausführungsbeispielen führt der Kernel ein Stufenelement der mehrstufigen Verarbeitungspipelineplattform aus, das einen Hakeneintrittspunkt umfasst, welcher eine angepasste Plug-in-Komponente aktiviert. Ansprechend darauf fügt der Kernel die spezifizierte angepasste Plug-in-Komponente in die mehrstufige Verarbeitungspipelinekette während der Laufzeit ein. Im Einzelnen muss der Code, der der mehrstufigen Verarbeitungspipelineplattform entspricht, nicht notwendigerweise rekompiliert werden, um die spezifizierte angepasste Plug-in-Komponente einzufügen und auszuführen.
-
Es ist ersichtlich, dass unterschiedliche Details des vorliegenden offenbarten Gegenstands geändert werden können, ohne vom Schutzumfang des vorliegenden offenbarten Gegenstands abzuweichen. Ferner dient die vorstehende Beschreibung lediglich illustrativen Zwecken, und ist somit nicht als Einschränkung anzusehen.
