DE102023203519A1

DE102023203519A1 - Sitzungsbasierter direkter Fernarbeitsspeicherzugriff

Info

Publication number: DE102023203519A1
Application number: DE102023203519.7A
Authority: DE
Inventors: Liran Liss; Yamin Friedman; Michael Kagan; Diego Crupnicoff; Idan Burstein; Matty Kadosh; Tzah Oved; Dror Goldenberg; Ron Yuval Efraim; Alexander Eli Rosenbaum; Aviad Yehezkel; Rabia Loulou
Original assignee: Mellanox Technologies Ltd
Current assignee: Mellanox Technologies Ltd
Priority date: 2022-04-20
Filing date: 2023-04-18
Publication date: 2023-10-26
Also published as: US11765237B1; US12244670B2; US20230379390A1; CN116915832A

Abstract

Eine Vorrichtung zur Datenkommunikation beinhaltet eine Netzwerkschnittstelle zum Verbinden mit einem Paketdatennetzwerk und eine Host-Schnittstelle zum Verbinden mit einem Host-Computer, der eine Zentraleinheit (CPU) und einen Host-Arbeitsspeicher enthält. Die Paketverarbeitungsschaltung empfängt über die Host-Schnittstelle, von einem auf der CPU laufenden Kernel, Assoziationen zwischen mehreren RDMA-(Remote Direct Memory Access)-Sitzungen und mehreren verschiedenen UDP-(User Datagram Protocol)-5-Tupeln, die jeweils den RDMA-Sitzungen zugewiesen sind, und empfängt von einer auf der CPU laufenden Anwendung eine Anforderung zum Senden einer RDMA-Nachricht, unter Verwendung einer ausgewählten Gruppe von einer oder mehreren der RDMA-Sitzungen, zu einer Peer-Anwendung über das Paketdatennetz, und sendet als Reaktion auf die Anforderung über die Netzschnittstelle ein oder mehrere Datenpakete unter Verwendung eines einer der RDMA-Sitzungen in der ausgewählten Gruppe zugewiesenen UDP-5-Tupels.

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung bezieht sich allgemein auf Paketdatenkommunikationen und insbesondere auf Systeme und Verfahren für direkten Fernarbeitsspeicherzugriff (RDMA) .
HINTERGRUND
Datenpakete, die nach dem Internet-Protokoll (IP) übertragen werden, haben Paket-Header, die (neben anderen Feldern) eine Ziel-IP-Adresse, einen Ziel-Port, eine Quell-IP-Adresse, einen Quell-Port und eine Protokollnummer enthalten. Die Werte dieser fünf Felder werden zusammen als „IP 5-Tupel“ bezeichnet. Dieses 5-Tupel wird üblicherweise zum Identifizieren von Paketen und Paketflüssen für Routingzwecke und andere Netzwerkdienste verwendet. Die Protokollnummer identifiziert das in der IP-Paketnutzlast verwendete Protokoll der nächsten Ebene. So wird beispielsweise das User Datagram Protocol (UDP) durch die Protokollnummer 17 identifiziert. In der vorliegenden Beschreibung und in den Ansprüchen wird ein IP-5-Tupel, bei dem das Protokoll der nächsten Ebene UDP ist, auch als UDP-5-Tupel bezeichnet.
RDMA over Converged Ethernet (RoCE) ist ein Netzwerkprotokoll, das direkten Fernarbeitsspeicherzugriff (RDMA) über ein Ethernet-Netzwerk ermöglicht. RoCE v1 ist ein Ethernet-Verbindungsprotokoll, das die Kommunikation zwischen zwei beliebigen Hosts in derselben Ethernet-Broadcast-Domäne ermöglicht. RoCE v2 ist ein Internetschicht-Protokoll, das das Routen von RoCE-Paketen ermöglicht. Das RoCE v2-Protokoll läuft über UDP, d.h. der RoCE v2-Header und die Nutzlast werden in ein UDP/IP-Paket unter Verwendung der Zielportnummer 4791 im IP-Header eingekapselt.
ZUSAMMENFASSUNG
Die Erfindung wird durch die Ansprüche definiert. Zur Veranschaulichung der Erfindung werden hier Aspekte und Ausführungsformen beschrieben, die in den Umfang der Ansprüche fallen können oder auch nicht.
Die im Folgenden beschriebenen Ausführungsformen der vorliegenden Erfindung stellen verbesserte Verfahren für die RDMA-Kommunikation sowie Geräte, Systeme und Software bereit, die solche Verfahren implementieren.
Gemäß einer Ausführungsform der Erfindung wird daher eine Vorrichtung zur Datenkommunikation bereitgestellt, die eine Netzwerkschnittstelle zum Verbinden mit einem Paketdatennetzwerk und eine Host-Schnittstelle zum Verbinden mit einem Host-Computer umfasst, der eine Zentraleinheit (CPU) und einen Host-Arbeitsspeicher enthält. Paketverarbeitungsschaltung empfängt über die Host-Schnittstelle von einem auf der CPU laufenden Kernel Assoziationen zwischen mehreren RDMA-(Remote Direct Memory Access)-Sitzungen und mehreren verschiedenen UDP-(User Datagram Protocol)-5-Tupeln, die jeweils den RDMA-Sitzungen zugewiesen sind, und empfängt von einer auf der CPU laufenden Anwendung eine Anforderung zum Senden einer RDMA-Nachricht, unter Verwendung einer ausgewählten Gruppe von einer oder mehreren der RDMA-Sitzungen, zu einer Peer-Anwendung über das Paketdatennetz, und überträgt als Reaktion auf die Anforderung über die Netzwerkschnittstelle ein oder mehrere Datenpakete unter Verwendung eines UDP-5-Tupels, das der einen der RDMA-Sitzungen in der ausgewählten Gruppe zugewiesen ist.
In einigen Ausführungsformen überträgt die Paketverarbeitungsschaltung die ein oder mehreren Datenpakete durch Einkapseln einer RDMA-Nutzlast in ein IP-(Internet Protocol)-Paket mit einem IP-Header, der ein ausgewähltes der UDP-5-Tupel enthält. In einer offenbarten Ausführungsform umfassen die mehreren jeweils den RDMA-Sitzungen zugewiesenen verschiedenen UDP-5-Tupel jeweils unterschiedliche UDP-Quellports.
Zusätzlich oder alternativ dazu identifiziert die Paketverarbeitungsschaltung nach dem Empfang eines eingehenden IP-Pakets aus dem Paketdatennetz das UDP-5-Tupel in einem Header des eingehenden IP-Pakets, erkennt eine RDMA-Sitzung, der das UDP-5-Tupel zugewiesen ist, und entkapselt die RDMA-Nutzlast des eingehenden Pakets auf der Basis der erkannten Sitzung und liefert sie an die Anwendung. In einer offenbarten Ausführungsform weist der Kernel verschiedene der RDMA-Sitzungen Arbeitswarteschlangen zu, die mit verschiedenen jeweils auf der CPU laufenden Anwendungen assoziiert sind, und die Paketverarbeitungsschaltung liefert die RDMA-Nutzlast an die Anwendung erst nach dem Überprüfen, dass die erkannte Sitzung einer der Anwendung zugewiesenen Arbeitswarteschlange zugewiesen ist.
In einigen Ausführungsformen speichert die Paketverarbeitungsschaltung als Reaktion auf vom Kernel übermittelte Befehle Zuweisungen verschiedener der RDMA-Sitzungen an verschiedene jeweils auf der CPU laufende Anwendungen. In einer Ausführungsform speichert die Paketverarbeitungsschaltung eine Zuweisung einer Gruppe von zwei oder mehr der RDMA-Sitzungen zu einer einzigen der Anwendungen. Zusätzlich oder alternativ reiht die Anwendung die Anforderung zum Senden der RDMA-Nachricht in eine Arbeitswarteschlange ein, die der Anwendung zugewiesen ist, und die Arbeitswarteschlange wird vom Kernel an eine der Anwendung zugewiesene RDMA-Sitzung gebunden, und die Paketverarbeitungsschaltung speichert Datensätze der Sitzungen und der jeweils an die Sitzungen gebundenen Arbeitswarteschlangen und wendet die Datensätze bei der Validierung von RDMA-Nachrichten von und zu der Anwendung an.
In einer offenbarten Ausführungsform speichert die Paketverarbeitungsschaltung jeweilige kryptografische Schlüssel für eine oder mehrere der RDMA-Sitzungen und wendet die jeweiligen kryptografischen Schlüssel beim Ver- und Entschlüsseln von RDMA-Nutzlasten der Datenpakete an, die in den ein oder mehreren der RDMA-Sitzungen zum Paketdatennetz übertragen und davon empfangen werden.
Gemäß einer Ausführungsform der Erfindung wird auch ein Verfahren zur Datenkommunikation bereitgestellt, das das Koppeln einer Netzwerkschnittstellensteuerung (NIC) zwischen einem Paketdatennetz und einem Host-Computer beinhaltet, der eine Zentraleinheit (CPU) und einen Host-Speicher enthält. Die NIC empfängt von einem auf der CPU laufenden Kernel eine Definition mehrerer RDMA-(Remote Direct Memory Access)-Sitzungen und mehrerer verschiedener jeweils den RDMA-Sitzungen zugeordneter UDP-(User Datagram Protocol)-5-Tupel. Die NIC empfängt von einer auf der CPU laufenden Anwendung eine Anforderung zum Senden einer RDMA-Nachricht unter Verwendung einer ausgewählten Gruppe von einer oder mehreren der RDMA-Sitzungen über das Paketdatennetz zu einer Peer-Anwendung. Als Reaktion auf die Anforderung überträgt die NIC über das Paketdatennetz ein oder mehrere Datenpakete unter Verwendung eines UDP-5-Tupels, das der einen der RDMA-Sitzungen in der ausgewählten Gruppe zugewiesen ist.
In einigen Ausführungsformen beinhaltet das Übertragen der ein oder mehreren Datenpakete das Einkapseln einer RDMA-Nutzlast in ein IP-(Internet Protocol)-Paket mit einem IP-Header, der ein ausgewähltes der UDP-5-Tupel enthält. In einer offenbarten Ausführungsform umfassen die jeweils den RDMA-Sitzungen zugewiesenen mehreren verschiedenen UDP-5-Tupel jeweils verschiedene UDP-Quellports.
Zusätzlich oder alternativ beinhaltet das Verfahren ferner: Empfangen, in der NIC, eines eingehenden IP-Pakets aus dem Paketdatennetz; Identifizieren, durch die NIC, des UDP-5-Tupels in einem Header des eingehenden IP-Pakets; Erkennen einer RDMA-Sitzung, der das UDP-5-Tupel zugewiesen ist; und Entkapseln, auf der Basis der erkannten Sitzung, der RDMA-Nutzlast des eingehenden Pakets und Liefern desselben an die Anwendung. In einer offenbarten Ausführungsform beinhaltet das Verfahren das Empfangen, in der NIC vom Kernel, von Zuweisungen verschiedener der RDMA-Sitzungen zu Arbeitswarteschlangen, die mit verschiedenen jeweils auf der CPU laufenden Anwendungen assoziiert sind, wobei das Liefern der RDMA-Nutzlast das Weiterleiten der RDMA-Nutzlast zu der Anwendung erst nach dem Verifizieren beinhaltet, dass die erkannte Sitzung einer der Anwendung zugewiesenen Arbeitswarteschlange zugewiesen ist.
In einigen Ausführungsformen beinhaltet das Verfahren ferner das Zuweisen, durch den Kernel, verschiedener der RDMA-Sitzungen zu verschiedenen auf der CPU laufenden jeweiligen Anwendungen. In einer Ausführungsform beinhaltet das Zuweisen der verschiedenen der RDMA-Sitzungen das Zuweisen einer Gruppe von zwei oder mehr der RDMA-Sitzungen zu einer einzigen der Anwendungen. Zusätzlich oder alternativ beinhaltet das Empfangen der Anforderung das Einreihen einer Arbeitsanforderung zum Senden der RDMA-Nachricht in eine der Anwendung zugewiesene Arbeitswarteschlange, wobei die Arbeitswarteschlange durch den Kernel an eine der Anwendung zugewiesene RDMA-Sitzung gebunden ist, und wobei die NIC Datensätze der Sitzungen und der jeweils an die Sitzungen gebundenen Arbeitswarteschlangen speichert und die Datensätze beim Validieren von RDMA-Nachrichten von und zu der Anwendung anwendet.
In einer offenbarten Ausführungsform beinhaltet das Verfahren ferner das Speichern, in der NIC, jeweiliger kryptografischer Schlüssel für eine oder mehrere der RDMA-Sitzungen und das Anwenden der jeweiligen kryptografischen Schlüssel beim Ver- und Entschlüsseln von RDMA-Nutzlasten der Datenpakete, die in den ein oder mehreren RDMA-Sitzungen zum Paketdatennetz übertragen und davon empfangen werden.
Darüber hinaus wird gemäß einer Ausführungsform der Erfindung ein System für Datenkommunikation bereitgestellt, das einen Host-Arbeitsspeicher und eine Zentraleinheit (CPU) enthält, auf der ein Kernel läuft, der mehrere RDMA-(Remote Direct Memory Access)-Sitzungen definiert und den RDMA-Sitzungen jeweils mehrere verschiedene UDP-(User Datagram Protocol)-5-Tupel zuweist, sowie eine Anwendung, die eine Anforderung zum Senden einer RDMA-Nachricht mit Hilfe einer ausgewählten Gruppe von einer oder mehreren der RDMA-Sitzungen an eine Peer-Anwendung über ein Paketdatennetz erzeugt. Eine Netzwerkschnittstellensteuerung (NIC) überträgt als Reaktion auf die Anforderung, über das Paketdatennetz, ein oder mehrere Datenpakete unter Verwendung eines UDP-5-Tupels, das der einen der RDMA-Sitzungen in der ausgewählten Gruppe zugewiesen ist.
In einigen Ausführungsformen überträgt die NIC die ein oder mehreren Datenpakete durch Einkapseln einer RDMA-Nutzlast in ein IP-(Internet Protocol)-Paket mit einem IP-Header, der ein ausgewähltes der UDP-5-Tupel enthält, und wobei die mehreren verschiedenen UDP-5-Tupel, die jeweils den RDMA-Sitzungen zugewiesen sind, unterschiedliche jeweilige UDP-Quellports umfassen.
Zusätzlich oder alternativ erkennt, wobei nach dem Empfang eines eingehenden IP-(Internet Protocol)-Pakets vom Paketdatennetz die NIC das UDP-5-Tupel in einem Header des eingehenden IP-Pakets identifiziert, eine RDMA-Sitzung, der das UDP-5-Tupel zugewiesen ist, und entkapselt auf der Basis der erkannten Sitzung die RDMA-Nutzlast des eingehenden Pakets und liefert sie an die Anwendung. In einer offenbarten Ausführungsform weist der Kernel verschiedene der RDMA-Sitzungen Arbeitswarteschlangen zu, die jeweils mit verschiedenen auf der CPU laufenden Anwendungen assoziiert sind, wobei die NIC die RDMA-Nutzlast erst nach dem Überprüfen, dass die erkannte Sitzung einer der Anwendung zugewiesenen Arbeitswarteschlange zugewiesen ist, an die Anwendung übermittelt.
In einigen Ausführungsformen speichert die NIC als Reaktion auf vom Kernel übermittelte Befehle Zuweisungen verschiedener der RDMA-Sitzungen an verschiedene, jeweils auf der CPU laufende Anwendungen. Zusätzlich oder alternativ gibt die Anwendung die Anforderung zum Senden der RDMA-Nachricht in eine der Anwendung zugewiesene Arbeitswarteschlange ein, und die Arbeitswarteschlange wird durch den Kernel an eine der Anwendung zugewiesene RDMA-Sitzung gebunden, wobei die NIC Datensätze der Sitzungen und der jeweils an die Sitzungen gebundenen Arbeitswarteschlangen speichert und die Datensätze beim Validieren von RDMA-Nachrichten von und zu der Anwendung anwendet.
In einer offenbarten Ausführungsform speichert die NIC jeweilige kryptografische Schlüssel für eine oder mehrere der RDMA-Sitzungen und wendet die jeweiligen kryptografischen Schlüssel beim Ver- und Entschlüsseln von RDMA-Nutzlasten der Datenpakete an, die in den ein oder mehreren RDMA-Sitzungen zum Paketdatennetz gesendet und davon empfangen werden.
Jedes Merkmal eines Aspekts oder einer Ausführungsform kann auf andere Aspekte oder Ausführungsformen in jeder geeigneten Kombination angewendet werden. Insbesondere kann jedes Merkmal eines/r Verfahrensaspekts oder -ausführungsform auf eine(n) Vorrichtungsaspekt oder -ausführungsform angewandt werden und umgekehrt.
Das Verständnis der vorliegenden Erfindung wird durch die folgende detaillierte Beschreibung der Ausführungsformen davon in Verbindung mit den Zeichnungen verbessert. Dabei zeigt:
KURZBESCHREIBUNG DER ZEICHNUNGEN

1 ein Blockdiagramm, das schematisch ein Datennetzkommunikationssystem gemäß einer Ausführungsform der Erfindung darstellt;
2 ein Blockdiagramm, das schematisch eine Netzwerkschnittstellensteuerung (NIC) gemäß einer Ausführungsform der Erfindung darstellt;
3 ein Blockdiagramm, das schematisch die Struktur eines RDMA-Datenpakets gemäß einer Ausführungsform der Erfindung darstellt;
4A und 4B Blockdiagramme, die schematisch Tabellen darstellen, die von einer NIC beim Verarbeiten von Datenpaketen gemäß einer Ausführungsform der Erfindung verwendet werden;
5A und 5B ein Flussdiagramm, das schematisch ein Verfahren zum Einrichten einer RDMA-Sitzung gemäß einer Ausführungsform der Erfindung darstellt; und
6 ein Flussdiagramm, das schematisch ein Verfahren zum Verarbeiten von von einer NIC empfangenen Paketen darstellt, gemäß einer Ausführungsform der Erfindung.

AUSFÜHRLICHE BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
ÜBERBLICK
Wie bereits erwähnt, verwendet das RoCE v2-Protokoll UDP/IP-Pakete mit der Zielportnummer 4791. Die Verwendung einer festen Portnummer erleichtert es einer Netzwerkschnittstellensteuerung (NIC) und anderen Netzwerkelementen, das Protokoll zu implementieren und RoCE-Datenverkehr zu erkennen. Viele Netzwerkdienste, wie z.B. Network Address Translation (NAT), Firewalls und Multipath-Routing, sind jedoch darauf angewiesen, die Werte von Feldern im IP-Paket-Header, einschließlich der Zielportnummer, ändern zu können. Die Beschränkung von RoCE-Verkehr auf einen festen Zielport bedeutet, dass diese Dienste nicht auf RoCE-Pakete angewendet werden können.
Die hier beschriebenen Ausführungsformen der vorliegenden Erfindung bieten ein neues sitzungsbasiertes Protokoll für die Übertragung von RDMA-Nachrichten über UDP/IP, das diese Einschränkungen überwindet. Das Protokoll wird hier als sitzungsbasiertes RoCE oder SRoCE bezeichnet. Jede Sitzung wird an den RDMA-Endpunkten durch ein eindeutiges IP-5-Tupel identifiziert. In der Regel haben verschiedene SROCE-Sitzungen an einem gegebenen Netzwerkendpunkt unterschiedliche Quellport-Nummern. Wenn ein Netzwerkendpunkt ein SRoCE-Paket empfängt, kann er daher einfach durch Umkehren des 5-Tupels (d.h. Austauschen der Werte der Ziel- und Quell-IP-Adressen und der Werte der Ziel- und Quell-Ports) reagieren, ohne die vorher zugewiesene Zielport-Nummer wie bei RoCE v2 beibehalten zu müssen. Netzwerkendpunkte und Zwischenknoten können die Pakete wie jedes andere UDP/IP-Paket handhaben und NAT, Firewalls, Routing-Algorithmen und andere Funktionen auf die Pakete anwenden, wie sie es bei jedem anderen UDP/IP-Paketfluss tun würden.
In den offenbarten Ausführungsformen werden SRoCE-Sitzungen von vertrauenswürdiger Software auf einem Host-Computer eingerichtet, z.B. dem Betriebssystem-Kernel. Der Kernel weist Sitzungen auf Anforderung Arbeitswarteschlangen von Benutzeranwendungen zu, die eine RDMA-Kommunikation über das Netz mit auf anderen Netzknoten laufenden Peer-Anwendungen einrichten wollen. Der Kernel registriert die Sitzungen und die Arbeitswarteschlangen, denen sie zugewiesen sind, bei der NIC des Host-Computers. Auf diese Weise kann die NIC SRoCE-Sitzungen auf der Basis der Paket-5-Tupel erkennen und sicherstellen, dass SRoCE-Pakete in einer gegebenen Sitzung nur von der Anwendungswarteschlange, der die Sitzung zugewiesen ist, gesendet und empfangen werden können. Auf diese Weise erleichtert SRoCE eine sichere und effiziente Verlagerung von RDMA-Funktionen auf die Paketverarbeitungslogik in der NIC.
Da die NIC SRoCE-Pakete auf der Basis der UDP-5-Tupel in den Paket-Headern identifizieren und lenken kann, können außerdem die gesamten UDP-Nutzlasten dieser Pakete, einschließlich der RDMA-Headers, verschlüsselt werden. So kann die NIC beispielsweise jeweilige kryptografische Schlüssel für registrierte Sitzungen speichern und diese Schlüssel beim Ver- und Entschlüsseln der Paketnutzdaten anwenden. Da die gesamte UDP-Nutzlast verschlüsselt und die Sitzungsnummer im 5-Tupel variabel ist, kann eine die Pakete abfangende böswillige Partei nicht einmal erkennen, dass sie RDMA-Verkehr enthalten.
In den hier beschriebenen Ausführungsformen umfasst eine Datenkommunikationsvorrichtung, z.B. eine NIC, eine Netzwerkschnittstelle zum Verbinden mit einem Paketdatennetz und eine Host-Schnittstelle zum Verbinden mit einem Host-Computer. Die Paketverarbeitungsschaltung in der NIC empfängt von dem auf der Host-CPU laufenden Kernel über die Host-Schnittstelle eine Definition mehrerer RDMA-Sitzungen und mehrere verschiedene UDP-5-Tupel, die jeweils den RDMA-Sitzungen zugewiesen sind. Nach dem Empfang einer Anforderung von einer auf der CPU laufenden Anwendung zum Senden einer RDMA-Nachricht zu einer Peer-Anwendung über das Netz unter Verwendung einer ausgewählten RDMA-Sitzung (oder einer Gruppe von einer, zwei oder mehreren Sitzungen) überträgt die Paketverarbeitungsschaltung über die Netzwerkschnittstelle ein oder mehrere Datenpakete mit Hilfe des der RDMA-Sitzung zugewiesenen UDP-5-Tupels.
In ähnlicher Weise analysiert die Paketverarbeitungsschaltung nach dem Empfang eines eingehenden UDP/IP-Pakets aus dem Netz den Paket-Header, um das UDP-5-Tupel zu identifizieren und so zu erkennen, dass das Paket zu einer RDMA-Verkehr führenden Sitzung gehört. Auf der Basis der eingekapselten RDMA-Header in den Paketen entkapselt die Paketverarbeitungsschaltung die RDMA-Nutzlast des eingehenden Pakets und liefert sie an die Anwendungswarteschlange, der es zugewiesen ist. Vor der Lieferung der RDMA-Nutzlast analysiert die Paketverarbeitungsschaltung in der Regel zunächst den RDMA-Header, um zu überprüfen, ob die Sitzung tatsächlich der im RDMA-Header identifizierten Arbeitswarteschlange zugewiesen ist, so dass sichergestellt ist, dass Benutzeranwendungen SRoCE-Verkehr nur über die ihnen vom Kernel zugewiesenen Sitzungen senden und empfangen können.
SYSTEMBESCHREIBUNG
1 ist ein Blockdiagramm, das schematisch ein Netzdatenkommunikationssystem 20 gemäß einer Ausführungsform der Erfindung zeigt. Das System 20 umfasst Rechenknoten 22, 24, 26, ..., die zur Kommunikation über ein IP-Netz 28 verbunden sind. Jeder Rechenknoten im dargestellten Beispiel umfasst einen Host-Computer 30, der über eine jeweilige NIC 32 mit dem Netz 28 verbunden ist. Alternativ oder zusätzlich kann das System 20 auch andere Arten von Knoten umfassen, z.B. Speicherknoten und/oder dedizierte Verarbeitungsknoten. Die NICs 32 tauschen typischerweise IP-Pakete über das Netz 28 aus, die Nutzdaten gemäß verschiedenen Protokollen der höheren Schicht tragen, die in den 5-Tupeln der Paket-Header identifiziert werden. Die vorliegende Beschreibung konzentriert sich jedoch ausschließlich auf die Übertragung von SRoCE-Paketen 52, d.h. von sitzungsbasierte RDMA-Nutzlasten enthaltenden UDP/IP-Paketen.
Jeder Host-Computer 30 umfasst eine Zentraleinheit (CPU) 40 mit einem Host-Arbeitsspeicher 42, der typischerweise einen Direktzugriffsarbeitsspeicher (RAM) umfasst. Die CPU 40 und der Host-Speicher 42 sind über einen geeigneten Bus 38, z.B. einen PCI Express® (PCIe®)-Bus, mit der NIC 32 verbunden. Auf der CPU 40 laufen ein Betriebssystem, einschließlich eines Kernels 44, sowie Benutzeranwendungen 46. Damit die Anwendungen 46 SRoCE-Pakete 52 zu und von Peer-Anwendungen auf anderen Knoten im System 20 senden und empfangen können, richtet der Kernel 44 RDMA-Sitzungen 48 ein. Der Kernel 44 weist Sitzungen 48 jeweiligen Warteschlangenpaaren (QPs) 50 zu, die als Arbeitswarteschlangen dienen, um RDMA-Arbeitsanforderungen (als Arbeitswarteschlangenelemente oder WQEs bezeichnet) von den Anwendungen 46 an die NIC 32 zu liefern.
Der Vorgang des Zuweisens von Sitzungen 48 zu QPs 50 wird als „Bindung“ bezeichnet. In der Regel wird jedes in der SRoCE-Kommunikation zu verwendende QP 50 an eine einzige Sitzung 48 oder an eine Gruppe von mehreren Sitzungen gebunden. Beispielsweise können einem einzelnen QP mehrere Sitzungen zugewiesen werden, damit das QP SRoCE-Pakete mit mehreren verschiedenen 5-Tupeln senden und/oder empfangen kann, so dass die Paketlast auf mehrere verschiedene Pfade durch das Netz 28 verteilt werden kann. Ebenso kann eine einzige Sitzung 48 oder eine Gruppe von Sitzungen von mehreren QPs 50 gemeinsam genutzt werden.
Die Zuweisungen von Sitzungen zu QPs 50 werden typischerweise in den Kontextdaten der QPs im Arbeitsspeicher 42 gespeichert, wo sie auch von der NIC 32 abgerufen werden können. Zusätzlich oder alternativ kann die Sitzungszuweisung für jede RDMA-Nachricht an die NIC im entsprechenden WQE übermittelt werden, d.h. in der Arbeitsanforderung, die die Details der RDMA-Nachricht enthält, die die NIC senden oder empfangen soll. Dieser letztere WQE-basierte Modus des Leitens von Sitzungszuweisungen zur NIC 32 ist besonders nützlich im Zusammenhang mit UD-(Unconnected Datagram)- und DC-(Dynamically Connected)-QPs, bei denen dasselbe QP von einer gegebenen Anwendung 46 zur Kommunikation mit mehreren verschiedenen Peer-Anwendungen auf anderen Knoten 24, 26, .... verwendet werden kann.
2 ist ein Blockdiagramm, das schematisch Details der NIC 32 gemäß einer Ausführungsform der Erfindung zeigt. Die NIC 32 ist mit dem Bus 38 über eine Host-Schnittstelle 60 verbunden, die beispielsweise eine geeignete PCIe-Schnittstelle umfasst. Die NIC 32 umfasst auch eine Netzwerkschnittstelle 62 in Form von einem oder mehreren physischen Netzwerkports, die für die Verbindung mit dem Netz 28 konfiguriert sind. Die Schnittstellen 60 und 62 umfassen typischerweise geeignete analoge und digitale Hardware-Schaltungen, die die anwendbaren Bitübertragungsschicht- (physical layer) und Datenverbindungsstandards für die Kommunikation über den Bus 38 und das Netz 28 implementieren.
Die Paketverarbeitungsschaltung 64 in der NIC 32 ist zwischen die Netzwerkschnittstelle 62 und die Host-Schnittstelle 60 geschaltet und umfasst sowohl eine Sende-(Tx)-Pipe 66, die abgehende Pakete zur Übertragung zum Netz 28 bearbeitet, als auch eine Empfangs-(Rx)-Pipe 68, die eingehende, vom Netz 28 empfangene Pakete handhabt. Die folgende Beschreibung konzentriert sich auf die Funktionalität der Paketverarbeitungsschaltung 64 beim Handhaben von SRoCE-Verkehr. Im Allgemeinen handhabt die NIC 32 auch andere Arten von Paketverkehr, aber diese anderen Funktionen fallen nicht in den Rahmen der vorliegenden Beschreibung.
Die Paketverarbeitungsschaltung 64 empfängt vom Kernel 44 (1) bereitgestellte Definitionen von RDMA-Sitzungen 48 und die den RDMA-Sitzungen jeweils zugewiesenen UDP-5-Tupel. Diese Sitzungsinformationen werden in einer Lenkungstabelle 70 gespeichert, die typischerweise in einem Arbeitsspeicher in der NIC 32 gespeichert ist und von der Paketverarbeitungsschaltung 64 beim Assoziieren von Sitzungen (gemäß den entsprechenden 5-Tupeln) mit Sitzungsgruppen-IDs und umgekehrt verwendet wird. Die Paketverarbeitungsschaltung speichert auch eine QP-Tabelle 71, die Kontextinformationen in Bezug auf QPs 50 enthält, die mit Anwendungen 46 assoziiert sind, für die die NIC 32 RDMA-Nachrichten sendet und empfängt. Die QP-Tabelle 71 gibt unter anderem die jedem der QPs zugewiesene SRoCE-Sitzung oder -Sitzungsgruppe an.
Die Tx-Pipe 68 empfängt Anforderungen in Form von an QPs 50 geposteten WQEs, von auf der CPU 40 laufenden Anwendungen 46, um RDMA-Nachrichten über das Netz 28 zur Peer-Anwendung zu senden. Die für jede Nachricht zu verwendende SRoCE-Sitzung (oder -Sitzungsgruppe) wird durch die QP-Tabelle 71 oder durch das WQE selbst spezifiziert. Als Reaktion auf das WQE erzeugt die Tx-Pipe 66 eine RDMA-Nutzlast, die einen RDMA-Header und möglicherweise aus dem Arbeitsspeicher 42 gelesene Daten enthält. Die SRoCE-Einkapselungslogik 72 kapselt die RDMA-Nutzlast in ein oder mehrere IP-Pakete mit einem IP-Header ein, der das der SRoCE-Sitzung zugewiesene UDP-5-Tupel enthält. Die Verschlüsselungslogik 74 in der Tx-Pipe 66 kann auch die RDMA-Nutzlasten (einschließlich Header und Daten) der abgehenden Pakete in einer gegebenen Sitzung mittels kryptografischer Schlüssel verschlüsseln, die von der Paketverarbeitungsschaltung für jede Sitzung gespeichert werden.
Nach dem Empfang eines eingehenden IP-Pakets aus dem Netz 28 analysiert die SRoCE-Entkapselungs- und - Validierungslogik 76 in der Rx-Pipe 68 den Paket-Header, um das 5-Tupel zu extrahieren. Die Logik 76 sucht das 5-Tupel in der Lenkungstabelle 70 und identifiziert so UDP-5-Tupel von RDMA-Sitzungen und extrahiert die Nummer der Sitzung, der das UDP-5-Tupel zugewiesen ist. Verwendet die Sitzung verschlüsselte Nutzlasten, so verwendet die Entschlüsselungslogik 78 den von der Paketverarbeitungsschaltung 64 für diese Sitzung gespeicherten kryptografischen Schlüssel zum Entschlüsseln der Nutzlast. Die Logik 76 entkapselt und validiert dann die RDMA-Nutzlast, um zu überprüfen, ob sie zu einem QP 50 gehört, das an die durch das UDP-5-Tupel angegebene Sitzung gebunden ist, und liefert die RDMA-Nutzlast an die entsprechende Anwendung 46, indem sie die Nutzlast in einen Puffer schreibt, der dem QP im Arbeitsspeicher 42 zugewiesen ist.
Der Übersichtlichkeit halber sind die physischen Komponenten der NIC 32 in 2 als mehrere separate Funktionsblöcke dargestellt. In der Praxis werden diese Komponenten jedoch typischerweise (wenn auch nicht notwendigerweise) als Hardware- und Firmware-Komponenten in einem einzigen integrierten Schaltungschip oder Chipsatz implementiert, möglicherweise auch zusammen mit der CPU 40. Die Paketverarbeitungsschaltung 64 umfasst typischerweise Hardware-Logikschaltungen, die programmierbar oder fest verdrahtet sein können und so konfiguriert sind, dass sie die hier beschriebenen Funktionen sowie andere in der Technik bekannte Paketverarbeitungsfunktionen ausführen. Zusätzlich oder alternativ können zumindest einige dieser Funktionen von einem eingebetteten Prozessor in der NIC 32 unter der Steuerung von Software oder Firmware ausgeführt werden.
2 zeigt zwar eine mögliche Implementation der NIC 32, aber es werden für die Fachperson nach der Lektüre der vorliegenden Beschreibung auch andere Implementationen offensichtlich und werden als im Rahmen der vorliegenden Erfindung liegend betrachtet.
3 ist ein Blockdiagramm, das schematisch die Struktur eines der SRoCE-Pakete 52 gemäß einer Ausführungsform der Erfindung darstellt. Wie bereits erläutert, hat das Paket 52 die Form eines Standard-UDP/IP-Pakets, das einen Ethernet-Header 80, einen IP-Header 82 und einen UDP-Header 90 enthält. Der IP-Header 82 enthält eine Ziel-IP-Adresse (DIP) 84, eine Quell-IP-Adresse (SIP) 86 und eine Protokollnummer 88, die auf den Wert für UDP eingestellt ist. Der UDP-Header 90 enthält einen Quell-Port (SP) 92 und einen Ziel-Port (DP) 94. Das aus diesen fünf Feldern bestehende 5-Tupel identifiziert die RDMA-Sitzung, zu der das Paket 52 gehört.
In der Regel haben die 5-Tupel, die verschiedenen RDMA-Sitzungen zugewiesen sind, die bei einem gegebenen Netzknoten registriert sind, jeweils unterschiedliche Quellports 92. Die zugewiesene Portnummer erscheint als Quellport in abgehenden Paketen und als Zielport in eingehenden Paketen der gleichen Sitzung. Alle Sitzungen haben in der Regel dieselbe Quell-IP-Adresse 88, doch können, wenn die NIC 32 der RDMA-Anwendung mehrere Schnittstellen mit unterschiedlichen IP-Adressen präsentiert, die Sitzungen unter diesen Schnittstellen aufgeteilt werden und entsprechend unterschiedliche Quell-IP-Adressen haben.
Das Paket 52 enthält eine RDMA-Nutzlast 98, die einen RDMA-Header, darunter mindestens einen BTH (Base Transport Header) 100, und eine Datennutzlast 102 umfasst. Wenn die RDMA-Nutzlast 98 verschlüsselt ist, geht ihr typischerweise ein DTLS-(Datagram Transport Layer Security)-Header 96 voran. In diesem Fall werden sowohl der BTH 100 als auch die Datennutzlast 102 mit dem dieser DTLS-Sitzung zugewiesenen kryptografischen Schlüssel verschlüsselt. Die Form des BTH 100 ähnelt in dem in RoCEv2 verwendeten BTH und enthält neben anderen Daten die QP-Nummer und die RDMA-Paketfolgenummer.
Das Paket 52 endet mit einem Standard-Footer 104, der einen oder mehrere Fehlererkennungscodes wie in den einschlägigen Normen vorgeschrieben enthält.
4A und 4B sind Blockdiagramme, die schematisch Details der Lenkungstabelle 70 und der QP-Tabelle 71 zeigen, die von der NIC 64 beim Verarbeiten von SRoCE-Datenpaketen gemäß einer Ausführungsform der Erfindung verwendet werden. Die Tabellen 70 und 71 werden typischerweise in einem lokalen Arbeitsspeicher der Paketverarbeitungsschaltung 64 gespeichert. Alternativ oder zusätzlich können einige oder alle Informationen in diesen Tabellen im Host-Arbeitsspeicher 42 gespeichert werden. 4 zeigt nur einen kleinen Teil der Informationen in den Tabellen 70 und 71, um das Verständnis für Aspekte der Implementation des SRoCE-Protokolls zu erleichtern. In der Praxis enthalten diese Tabellen in der Regel umfangreiche zusätzliche Informationen über die Paketlenkung und den QP-Kontext, einschließlich der Lenkung von Paketen, die nicht mit SRoCE-Sitzungen assoziiert sind.
Die Lenkungstabelle 70 enthält Datensätze 110 von RDMA-Sitzungen, die vom Kernel 44 in der NIC 32 registriert wurden (1). Jeder Datensatz enthält ein UDP-5-Tupel 112 und eine entsprechende Sitzungsgruppennummer 114, der das 5-Tupel zugewiesen ist. Bei Sitzungen, die für die Verwendung verschlüsselter Nutzlasten 98 konfiguriert sind, kann der entsprechende Datensatz 110 auch einen kryptografischen Status 115 enthalten, der unter anderem den in dieser Sitzung zu verwendenden kryptografischen Schlüssel enthält. Dieser Schlüssel kann vom Kernel 44 ausgewählt werden, z.B. durch Aushandeln mit dem Kernel des Peer-Knotens in der SRoCE-Sitzung mittels einer Standard-DTLS-Handshaking-Prozedur über UDP/IP-Pakete. Der Kernel 44 gibt den Schlüssel und andere assoziierte kryptografische Statusinformationen an die NIC 32 weiter, die den Schlüssel in der Tabelle 70 speichert und bei Bedarf darauf zugreift, um Nutzlasten 98 von abgehenden Paketen zu verschlüsseln und Nutzlasten 98 von eingehenden Paketen zu entschlüsseln.
Die QP-Tabelle 71 enthält Datensätze von QPs, die von Anwendungen 46 (1) zum Austauschen von RDMA-Nachrichten mit Peer-Anwendungen geöffnet wurden. Jeder Datensatz enthält eine QP-Nummer 116 und eine Auflistung einer Sitzungsgruppe 118, an die der Kernel 44 diese QP-Nummer gebunden hat. Jede Sitzungsgruppe 118 kann eine einzelne SRoCE-Sitzung (identifiziert durch ein einzelnes 5-Tupel) oder mehrere Sitzungen (mit verschiedenen entsprechenden 5-Tupeln) enthalten. Ein QP, das an eine Gruppe von zwei oder mehr Sitzungen gebunden ist, kann somit Pakete mit zwei oder mehr verschiedenen 5-Tupeln übertragen, die dasselbe Ziel erreichen, und diese Pakete können folglich über verschiedene Pfade durch das Netz 28 geleitet werden. Dieses Merkmal kann zum Verringern von Netzüberlastung vorteilhaft sein, wenn ein gegebenes QP Datenströme mit hoher Bandbreite überträgt.
EINRICHTEN UND BENUTZEN VON RDMA-SITZUNGEN
5A und 5B sind ein Flussdiagramm, das schematisch ein Verfahren zum Einrichten einer RDMA-Sitzung gemäß einer Ausführungsform der Erfindung darstellt. Das Verfahren wird der Einfachheit und Klarheit halber unter Bezugnahme auf die Elemente des Systems 20 (1) beschrieben, wobei der Knoten 22 als Client oder Initiator fungiert, um eine RDMA-Sitzung mit einem Server am Knoten 24 als Responder einzurichten. 5A und 5B zeigen insbesondere die jeweiligen Rollen einer Anwendung 46 und des Kernels 44, die auf dem Host-Computer 30 laufen, und der Paketverarbeitungsschaltung in der NIC 32 des Knotens 22. Diese spezielle Implementation ist jedoch nur beispielhaft gezeigt; alternative Methoden zum Einrichten von RDMA-Sitzungen und zum Binden der Sitzungen an Anwendungswarteschlangen werden für die Fachperson nach der Lektüre der vorliegenden Beschreibung offensichtlich und werden als im Rahmen der vorliegenden Erfindung liegend betrachtet.
Zum Einleiten der RDMA-Sitzung sendet die Anwendung 46 in einem Socket-Anforderungsschritt 120 eine Anforderung zum Erstellen eines UDP-Sockets zum Kernel 44. Als Reaktion auf diese Anforderung weist der Kernel einen UDP-Socket zu, einschließlich einer eindeutigen Quellportnummer, und gibt in einem Socket-Zuweisungsschritt 122 einen entsprechenden Dateideskriptor (FD) des Sockets an die Anwendung zurück. (Der FD ist ein Handle auf das Kernel-Socket-Objekt, da Benutzeranwendungen nicht direkt auf den Socket zugreifen dürfen.)
In Vorbereitung für das Einrichten einer RDMA-Verbindung mit einem entfernten Peer sendet die Anwendung 46 in einem Sitzungsanforderungsschritt 124 eine weitere Anforderung zum Erstellen einer RDMA-Sitzung zum Kernel 44. Diese Anforderung enthält den Socket-FD, den die Anwendung zuvor erhalten hat. Der Kernel 44 erstellt eine Sitzung, extrahiert die mit dem FD assoziierte Quellportnummer und weist sie der erstellten Sitzung in einem Sitzungserstellungsschritt 126 zu.
Die Anwendung 46 initiiert eine RDMA-Verbindung mit einem entfernten Peer in einem Verbindungsanforderungsschritt 128. Zu diesem Zweck übermittelt die Anwendung 46 dem Kernel 44 die Ziel-IP-Adresse und den Ziel-Port der Peer-Anwendung. Der Kernel 44 initiiert ein RDMA-Verbindungsprotokoll unter Verwendung des resultierenden UDP-5-Tupels in einem Sitzungsverbindungsschritt 130. Dieses 5-Tupel enthält die lokale IP-Schnittstelle als Quell-IP-Adresse, den vom Socket-FD angegebenen Quell-Port, die Ziel-IP-Adresse des Servers (Knoten 24), den Ziel-Port der Anwendung auf dem Server und die UDP-Protokollnummer. Als Reaktion auf das RDMA-Verbindungsprotokoll nimmt der Server die Verbindung an und assoziiert sie in einem Sitzungsannahmeschritt 132 mit einer eigenen Sitzung.
Der Kernel 44 registriert die Sitzung in der NIC 32, die das 5-Tupel und die Sitzungsgruppen-ID in der Lenkungstabelle 70 (4A) speichert, in einem Sitzungsregistrierungsschritt 134. Wenn die Registrierung erfolgreich abgeschlossen ist, löst der Kernel 44 in einem Sitzungseinrichtungsschritt 136 ein „Sitzung eingerichtet“ Ereignis aus.
Zum Einleiten der RDMA-Kommunikation erstellt die Anwendung 46 ein QP 50 zusammen mit einer das QP darstellenden RDMA-Verbindungs-ID. Die Anwendung 46 bindet das QP in einem Bindungsschritt 140 an eine Sitzungsgruppe (die eine einzige Sitzung oder mehrere Sitzungen umfassen kann) durch Assoziieren der entsprechenden Verbindungs-ID mit einer vom Kernel 44 empfangenen Sitzungsgruppen-ID. Die Anwendung 46 weist den Kernel in einem Verbindungsanforderungsschritt 141 zum Herstellen der Verbindung an. Als Reaktion auf diesen Befehl initiiert der Kernel 44 in einem Verbindungsaufbauschritt 142 ein QP-Verbindungsprotokoll mit dem Server. Die Verbindungsherstellungsnachrichten werden über die an die Verbindungs-ID gebundene Sitzung gesendet, d.h. in Paketen, die in ihrem Header das bezeichnete 5-Tupel enthalten. Der Server nimmt die Verbindung gemäß dem Protokoll in einem Verbindungsannahmeschritt 143 an.
Der Kernel 44 konfiguriert dann in einem QP-Konfigurationsschritt 144 die QP-Kontexttabelle 71 in der NIC 32 mit dem entsprechenden Sitzung-5-Tupel. Wenn die Konfiguration erfolgreich abgeschlossen ist, löst der Kernel 44 in einem Verbindungsherstellungsschritt 145 ein „Verbindung hergestellt“ Ereignis aus.
Die Anwendung 46 kann nun die SRoCE-Sitzung zum Austauschen von Daten mit dem Server (Knoten 24) über das Netz 28 nutzen. Zu diesem Zweck submittiert die Anwendung 46 in einem Arbeitsanforderungsvorlageschritt 146 Arbeitsanforderungen, die als WQEs 142 zur Ausführung durch die NIC 32 in eine Warteschlange eingereiht werden. Nach dem Empfang einer der WQEs 142 prüft die Paketverarbeitungsschaltung 64 die QP-Kontexttabelle 71, um die RDMA-Sitzung zu identifizieren, die an dieses QP gebunden ist. Die NIC 32 sendet und empfängt dann RDMA-Nachrichten über dieses QP in Datenpaketen mit dem richtigen UDP-5-Tupel im IP-Header 82 in einem Paketkommunikationsschritt 148.
6 ist ein Flussdiagramm, das schematisch ein Verfahren zur Verarbeitung von von der NIC 32 aus dem Netz 28 empfangenen IP-Paketen zeigt, gemäß einer Ausführungsform der Erfindung. Im Rahmen dieses Verfahrens identifiziert die Rx-Pipe 68 (2) die UDP-5-Tupel in den Headern von eingehenden IP-Paketen und findet die RDMA-Sitzungen, mit denen die UDP-5-Tupel assoziiert sind. Auf dieser Basis entkapselt die Rx-Pipe die in den eingehenden Paketen enthaltenen RDMA-Nachrichten und liefert sie an die Anwendungen, denen die Sitzungen zugewiesen sind. Insbesondere liefert die SRoCE-Entkapselungs- und -Validierungslogik 76 in der Rx-Pipe 68 RDMA-Befehle und -Daten nur dann an eine gegebene Anwendung, wenn überprüft wurde, dass die Sitzung, mit der das 5-Tupel assoziiert ist, an ein QP 50 gebunden ist, das der Anwendung zugewiesen ist.
Das Verfahren von 6 wird eingeleitet, wenn die NIC 32 in einem Paketempfangsschritt 150 ein UDP/IP-Paket vom Netz 28 empfängt. Die Rx-Pipe 68 analysiert den Paket-Header, um das 5-Tupel zu extrahieren, und sucht das 5-Tupel in der Lenkungstabelle 70 in einem 5-Tupel-Nachschlagschritt 152. Die Lenkungstabelle gibt in einem Sitzungsprüfschritt 154 an, ob dieses 5-Tupel einer SRoCE-Sitzung zugewiesen ist. Wenn ja, liest die Rx-Pipe 68 die Sitzungsnummer aus der Tabelle 70. Wenn nicht, leitet die Rx-Pipe 68 das Paket zur weiteren Verarbeitung zum Host-Computer 30 weiter, z.B. zur Verarbeitung durch den UDP-Stapel im Kernel 44 in einem Host-Verarbeitungsschritt 156.
Nach dem Identifizieren des eingehenden Pakets in Schritt 154 als zu einer SRoCE-Sitzung gehörend prüft die Rx-Pipe 68 in einem Verschlüsselungsprüfschritt 158, ob die Nutzlast 98 des Pakets verschlüsselt ist. Wenn ja, holt die Entschlüsselungslogik 78 den kryptografischen Schlüssel 115 für diese Sitzung aus dem entsprechenden Datensatz 110 in der Lenkungstabelle 70 und wendet den Schlüssel bei der Entschlüsselung der Nutzlast 98 in einem Entschlüsselungsschritt 160 an. (Die Rx-Pipe 68 überspringt Schritt 160, wenn die Nutzlast nicht verschlüsselt ist.)
Die Entkapselungs- und Validierungslogik 76 analysiert nun den RDMA-Header (BTH 100 in 4) und extrahiert die Ziel-QP-Nummer in einem Header-Parsing-Schritt 162. Die Logik 76 prüft die QP-Kontexttabelle 71, um zu verifizieren, dass die Ziel-QP-Nummer an die Sitzungsnummer gebunden ist, die in Schritt 154 extrahiert wurde. Wenn ja, führt die Rx-Pipe 68 in einem RDMA-Ausführungsschritt 168 die durch das Paket ausgelöste RDMA-Operation aus. Beispielsweise kann die Logik 76 die RDMA-Nutzlast 102 entkapseln und die Nutzlastdaten durch Schreiben der Daten in einen designierten Puffer im Host-Arbeitsspeicher 42 an die richtige Anwendung 46 liefern. Andernfalls invalidiert die Logik 76 das Paket und verwirft es in einem Paketverwerfungsschritt 166.
Man wird verstehen, dass die oben beschriebenen Ausführungsformen als Beispiele angeführt werden und dass die vorliegende Erfindung nicht auf das hierin besonders Gezeigte und Beschriebene beschränkt ist. Vielmehr umfasst der Umfang der vorliegenden Erfindung sowohl Kombinationen und Subkombinationen der verschiedenen oben beschriebenen Merkmale als auch Variationen und Modifikationen davon, die der Fachperson nach der Lektüre der vorstehenden Beschreibung einfallen würden und die im Stand der Technik nicht offenbart sind.
Man wird verstehen, dass die oben beschriebenen Aspekte und Ausführungsformen nur beispielhaft sind und dass Änderungen im Detail im Rahmen der Ansprüche vorgenommen werden können.
Alle in der Beschreibung und (ggf.) in den Ansprüchen und Zeichnungen offenbarten Vorrichtungen, Verfahren und Merkmale können unabhängig voneinander oder in jeder geeigneten Kombination bereitgestellt werden.
Die in den Ansprüchen angegebenen Bezugszahlen dienen nur der Veranschaulichung und haben keine einschränkende Wirkung auf den Umfang der Ansprüche.

Claims

Vorrichtung zur Datenkommunikation, die Folgendes umfasst: eine Netzwerkschnittstelle zum Verbinden mit einem Paketdatennetz; eine Host-Schnittstelle zum Verbinden mit einem Host-Computer, der eine Zentraleinheit (CPU) und einen Host-Arbeitsspeicher enthält; und Paketverarbeitungsschaltung zum Empfangen, über die Host-Schnittstelle von einem auf der CPU laufenden Kernel, von Assoziationen zwischen mehreren RDMA-(Remote Direct Memory Access)-Sitzungen und mehreren verschiedenen UDP-(User Datagram Protocol)-5-Tupeln, die jeweils den RDMA-Sitzungen zugewiesen sind, und zum Empfangen einer Anforderung zum Senden einer RDMA-Nachricht von einer auf der CPU laufenden Anwendung unter Verwendung einer ausgewählten Gruppe von einer oder mehreren der RDMA-Sitzungen zu einer Peer-Anwendung über das Paketdatennetz, und zum Senden, als Reaktion auf die Anforderung über die Netzschnittstelle, eines oder mehrerer Datenpakete unter Verwendung eines UDP-5-Tupels, das einer der RDMA-Sitzungen in der ausgewählten Gruppe zugewiesen ist.
Vorrichtung nach Anspruch 1, wobei die Paketverarbeitungsschaltung die ein oder mehreren Datenpakete durch Einkapseln einer RDMA-Nutzlast in ein IP-(Internet Protocol)-Paket mit einem IP-Header überträgt, der ein ausgewähltes der UDP-5-Tupel enthält.
Vorrichtung nach Anspruch 2, wobei die mehreren verschiedenen UDP-5-Tupel, die jeweils den RDMA-Sitzungen zugewiesen sind, verschiedene jeweilige UDP-Quellports umfassen.
Vorrichtung nach Anspruch 2 oder 3, wobei die Paketverarbeitungsschaltung nach dem Empfang eines eingehenden IP-Pakets aus dem Paketdatennetz das UDP-5-Tupel in einem Header des eingehenden IP-Pakets identifiziert, eine RDMA-Sitzung erkennt, der das UDP-5-Tupel zugewiesen ist, und auf der Basis der erkannten Sitzung die RDMA-Nutzlast des eingehenden Pakets entkapselt und an die Anwendung liefert.
Vorrichtung nach Anspruch 4, wobei der Kernel verschiedene der RDMA-Sitzungen Arbeitswarteschlangen zuweist, die mit verschiedenen jeweils auf der CPU laufenden Anwendungen assoziiert sind, und wobei die Paketverarbeitungsschaltung die RDMA-Nutzlast erst nach dem Überprüfen an die Anwendung liefert, dass die erkannte Sitzung einer der Anwendung zugewiesenen Arbeitswarteschlange zugewiesen ist.
Vorrichtung nach einem vorherigen Anspruch, wobei die Paketverarbeitungsschaltung als Reaktion auf vom Kernel übermittelte Befehle Zuweisungen verschiedener der RDMA-Sitzungen an verschiedene, jeweils auf der CPU laufende Anwendungen speichert.
Vorrichtung nach Anspruch 6, wobei die Paketverarbeitungsschaltung eine Zuweisung einer Gruppe von zwei oder mehr der RDMA-Sitzungen zu einer einzigen der Anwendungen speichert.
Vorrichtung nach Anspruch 6 oder 7, wobei die Anwendung die Anforderung zum Senden der RDMA-Nachricht in eine der Anwendung zugewiesene Arbeitswarteschlange eingibt und die Arbeitswarteschlange durch den Kernel an eine der Anwendung zugewiesene RDMA-Sitzung gebunden ist, und wobei die Paketverarbeitungsschaltung Datensätze der Sitzungen und der jeweils an die Sitzungen gebundenen Arbeitswarteschlangen speichert und die Datensätze beim Validieren von RDMA-Nachrichten von und zu der Anwendung anwendet.
Vorrichtung nach einem vorherigen Anspruch, wobei die Paketverarbeitungsschaltung jeweilige kryptographische Schlüssel für eine oder mehrere der RDMA-Sitzungen speichert und die jeweiligen kryptographischen Schlüssel beim Ver- und Entschlüsseln von RDMA-Nutzlasten der Datenpakete anwendet, die in den ein oder mehreren der RDMA-Sitzungen an das Paketdatennetz übertragen und davon empfangen werden.
Verfahren zur Datenkommunikation, das Folgendes beinhaltet: Koppeln einer Netzwerkschnittstellensteuerung (NIC) zwischen einem Paketdatennetzwerk und einem Host-Computer, der eine Zentraleinheit (CPU) und einen Host-Arbeitsspeicher enthält; Empfangen in der NIC, von einem auf der CPU laufenden Kernel, einer Definition von mehreren RDMA-(Remote Direct Memory Access)-Sitzungen und mehreren verschiedenen UDP-(User Datagram Protocol)-5-Tupeln, die jeweils den RDMA-Sitzungen zugewiesen sind; Empfangen in der NIC, von einer auf der CPU laufenden Anwendung, einer Anforderung zum Senden einer RDMA-Nachricht unter Verwendung einer ausgewählten Gruppe von einer oder mehreren der RDMA-Sitzungen über das Paketdatennetz zu einer Peer-Anwendung; und Übertragen, als Reaktion auf die Anforderung, von der NIC über das Paketdatennetz, eines oder mehrerer Datenpakete unter Verwendung eines UDP-5-Tupels, das einer der RDMA-Sitzungen in der ausgewählten Gruppe zugewiesen ist.
Verfahren nach Anspruch 10, wobei das Übertragen der ein oder mehreren Datenpakete das Einkapseln einer RDMA-Nutzlast in ein IP-(Internet Protocol)-Paket mit einem IP-Header umfasst, der ein ausgewähltes der UDP-5-Tupel enthält.
Verfahren nach Anspruch 11, wobei die mehreren verschiedenen UDP-5-Tupel, die jeweils den RDMA-Sitzungen zugewiesen sind, unterschiedliche jeweilige UDP-Quellports umfassen.
Verfahren nach Anspruch 11 oder 12, das Folgendes beinhaltet: Empfangen, in der NIC, eines eingehenden IP-Pakets aus dem Paketdatennetz; Identifizieren, durch die NIC, des UDP-5-Tupels in einem Header des eingehenden IP-Pakets; Erkennen einer RDMA-Sitzung, der das UDP-5-Tupel zugewiesen ist; und Entkapseln, auf der Basis der erkannten Sitzung, der RDMA-Nutzlast des eingehenden Pakets und Liefern derselben an die Anwendung.
Verfahren nach Anspruch 13, das das Empfangen, in der NIC, von Zuweisungen verschiedener der RDMA-Sitzungen vom Kernel zu Arbeitswarteschlangen beinhaltet, die mit verschiedenen, jeweils auf der CPU laufenden Anwendungen assoziiert sind, wobei das Liefern der RDMA-Nutzlast das Leiten der RDMA-Nutzlast an die Anwendung erst nach dem Verifizieren beinhaltet, dass die erkannte Sitzung einer der Anwendung zugewiesenen Arbeitswarteschlange zugewiesen ist.
Verfahren nach einem der Ansprüche 10 bis 14, das das Zuweisen, durch den Kernel, verschiedener der RDMA-Sitzungen an verschiedene jeweils auf der CPU laufende Anwendungen beinhaltet.
Verfahren nach Anspruch 15, wobei das Zuweisen der verschiedenen der RDMA-Sitzungen das Zuweisen einer Gruppe von zwei oder mehr RDMA-Sitzungen an eine einzige der Anwendungen beinhaltet.
Verfahren nach Anspruch 15 oder 16, wobei das Empfangen der Anforderung das Einreihen einer Arbeitsanforderung zum Senden der RDMA-Nachricht in eine der Anwendung zugewiesene Arbeitswarteschlange beinhaltet, wobei die Arbeitswarteschlange durch den Kernel an eine der Anwendung zugewiesene RDMA-Sitzung gebunden ist, und wobei die NIC Datensätze der Sitzungen und der Arbeitswarteschlangen speichert, die jeweils an die Sitzungen gebunden sind, und die Datensätze beim Validieren von RDMA-Nachrichten von und zu der Anwendung anwendet.
Verfahren nach einem der Ansprüche 10 bis 17, das das Speichern, in der NIC, jeweiliger kryptographischer Schlüssel für eine oder mehrere der RDMA-Sitzungen und das Anwenden der jeweiligen kryptographischen Schlüssel beim Ver- und Entschlüsseln von RDMA-Nutzlasten der Datenpakete beinhaltet, die in den ein oder mehreren der RDMA-Sitzungen zum Paketdatennetz übertragen und davon empfangen werden.
System zur Datenkommunikation, das Folgendes umfasst: einen Host-Arbeitsspeicher; eine Zentraleinheit (CPU) zum Ausführen eines Kernels, der mehrere RDMA-(Remote Direct Memory Access)-Sitzungen definiert und den RDMA-Sitzungen jeweils mehrere verschiedene UDP-(User Datagram Protocol)-5-Tupel zuweist, und eine Anwendung, die eine Anforderung zum Senden einer RDMA-Nachricht unter Verwendung einer ausgewählten Gruppe von einer oder mehreren der RDMA-Sitzungen zu einer Peer-Anwendung über ein Paketdatennetz erzeugt; und eine Netzwerkschnittstellensteuerung (NIC), die als Reaktion auf die Anforderung über das Paketdatennetz ein oder mehrere Datenpakete unter Verwendung eines einer der RDMA-Sitzungen in der ausgewählten Gruppe zugewiesenen UDP-5-Tupels übertragen soll.
System nach Anspruch 19, wobei die NIC die ein oder mehreren Datenpakete durch Einkapseln einer RDMA-Nutzlast in ein IP-(Internet Protocol)-Paket mit einem IP-Header überträgt, der ein ausgewähltes der UDP-5-Tupel enthält, und wobei die mehreren verschiedenen, jeweils den RDMA-Sitzungen zugewiesenen UDP-5-Tupel verschiedene jeweilige UDP-Quellports umfassen.
System nach Anspruch 19 oder 20, wobei die NIC nach dem Empfang eines eingehenden IP-(Internet Protocol)-Pakets vom Paketdatennetz das UDP-5-Tupel in einem Header des eingehenden IP-Pakets identifiziert, eine RDMA-Sitzung erkennt, der das UDP-5-Tupel zugewiesen ist, und auf der Basis der erkannten Sitzung die RDMA-Nutzlast des eingehenden Pakets entkapselt und an die Anwendung liefert.
System nach Anspruch 21, wobei der Kernel verschiedenen der RDMA-Sitzungen Arbeitswarteschlangen zuweist, die mit verschiedenen jeweils auf der CPU laufenden Anwendungen assoziiert sind, und wobei die NIC die RDMA-Nutzlast erst nach dem Überprüfen an die Anwendung liefert, dass die erkannte Sitzung einer der Anwendung zugewiesenen Arbeitswarteschlange zugewiesen ist.
System nach einem der Ansprüche 19 bis 22, wobei die NIC als Reaktion auf vom Kernel übermittelte Befehle Zuweisungen verschiedener der RDMA-Sitzungen zu verschiedenen jeweils auf der CPU laufenden Anwendungen speichert.
System nach Anspruch 23, wobei die Anwendung die Anforderung zum Senden der RDMA-Nachricht in eine der Anwendung zugewiesene Arbeitswarteschlange eingibt, und die Arbeitswarteschlange durch den Kernel an eine der Anwendung zugewiesene RDMA-Sitzung gebunden ist, und wobei die NIC Datensätze der Sitzungen und der jeweils an die Sitzungen gebundenen Arbeitswarteschlangen speichert und die Datensätze beim Validieren von RDMA-Nachrichten von und zu der Anwendung anwendet.
System nach einem der Ansprüche 19 bis 24, wobei die NIC jeweilige kryptographische Schlüssel für eine oder mehrere der RDMA-Sitzungen speichert und die jeweiligen kryptographischen Schlüssel beim Ver- und Entschlüsseln von RDMA-Nutzdaten der Datenpakete anwendet, die in den ein oder mehreren RDMA-Sitzungen zum Paketdatennetz gesendet und davon empfangen werden.