DE102022102788A1

DE102022102788A1 - Konfigurierbare vorrichtungsschnittstelle

Info

Publication number: DE102022102788A1
Application number: DE102022102788.0A
Authority: DE
Inventors: Patrick KUTCH; Andrey Chilikin; Jin Yu; Cunming LIANG; Changpeng Liu; Ziye Yang; Gang Cao; Xiaodong Liu; Zhiguo Wen; Zhihua Chen
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2021-03-22
Filing date: 2022-02-07
Publication date: 2022-09-22
Also published as: CN115113973A; US20210232528A1

Abstract

Hier beschriebene Beispiele betreffen eine Einrichtung, die Folgendes umfasst: einen Deskriptorformatübersetzer, auf den ein Treiber zugreifen kann. In manchen Beispielen nutzen der Treiber und der Deskriptorformatübersetzer einen Zugriff zum Übertragen und zum Empfangen von Deskriptoren gemeinsam. In manchen Beispielen ist der Deskriptorformatübersetzer, basierend auf einem Format eines Deskriptors, das mit einer Vorrichtung assoziiert ist, das sich von einem zweiten Format eines Deskriptors unterscheidet, das mit dem Treiber assoziiert ist, zu Folgendem ausgelegt: Durchführen einer Übersetzung des Deskriptors von dem Format in das zweite Format und Speichern des übersetzten Deskriptors in dem zweiten Format für einen Zugriff durch die Vorrichtung. In manchen Beispielen soll die Vorrichtung auf den übersetzten Deskriptor zugreifen; soll die Vorrichtung den Inhalt des übersetzten Deskriptors modifizieren, um mindestens eine Arbeitsanforderung zu identifizieren, und soll der Deskriptorformatübersetzer den modifizierten übersetzten Deskriptor in das Format übersetzen und soll den übersetzten modifizierten übersetzten Deskriptor für einen Zugriff durch den Treiber speichern.

Description

1 stellt ein Beispiel für eine bekannte Weise des Paket- und Deskriptorkopierens zwischen einem Gastsystem und einer Netzwerkschnittstellensteuerung (NIC) dar. Der virtuelle Funktions(VF)-Treiber (VDEV-Treiber) 104 ordnet Speicher für Paketpuffer und Deskriptoren sowohl für Paketempfangs(Rx)- als auch für Sende(Tx)-Aktivitäten zu. Die Deskriptoren enthalten Zeiger zu Speicherbereichen, in denen die Paketpuffer zugeordnet wurden. Der VF-Treiber 104 programmiert die VF-Schnittstelle (z. B. eine einer VF zuweisbare Geräteschnittstelle (ADI: assignable device interface) oder eine Schnittstelle zu einer virtuellen Station (VSI: virtual station interface)) der NIC 120 mit diesen Deskriptoradressen.
Wenn ein Paket empfangen wird, kopiert die NIC 120 das Paket durch Direktspeicherzugriff (DMA: direct memory access) in einen Speicherort, der in dem nächsten Rx-Deskriptor identifiziert ist, und aktualisiert den Rx-Deskriptor, der wiederum den VF-Treiber 104 benachrichtigt, dass Daten zur Verarbeitung bereit sind. Nachdem der VF-Treiber 104 einen Puffer mit zu übertragenden Daten aufweist, vervollständigt der VF-Treiber 104 zur Paketübertragung einen Tx-Deskriptor und die NIC 120 identifiziert den Deskriptor als aktualisiert und initiiert eine DMA-Übertragung von dem Puffer zu der NIC 120. Die NIC 120 überträgt das Paket und schreibt zurück in den Tx-Deskriptor und stellt dem VF-Treiber 104 eine Benachrichtigung bereit, dass das Paket übertragen worden ist.
Es gibt mehrere Anbieter von NICs mit einer Vielzahl von Fähigkeiten und Funktionalitäten. Unterschiedliche NICs können unterschiedliche Deskriptorformate unterstützen. Entwickler, wie etwa Firewallanbieter oder Entwickler virtueller Netzwerkfunktionen (VNF), stehen jedoch durch sich ändernde oder aktualisierte NICs aus der wiederholten Aktualisierung und Revalidierung von Produkten vor Herausforderungen, um einer potenziellen Treiberinkompatibilität oder Änderungen der Schnittstellentechnologie (z. B. VirtIO-net, Intel® Ethernet Adaptive Virtual Function) zu begegnen, um die Verwendung der neuesten Generation von NICs aufrechtzuerhalten. Aktualisierungen an Kernel-Firmware oder -Treibern können zur Inkompatibilität mit VF-Treibern (z. B. Kernel- und/oder Abfragemodus-Treiber (PMD: poll mode driver)) und zur Inkompatibilität mit einer NIC führen. Single-Root-I/O-Virtualisierung (SR-IOV) (hier beschrieben) ermöglicht einer NIC, virtuellen Maschinen separaten Zugriff auf ihre Ressourcen bereitzustellen. Falls ein NIC-Anbieter nur garantiert, dass ein spezifischer SR-IOV-VF-Treiber mit einem spezifischen physischen Funktions(PF)-Treiber arbeitet, besteht keine Garantie, dass der VF-Treiber in der virtuellen Maschine (VM) wie erwartet weiterarbeitet, und es können Testen sowie eine Revalidierung oder eine Treibermodifikation erforderlich sein.
Moderne Arbeitslasten und Ausgestaltungen von Rechenzentren können einen Netzwerkaufwand für die CPU-Kerne erfordern. Bei einer schnelleren Vernetzung (z. B. 25/50/100/200 Gb/s pro Link oder anderen Geschwindigkeiten) führen die CPU-Kerne die Klassifizierung, Nachverfolgung und Lenkung von Netzwerkverkehr durch. Ein SmartNIC kann durch eine CPU verwendet werden, um komplexe Open vSwitch(OVS)- oder netzwerkspeicherbezogene Operationen auf ein FPGA oder SOC des SmartNIC auszulagern. Schnittstellen zu einer Vorrichtung, wie etwa VirtIO, können von einer virtuellen Maschine (VM), einem Container oder in einem Bare-Metal-Szenario verwendet werden. Zur Beschreibung von VirtIO siehe „Virtual I/O Device (VirtIO) Version 1.1“, Committee Specification Draft 01 / Public Review Draft 01 (20. Dezember 2018) sowie Variationen, Revisionen, frühere Versionen davon oder spätere Versionen davon.
Skalierbare IOV von Intel®(S-IOV: scalable IOV) und Single-Root-I/O-Virtualisierung (SR-IOV) können virtuellen Maschinen und Containern Zugriff auf eine Vorrichtung unter Verwendung isolierter gemeinsam genutzter physischer Funktions(PF)-Ressourcen und mehrerer virtueller Funktionen (VFs) und entsprechender Treiber bereitstellen. Zur Beschreibung von SR-IOV siehe die Spezifikation zu Single-Root-I/O-Virtualisierung und gemeinsame Nutzung, Revision 1.1 (2010) und Variationen davon, frühere Versionen oder Aktualisierungen davon. Zur Beschreibung von S-IOV siehe die Technische Spezifikation von Intel® zur Skalierbaren I/O-Virtualisierung (Juni 2018).
Unter Verwendung von S-IOV, um auf die Vorrichtung zuzugreifen, greifen virtuelle Maschinen und Container auf eine Softwareemulationsschicht zu, die virtuelle Vorrichtungen (vdev: virtual devices) simuliert, und vdevs können auf die Eingabe-/Ausgabe(EA)-Warteschlangen der Vorrichtung zugreifen. Bei S-IOV entspricht eine vdev einer zuweisbaren Geräteschnittstelle (ADI), die ihren eigenen speicherabgebildeten E/A (MMIO)-Raum und E/A-Warteschlangen aufweist. SR-IOV-PFs stellen Erkennung, Verwaltung und Konfiguration als Peripheral Component Interconnect Express(PCIe)-Vorrichtungen bereit. PCIe ist zum Beispiel in der Basis-Spezifikation 1.0 Peripheral Component Interconnect (PCI) Express (2002) sowie früheren Versionen, späteren Versionen und Variationen davon beschrieben. VFs ermöglichen die Steuerung der Vorrichtung und werden aus physischen Funktionen abgeleitet. Mit SR-IOV weist eine VF ihren eigenen unabhängigen Konfigurationsraum, Basisadressregister(BAR)-Raum und Eingabe-/Ausgabe(E/A)-Warteschlangen auf.
Es kann einem Container entweder VF (SR-IOV) oder ADI (S-IOV) in einer Art der Weiterleitung (voll oder vermittelt) zugewiesen werden, die eine virtuelle Vorrichtung bereitstellen, die mit einer physischen Vorrichtungsinstanz (z. B. VF oder ADI) assoziiert ist. SR-IOV kann 128-256 VFs bereitstellen, wohingegen S-IOV Tausende von ADIs bereitstellen kann. Die Anzahl von Container-Bereitstellungen kann jedoch die Anzahl verfügbarer VFs überschreiten. Mit anderen Worten, eine maximale Anzahl virtueller Vorrichtungen kann durch eine Anzahl virtueller Schnittstellen begrenzt sein, die durch die Hardwarevirtualisierungsmethodologie bereitgestellt werden, und es gibt möglicherweise nicht ausreichend virtuelle Schnittstellen, die allen bereitgestellten Containern zugewiesen werden können. Dementsprechend stehen aufgrund eines Mangels an virtuellen Schnittstellen möglicherweise nicht für alle bereitgestellten Container Vorrichtungs-E/A-Warteschlangen zur Verfügung.
Cloud-Dienstanbieter (CSPs), wie etwa in Multi-Cloud- oder Hybrid-Cloud-Umgebungen, stellen zum Beispiel Zehntausende Container-Instanzen über VMs (z. B. ungefähr 2000 Container pro VM) auf einem einzigen physischen Rechenknoten bereit, die eine einzige Netzwerkschnittstelle und eine einzige Speichervorrichtungsschnittstelle nutzen. Falls SR-IOV verwendet wird, werden, falls die Anzahl von Containern oder Anwendungen die maximale VF überschreitet, die durch die SR-IOV unterstützt wird, Warteschlangen für eine Anzahl von Containern oberhalb von 256 Containern möglicherweise nicht bereitgestellt.
2 stellt einen Überblick über ein System bereit, das vHost- oder virtuelle Datenpfadbeschleunigung (vDPA) verwendet. vDPA ermöglicht es, eine Verbindung zwischen einer VM oder einem Container und einer Vorrichtung unter Verwendung von VirtIO herzustellen, um eine Datenebene zwischen einem VirtIO-Treiber, der innerhalb einer VM ausgeführt wird, und einer SR-IOV-VF und einer Steuerebene bereitzustellen, die durch eine vDPA-Anwendung verwaltet wird. vDPA wird zum Beispiel in Data Plane Development Kit (DPDK) Release 1805 und QEMU Version 3.0.0 unterstützt. Ein vDPA-Treiber kann eine VirtIO-Datenebenenschnittstelle zwischen dem VirtIO-Treiber und der Vorrichtung einrichten. vDPA stellt einen Datenpfad von einer VM zu einer Vorrichtung bereit, wodurch die VM mit der Vorrichtung als eine VirtIO-Vorrichtung (z. B. virtio-blk-Datenspeichervorrichtung oder virtio-net-Netzwerkvorrichtung) kommunizieren kann. Unter Verwendung von vDPA nutzt die Datenebene der Vorrichtung ein VirtIO-Ring-konsistentes Layout (z. B. virtqueue: VirtIO-Warteschlange). vDPA kann in Verbindung mit SR-IOV und SIOV arbeiten. Eine Live-Migration eines Containers und einer VM, die unter Verwendung von vDPA auf eine Vorrichtung zugreift, können unterstützt werden. Eine Live-Migration kann das Ändern von einer oder mehrerer Rechen- oder Speicherressourcen beinhalten, die einen Container oder eine VM ausfführen, um Speicher, Datenspeicher sowie Netzwerk- oder Fabric-Konnektivität zu einem Ziel zu transferieren.
Figurenliste

1 stellt ein Beispiel für eine bekannte Art und Weise des Paket- und Deskriptorkopierens zwischen einem Gastsystem und einer Netzwerkschnittstellensteuerung (NIC) dar.
2 stellt einen Überblick über ein System bereit, das vHost- oder virtuelle Datenpfadbeschleunigung (vDPA) verwendet.
3 zeigt ein Beispiel, bei dem ein Treiber mit einem Deskriptorübersetzer kommuniziert.
4 A stellt ein Beispiel für eine Sendedeskriptorübersetzung dar.
4 B stellt ein Beispiel für eine Empfangsdeskriptorübersetzung dar.
5 zeigt ein Beispiel für die Verwendung einer Deskriptorübersetzung mit mehreren Vorrichtungen.
6 stellt ein Beispiel für die Verwendung mehrerer virtueller Gastumgebungen dar, die Deskriptorübersetzung mit mehreren Vorrichtungen nutzen.
7 A-7 C stellen Prozesse zum Konfigurieren und Verwenden von Deskriptorformatübersetzung dar.
8 stellt einen Überblick über verschiedene Ausführungsformen bereit, die Warteschlangen für Container bereitstellen können.
9 stellt einen beispielhaften Prozess zum Zuordnen von Warteschlangen einer Vorrichtung zu einer virtualisierten Ausführungsumgebung dar.
10 stellt ein Beispiel für einen Warteschlangenzugriff über ein vHost-Ziel dar.
11 stellt ein Beispiel für eine Anforderungs-, Datenzugriffs- und Antwortsequenz dar.
12 zeigt eine beispielhafte Konfiguration einer VirtIO-Warteschlange, die eine Konfiguration pro Warteschlange bereitstellt.
13 stellt ein System dar.
14 stellt eine beispielhafte Umgebung dar.

AUSFÜHRLICHE BESCHREIBUNG
ÜBERSETZUNG VON DESKRIPTOREN
Verschiedene Ausführungsformen stellen eine Kompatibilität zwischen virtuellen Schnittstellen mit einer Vielzahl von NICs bereit. In manchen Beispielen kann auf NICs als virtuelle Vorrichtungen unter Verwendung von SR-IOV, Intel® SIOV oder anderen Virtualisierungstechnologien von Vorrichtungen oder Technologien zum gemeinsamen Nutzen von Vorrichtungen zugegriffen werden. Zumindest um eine Kompatibilität zwischen virtuellen Schnittstellen mit einer Vielzahl von NICs bereitzustellen, stellen verschiedene Ausführungsformen eine Deskriptorformatumwandlung in Verbindung mit Paketübertragung oder -empfang bereit, so dass eine virtualisierte Ausführungsumgebung (VEE: virtualized execution environment) einen Treiber für eine NIC nutzen kann, die von einer NIC, die zum Übertragen oder Empfangen von Paketen verwendet wird, verschieden ist. Verschiedene Ausführungsformen stellen einen Deskriptorformatwandler (z. B. Hardware und/oder Software) bereit, um eine Verfügbarkeit von Deskriptoren zu oder von einer NIC für eine Paketübertragung oder einen Paketempfang zu identifizieren, Deskriptoren in ein anderes Schnittstellenformat zu übersetzen und dann die übersetzten Deskriptoren in ein Deskriptorformat zu schreiben, das der VEE-Treiber oder die PMD lesen und darauf einwirken kann. Zum Beispiel kann ein Entwickler oder Kunde eine Anwendung oder eine andere Software entwickeln, um eine bestimmte NIC zu nutzen, und eine bestimmte virtuelle Schnittstelle (z. B. virtio-net, vmxnet 3, iavf, e1000, AF_XDP, ixgbevf, i40evf und so weiter) nutzen und die Verwendung dieser Schnittstelle trotz eines Wechsels zu einer anderen NIC, die ein anderes Deskriptorformat unterstützt, beibehalten.
Zum Beispiel kann eine Anwendung oder eine VEE (z. B. Firewall der nächsten Generation (NGFW) oder Lastausgleicher) eine virtualisierte Schnittstelle (z. B. virtio-net oder vmxnet3) nutzen, SR-IOV mit vSwitch-Umgehung nutzen, wodurch die NIC durch Direktspeicherzugriff (DMA) Daten direkt in und aus Puffern kopiert, die durch die virtuelle Firewall konfiguriert werden, und Deskriptoren für einen Deskriptorformatwandler offenlegt, um eine Kompatibilität zwischen der virtualisierten Schnittstelle und der NIC bereitzustellen. Verschiedene Ausführungsformen können das Ausskalieren der Verwendung von Ressourcen (z. B. Rechenressourcen, Speicherressourcen, Beschleunigerressourcen) über eine NIC oder Fabric-Schnittstelle ermöglichen.
3 stellt ein beispielhaftes System dar. Eine Gast-VEE 302 kann eine beliebige Art von Anwendungen, Dienst, Mikrodienst, Cloud-nativem Mikrodienst, Arbeitslast oder Software beinhalten. Zum Beispiel kann die VEE 302 eine virtuelle Netzwerkfunktion (VNF), eine NEXGEN-Firewall, ein virtuelles privates Netzwerk (VPN), einen Lastausgleich durchführen, eine Paketverarbeitung basierend auf einem oder mehreren von Data Plane Development Kit (DPDK), Storage Performance Development Kit (SPDK), OpenDataPlane, Netzwerkfunktionsvirtualisierung (NFV), softwaredefiniertem Netzwerk (SDN), Evolved Packet Core (EPC) oder 5G-Netzwerk-Slicing durchführen. Einige beispielhafte Implementierungen von NFV sind in ETSI-Spezifikationen (ETSI: European Telecommunications Standards Institute) oder Open-Source-NFV-MANO (MANO: Management and Orchestration) der Open-Source-Mano(OSM)-Gruppe von ETSI beschrieben.
Eine VNF kann eine Dienstkette oder eine Sequenz virtualisierter Aufgaben beinhalten, die auf generischer konfigurierbarer Hardware, wie etwa Firewalls, Domänennamensystem (DNS: domain name system), Caching oder Netzwerkadressübersetzung (NAT: network address translation), ausgeführt werden, und kann in VEEs ausgeführt werden. VNFs können als eine Dienstkette miteinander verknüpft sein. In manchen Beispielen ist EPC eine 3GPP-spezifizierte Kernarchitektur zumindest für einen Long-Term-Evolution(LTE)-Zugriff. 5G-Netzwerk-Slicing kann ein Multiplexen virtualisierter und unabhängiger logischer Netzwerke auf derselben physischen Netzwerkinfrastruktur bereitstellen.
Mikrodienste können unter Verwendung einer zentralisierten Dienstverwaltung unabhängig bereitgestellt werden. Das Verwaltungssystem kann in unterschiedlichen Programmiersprachen geschrieben sein und unterschiedliche Datenspeichertechniken verwenden. Ein Mikrodienst kann durch eines oder mehrere von Folgendem gekennzeichnet sein: Verwenden von feingranulierten Schnittstellen (für unabhängig einsetzbare Dienste), polyglotte Programmierung (z. B. Code, der in mehreren Sprachen geschrieben ist, um eine zusätzliche Funktionalität und Effizienz zu erfassen, die in einer einzigen Sprache nicht verfügbar sind), oder Einsatz von leichten Containern oder virtuellen Maschinen sowie dezentralisierte kontinuierliche Bereitstellung von Mikrodiensten. In manchen Beispielen kann ein Mikrodienst mit einem oder mehreren anderen Mikrodiensten unter Verwendung von Protokollen (z. B. Anwendungsprogrammschnittstelle (API), Hypertext Transfer Protocol (HTTP)-Ressourcen-API, Nachrichtendienst, Remote Procedure Calls (RPC) oder Google RPC (gRPC)) kommunizieren.
Eine VEE kann mindestens eine virtuelle Maschine oder einen Container beinhalten. VEs können in Bare-Metal-Umgebungen (z. B. Einzelmandant) oder gehosteten Umgebungen (z. B. mehrere Mandanten) ausgeführt werden. Eine virtuelle Maschine (VM) kann Software sein, die ein Betriebssystem und eine oder mehrere Anwendungen ausführt. Eine VM kann durch Spezifikation, Konfigurationsdateien, virtuelle Plattendatei, NVRAM-Einstelldatei (NVRAM: non-volatile random access memory - nichtflüchtiger Direktzugriffsspeicher) und die Protokolldatei definiert werden und wird durch die physischen Ressourcen einer Host-Rechenplattform gesichert. Eine VM kann ein OS oder eine Anwendungsumgebung sein, die auf Software installiert ist, die dedizierte Hardware imitiert. Der Endbenutzer hat auf einer virtuellen Maschine das gleiche Erlebnis, wie er es auf dedizierter Hardware hätte. Spezialisierte Software, Hypervisor genannt, emuliert die CPU, den Speicher, die Festplatte, das Netzwerk und andere Hardwareressourcen des PC-Clients oder -Servers vollständig, wodurch ermöglicht wird, dass virtuelle Maschinen die Ressourcen gemeinsam nutzen. Der Hypervisor kann mehrere virtuelle Hardwareplattformen emulieren, die voneinander isoliert sind, was es virtuellen Maschinen ermöglicht, Linux®-, FreeBSD-, VMWare- oder Windows®-Server-Betriebssysteme auf demselben zugrundeliegenden physischen Host auszuführen.
Ein Container kann ein Softwarepaket von Anwendungen, Konfigurationen und Abhängigkeiten sein, so dass die Anwendungen zuverlässig von einer Rechenumgebung zu einer anderen ausgeführt werden. Container können ein auf der Serverplattform installiertes Betriebssystem gemeinsam nutzen und als isolierte Prozesse ablaufen. Ein Container kann ein Softwarepaket sein, das alles enthält, das die Software ausführen muss, wie etwa Systemwerkzeuge, Bibliotheken und Einstellungen. Container werden nicht wie herkömmliche Softwareprogramme installiert, wodurch sie von der anderen Software und dem Betriebssystem selbst isoliert werden können. Die Isolation kann einen erlaubten Zugriff auf einen Bereich eines adressierbaren Speichers oder einer adressierbaren Speicherung durch einen bestimmten Container, aber keinen anderen Container, beinhalten. Die isolierte Natur von Containern bietet mehrere Vorteile. Zuerst wird die Software in einem Container in unterschiedlichen Umgebungen gleich ausgeführt. Zum Beispiel kann ein Container, der PHP und MySQL beinhaltet, sowohl auf einem Linux-Computer als auch auf einer Windows®-Maschine identisch ausgeführt werden. Zweitens stellen Container zusätzliche Sicherheit bereit, da die Software das Host-Betriebssystem nicht beeinflusst. Obwohl eine installierte Anwendung Systemeinstellungen ändern und Ressourcen modifizieren kann, wie etwa die Windows®-Registrierungsdatenbank, kann ein Container nur Einstellungen innerhalb des Containers modifizieren.
Eine physische PCIe-verbundene NIC 330 (z. B. eine SR-IOV-VF, eine S-IOV-VDEV oder eine PF) kann als eine Vorrichtung ausgewählt werden, die Pakete empfangen und übertragen oder Arbeit auf Anforderung der VEE 302 durchführt. Verschiedene Ausführungsformen können Compute Express Link (CXL) (z. B. Compute Express Link Specification Revision 2.0, Version 0.7 (2019) sowie frühere Versionen, spätere Versionen und Variationen davon) nutzen, um eine Kommunikation zwischen einem Host und einer NIC 330 oder einem Flexible Descriptor Representor (FDR) 320 bereitzustellen. Der virtuelle Geräte(VDEV)-Treiber 304 kann einen Konfigurationsbefehl an den FDR 320 senden, um den FDR 320 mit einer virtualisierten Schnittstelle zu verbinden, die durch die VEE 302 offengelegt wird. Es wird angemerkt, dass, obwohl Bezug auf eine NIC genommen wird, die NIC 330 zusätzlich oder alternativ dazu eine Datenspeichersteuerung, eine Datenspeichervorrichtung, eine Infrastrukturverarbeitungseinheit (IPU), eine Datenverarbeitungseinheit (DPU), einen Beschleuniger (z. B. FPGAs) oder einen Hardwarewarteschlangenmanager (HQM) beinhalten kann.
Der VDEV-Treiber 304 für die VEE 302 kann Kernelspeicher für Deskriptoren und Systemspeicher für Paketpuffer zuordnen und den FDR 320 programmieren, um auf diese Deskriptoren zuzugreifen. Zum Beispiel kann der VDEV-Treiber 304 dem FDR 320 Deskriptorpufferorte (z. B. Tx oder Rx) angeben. Der VDEV-Treiber 304 kann mit dem FDR 320 anstelle der NIC 330 kommunizieren, um Deskriptoren für Paketübertragung (Tx) oder Zugangsdeskriptoren für Paketempfang (Rx) bereitzustellen. Der VDEV-Treiber 304 kann Speicher für Paketpuffer und Rx- oder Tx-Deskriptorenringe zuordnen, und Deskriptorenringe (Warteschlangen) können für den FDR 320 zugänglich sein und einige Deskriptorenringe können für die NIC 330 zugänglich sein.
Die VEE 302 kann eine gleiche virtualisierte Schnittstelle (z. B. den VDEV-Treiber 304) unabhängig davon nutzen, wie die physische VF- oder SIOV-NIC 330 für Paketübertragung bzw. -empfang verwendet wird. Beispiele für eine virtualisierte Schnittstelle beinhalten unter anderem virtio-net, vmxnet3, iavf, e1000, AF_XDP, ixgbevf, i40evf und so weiter. In manchen Beispielen kann die virtualisierte Schnittstelle, die von der VEE 302 verwendet wird, in Verbindung mit Open vSwitch oder Data Plane Development Kit (DPDK) arbeiten. Dementsprechend können trotz Verwendung einer anderen NIC als der NIC 330, wie etwa von einem anderen Anbieter oder einem anderen Modell, eine virtualisierte Schnittstelle und ein virtualisiertes Softwareökosystem weiterhin verwendet werden. In einem Szenario, in dem die VEE 302 zur Ausführung auf einem anderen CPU-Sockel migriert wird, kann der FDR 320 zum Beispiel eine Deskriptorformatumwandlung durchführen, so dass die VEE 302 dieselbe virtuelle Schnittstelle nutzen kann, um mit einer NIC zu kommunizieren, die von einem anderen Kern verwendet wird.
In dem System aus 3 kommuniziert der VDEV-Treiber 304 mit dem FDR 320, der mit dem VDEV-Treiber 304 als eine NIC (oder eine andere Vorrichtung) interagiert. Zum Beispiel kann die NIC 330 aus 3 mit dem VDEV-Treiber 304 interagieren, als ob es sich um die NIC 120 aus 1 handeln würde. In dem System aus 1 kommuniziert der VDEV-Treiber 104 direkt mit der NIC 120, um einen Zugriff auf Warteschlangen und Deskriptorringe zu konfigurieren. In manchen Beispielen kann der VDEV-Treiber 304 auch mit der NIC 330 kommunizieren, um einen Zugriff auf Warteschlangen und Deskriptorringe zu konfigurieren. Zum Beispiel kann in 1 der NIC-Typ A verwendet werden, wohingegen in 3 der NIC-Typ B verwendet werden kann, wobei der NIC-Typ A und der NIC-Typ B unterschiedliche Formate von Rx- oder Tx-Deskriptoren verwenden, aber der FDR 320 eine Deskriptorformatumwandlung bereitstellt, so dass der VDEV-Treiber 304 Deskriptoren für den NIC-Typ A bereitstellt und verarbeitet, und die NIC 330 Deskriptoren des NIC-Typs B verarbeitet.
In manchen Beispielen könnte der FDR 320 für VEEs, die auf einem oder mehreren Servern laufen, mehrere virtuelle Empfangsschnittstellen offenlegen. Virtuelle Schnittstellen können von unterschiedlichen Typen sein, zum Beispiel könnten manche virtio-net-konsistente Schnittstellen sein, manche könnten iafv-konsistente Schnittstellen sein, andere können i40evf-konsistente Schnittstellen sein. Zum Beispiel könnte eine VEE die NIC A von Anbieter A nutzen, die als eine SR-IOV-VF einer NIC B von Anbieter B (oder einer anderen NIC von Anbieter A) präsentiert wird. Die VEE 302 hat möglicherweise keinen Zugriff auf alle der Funktionen und Fähigkeiten der NIC A, wäre aber fähig, eine VEE zu verwenden, die programmiert ist, um auf eine VF der NIC B zuzugreifen. VEEs können mit einem virtuellen Switch (vSwitch) kommunizieren, der eine Kommunikation zwischen VEEs ermöglicht.
In manchen Beispielen kann der PF-Host-Treiber 314 den FDR 320 initialisieren und den FDR 320 mit der NIC 330 verbinden. In manchen Beispielen kann der FDR 320 Rx/Tx-Deskriptorringe für die NIC 330 zuordnen. Nach der Initialisierung kann der FDR 320 zwei Kopien von Rx/Tx-Ringen, wie etwa einen Rx/Tx-Ring für die NIC 330 und einen Rx/Tx-Ring für den VDEV-Treiber 304, enthalten. Der FDR 320 kann Deskriptorumwandlung 322 nutzen, um eine Deskriptorübersetzung von Rx- oder Tx-Deskriptoren durchzuführen, so dass ein Deskriptor im Rx/Tx-Ring für die NIC 330 eine Übersetzung eines entsprechenden Rx- oder Tx-Deskriptors im Rx/Tx-Ring für den VDEV-Treiber 304 ist. In manchen Beispielen kann der FDR 320 auf die NIC 330 als eine VF oder PF unter Verwendung von SR-IOV oder SIOV zugreifen, oder die NIC 330 kann auf den FDR 320 als eine VF oder PF unter Verwendung von SR-IOV oder SIOV zugreifen.
Zum Beispiel kann der FDR 320 als eine diskrete PCIe-Vorrichtung implementiert sein, wie etwa eine Riser-Karte, die mit einer Leiterplatte verbunden ist und auf die eine CPU oder eine XPU zugreifen kann. Zum Beispiel kann der FDR 320 als eine virtuelle Vorrichtung unter Verwendung einer virtuellen Schnittstelle zugänglich sein. In manchen Beispielen kann der FDR 320 als ein Prozess implementiert sein, der in einer VEE, einem Plug-in im Benutzerraum oder einer anderen Software ausgeführt wird.
Zum Beispiel kann die NIC 330 zum Paketempfang durch Direktspeicherzugriff(DMA) Daten an den Zielort kopieren und einen Rx-Deskriptor an einen Deskriptorring bereitstellen, der durch den FDR 320 verwaltet wird. Zum Beispiel kann ein Rx-Deskriptor eines oder mehrere von Folgendem beinhalten: Paketpufferadresse im Speicher (z. B. physisch oder virtuell), Header-Pufferadresse im Speicher (z. B. physisch oder virtuell), Status, Länge, VLAN-Tag, Fehler, Fragmentprüfsumme, Filterkennung und so weiter. Die NIC 330 kann den Rx-Deskriptor aktualisieren, um zum Beispiel einen Zielort von Daten in einem Puffer zu identifizieren. Die NIC 330 kann den Rx-Deskriptor aktualisieren, um anzugeben, dass er Daten in den Puffer geschrieben hat, und kann andere Handlungen durchführen, wie etwa das Entfernen eines Virtual-Local-Area-Network(VLAN)-Tags aus dem empfangenen Paket. Der FDR 320 kann bestimmen, wann die NIC 330 einen Rx-Deskriptor aktualisiert oder einen Rx-Deskriptor zu einem durch den FDR 320 verwalteten Ring hinzufügt (z. B. durch Abfragen oder über eine Unterbrechung durch die NIC 330). Wenn er zum Übersetzen eines Deskriptors konfiguriert ist, kann der FDR 320 den Rx-Deskriptor in ein Format übersetzen, das durch den VDEV-Treiber 304 erkannt und ordnungsgemäß gelesen wird. Wenn jedoch keine Deskriptorübersetzung benötigt wird, kann der FDR 320 ermöglichen, dass der Rx-Deskriptor ohne Übersetzung verfügbar ist. Der FDR 320 kann den übersetzten Rx-Deskriptor an einen Deskriptorring bereitstellen, auf den der VDEV-Treiber 304 zugreifen kann. Der VDEV-Treiber 304 kann bestimmen, dass ein Rx-Deskriptor zur Verarbeitung durch die VEE 302 verfügbar ist. Die VEE 302 kann die empfangenen Daten im Zielpuffer aus dem übersetzten Rx-Deskriptor identifizieren.
Zum Beispiel kann der VDEV-Treiber 304 zur Paketübertragung ein Paket in einen Speicherpuffer platzieren und in einen Tx-Deskriptor schreiben. Zum Beispiel kann ein Sendedeskriptor eines oder mehrere von Folgendem beinhalten: Paketpufferadresse (z. B. physisch oder virtuell), Layer-2-Tag, VLAN-Tag, Puffergröße, Offset, Befehl, Deskriptortyp und so weiter. Andere Beispiele für Deskriptorfelder und -formate sind zumindest in Intel® Ethernet Adaptive Virtual Function Specification (2018) beschrieben. Der VDEV-Treiber 304 gibt dem FDR 320 an, dass ein Tx-Deskriptor für einen Zugriff verfügbar ist. Wenn er zum Übersetzen eines Deskriptors konfiguriert ist, kann der FDR 320 den Tx-Deskriptor in ein Format übersetzen, das durch die NIC 330 erkannt und ordnungsgemäß gelesen wird. Wenn jedoch keine Deskriptorübersetzung benötigt wird, kann der FDR 320 ermöglichen, dass der Tx-Deskriptor ohne Übersetzung verfügbar ist. Der FDR 320 kann die durch den VDEV-Treiber 304 bereitgestellten Tx-Deskriptoren überwachen, einen kürzlich geschriebenen Tx-Deskriptor in ein Deskriptorformat übersetzen, das durch die NIC 330 verwendet wird, in den übersetzten Tx-Deskriptor die Adresse des zu übertragenden Datenpuffers einbeziehen und den übersetzten Deskriptor in einen Ring schreiben, den die NIC 330 überwacht. Die NIC 330 kann den Tx-Deskriptor aus einem Deskriptorring lesen, der von dem FDR 320 verwaltet wird, und die NIC 330 kann auf Paketdaten von einem Speicherpuffer zugreifen, der in dem übersetzten (oder unübersetzten) Tx-Deskriptor durch eine DMA-Kopieroperation identifiziert wird.
4 A und 4 B stellen ein Beispiel für Deskriptorformatübersetzungen für Empfangsdeskriptoren dar, aber die Übersetzung kann für Sendedeskriptoren gelten. Eine Deskriptorübersetzung kann das Kopieren des gesamten oder eines Teilsatzes eines Feldes eines Deskriptors in ein Feld in einem Deskriptor eines anderen Formats beinhalten. Eine Deskriptorübersetzung kann das Einfügen von Werten in ein oder mehrere Felder eines Deskriptors eines anderen Formats beinhalten, selbst wenn die Werte in einem Deskriptor, der übersetzt wird, nicht vorhanden sind. Verschiedene Beispiele betreffen einen VDEV-Treiber, der einem FDR oder einem Deskriptorübersetzer einen leeren Deskriptor bereitstellt, und einen FDR oder einen Deskriptorübersetzer, der einem VDEV-Treiber einen Deskriptor für ein empfangenes Paket bereitstellt.
Wie in 4 A gezeigt, stellt ein VDEV-Treiber dem FDR oder dem Deskriptorübersetzer einen Deskriptor 400 bereit. Dieser Rx-Deskriptor ist ein älteres Intel® 82599-NIC-Format. Ein VDEV-Treiber kann einen Pufferadresswert in den Bits [63:0] bereitstellen. Die Felder VLAN-Tag, Fehler, Status, Fragmentprüfsumme und Länge werden auf null initialisiert und können bei Paketempfang durch die NIC gefüllt werden.
Ein FDR oder ein Deskriptorübersetzer kann das Deskriptorformat 400 in das Rx-Deskriptorformat 402 umwandeln, wobei eine Intel® E800-NIC verwendet wird. Ein FDR oder ein Deskriptorübersetzer kann Pufferadressbits in die entsprechenden Bits des Deskriptorformats 402 kopieren, wobei ein ursprünglicher älterer 16-Byte-Deskriptor in einen 32-Byte-Deskriptor übersetzt wird.
Wie in 4 B gezeigt, stellt die NIC einen Rx-Deskriptor, der einem empfangenen Paket entspricht, zurück an den VDEV-Treiber bereit. Die NIC empfängt ein Paket, kopiert es durch Direktspeicherzugriff in die Pufferadresse und markiert den Rx-Deskriptor als vollständig. Ein FDR oder ein Deskriptorübersetzer kann den Rx-Deskriptor in das Format 450 übersetzen und entsprechende Felder extrahieren, um sie in das Deskriptorformat 452 einzufügen. Übersetzung und Abbildung können so durchgeführt werden, dass etwa die Feldlänge in Bits geändert und nur gültige Bits kopiert werden. Zum Beispiel können Informationen in L2TAG1 des Deskriptors 450 in einen VLAN-Tag des Deskriptors 452 übersetzt und übermittelt werden; Informationen im Feld Fehler des Deskriptors 450 können übersetzt und in das Feld Fehler des Deskriptors 452 übermittelt werden; Informationen in Status des Deskriptors 450 können übersetzt und in den Status des Deskriptors 452 übermittelt werden; und Informationen in Länge des Deskriptors 450 können übersetzt und seine Informationen in Länge des Deskriptors 452 übermittelt werden. Die Fragmentprüfsumme ist in dem NIC-Deskriptor nicht vorhanden, so dass der FDR eine Rohprüfsumme berechnen kann, um ihren Wert bei Bedarf an den VDEV-Treiber bereitzustellen.
Wieder Bezug nehmend auf 3 kann der VDEV-Treiber 304 unter Verwendung eines Steuerpfads eine Tunnel-Einkapselung/-Entkapselung konfigurieren oder an den FDR 320 oder irgendeine Software, die auf der NIC 330 ausgeführt wird, auslagern.
5 zeigt ein Beispiel für die Verwendung mehrerer NICs für eine VEE. Der FDR 510 kann den Deskriptorring 512-0 für die NIC 520-0 und den Deskriptorring 512-1 für die NIC 520-1 bereitstellen. In diesem Beispiel können der VDEV-Treiber 504-0 für dev#0 und der VDEV-Treiber 504-1 für dev#1, die in der VEE 502 ausgeführt werden, mit dem FDR 510 kommunizieren. Der FDR 510 kann eine Deskriptorumwandlung von Sende- und Empfangsdeskriptoren von einem Format, das durch die NICs 520-0 und 520-1 ordnungsgemäß lesbar ist, in ein Format, das durch eine virtuelle Schnittstelle ordnungsgemäß lesbar ist, durchführen, wobei der jeweilige VDEV-Treiber 504-0 für dev#0 und der VDEV-Treiber 504-1 für dev#1 in der VEE 502 ausgeführt werden und umgekehrt. In manchen Beispielen kann die NIC 520-0 ein gleiches oder ein anderes Tx- und Rx-Deskriptorformat als das durch die NIC 520-1 verwendete unterstützen. Obwohl zwei NICs gezeigt sind, kann eine beliebige Anzahl von NICs verwendet werden, die das gleiche oder andere Tx- oder Rx-Deskriptorformate nutzen. Es können mehrere Instanzen des FDR 510 genutzt werden.
6 stellt ein Beispiel für die Verwendung mehrerer Gast-VEEs dar, die mehrere NICs nutzen. Der FDR 610 kann den Deskriptorring 612-0 für die NIC 620-0 und den Deskriptorring 612-1 für die NIC 620-1 bereitstellen. In diesem Beispiel können der VDEV-Treiber 604-0 für die VEE 602-0 und der VDEV-Treiber 604-1 für die VEE 602-0 mit dem FDR 610 kommunizieren. Der FDR 610 kann eine Deskriptorumwandlung von Sende- und Empfangsdeskriptoren von einem Format, das durch die NICs 620-0 und 620-1 ordnungsgemäß lesbar ist, in ein Format, das durch eine virtuelle Schnittstelle, den jeweiligen VDEV-Treber 604-0 und den VDEV-Treiber 604-1 und umgekehrt ordnungsgemäß lesbar ist, durchführen. In manchen Beispielen kann die NIC 620-0 ein gleiches oder ein anderes Tx- und Rx-Deskriptorformat als das durch die NIC 620-1 verwendete unterstützen. Obwohl zwei NICs gezeigt sind, kann eine beliebige Anzahl von NICs verwendet werden, die das gleiche oder andere Tx- oder Rx-Deskriptorformate nutzen. Es können mehrere Instanzen des FDR 610 genutzt werden.
7 A stellt einen beispielhaften Prozess zum Einrichten der Verwendung von Deskriptorübersetzung und einer NIC dar. Bei 702 kann eine Verbindung zwischen einem Deskriptorformatübersetzer und einer VEE gebildet werden. Der Deskriptorformatübersetzer kann zum Beispiel als ein PCIe-Endpunkt, wie etwa eine virtuelle Vorrichtung (z. B. VF oder VirtIO) oder eine PF, zu einer VEE dargestellt werden. Zum Beispiel kann ein virtueller Schnittstellentreiber die Verbindung zwischen dem Deskriptorformatübersetzer und der VEE aufbauen.
Bei 704 kann der Deskriptorformatübersetzer eingerichtet werden, um einer NIC Zugriff auf Deskriptoren bereitzustellen. Zum Beispiel kann ein PF-Host-Treiber den Deskriptorformatübersetzer initialisieren und ihn mit einer NIC verbinden, so dass der Deskriptorformatübersetzer Rx- oder Tx-Deskriptorringe für den Zugriff durch die NIC zuordnen kann und die NIC auf Deskriptoren von Ringen aus zugreift, die durch den Deskriptorformatübersetzer identifiziert werden. Zum Beispiel kann der PF-Host-Treiber die NIC programmieren, um Sende- und Empfangsdeskriptorringe in einem Speicherbereich zu identifizieren, der durch den Deskriptorformatübersetzer verwaltet und zur Verwendung durch die NIC zugeordnet wird. In manchen Beispielen kann der Deskriptorformatübersetzer die virtuelle Funktion ADI (z. B. VF oder ADI) der NIC programmieren, um Deskriptoren unter Verwendung von Deskriptoren in dem Speicherbereich, der durch den Deskriptorformatübersetzer verwaltet wird, zu lesen oder zu schreiben. Die NIC kann auf Deskriptoren von den Deskriptorringen aus zugreifen, die durch den Deskriptorformatübersetzer verwaltet werden. Die Deskriptorringe, auf die die NIC zugreifen kann, können im Deskriptorformatübersetzerspeicher oder im Systemspeicher zugeordnet werden. In manchen Beispielen können separate Ringe für Sende- und Empfangsdeskriptoren zugeordnet werden. Andere Einrichtungsoperationen können für die Vorrichtung durchgeführt werden, wie etwa IOMMU-Konfiguration (IOMMU: Input - Output Memory Management Unit), die einen DMA-fähigen E/A-Bus mit dem Hauptspeicher verbindet, Interrupt-Einrichtung und so weiter.
Bei 706 kann die virtuelle Schnittstelle eine Deskriptorübersetzung einrichten, die durch den Deskriptorformatübersetzer durchzuführen ist, so dass das Deskriptorformat, das durch die NIC empfangen oder durch die VEE oder ihre virtuelle Schnittstelle gelesen wird, ordnungsgemäß gelesen wird. Die Art der Deskriptorübersetzung kann spezifiziert werden, um einen Quelldeskriptor bitweise und/oder feldweise in einen Zieldeskriptor zu übersetzen.
Bei 708 kann die VEE beim Starten einer VEE eine PCIe-Erkennung durchführen und den Deskriptorformatübersetzer erkennen. Die VEE kann unter Verwendung eines virtuellen Vorrichtungstreibers Deskriptoren lesen oder in Ringe schreiben, die von dem Deskriptorformatübersetzer verwaltet werden und diesem zuordnet sind, als ob die VEE direkt mit der NIC kommunizieren würde.
7 B stellt einen beispielhaften Prozess zum Verwenden einer Deskriptorübersetzung mit einer NIC für eine Paketübertragung dar. Bei 750 aktualisiert eine VEE in Verbindung mit einer Paketübertragungsanforderung einen Sendedeskriptor, um zu sendende Daten zu identifizieren. Bei anderen Beispielen kann der Sendedeskriptor für eine NIC oder eine andere Vorrichtung eine Arbeitsanforderung angeben. Bei 752 kann ein Deskriptorformatübersetzer auf den Sendedeskriptor von einem Sendedeskriptorring aus zugreifen und eine Übersetzung des Deskriptors basierend auf seiner Konfiguration durchführen. Die Deskriptorformatübersetzung kann eines oder mehrere von Folgendem beinhalten: Kopieren eines oder mehrerer Felder von einem ersten Deskriptor in einen zweiten Deskriptor; Erweitern oder Kontrahieren von Inhalt in einem oder mehreren Feldern in einem ersten Deskriptor und Schreiben des erweiterten oder kontrahierten Inhalts in ein oder mehrere Felder in einem zweiten Deskriptor; Füllen mit Inhalt oder Leerlassen eines oder mehrerer Felder des zweiten Deskriptors, wobei ein oder mehrere solche Felder im ersten Deskriptor nicht ausgefüllt werden; und so weiter. In manchen Beispielen kann zur Deskriptorumwandlung ein bitweises Umwandlungsschema angewendet werden. Der erste Deskriptor kann ein Format aufweisen, das durch einen virtuellen Schnittstellentreiber erzeugt wird, und das zweite Format kann ein Format sein, das durch die NIC lesbar ist. In manchen Beispielen wird keine Deskriptorformatübersetzung durchgeführt, falls das durch den Gerätetreiber verwendete Deskriptorformat durch die NIC unterstützt wird. Der Deskriptorformatübersetzer kann Zeiger auf übersetzte Deskriptoren in einem Sendedeskriptorring für einen Zugriff durch die NIC platzieren.
Bei 754 kann die NIC eine Paketübertragung basierend auf einem Zugriff auf einen Sendedeskriptor von einem Deskriptorring durchführen, der durch den Deskriptorformatübersetzer verwaltet wird. Die NIC kann Nutzdaten aus einem Speicherpuffer durch eine DMA-Operation basierend auf Pufferinformationen in den Sendedeskriptor kopieren. Die NIC kann den Sendedeskriptor aktualisieren, um anzugeben, dass die Übertragung abgeschlossen ist. Der aktualisierte Sendedeskriptor kann durch den Deskriptorformatübersetzer in ein durch den virtuellen Schnittstellentreiber lesbares Format übersetzt werden.
7 C stellt einen beispielhaften Prozess zum Verwenden einer Deskriptorübersetzung mit einer NIC in Reaktion auf einen Paketempfang dar. Bei 770 kann die NIC in Verbindung mit einem Paketempfang den Empfangsdeskriptor lesen, um einen Datenspeicherungsort im Speicher eines Teils der Nutzdaten des empfangenen Pakets zu identifizieren. Die NIC kann Felder in dem Empfangsdeskriptor ausfüllen, wie etwa zum Angeben einer Prüfsummenvalidierung oder anderer Paketmetadaten. Der Empfangsdeskriptor kann in einem Ring identifiziert werden, der durch einen Deskriptorformatübersetzer verwaltet wird. Die NIC kann Nutzdaten des empfangenen Pakets unter Verwendung einer DMA-Operation in einen Zielpufferort kopieren, der in dem Empfangsdeskriptor identifiziert ist. In anderen Beispielen kann der Empfangsdeskriptor für eine NIC oder eine andere Vorrichtung eine Arbeitsanforderung angeben.
Bei 772 kann ein Deskriptorformatübersetzer auf den Empfangsdeskriptor von einem Empfangsdeskriptorring aus zugreifen und eine Übersetzung des Deskriptors basierend auf seiner Konfiguration durchführen. Die Formatübersetzung kann eines oder mehrere von Folgendem beinhalten: Kopieren eines oder mehrerer Felder von einem ersten Deskriptor in einen zweiten Deskriptor; Erweitern oder Kontrahieren von Inhalt in einem oder mehreren Feldern in einem ersten Deskriptor und Schreiben des erweiterten oder kontrahierten Inhalts in ein oder mehrere Felder in einem zweiten Deskriptor; Füllen mit Inhalt oder Leerlassen eines oder mehrerer Felder des zweiten Deskriptors, wobei ein oder mehrere solche Felder im ersten Deskriptor nicht ausgefüllt werden; und so weiter. In manchen Beispielen kann zur Deskriptorumwandlung ein bitweises Umwandlungsschema angewendet werden. Der erste Deskriptor kann ein Format aufweisen, das durch die NIC lesbar ist und durch sie modifiziert werden kann, und das zweite Format kann ein Format sein, das durch den virtuellen Schnittstellentreiber lesbar ist. Der Deskriptorformatübersetzer kann Zeiger auf übersetzte Deskriptoren in einem Empfangsdeskriptorring für einen Zugriff durch den virtuellen Schnittstellentreiber platzieren. In manchen Beispielen wird keine Deskriptorformatübersetzung durchgeführt, falls das durch die NIC verwendete Deskriptorformat ordnungsgemäß durch den Gerätetreiber lesbar ist.
Bei 774 kann der virtuelle Schnittstellentreiber auf den übersetzten Empfangsdeskriptor zugreifen und der VEE ermöglichen, auf Paketnutzdaten zuzugreifen, auf die durch den übersetzten Empfangsdeskriptor verwiesen wird.
Während Beispiele, die in 7 A-7 C beschrieben sind, sich auf eine NIC- oder Netzwerkschnittstellenvorrichtung beziehen, können verschiedene Ausführungsformen für eine beliebige Arbeitslastdeskriptorformatübersetzung für eine Vorrichtung gelten, wie etwa einen Beschleuniger, einen Hardwarewarteschlangenmanager (HQM: hardware queue manager), eine Warteschlangenverwaltungsvorrichtung (QMD: queue management device), eine Datenspeichersteuerung, eine Datenspeichervorrichtung, einen Beschleuniger und so weiter.
KONFIGURIERBARE ANZAHL ZUGÄNGLICHER VORRICHTUNGSWARTESCHLANGEN
8 stellt einen Überblick über verschiedene Ausführungsformen bereit, die Warteschlangen für N Container, die in einer VM oder Bare-Metal-Umgebung ausgeführt werden, bereitstellen können. Verschiedene Ausführungsformen konfigurieren eine Anzahl von Warteschlangen (VQs) in der Vorrichtung 820 für einen Zugriff (z. B. Lesen oder Schreiben) durch VEEs, indem sie eine Anzahl virtueller Vorrichtungen, die in der vDPA-Anwendung 810 als aktiv konfiguriert sind, konfigurieren. Es können andere Frameworks verwendet werden, wie etwa VirtIO. In manchen Beispielen wird die vDPA-Anwendung 810 im Benutzerraum ausgeführt, kann aber auch im Kemelraum ausgeführt werden. Die vDPA-Anwendung 810 kann In manchen Beispielen auf einem vDPA-Framework basieren, das unter Verwendung von DPDK oder QEMU entwickelt wird. In manchen Beispielen kann eine aktive virtuelle Vorrichtung in der vDPA-Anwendung 810 ein vHost-Ziel (vhost target) sein. Um eine 1:1-Abbildung von Warteschlangen an VEEs bereitzustellen, kann eine Anzahl von vHost-Zielen (z. B. vhost-tgt) durch einen Eingangsparameter bestimmt werden, überschreitet aber möglicherweise nicht die Anzahl von VirtIO-Warteschlangen oder Warteschlangen, die in der Vorrichtung 820 verfügbar sind.
Eine virtuelle Vorrichtung (z. B. vHost-Ziel) in der vDPA-Anwendung 810 kann die Steuerebene und die Datenebene für eine VEE (z. B. VM 802 und ihre Container oder Container, die in der Bare-Metal-Umgebung 804 laufen) bereitstellen. Auf eine E/A-Warteschlange (VQ) in der Vorrichtung 820 (z. B. Speichersteuerung oder Netzwerkschnittstelle) kann von einer entsprechenden virtuellen Vorrichtung aus Eins-zu-Eins zugegriffen werden. E/A-Warteschlangen in der Vorrichtung 820, die für eine VF (SR-IOV) oder ADI (SIOV) zugeordnet sind, können erhöht oder verringert und eingesetzten VEEs zugewiesen werden, indem eine Anzahl aktiver virtueller Vorrichtungen in der vDPA-Anwendung 810 erhöht oder verringert wird. Eine VF oder ADI kann Konnektivität zwischen einer virtuellen Vorrichtung in der vDPA-Anwendung 810 und der Vorrichtung 820 zur Mandantenisolation bereitstellen. Eine einzelne isolierte Instanz (z. B. VF oder ADI) kann mit einer VEE assoziiert sein. Auf diese Weise kann eine gemeinsame Nutzung der Vorrichtung 820 mit einer Isolation von E/A-Warteschlangen erreicht werden. Virtuelle Vorrichtungen könnten entweder ein dediziertes physisches Warteschlangenpaar aufweisen oder ein physisches Warteschlangenpaar mit anderen virtuellen Vorrichtungen gemeinsam nutzen.
Eine Schnittstelle zwischen einer VEE und einer vDPA-Anwendung 810 kann durch eine vHost-Bibliothek als ein vHost-Ziel implementiert werden. Ein VirtIO-Treiber, der in einer VEE ausgeführt wird, kann sich mit dem vHost-Ziel und der Vorrichtung 820 durch das vDPA-Framework oder die Anwendung 810 verbinden. Das vDPA-Framework oder die Anwendung 810 kann das vHost-Ziel mit der Vorrichtung 820 verbinden. Wenn die Vorrichtung 820 SR-IOV unterstützt, kann ein Zugriff durch eine PF oder eine VF genutzt werden. Die vDPA-Anwendung 810 kann mit einer PF oder einer VF als eine Vorrichtung interagieren. In manchen Beispielen kann das Verbinden einer VEE mit einem SmartNIC unter Verwendung von SIOV Zugriff auf Merkmale einer VirtIO-Warteschlange bereitstellen, einschließlich Ratenbegrenzung und Warteschlangenplanung usw. Die Weiterleitung auf Datenebene zwischen der Vorrichtung 820 zu einer VEE kann verwendet werden, um Verzögerungen bei der Daten- oder Deskriptorübertragung zu reduzieren.
In manchen Beispielen kommunizieren virtuelle Vorrichtungen mit VEEs unter Verwendung eines VirtIO-Treibers. Deskriptoren können von einer VEE an eine virtuelle Vorrichtung unter Verwendung eines VirtIO-Rings weitergeleitet und einer entsprechenden E/A-Warteschlange der Vorrichtung 820 bereitgestellt werden. In manchen Beispielen können virtuelle Vorrichtungen, die in der vDPA-Anwendung 810 konfiguriert sind, auf Deskriptor-VirtIO-Ringe zugreifen. Die VirtIO-Datenebene kann von einer VEE auf die VF der Vorrichtung 820 abgebildet werden.
Ein beispielhafter Pseudocode der vDPA-Anwendung 810, der eine konfigurierte Anzahl von vHost-Zielen aufweist, wird nachstehend gezeigt.

 cmd: vdpa -1 0,2 -socket-mem 1024 -w 0000:00:02.0, vdpa=1, mapping=128 -- --iface
 /tmp/vdpa
 // mapping=128 bedeutet Start von 128 vHost-Zielen.
 VDPA-Prozess:
 vdpa_app.c:
 start_vdpa():
       vhost_driver_register();
       vhost_driver_attach_vdpa_device();
       vhost_driver_start()
 ifc.c:
 pci_dev_probe(): input mapping
       pci_dev->num_queueus = get_pci_capability();
       vdpa->mappings = (pci_dev->num_queues > mapping) ? mapping : pci_dev-

      >num_queues;

       for (i = 0; i < vdpa->mapping; i++) {
       }vdpa_register_device(vdpa, ops);
       }
ops {
       open = vdpa_config,
       };
 vdpa_config():
       updata_datapath();
 updata_ datapath():
       dma _map(); 

       enable_intr();
       vdpa_start();
vdpa_start():
       set_vring_base();
       start_hw();

Diverse Ausführungsformen, die die vDPA-Anwendung 810 verwenden, können Flexibilität bereitstellen, um eine Anzahl von VEEs und entsprechende Warteschlangen in der Vorrichtung 820 zu skalieren. Verschiedene Ausführungsformen ermöglichen die Verwendung einer üblicherweise verwendeten Schnittstelle, wie etwa eines VirtIO-Treibers für eine VEE, um auf die vDPA-Anwendung 810 zuzugreifen. In manchen Fällen muss die Treibermodifikation möglicherweise nicht an einer VEE oder Software vorgenommen werden, die in der VEE ausgeführt wird, um einen Eins-zu-Eins-VEE-zu-Vorrichtungswarteschlangenzugriff zu unterstützen.

9 stellt einen beispielhaften Prozess zum Zuordnen von Warteschlangen einer Vorrichtung zu einer virtualisierten Ausführungsumgebung dar. Bei 902 kann beim Vorrichtungsstart eine Anzahl von Eingabe-/Ausgabe(E/A)-Warteschlangen in der Vorrichtung zugeordnet werden. Zum Beispiel kann eine maximal zulässige Anzahl von E/A-Warteschlangen in der Vorrichtung zugeordnet werden. In manchen Beispielen beinhaltet die Vorrichtung unter anderem eine Datenspeichersteuerung, eine Datenspeichervorrichtung, eine Netzwerkschnittstellenkarte, einen Hardwarewarteschlangenmanager (HQM), einen Beschleuniger.

Bei 904 kann bei einer Zwischenanwendung eine Anzahl virtueller Ziele zugeordnet werden, wobei die Anzahl virtueller Ziele einer Anzahl von E/A-Warteschlangen entspricht, die VEEs Eins-zu-Eins zuzuordnen sind. Die Zwischenanwendung kann zum Beispiel eine vDPA-Anwendung sein, die unter Verwendung von DPDK oder QEMU entwickelt wurde. Zum Beispiel kann eine Anzahl von E/A-Warteschlangen unter den zugeordneten E/A-Warteschlangen an der Vorrichtung durch Hinzufügen oder Löschen von vHost-Zielen in einer vDPA-Anwendung eingestellt werden. Eine Anzahl von E/A-Warteschlangen kann gemäß der Anzahl von vHost-Zielen in der vDPA-Anwendung hoch- oder herunterskaliert werden. Eine Anzahl von vHost-Zielen und entsprechenden E/A-Warteschlangen kann spezifiziert werden, wenn eine vDPA-Anwendung gestartet wird oder durch einen Fernprozeduraufruf (RPC)-Befehl.

10 stellt ein Beispiel für einen Warteschlangenzugriff durch eine VEE über ein vHost-Ziel dar. In manchen Beispielen kann eine Eingabe-/Ausgabe(E/A)-Verarbeitung zwischen VEE und vHost-Ziel durch VirtIO-Warteschlangen (virtqueue) umgesetzt werden. In manchen Beispielen kann eine VirtIO-Warteschlange verwendet werden, um einen Index zu einem verfügbaren (avail) Ring, der einem Deskriptor in einer Deskriptortabelle entspricht, und/oder einen Eintragsindex zu einem verwendeten Ring, der einem Deskriptor in einer Deskriptortabelle entspricht, zu übertragen. In manchen Beispielen nutzen eine VEE und ein vHost-Ziel den Lese- und Schreibzugriff auf eine VirtIO-Warteschlange gemeinsam und eine vDPA-Anwendung stellt eine Weiterleitung von Einträgen in der VirtIO-Warteschlange zu der virtuellen Warteschlange (VQ) der Vorrichtung bereit. Die vDPA-Anwendung kann Kommunikation zwischen dem VirtIO-Treiber der VEE und zwischen dem vHost-Ziel und der(den) E/A-Warteschlange(n) bereitstellen.

In manchen Beispielen kann eine VEE zum Senden einer E/A-Anforderung (z. B. Lesen oder Schreiben) an die Vorrichtung einen freien (verfügbaren) Deskriptoreintrag aus der Deskriptortabelle lokalisieren, die im Speicher im Host gespeichert ist und bei 1002 durch die VEE mit der vDPA-Anwendung (als vDPA gezeigt) gemeinsam genutzt wird. In diesem Beispiel ist ein freier Eintrag ein desc mit Index 0 (desc 0). Die VEE setzt eine E/A-Anforderung in desc 0 ein, setzt den verfügbaren (avail) Eintragswert am Ringende 0 ein und benachrichtigt ein vHost-Ziel durch Senden eines Benachrichtigungsereignisses über einen VirtIO-Treiber. Der Deskriptor kann eine E/A-Anforderung identifizieren, einschließlich Anforderung(req), Daten und Antwort(rsp). Ein Deskriptor kann einen Befehl (z. B. Lesen oder Schreiben), eine Adresse von Daten, auf die im Speicher zuzugreifen ist, eine Länge von Daten, auf die zuzugreifen ist, und andere Informationen, wie etwa Sektor- oder Antwortstatus, spezifizieren. Ein Deskriptor kann auf eine Adresse im Speicher zeigen, auf die die Vorrichtung unter Verwendung einer Direktspeicherzugriff(DMA)-Operation zugreifen kann. Bei 1004 kann die Vorrichtung über eine VirtIO-Warteschlange auf den Deskriptor zugreifen. Die VEE kann auf eine Rückmeldung von dem vHost-Ziel warten und den verwendeten Ring prüfen, um zu sehen, welche E/A-Anforderung abgeschlossen ist, und den abgeschlossenen Deskriptor auf Leerlauf setzen.

Ein spezielles vHost-Ziel kann durch eine Benachrichtigung ausgelöst werden, die durch den Treiber einer VEE gesendet wird, um den verfügbaren (avail) Ring zu prüfen, um zu bestimmen, welcher Deskriptor (desc) die E/A-Anforderung von der VEE beinhaltet. Das vHost-Ziel kann den Deskriptor in dem verfügbaren (avail) Ring verarbeiten. Nachdem die durch den Deskriptor spezifizierte E/A-Operation abgeschlossen ist, kann das vHost-Ziel den verwendeten Ring aktualisieren, um den Abschluss in einem Antwortstatus anzugeben, und die VEE durch Senden eines Benachrichtigungsereignisses benachrichtigen.

In manchen Beispielen kann, falls die Vorrichtung eine Datenspeichersteuerung oder Datenspeichervorrichtung (z. B. mit einer oder mehreren nichtflüchtigen Speichervorrichtungen) zum Zugriff auf eine Datenspeichervorrichtung ist, eine einzige VirtIO-Warteschlange verwendet werden, um Anforderungen zu senden und Antworten zu empfangen. Die VEE kann eine VirtIO-Warteschlange verwenden, um einen Index für einen verfügbaren Ring bereitzustellen, um einen Deskriptor an das vHost-Ziel weiterzuleiten, und das vHost-Ziel kann die VirtIO-Warteschlange mit einem Index für einen verwendeten Ring an die VEE aktualisieren. Das Schreiben in den Datenspeicher kann ein Schreibbefehl sein und das Lesen aus dem Datenspeicher kann ein Lesebefehl sein. Für einen Schreib- oder Lesebefehl kann ein freier Eintrag in der Deskriptortabelle identifiziert und mit dem Befehl gefüllt werden, der dieses Schreiben oder Lesen angibt, wo die Daten geschrieben oder ausgelesen werden sollten. Der Deskriptor kann an einem Endeintrag des verfügbaren Rings über eine VirtIO-Warteschlange identifiziert werden und dann kann das vHost-Ziel über einen verfügbaren Deskriptor benachrichtigt werden. Nachdem das vHost-Ziel die E/A-Operation abgeschlossen hat, kann es das Ergebnis der Verarbeitung über den Status schreiben, dann den verwendeten Ring aktualisieren und den Indexwert des Deskriptors in den Endeintrag des verwendeten Rings schreiben, dann die VEE benachrichtigen. Die VEE kann den verwendeten Ring über die VirtIO-Warteschlange lesen und den Deskriptor erhalten, um zu bestimmen, dass die E/A-Anforderung erfolgreich abgeschlossen ist oder nicht, und dass sich Daten im Speicher befinden, auf die der Datenzeiger zeigt. In manchen Beispielen kann Deskriptorformatumwandlung verwendet werden, um Deskriptoren unter Verwendung von hier beschriebenen Ausführungsformen zu modifizieren.

In manchen Beispielen können, falls die Vorrichtung eine Netzwerkvorrichtung ist, zwei VirtIO-Warteschlangen verwendet werden, wie etwa eine Empfangs-VirtIO-Warteschlange und eine Sende-VirtIO-Warteschlange. Eine Sende-VirtIO-Warteschlange kann von einer VEE verwendet werden, um Anforderungen an ein vHost-Ziel zu senden. Eine Empfangs-VirtIO-Warteschlange kann von einer VEE verwendet werden, um Anforderungen von einem vHost-Ziel anzunehmen. Unterschiedliche VirtIO-Warteschlangen können eine unabhängige Kommunikation bereitstellen.

11 stellt ein Beispiel für eine VirtIO-Block-Anforderungs- (req), Datenzugriffs- und Antwort- (resp) Formatsequenz dar. Das Codesegment struct virtio blk req kann ein Format einer VirtIO-Block-Anforderung darstellen.

12 zeigt einen beispielhaften Pseudocode einer Konfiguration einer VirtIO-Warteschlange, die eine Konfiguration pro Warteschlange bereitstellt, einschließlich einer Konfiguration von mxixs_vector, enable und notify_off. Dementsprechend kann eine Warteschlange individuell konfiguriert und aktiviert werden.

13 stellt ein beispielhaftes System dar. Beliebige der Vorrichtungen hier (z. B. Beschleuniger, Netzwerkschnittstelle, Datenspeichervorrichtung und so weiter) können die hier beschriebene Deskriptorformatumwandlung nutzen. Das System 1300 beinhaltet einen Prozessor 1310, der Verarbeitung, Betriebsverwaltung und Ausführung von Anweisungen für das System 1300 bereitstellt. Der Prozessor 1310 kann eine beliebige Art von Mikroprozessor, Zentralverarbeitungseinheit (CPU), Grafikverarbeitungseinheit (GPU), Verarbeitungskern oder anderer Verarbeitungshardware zum Bereitstellen von Verarbeitung für das System 1300 oder eine Kombination von Prozessoren beinhalten. Der Prozessor 1310 steuert den Gesamtbetrieb des Systems 1300 und kann ein oder mehrere programmierbare Allzweck- oder Spezialzweckmikroprozessoren, Digitalsignalprozessoren (DSPs), programmierbare Steuerungen, anwendungsspezifische integrierte Schaltungen (ASICs), programmierbare Logikvorrichtungen (PLDs) oder dergleichen oder eine Kombination solcher Vorrichtungen sein oder beinhalten.

In einem Beispiel beinhaltet das System 1300 eine Schnittstelle 1312, die mit dem Prozessor 1310 gekoppelt ist, die eine Schnittstelle mit höherer Geschwindigkeit oder eine Schnittstelle mit hohem Durchsatz für Systemkomponenten darstellen kann, die Verbindungen mit höherer Bandbreite benötigen, wie etwa das Speichersubsystem 1320 oder die Grafikschnittstellenkomponenten 1340 oder der Beschleuniger 1342. Die Schnittstelle 1312 repräsentiert eine Schnittstellenschaltung, die eine eigenständige Komponente sein oder auf einem Prozessor-Die integriert sein kann. Wo vorhanden, bildet die Grafikschnittstelle 1340 mit Grafikkomponenten eine Schnittstelle, um einem Benutzer des Systems 1300 eine visuelle Anzeige bereitzustellen. In einem Beispiel kann die Grafikschnittstelle 1340 eine HD(High Definition)-Anzeige ansteuern, die einem Benutzer eine Ausgabe liefert. Eine hohe Auflösung kann sich auf eine Anzeige mit einer Pixeldichte von näherungsweise 100 PPI (Pixel pro Zoll) oder mehr beziehen und kann Formate, wie etwa Full-HD (z. B. 1080 p), Retina-Displays, 4 K (Ultrahochauflösung oder UHD) oder andere beinhalten. In einem Beispiel kann die Anzeige eine Berührungsbildschirm-Anzeige beinhalten. In einem Beispiel erzeugt die Grafikschnittstelle 1340 eine Anzeige basierend auf Daten, die in dem Speicher 1330 gespeichert sind, oder basierend auf Operationen, die durch den Prozessor 1310 ausgeführt werden, oder beides. In einem Beispiel erzeugt die Grafikschnittstelle 1340 eine Anzeige basierend auf Daten, die in dem Speicher 1330 gespeichert sind, oder basierend auf Operationen, die durch den Prozessor 1310 ausgeführt werden, oder beides.

Die Beschleuniger 1342 können eine programmierbare oder Festfunktions-Offload-Engine sein, auf die von einem Prozessor 1310 zugegriffen werden kann oder die von diesem verwendet werden kann. Ein Beschleuniger unter den Beschleunigern 1342 kann zum Beispiel Komprimierungsfähigkeit (DC-Fähigkeit), Kryptographiedienste, wie etwa Public-Key-Verschlüsselung (PKE), Chiffrierung, Hash-/Authentifizierungsfähigkeiten, Entschlüsselung oder andere Fähigkeiten oder Dienste bereitstellen. Bei manchen Ausführungsformen stellt zusätzlich oder alternativ dazu ein Beschleuniger unter den Beschleunigern 1342 Feldauswahlsteuerungsfähigkeiten, wie hier beschrieben, bereit. In manchen Fällen können Beschleuniger 1342 in einen CPU-Sockel (zum Beispiel einen Verbinder zu einer Hauptplatine oder Leiterplatte, die eine CPU beinhaltet und eine elektrische Schnittstelle mit der CPU bereitstellt) integriert sein. Die Beschleuniger 1342 können zum Beispiel einen Einzel- oder Mehrkernprozessor, eine Grafikverarbeitungseinheit, einen Einzel- oder Mehrebenen-Cache einer logischen Ausführungseinheit, Funktionseinheiten, die zum unabhängigen Ausführen von Programmen oder Threads verwendet werden können, anwendungsspezifische integrierte Schaltungen (ASICs), Neuronalnetzwerkprozessoren (NNPs), programmierbare Steuerlogik und programmierbare Verarbeitungselemente, wie etwa feldprogrammierbare Gate-Arrays (FPGAs) beinhalten. Beschleuniger 1342 können mehrere neuronale Netzwerke, CPUs, Prozessorkerne, Universal-Grafikverarbeitungseinheiten bereitstellen oder Grafikverarbeitungseinheiten können zur Verwendung durch künstliche Intelligenz (AI) oder Modelle zum maschinellen Lernen (ML) verfügbar gemacht werden. Das AI-Modell kann zum Beispiel eines oder eine Kombination der Folgenden verwenden oder beinhalten: ein Verstärkungs-Lernsystem, Q-Lernsystem, Deep-Q-Lernen oder Asynchronous Advantage Actor-Critic (A3C), kombinatorisches neuronales Netzwerk, rekurrentes kombinatorisches neuronales Netzwerk oder ein anderes AI- oder ML-Modell. Mehrere neuronale Netzwerke, Prozessorkerne oder Grafikverarbeitungseinheiten können zur Verwendung durch AI- oder ML-Modelle verfügbar gemacht werden.

Das Speichersubsystem 1320 repräsentiert den Hauptspeicher des Systems 1300 und stellt Speicherung für Code, der von dem Prozessor 1310 ausgeführt werden soll, oder Datenwerte, die beim Ausführen einer Routine verwendet werden sollen, bereit. Das Speichersubsystem 1320 kann eine oder mehrere Speichervorrichtungen 1330, wie etwa einen Nur-Lese-Speicher (ROM), einen Flash-Speicher, eine oder mehrere Arten von Direktzugriffsspeicher (RAM), wie etwa DRAM oder andere Speichervorrichtungen, oder eine Kombination solcher Vorrichtungen beinhalten. Der Speicher 1330 speichert und hostet unter anderem das Betriebssystem (OS) 1332, um eine Softwareplattform zur Ausführung von Anweisungen im System 1300 bereitzustellen. Außerdem können Anwendungen 1334 auf der Softwareplattform des OS 1332 aus dem Speicher 1330 ausgeführt werden. Die Anwendungen 1334 stellen Programme dar, die ihre eigene Betriebslogik aufweisen, um die Ausführung einer oder mehrerer Funktionen auszuführen. Die Prozesse 1336 stellen Agenten oder Routinen dar, die dem OS 1332 oder einer oder mehreren Anwendungen 1334 oder einer Kombination davon Hilfsfunktionen bereitstellen. Das OS 1332, die Anwendungen 1334 und die Prozesse 1336 stellen Softwarelogik bereit, um Funktionen für das System 1300 bereitzustellen. In einem Beispiel beinhaltet das Speichersubsystem 1320 die Speichersteuerung 1322, die eine Speichersteuerung zum Erzeugen und Ausgeben von Befehlen an den Speicher 1330 ist. Es versteht sich, dass die Speichersteuerung 1322 ein physischer Teil des Prozessors 1310 oder ein physischer Teil der Schnittstelle 1312 sein könnte. Zum Beispiel kann die Speichersteuerung 1322 eine integrierte Speichersteuerung sein, die in einer Schaltung mit dem Prozessor 1310 integriert ist.

Obwohl dies nicht spezifisch veranschaulicht ist, versteht es sich, dass das System 1300 einen oder mehrere Busse oder Bussysteme zwischen Vorrichtungen beinhalten kann, wie etwa einen Speicherbus, einen Grafikbus, Schnittstellenbusse oder andere. Busse oder andere Signalleitungen können Komponenten kommunikativ oder elektrisch miteinander koppeln oder die Komponenten sowohl kommunikativ als auch elektrisch koppeln. Busse können physische Kommunikationsleitungen, Punkt-zu-Punkt-Verbindungen, Brücken, Adapter, Steuerungen oder andere Schaltungen oder eine Kombination davon beinhalten. Busse können zum Beispiel einen Systembus und/oder einen Peripheral Component Interconnect(PCI)-Bus und/oder einen Hyper Transport- oder Industriestandard-Architektur(ISA)-Bus und/oder einen Small Computer System Interface(SCSI)-Bus und/oder einen Universal Serial Bus (USB) oder einen Institute of Electrical and Electronics Engineers(IEEE)-Standard 1394-Bus (Firewire) beinhalten.

In einem Beispiel beinhaltet das System 1300 die Schnittstelle 1314, die mit der Schnittstelle 1312 gekoppelt sein kann. In einem Beispiel stellt die Schnittstelle 1314 eine Schnittstellenschaltung dar, die eigenständige Komponenten und integrierte Schaltungen beinhalten kann. In einem Beispiel sind mehrere Benutzerschnittstellenkomponenten oder Peripheriekomponenten oder beide mit der Schnittstelle 1314 gekoppelt. Die Netzwerkschnittstelle 1350 stellt dem System 1300 die Fähigkeit bereit, mit entfernten Vorrichtungen (z. B. Servern oder anderen Rechenvorrichtungen) über ein oder mehrere Netzwerke zu kommunizieren. Die Netzwerkschnittstelle (z. B. NIC) 1350 kann einen Ethernet-Adapter, Drahtlosverbindungskomponenten, Mobilfunknetzwerkverbindungskomponenten, USB (Universal Serial Bus) oder andere drahtgebundene oder drahtlose standardbasierte oder proprietäre Schnittstellen beinhalten. Die Netzwerkschnittstelle 1350 kann Daten an eine Vorrichtung übertragen, die sich in demselben Rechenzentrum oder Rack befindet, oder an eine entfernte Vorrichtung, die Senden von im Speicher gespeicherten Daten beinhalten kann. Die Netzwerkschnittstelle 1350 kann Daten von einer entfernten Vorrichtung empfangen, was Speichern empfangener Daten in einem Speicher beinhalten kann. Verschiedene Ausführungsformen können in Verbindung mit der Netzwerkschnittstelle 1350, dem Prozessor 1310 und dem Speichersubsystem 1320 verwendet werden.

Manche Beispiele für die Netzwerkvorrichtung 1350 sind Teil einer Infrastrukturverarbeitungseinheit (IPU) oder Datenverarbeitungseinheit (DPU) oder werden von einer IPU oder DPU genutzt. Eine IPU oder DPU kann eine Netzwerkschnittstelle mit einem oder mehreren programmierbaren oder Festfunktionsprozessoren beinhalten, um ein Auslagern von Operationen durchzuführen, die durch eine CPU durchgeführt worden sein könnten. Die IPU oder DPU kann eine oder mehrere Speichervorrichtungen beinhalten. In manchen Beispielen kann die IPU oder DPU virtuelle Umschaltoperationen durchführen, Datenspeichertransaktionen (z. B. Komprimierung, Kryptographie, Virtualisierung) verwalten und Operationen verwalten, die auf anderen IPUs, DPUs, Servern oder Vorrichtungen durchgeführt werden.

In manchen Beispielen können die Warteschlangen in der Netzwerkschnittstelle 1350 unter Verwenden virtueller Ziele, die in einer vDPA-Anwendung, wie hier beschrieben, konfiguriert sind und auf die unter Verwenden von VEEs zugegriffen werden kann, erhöht oder verringert werden.

In einem Beispiel weist das System 1300 eine oder mehrere Eingabe-/Ausgabe(E/A)-Schnittstellen 1360 auf. Die E/A-Schnittstelle 1360 kann eine oder mehrere Schnittstellenkomponenten beinhalten, über die ein Benutzer mit dem System 1300 interagiert (z. B. akustisch, alphanumerisch, taktil/berührend oder eine andere Schnittstellenbildung). Die Peripherieschnittstelle 1370 kann eine beliebige Hardwareschnittstelle beinhalten, die vorstehend nicht spezifisch erwähnt ist. Peripheriegeräte beziehen sich allgemein auf Vorrichtungen, die sich abhängig von dem System 1300 verbinden. Eine abhängige Verbindung ist eine Verbindung, bei der das System 1300 die Softwareplattform oder Hardwareplattform oder beide bereitstellt, auf der die Operation ausgeführt wird und mit der ein Benutzer interagiert.

In einem Beispiel beinhaltet das System 1300 das Datenspeichersubsystem 1380, um Daten auf eine nichtflüchtige Weise zu speichern. In einem Beispiel können sich in bestimmten Systemumsetzungen zumindest bestimmte Komponenten des Datenspeichers 1380 mit Komponenten des Speichersubsystems 1320 überlappen. Das Datenspeichersubsystem 1380 beinhaltet eine oder mehrere Datenspeichervorrichtungen 1384, die ein beliebiges herkömmliches Medium zum Speichern großer Datenmengen auf nichtflüchtige Weise sein können oder beinhalten können, wie etwa eine oder mehrere magnetische, Festkörper- oder optische Platten oder eine Kombination davon. Der Datenspeicher 1384 hält Code oder Anweisungen und Daten 1386 in einem persistenten Zustand (zum Beispiel wird der Wert trotz Unterbrechung der Stromversorgung des Systems 1300 beibehalten). Der Datenspeicher 1384 kann allgemein als ein „Speicher“ angesehen werden, obwohl der Speicher 1330 in der Regel der Ausführungs- oder Arbeitsspeicher ist, um dem Prozessor 1310 Anweisungen bereitzustellen. Während der Datenspeicher 1384 nichtflüchtig ist, kann der Speicher 1330 flüchtigen Speicher beinhalten (zum Beispiel ist der Wert oder Zustand der Daten unbestimmt, falls die Stromversorgung zum System 1300 unterbrochen wird). In einem Beispiel beinhaltet das Datenspeichersubsystem 1380 eine Steuerung 1382 zum Bilden einer Schnittstelle mit dem Datenspeicher 1384. In einem Beispiel ist die Steuerung 1382 ein physischer Teil der Schnittstelle 1314 oder des Prozessors 1310 oder kann Schaltungen oder Logik sowohl im Prozessor 1310 als auch in der Schnittstelle 1314 beinhalten.

Ein flüchtiger Speicher ist ein Speicher, dessen Zustand (und damit die in ihm gespeicherten Daten) unbestimmt ist, wenn die Stromversorgung zur Vorrichtung unterbrochen wird. Dynamischer flüchtiger Speicher erfordert ein Auffrischen der in der Vorrichtung gespeicherten Daten, um den Zustand beizubehalten. Ein Beispiel für dynamischen flüchtigen Speicher beinhaltet DRAM (Dynamic Random Access Memory) oder irgendeine Variante, wie etwa synchronen DRAM (SDRAM). Ein anderes Beispiel für flüchtigen Speicher beinhaltet Cache oder statischen Direktzugriffsspeicher (SRAM). Ein Speichersubsystem, wie hier beschrieben, kann mit einer Anzahl von Speichertechnologien kompatibel sein, wie etwa mit DDR3 (Double Data Rate Version 3, Originalversion von JEDEC (Joint Electronic Device Engineering Council) am 27. Juni 2007), DDR4 (DDR Version 4, erste Spezifikation veröffentlicht im September 2012 von JEDEC), DDR4E (DDR Version 4), LPDDR3 (Low Power DDR Version 3, JESD209-3B, August 2013 von JEDEC), LPDDR4) LPDDR Version 4, JESD209-4, ursprünglich veröffentlicht von JEDEC im August 2014), WIO2 (Wide Input/Output Version 2, JESD229-2, ursprünglich veröffentlicht von JEDEC im August 2014, HBM (High Bandwidth Memory, JESD325, ursprünglich veröffentlicht von JEDEC im Oktober 2013, LPDDR5 (gegenwärtig diskutiert von JEDEC), HBM2 (HBM Version 2), gegenwärtig diskutiert von JEDEC, oder andere oder Kombinationen von Speichertechnologien und Technologien basierend auf Ableitungen oder Erweiterungen derartiger Spezifikationen. Die JEDEC-Standards sind bei www.jedec.org verfügbar.

Eine nichtflüchtige Speicher(NVM)-Vorrichtung ist ein Speicher, dessen Zustand bestimmt ist, selbst wenn Strom zu der Vorrichtung unterbrochen wird. Bei manchen Ausführungsformen kann die NVM-Vorrichtung eine blockadressierbare Speichervorrichtung umfassen, wie etwa NAND-Technologien, oder insbesondere NAND-Flash-Speicher mit mehreren Bitebenen (zum Beispiel Single-Level-Cell („SLC“, ein Bit pro Zelle), Multi-Level-Cell („MLC“, mehr als ein Bit pro Zelle), Quad-Level-Cell („QLC“, vier Bit pro Zelle), Tri-Level-Cell („TLC“, drei Bit pro Zelle) oder irgendein anderes NAND). Eine NVM-Vorrichtung kann auch eine byteadressierbare dreidimensionale Crosspoint-Speichervorrichtung für Schreibvorgänge an Ort und Stelle oder eine andere byteadressierbare NVM-Vorrichtung für Schreibvorgänge an Ort und Stelle (auch als persistenter Speicher bezeichnet), wie etwa einen Phasenwechselspeicher (PCM) mit einer oder mehreren Bitebenen oder Phasenwechselspeicher mit einem Schalter (PCMS), NVM-Vorrichtungen, die Chalkogenid-Phasenwechselmaterial (zum Beispiel Chalkogenidglas) verwenden, resistiven Speicher einschließlich Speicher auf Metalloxidbasis, Sauerstoffleerstellenbasis und Direktzugriffsspeicher auf Basis von leitfähigen Brücken (CB-RAM: Conductive Bridge Random Access Memory), Nanodrahtspeicher, ferroelektrischen Direktzugriffsspeicher (FeRAM, FRAM), magnetoresistiven Direktzugriffsspeicher (MRAM), der Memristortechnologie beinhaltet, Spindrehmoment(STT)-MRAM, eine Spintronik-Magnetübergangsspeicher-basierte Vorrichtung, eine MTJ-basierte (MTJ: Magnetic Tunnel Junction) Vorrichtung, eine DW (Domain Wall)- und SOT(Spin Orbit Transfer)-basierte Vorrichtung, eine Speichervorrichtung auf Thyristorbasis oder eine Kombination beliebiger der vorstehenden oder einen anderen Speicher umfassen.

Eine Stromquelle (nicht abgebildet) versorgt die Komponente des Systems 1300 mit Strom. Konkret bildet die Stromquelle in der Regel mit einer oder mehreren Stromversorgungen im System 1300 eine Schnittstelle, um die Komponenten des Systems 1300 mit Strom zu versorgen. In einem Beispiel beinhaltet die Stromversorgung einen AC-DC-Adapter (Wechselstrom-zu-Gleichstrom-Adapter) zum Anschließen an eine Wandsteckdose. Ein solcher Wechselstrom kann eine Stromquelle mit erneuerbarer Energie (z. B. Solarenergie) sein. In einem Beispiel beinhaltet die Stromquelle eine Gleichstromquelle, wie etwa einen externen AC-DC-Wandler. In einem Beispiel beinhaltet die Stromquelle oder die Stromversorgung drahtlose Ladehardware zum Laden über die Nähe zu einem Ladefeld. In einem Beispiel kann die Stromquelle eine interne Batterie, eine Wechselstromquelle, eine bewegungsbasierte Stromversorgung, eine Solarstromquelle oder eine Brennstoffzellenquelle beinhalten.

In einem Beispiel kann das System 1300 unter Verwendung von miteinander verbundenen Rechenschlitten von Prozessoren, Speichern, Datenspeichern, Netzwerkschnittstellen und anderen Komponenten implementiert werden. Es können Hochgeschwindigkeits-Interconnects verwendet werden, wie etwa PCIe, Ethernet oder optische Interconnects (oder eine Kombination davon).

14 bildet eine Umgebung 1400 ab, die mehrere Rechen-Racks 1402 beinhaltet, die jeweils einen Top-of-Rack-Switch (ToR-Switch) 1404, einen Pod-Manager 1406 und mehrere gepoolte Systemeinschübe beinhalten. Verschiedene Vorrichtungen in der Umgebung 1400 können hier beschriebene Ausführungsformen zur Deskriptorformatumwandlung und/oder zum virtuellen Warteschlangenzugriff unter Verwendung eines Deskriptors verwenden, der virtuelle Ziele in einer vDPA-Anwendung durchläuft. Allgemein können die gepoolten Systemeinschübe gepoolte Recheneinschübe und gepoolte Datenspeichereinschübe beinhalten. Gegebenenfalls können die gepoolten Systemeinschübe auch gepoolte Speichereinschübe und gepoolte Eingabe-/Ausgabe(E/A)-Einschübe beinhalten. Bei der veranschaulichten Ausführungsform weisen die gepoolten Systemeinschübe einen gepoolten Intel®-XEON®-Computereinschub 1408 und einen gepoolten Intel®-ATOM™-Computereinschub 1410, einen gepoolten Datenspeichereinschub 1412, einen gepoolten Speichereinschub 1414 und einen gepoolten E/A-Einschub 1416 auf. Jeder der gepoolten Systemeinschübe ist über eine Hochgeschwindigkeitsverbindung 1418, wie etwa eine Ethernet-Verbindung oder eine optische Siliciumphotonik (SiPh)-Verbindung, mit dem ToR-Switch 1404 verbunden.

Mehrere der Rechen-Racks 1402 können über ihre ToR-Switches 1404 (zum Beispiel mit einem Pod-Level-Switch oder Rechenzentrum-Switch) miteinander verbunden sein, wie durch Verbindungen mit einem Netzwerk 1420 veranschaulicht ist. Bei manchen Ausführungsformen werden Gruppen von Rechen-Racks 1402 als separate Pods über einen oder mehrere Pod-Manager 1406 verwaltet. Bei manchen Ausführungsformen wird ein einziger Pod-Manager verwendet, um alle Racks in dem Pod zu verwalten. Alternativ dazu können verteilte Pod-Manager für Pod-Management-Operationen verwendet werden.

Die Umgebung 1400 beinhaltet ferner eine Verwaltungsschnittstelle 1422, die zum Verwalten verschiedener Aspekte der Umgebung verwendet wird. Dies beinhaltet das Verwalten der Rack-Konfiguration mit entsprechenden als Rack-Konfigurationsdaten 1424 gespeicherten Parametern. Die Umgebung 1400 kann für Rechen-Racks verwendet werden.

Ausführungsformen können hier in verschiedenen Arten von Rechen- und Networking-Ausrüstung umgesetzt werden, wie etwa Switches, Router, Racks und Blade-Server, wie etwa jenen, die in einem Rechenzentrum und/oder einer Serverfarmumgebung eingesetzt werden. Die in Rechenzentren und Serverfarmen verwendeten Server umfassen gereihte Serverkonfigurationen, wie rackbasierte Server oder Blade-Server. Diese Server stehen über verschiedene Netzwerkbereitstellungen miteinander in Kommunikation, wie etwa Partitionssätze von Servern in lokalen Netzwerken (LANs: Local Area Networks) mit geeigneten Switching- und Routingeinrichtungen zwischen den LANs, um ein privates Intranet zu bilden. Cloud-Hosting-Einrichtungen zum Beispiel können in der Regel große Rechenzentren mit einer Vielzahl von Servern einsetzen. Ein Blade umfasst eine separate Rechenplattform, die dazu konfiguriert ist, Servertyp-Funktionen durchzuführen, das heißt einen „Server auf einer Karte (Server-on-a-Card)“. Dementsprechend beinhaltet jedes Blade Komponenten, die bei herkömmlichen Servern üblich sind, einschließlich einer Leiterplatte (Hauptplatine), die interne Verdrahtungen (zum Beispiel Busse) zum Koppeln geeigneter integrierter Schaltungen (ICs) bereitstellt, und anderer Komponenten, die auf der Platine befestigt sind.

Verschiedene Beispiele können unter Verwendung von Hardwareelementen, Softwareelementen oder einer Kombination von beiden implementiert werden. In manchen Beispielen können Hardwareelemente Vorrichtungen, Komponenten, Prozessoren, Mikroprozessoren, Schaltungen, Schaltungselemente (z. B. Transistoren, Widerstände, Kondensatoren, Induktivitäten und so weiter), integrierte Schaltungen, ASICs, PLDs, DSPs, FPGAs, Speichereinheiten, Logikgatter, Register, Halbleitervorrichtungen, Chips, Mikrochips, Chipsätze und so weiter beinhalten. In manchen Beispielen können Softwareelemente Softwarekomponenten, Programme, Anwendungen, Computerprogramme, Anwendungsprogramme, Systemprogramme, Maschinenprogramme, Betriebssystemsoftware, Middleware, Firmware, Softwaremodule, Routinen, Subroutinen, Funktionen, Verfahren, Prozeduren, Softwareschnittstellen, APIs, Befehlssätze, Rechencode, Computercode, Codesegmente, Computercodesegmente, Wörter, Werte, Symbole oder eine beliebige Kombination davon. beinhalten. Das Bestimmen, ob ein Beispiel unter Verwendung von Hardwareelementen und/oder Softwareelementen implementiert wird, kann gemäß einer beliebigen Anzahl von Faktoren variieren, wie etwa einer gewünschten Rechenrate, Strompegeln, Wärmetoleranzen, Verarbeitungszyklusbudget, Eingangsdatenraten, Ausgangsdatenraten, Speicherressourcen, Datenbusgeschwindigkeiten und anderen Gestaltungs- oder Leistungsbeschränkungen, wie für eine gegebene Implementierung gewünscht. Es wird angemerkt, dass Hardware-, Firmware- und/oder Softwareelemente hier gemeinsam oder einzeln als „Modul“ oder „Logik“ bezeichnet werden können. Ein Prozessor kann eine oder mehrere Kombinationen aus einer Hardwarezustandsmaschine, digitaler Steuerlogik, Zentralverarbeitungseinheit oder beliebigen Hardware-, Firmware- und/oder Softwareelementen sein.

Manche Beispiele können unter Verwenden eines oder als ein Herstellungsartikel oder mindestens ein computerlesbares Medium implementiert werden. Ein computerlesbares Medium kann ein nicht-transitorisches Datenspeichermedium zum Speichern von Logik beinhalten. In manchen Beispielen kann das nicht-transitorische Datenspeichermedium einen oder mehrere Typen computerlesbarer Datenspeichermedien beinhalten, die elektronische Daten speichern können, einschließlich flüchtigen Speichers oder nichtflüchtigen Speichers, entfernbaren oder nicht entfernbaren Speichers, löschbaren oder nicht löschbaren Speichers, beschreibbaren oder wiederbeschreibbaren Speichers und so weiter. In manchen Beispielen kann die Logik verschiedene Softwareelemente, wie etwa Softwarekomponenten, Programme, Anwendungen, Computerprogramme, Anwendungsprogramme, Systemprogramme, Maschinenprogramme, Betriebssystemsoftware, Middleware, Firmware, Softwaremodule, Routinen, Subroutinen, Funktionen, Verfahren, Prozeduren, Softwareschnittstellen, API, Anweisungssätze, Rechencode, Computercode, Codesegmente, Computercodesegmente, Wörter, Werte, Symbole oder eine beliebige Kombination davon beinhalten.

Gemäß einigen Beispielen kann ein computerlesbares Medium ein nicht-transitorisches Datenspeichermedium zum Speichern oder Beibehalten von Anweisungen beinhalten, die, wenn sie von einer Maschine einer Recheneinrichtung oder einem System ausgeführt werden, die Maschine, die Rechenvorrichtung oder das System veranlassen, Verfahren und/oder Operationen gemäß den beschriebenen Beispielen auszuführen. Die Anweisungen können einen beliebigen geeigneten Typ von Code beinhalten, wie etwa Quellcode, kompilierten Code, interpretierten Code, ausführbaren Code, statischen Code, dynamischen Code und dergleichen. Die Anweisungen können gemäß einer vordefinierten Computersprache, Art und Weise oder Syntax implementiert werden, um eine Maschine, eine Rechenvorrichtung oder ein System anzuweisen, eine gewisse Funktion durchzuführen. Die Anweisungen können unter Verwendung einer beliebigen geeigneten höheren, niedrigeren, objektorientierten, visuellen, kompilierten und/oder interpretierten Programmiersprache implementiert werden.

Ein oder mehrere Aspekte mindestens eines Beispiels können durch repräsentative Anweisungen implementiert werden, die auf mindestens einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logik innerhalb des Prozessors darstellt, die, wenn sie durch eine Maschine, eine Rechenvorrichtung oder ein System gelesen werden, die Maschine, die Rechenvorrichtung oder das System veranlassen, Logik herzustellen, um die hier beschriebenen Techniken durchzuführen. Solche Repräsentationen, die als „IP-Kerne“ bekannt sind, können auf einem greifbaren, maschinenlesbaren Medium gespeichert werden und verschiedenen Kunden oder Herstellungsanlagen zugeführt werden, um in die Herstellungsmaschinen geladen zu werden, die tatsächlich die Logik oder den Prozessor herstellen.

Das Auftreten des Ausdrucks „ein Beispiel“ bezieht sich nicht notwendigerweise jedes Mal auf dasselbe Beispiel oder dieselbe Ausführungsform. Jeder hier beschriebene Aspekt kann mit jedem anderen hier beschriebenen Aspekt oder ähnlichen Aspekt, unabhängig davon, ob die Aspekte in Bezug auf dieselbe Figur oder dasselbe Element beschrieben sind, kombiniert werden. Eine Unterteilung, Weglassung oder Einschließung von in den begleitenden Figuren abgebildeten Blockfunktionen bedeutet nicht, dass die Hardwarekomponenten, Schaltungen, Software und/oder Elemente zum Umsetzen dieser Funktionen notwendigerweise in Ausführungsformen unterteilt, weggelassen oder eingeschlossen sein müssen.

Einige Beispiele können unter Verwenden des Ausdrucks „gekoppelt“ und „verbunden“ mit ihren jeweiligen Ableitungen beschrieben sein. Diese Begriffe sind nicht notwendigerweise als synonym zueinander zu betrachten. Beschreibungen, die die Begriffe „verbunden“ und/oder „gekoppelt“ verwenden, können z. B. angeben, dass sich zwei oder mehr Elemente in direktem physischen oder elektrischen Kontakt miteinander befinden. Der Begriff „gekoppelt“ kann jedoch auch bedeuten, dass zwei oder mehrere Elemente nicht in direktem Kontakt miteinander stehen, jedoch immer noch miteinander zusammenwirken oder interagieren.

Die Begriffe „erster“, „zweiter“ und dergleichen bezeichnen hier keine Reihenfolge, Menge oder Wichtigkeit, sondern werden eher verwendet, um ein Element von einem anderen zu unterscheiden. Die Begriffe „ein“ und „eine“ bezeichnen hier keine Mengenbeschränkung, sondern bezeichnen eher das Vorhandensein mindestens eines der genannten Elemente. Der Begriff „aktivgesetzt“, der hier in Bezug auf ein Signal verwendet wird, bezeichnet einen Zustand des Signals, in dem das Signal aktiv ist und der erreicht werden kann, indem ein beliebiger Logikpegel entweder logisch 0 oder logisch 1 an das Signal angelegt wird. Die Begriffe „folgend“ oder „nach“ können sich auf unmittelbar folgend oder nach einem anderen Ereignis oder Ereignissen folgend beziehen. Auch andere Abfolgen von Schritten können gemäß alternativen Ausführungsformen durchgeführt werden. Darüber hinaus können abhängig von den jeweiligen Anwendungen zusätzliche Schritte hinzugefügt oder entfernt werden. Es kann eine beliebige Kombination von Änderungen verwendet werden und ein Durchschnittsfachmann würde anhand dieser Offenbarung die vielen Variationen, Modifikationen und alternativen Ausführungsformen davon verstehen.

Disjunktive Sprache, wie etwa der Ausdruck „mindestens eines von X, Y oder Z“, sofern nicht ausdrücklich anders angegeben, wird im Kontext verstanden, wie er allgemein verwendet wird, um darzustellen, dass ein Element, ein Begriff usw. entweder X, Y oder Z oder eine beliebige Kombination davon (z. B. X, Y und/oder Z) sein kann. Somit soll und sollte eine solche disjunktive Ausdrucksweise im Allgemeinen nicht bezwecken, dass bestimmte Ausführungsformen erfordern, dass jeweils mindestens eines von X, mindestens eines von Y oder mindestens eines von Z vorhanden ist. Zusätzlich sollte konjunktive Sprache, wie etwa der Ausdruck „mindestens eines von X, Y und Z“, sofern nicht ausdrücklich anders angegeben, auch als X, Y, Z oder eine beliebige Kombination davon verstanden werden, einschließlich „X, Y und/oder Z“.

Veranschaulichende Beispiele der hier offenbarten Vorrichtungen, Systeme und Verfahren sind nachstehend bereitgestellt. Eine Ausführungsform der Vorrichtungen, Systeme und Verfahren kann eines oder mehrere der nachstehend beschriebenen Beispiele und jede Kombination davon beinhalten.

Flussdiagramme wie hier dargestellt stellen Beispiele für Abläufe verschiedener Prozessaktionen bereit. Die Flussdiagramme können Operationen, die von einer Software- oder Firmware-Routine auszuführen sind, sowie physische Operationen angeben. Bei manchen Ausführungsformen kann ein Flussdiagramm den Zustand eines endlichen Zustandsautomaten (Finite State Machine - FSM) veranschaulichen, der in Hardware und/oder Software implementiert sein kann. Obgleich sie in einer bestimmten Sequenz oder Reihenfolge gezeigt sind, kann die Reihenfolge der Handlungen modifiziert werden, sofern nichts anderes angegeben ist. Dementsprechend sollten die veranschaulichten Ausführungsformen nur als ein Beispiel verstanden werden und der Prozess kann in einer anderen Reihenfolge durchgeführt werden und manche Handlungen können parallel durchgeführt werden. Außerdem können eine oder mehrere Handlungen bei verschiedenen Ausführungsformen ausgelassen werden; es sind also nicht alle Handlungen in jeder Ausführungsform notwendig. Andere Prozessflüsse sind möglich.

Verschiedene hier beschriebene Komponenten können ein Mittel zum Durchführen der beschriebenen Operationen oder Funktionen sein. Jede hier beschriebene Komponente beinhaltet Software, Hardware oder eine Kombination davon. Die Komponenten können als Softwaremodule, Hardwaremodule, Spezialhardware (z. B. anwendungsspezifische Hardware, anwendungsspezifische integrierte Schaltungen (ASICs), Digitalsignalprozessoren (DSPs) usw.), eingebettete Steuerungen, festverdrahtete Schaltungsanordnungen und so weiter implementiert werden.

Beispiel 1 beinhaltet ein Verfahren, das Folgendes umfasst: Bereitstellen eines Zugriffs auf einen Deskriptor für eine Vorrichtung, wobei der Deskriptor ein erstes Format einer Organisation von Feldern und Feldgrößen umfasst; basierend darauf, dass sich das erste Format des Deskriptors von einem zweiten Format des Deskriptors unterscheidet, das mit einer zweiten Vorrichtung assoziiert ist: Durchführen einer Übersetzung des Deskriptors von dem ersten Format in das zweite Format und Speichern des übersetzten Deskriptors in dem zweiten Format für einen Zugriff durch die zweite Vorrichtung; und basierend darauf, dass das erste Format des Deskriptors mit dem zweiten Format des Deskriptors übereinstimmt, das mit der zweiten Vorrichtung assoziiert ist, Speichern des Deskriptors für einen Zugriff durch die zweite Vorrichtung.

Beispiel 2 beinhaltet ein oder mehrere andere Beispiele, wobei das erste Format mit einem Treiber assoziiert ist und Folgendes umfasst: basierend darauf, dass die zweite Vorrichtung einen zweiten Deskriptor des zweiten Formats bereitstellt: Durchführen einer Übersetzung des zweiten Deskriptors von dem zweiten Format in das erste Format, das mit dem Treiber assoziiert ist, und Speichern des übersetzten zweiten Deskriptors für einen Zugriff durch den Treiber.

Beispiel 3 beinhaltet ein oder mehrere andere Beispiele und beinhaltet Folgendes: Zugreifen auf den übersetzten Deskriptor durch die zweite Vorrichtung; Modifizieren des Inhalts des übersetzten Deskriptors durch die zweite Vorrichtung, um eine Arbeitsanforderung zu identifizieren; Durchführen einer Übersetzung des modifizierten übersetzten Deskriptors in das erste Format; und Speichern des übersetzten modifizierten übersetzten Deskriptors für einen Zugriff durch einen Treiber.

Beispiel 4 beinhaltet ein oder mehrere andere Beispiele und beinhaltet Folgendes: basierend auf einer Änderung von der zweiten Vorrichtung zu einer dritten Vorrichtung und darauf, dass die dritte Vorrichtung mit einem Deskriptorformat assoziiert ist, das sich von dem ersten Format des Deskriptors unterscheidet, Nutzen eines Treibers für die zweite Vorrichtung zum Kommunizieren von Deskriptoren zu und von der dritten Vorrichtung basierend auf einer Deskriptorübersetzung.

Beispiel 5 beinhaltet ein oder mehrere andere Beispiele, wobei die zweite Vorrichtung eines oder mehrere von Folgendem umfasst: eine Netzwerkschnittstellensteuerung (NIC), eine Infrastrukturverarbeitungseinheit (IPU), eine Datenspeichersteuerung und/oder eine Beschleunigervorrichtung.

Beispiel 6 beinhaltet ein oder mehrere andere Beispiele und beinhaltet Folgendes: Durchführen einer Zwischenanwendung, die mit einem oder mehreren virtuellen Zielen zur Kommunikation einer Deskriptorkennung von einer oder mehreren virtualisierten Ausführungsumgebungen (VEEs) zu einer oder mehreren entsprechenden Warteschlangen der zweiten Vorrichtung konfiguriert ist, wobei virtuelle Ziele Eins-zu-eins VEEs entsprechen und die virtuellen Ziele Eins-zu-eins Warteschlangen der zweiten Vorrichtung entsprechen.

Beispiel 7 beinhaltet ein oder mehrere andere Beispiele, wobei die Zwischenanwendung auf virtueller Datenpfadbeschleunigung (vDPA) basiert.

Beispiel 8 beinhaltet ein oder mehrere andere Beispiele und beinhaltet Folgendes: eine Einrichtung, die Folgendes umfasst: einen Deskriptorformatübersetzer, auf den ein Treiber zugreifen kann, wobei: der Treiber und der Deskriptorformatübersetzer den Zugriff zum Senden und Empfangen von Deskriptoren gemeinsam nutzen und basierend auf einem Format eines Deskriptors, das mit einer Vorrichtung assoziiert ist, das sich von einem zweiten Format eines Deskriptors unterscheidet, das mit dem Treiber assoziiert ist, der Deskriptorformatübersetzer zu Folgendem ausgelegt ist: Durchführen einer Übersetzung des Deskriptors von dem Format in das zweite Format und Speichern des übersetzten Deskriptors in dem zweiten Format für einen Zugriff durch die Vorrichtung.

Beispiel 9 beinhaltet ein oder mehrere andere Beispiele, wobei: die Vorrichtung auf den übersetzten Deskriptor zugreifen soll; die Vorrichtung den Inhalt des übersetzten Deskriptors modifizieren soll, um mindestens eine Arbeitsanforderung zu identifizieren, und der Deskriptorformatübersetzer den modifizierten übersetzten Deskriptor in das Format übersetzen soll und den übersetzten modifizierten übersetzten Deskriptor für einen Zugriff durch den Treiber speichern soll.

Beispiel 10 beinhaltet ein oder mehrere andere Beispiele, wobei: basierend darauf, dass ein Format eines Deskriptors, das mit der Vorrichtung assoziiert ist, mit dem zweiten Format des Deskriptors übereinstimmt, das mit dem Treiber assoziiert ist, der Deskriptorformatübersetzer den Deskriptor für den Zugriff durch die Vorrichtung speichern soll.

Beispiel 11 beinhaltet ein oder mehrere andere Beispiele, wobei: die Vorrichtung eines oder mehrere von Folgendem umfasst: eine Netzwerkschnittstellensteuerung (NIC), eine Infrastrukturverarbeitungseinheit (IPU), eine Datenspeichersteuerung und/oder eine Beschleunigervorrichtung.

Beispiel 12 beinhaltet ein oder mehrere andere Beispiele und beinhaltet Folgendes: einen Server zum Ausführen einer virtualisierten Ausführungsumgebung (VEE), um eine Arbeitsleistung durch die Vorrichtung anzufordern oder mindestens eine Arbeitsanforderung von der Vorrichtung über den Deskriptorformatübersetzer zu empfangen.

Beispiel 13 beinhaltet ein oder mehrere andere Beispiele und beinhaltet Folgendes: ein nicht-transitorisches computerlesbares Medium, das darauf gespeicherte Anweisungen umfasst, die, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren zu Folgendem veranlassen: Durchführen einer Zwischenanwendung, die mit einem oder mehreren virtuellen Zielen zur Kommunikation einer Deskriptorkennung von einer oder mehreren virtualisierten Ausführungsumgebungen (VEEs) zu einer oder mehreren entsprechenden Vorrichtungswarteschlangen konfiguriert ist, wobei virtuelle Ziele VEEs Eins-zu-eins entsprechen und die virtuellen Ziele Vorrichtungswarteschlangen Eins-zu-eins entsprechen.

Beispiel 14 beinhaltet ein oder mehrere andere Beispiele, wobei die Zwischenanwendung mit virtueller Datenpfadbeschleunigung (vDPA) konsistent ist.

Beispiel 15 beinhaltet ein oder mehrere andere Beispiele, wobei eine Anzahl von Vorrichtungswarteschlangen, die VEEs zugeordnet sind, auf einer Anzahl virtueller Ziele basiert, die in der Zwischenanwendung konfiguriert sind.

Beispiel 16 beinhaltet ein oder mehrere andere Beispiele, wobei mindestens ein virtuelles Ziel ein vHost-Ziel umfasst.

Beispiel 17 beinhaltet ein oder mehrere andere Beispiele und beinhaltet Folgendes: Konfigurieren einer maximalen Anzahl an Vorrichtungswarteschlangen in der Vorrichtung beim Vorrichtungsstart.

Beispiel 18 beinhaltet ein oder mehrere andere Beispiele, wobei die Vorrichtung eines oder mehrere von Folgendem umfasst: eine Netzwerkschnittstellensteuerung (NIC), eine Infrastrukturverarbeitungseinheit (IPU), eine Datenspeichersteuerung und/oder eine Beschleunigervorrichtung.

Beispiel 19 beinhaltet ein oder mehrere andere Beispiele, wobei die Kommunikation einer Deskriptorkennung von einer oder mehreren VEEs zu einer oder mehreren entsprechenden Vorrichtungswarteschlangen eine Kommunikation unter Verwendung einer entsprechenden virtuellen Warteschlange umfasst.

Beispiel 20 beinhaltet ein oder mehrere andere Beispiele und beinhaltet Folgendes: ein nicht-transitorisches computerlesbares Medium, das darauf gespeicherte Anweisungen umfasst, die, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren zu Folgendem veranlassen: Ermöglichen, dass eine Netzwerkschnittstellensteuerung (NIC) Paketübertragungsanforderungen von einem virtuellen Funktionstreiber empfängt und dem virtuellen Funktionstreiber den Paketempfang angibt, wobei sich ein Deskriptorformat, das durch die virtuelle Funktion an die NIC bereitgestellt wird, von einer Kommunikation, die mit der NIC assoziiert ist, unterscheidet.

Beispiel 21 beinhaltet ein oder mehrere andere Beispiele, wobei: der virtuelle Funktionstreiber mit der NIC unter Verwendung eines Deskriptorübersetzers kommunizieren soll, wobei: der Deskriptorübersetzer einen Deskriptor von dem virtuellen Funktionstreiber empfangen soll, die Netzwerkschnittstellensteuerung mit dem Deskriptorübersetzer interagieren soll, der virtuelle Funktionstreiber ein erstes Deskriptorformat unterstützen soll, die Netzwerkschnittstellensteuerung ein zweites Deskriptorformat unterstützen soll und sich das erste Deskriptorformat von dem zweiten Deskriptorformat unterscheidet.

Claims

Verfahren, Folgendes umfassend: Bereitstellen eines Zugriffs auf einen Deskriptor für eine Vorrichtung, wobei der Deskriptor ein erstes Format einer Organisation von Feldern und Feldgrößen umfasst; basierend darauf, dass sich das erste Format des Deskriptors von einem zweiten Format des Deskriptors unterscheidet, das mit einer zweiten Vorrichtung assoziiert ist: Durchführen einer Übersetzung des Deskriptors aus dem ersten Format in das zweite Format und Speichern des übersetzten Deskriptors in dem zweiten Format für einen Zugriff durch die zweite Vorrichtung; und basierend darauf, dass das erste Format des Deskriptors mit dem zweiten Format des Deskriptors übereinstimmt, das mit der zweiten Vorrichtung assoziiert ist, Speichern des Deskriptors für einen Zugriff durch die zweite Vorrichtung.
Verfahren nach Anspruch 1, wobei das erste Format mit einem Treiber assoziiert ist und Folgendes umfasst: basierend darauf, dass die zweite Vorrichtung einen zweiten Deskriptor des zweiten Formats bereitstellt: Durchführen einer Übersetzung des zweiten Deskriptors aus dem zweiten Format in das erste Format, das mit dem Treiber assoziiert ist, und Speichern des übersetzten zweiten Deskriptors für einen Zugriff durch den Treiber.
Verfahren nach Anspruch 1, das Folgendes umfasst: Zugreifen auf den übersetzten Deskriptor durch die zweite Vorrichtung; Modifizieren, durch die zweite Vorrichtung, des Inhalts des übersetzten Deskriptors, um eine Arbeitsanforderung zu identifizieren; Durchführen einer Übersetzung des modifizierten übersetzten Deskriptors in das erste Format; und Speichern des übersetzten modifizierten übersetzten Deskriptors für einen Zugriff durch einen Treiber.
Verfahren nach Anspruch 1, das Folgendes umfasst: basierend auf einer Änderung von der zweiten Vorrichtung zu einer dritten Vorrichtung und darauf, dass die dritte Vorrichtung mit einem Deskriptorformat assoziiert ist, das sich von dem ersten Format des Deskriptors unterscheidet, Nutzen eines Treibers für die zweite Vorrichtung zum Kommunizieren von Deskriptoren zu und von der dritten Vorrichtung basierend auf einer Deskriptorübersetzung.
Verfahren nach Anspruch 1, das Folgendes umfasst: Durchführen einer Zwischenanwendung, die mit einem oder mehreren virtuellen Zielen zur Kommunikation einer Deskriptorkennung von einer oder mehreren virtualisierten Ausführungsumgebungen (VEEs) zu einer oder mehreren entsprechenden Warteschlangen der zweiten Vorrichtung konfiguriert ist, wobei virtuelle Ziele Eins-zu-eins VEEs entsprechen und die virtuellen Ziele Eins-zu-eins Warteschlangen der zweiten Vorrichtung entsprechen.
Verfahren nach Anspruch 5, wobei die Zwischenanwendung auf virtueller Datenpfadbeschleunigung (vDPA) basiert.
Verfahren nach einem der Ansprüche 1-6, wobei die zweite Vorrichtung eines oder mehrere von Folgendem umfasst: eine Netzwerkschnittstellensteuerung (NIC), eine Infrastrukturverarbeitungseinheit (IPU), eine Datenspeichersteuerung und/oder eine Beschleunigervorrichtung.
Einrichtung, Folgendes umfassend: eine Deskriptorformatübersetzerschaltungsanordnung, auf die ein Treiber zugreifen kann, wobei: der Treiber und die Deskriptorformatübersetzerschaltungsanordnung einen Zugriff zum Übertragen und zum Empfangen von Deskriptoren gemeinsam nutzen und basierend auf einem Format eines Deskriptors, das mit einer Vorrichtung assoziiert ist, das sich von einem zweiten Format eines Deskriptors unterscheidet, das mit dem Treiber assoziiert ist, die Deskriptorformatübersetzerschaltungsanordnung zu Folgendem ausgelegt ist: Durchführen einer Übersetzung des Deskriptors aus dem Format in das zweite Format und Speichern des übersetzten Deskriptors in dem zweiten Format für einen Zugriff durch die Vorrichtung.
Einrichtung nach Anspruch 8, wobei: die Vorrichtung auf den übersetzten Deskriptor zugreifen soll; die Vorrichtung den Inhalt des übersetzten Deskriptors modifizieren soll, um mindestens eine Arbeitsanforderung zu identifizieren; und die Deskriptorformatübersetzerschaltungsanordnung den modifizierten übersetzten Deskriptor in das Format übersetzen und den übersetzten modifizierten übersetzten Deskriptor für einen Zugriff durch den Treiber speichern soll.
Einrichtung nach Anspruch 8, wobei: basierend darauf, dass ein Format eines Deskriptors, das mit der Vorrichtung assoziiert ist, mit dem zweiten Format des Deskriptors übereinstimmt, das mit dem Treiber assoziiert ist, die Deskriptorformatübersetzerschaltungsanordnung den Deskriptor für einen Zugriff durch die Vorrichtung speichern soll.
Verfahren nach Anspruch 8, wobei die Vorrichtung eines oder mehrere von Folgendem umfasst: eine Netzwerkschnittstellensteuerung (NIC), eine Infrastrukturverarbeitungseinheit (IPU), eine Datenspeichersteuerung und/oder eine Beschleunigervorrichtung.
Einrichtung nach einem der Ansprüche 8-11, die Folgendes umfasst: einen Server zum Ausführen einer virtualisierten Ausführungsumgebung (VEE), um eine Arbeitsleistung durch die Vorrichtung anzufordern oder mindestens eine Arbeitsanforderung von der Vorrichtung über den Deskriptorformatübersetzer zu empfangen.
Nicht-transitorisches computerlesbares Medium, das darauf gespeicherte Anweisungen umfasst, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren zu Folgendem veranlassen: Durchführen einer Zwischenanwendung, die mit einem oder mehreren virtuellen Zielen zur Kommunikation einer Deskriptorkennung von einer oder mehreren virtualisierten Ausführungsumgebungen (VEEs) zu einer oder mehreren entsprechenden Warteschlangen konfiguriert ist, wobei virtuelle Ziele Eins-zu-eins VEEs entsprechen und die virtuellen Ziele Eins-zu-eins Warteschlangen entsprechen.
Computerlesbares Medium nach Anspruch 13, wobei die Zwischenanwendung mit virtueller Datenpfadbeschleunigung (vDPA) konsistent ist.
Computerlesbares Medium nach Anspruch 13, wobei eine Anzahl von Vorrichtungswarteschlangen, die VEEs zugeordnet sind, auf einer Anzahl virtueller Ziele basiert, die in der Zwischenanwendung konfiguriert sind.
Computerlesbares Medium nach Anspruch 13, wobei mindestens ein virtuelles Ziel ein vHost-Ziel umfasst.
Computerlesbares Medium nach Anspruch 13, das Folgendes umfasst: Konfigurieren einer maximalen Anzahl an Vorrichtungswarteschlangen in der Vorrichtung beim Vorrichtungsstart.
Computerlesbares Medium nach Anspruch 13, wobei die Kommunikation einer Deskriptorkennung von der einen oder den mehreren VEEs zu einer oder mehreren entsprechenden Vorrichtungswarteschlangen eine Kommunikation unter Verwendung einer entsprechenden virtuellen Warteschlange umfasst.
Computerlesbares Medium nach einem der Ansprüche 13-18, wobei die Vorrichtung eines oder mehrere von Folgendem umfasst: eine Netzwerkschnittstellensteuerung (NIC), eine Infrastrukturverarbeitungseinheit (IPU), eine Datenspeichersteuerung und/oder eine Beschleunigervorrichtung.
Nicht-transitorisches computerlesbares Medium, das darauf gespeicherte Anweisungen umfasst, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren zu Folgendem veranlassen: Ermöglichen, dass eine Netzwerkschnittstellensteuerung (NIC) Paketübertragungsanforderungen von einem virtuellen Funktionstreiber empfängt und dem virtuellen Funktionstreiber einen Paketempfang angibt, wobei sich ein Deskriptorformat, das durch die virtuelle Funktion an die NIC bereitgestellt wird, von einer Kommunikation, die mit der NIC assoziiert ist, unterscheidet.
Computerlesbares Medium nach Anspruch 20, wobei: der virtuelle Funktionstreiber mit der NIC unter Verwendung eines Deskriptorübersetzers kommunizieren soll, wobei: der Deskriptorübersetzer einen Deskriptor von dem virtuellen Funktionstreiber empfangen soll, die NIC mit dem Deskriptorübersetzer kommunikativ gekoppelt ist, der virtuelle Funktionstreiber ein erstes Deskriptorformat unterstützen soll, die NIC ein zweites Deskriptorformat unterstützen soll, und das erste Deskriptorformat sich von dem zweiten Deskriptorformat unterscheidet.