DE112007000975B4

DE112007000975B4 - Techniken zum Erzeugen von Netzwerkprotokolleinheiten

Info

Publication number: DE112007000975B4
Application number: DE112007000975.6T
Authority: DE
Inventors: Linden Cornett; Steven King; Sujoy Sen; Parthasarathy Sarangam; Frank Berry
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2006-05-11
Filing date: 2007-05-09
Publication date: 2019-12-19
Anticipated expiration: 2027-05-10
Also published as: TWI369880B; US20070263629A1; WO2007134106A3; WO2007134106A2; TW200818799A; DE112007000975T5; US7710968B2

Abstract

Verfahren mit:Übertragen (302) einer Anforderung von einer ersten Logik an eine zweite Logik, wobei die Anforderung eine Anforderung zum Bilden einer Netzwerkprotokolleinheit übereinstimmend mit dem Direct Data Placement (DDP)-Protokoll beihaltet;an der ersten Logik, Erzeugen mindestens eines Headerfelds für einen Headerabschnitt mindestens einer mit DDP übereinstimmenden Netzwerkprotokolleinheit;Liefern des erzeugten mindestens einen Headerfelds an die zweite Logik;an der zweiten Logik, Erzeugen mindestens eines Headerfelds; undan der zweiten Logik, selektives Bilden (304) mindestens einer mit dem DDP-Protokoll übereinstimmenden Netzwerkprotokolleinheit als Reaktion auf die Anforderung und basierend auf den erzeugten Header-Feldern von der ersten und zweiten Logik, wobei die Anforderung eine Identifizierung von Daten, eine Identifizierung eines Headers und eine Identifizierung eines Kontext beinhaltet und wobei jede der mindestens einen Netzprotokolleinheit Header- und Payload-Abschnitte aufweist.

Description

Gebiet
Der hier offenbarte Gegenstand bezieht sich auf Techniken zum Erzeugen von Netzwerkprotokolleinheiten.
Stand der Technik
Das Direct Data Placement (DDP) Protokoll schafft eine Möglichkeit zum Platzieren von Upper Layer Protocol (ULP) Daten direkt in einer abschließenden Destination in einem Speicher ohne Verarbeitung durch das ULP. Eine Reihe von Protokollen kann geschichtet werden, um Information unter Verwendung des DDP zu übertragen und zu empfangen. 1 zeigt ein beispielhaftes Frameformat, das in Übereinstimmung mit dem DDP Protokoll gebildet ist. Wie gezeigt, kann ein DDP Segment einen Transmission Control Protocol (TCP) Header, einen Marker-based Protocol-data-unit-Aligned (MPA) Header, einen DDP Header, einen Remote Direct Memory Access (RDMA) Header, Payload und einen Wert einer zyklischen Redundanzprüfung (CRC) aufweisen.
Beispielsweise kann das DDP Protokoll, das in „Direct Data Placement over Reliable Transports“ (Version 1.0) (2002), das von dem RDMA Konsortium verfügbar ist, als auch dessen Revisionen beschrieben sein, das TCP/IP Protokoll beschrieben werden wenigstens in der Veröffentlichung mit dem Titel „Transmission Control Protocol: DARPA Internet Program Protocol Specification“, erstellt für die Defense Advanced Projects Research Agency (RFC 793) (September 1981) als auch dessen Revisionen; das MPA Protokoll kann beschrieben werden bei „Marker PDU Aligned Framing for TCP Specification“ (Version 1.0) (2002), verfügbar von dem RDMA Konsortium als auch dessen Revisionen und „Marker PDU Aligned Framing for TCP Specification“ von IETF Arbeitsforum Remote Direct Data Placement Work Group (Februar 2004) als auch dessen Revisionen; und das RDMA Protokoll kann beschrieben sein in „An RDMA Protocol Specification“ (Version 1.0) (2002), das von dem RDMA Konsortium erhältlich ist, als auch dessen Revisionen.
Figurenliste
Ausführungsbeispiele der vorliegenden Erfindung werden beispielhaft dargestellt, nicht also zum Zwecke der Beschränkung, in den Zeichnungen geben einander entsprechende Bezugszeichen einander ähnliche Elemente an.

1 zeigt ein beispielhaftes Frameformat, das nur in Übereinstimmung mit dem DDP Protokoll gebildet ist.
2 zeigt ein beispielhaftes Systemausführungsbeispiel in Übereinstimmung mit einigen Ausführungsbeispielen der vorliegenden Erfindung.
3 zeigt ein Beispiel von Elementen, die bei einigen Ausführungsbeispielen der vorliegenden Erfindung verwendet werden kann.
4 zeigt ein Flussdiagramm, das verwendet werden kann, um eine Netzwerkkomponente zu instruieren, wenigstens eine Netzwerkprotokolleinheit zur Übertragung zu bilden, in Übereinstimmung mit einigen Ausführungsbeispielen der vorliegenden Erfindung.
5 zeigt einen beispielhaften Prozess, der von einer Netzwerkkomponente verwendet werden kann, um eine oder mehrere Netzwerkprotokolleinheiten zur Übertragung zu bilden, in Übereinstimmung mit einigen Ausführungsbeispielen der vorliegenden Erfindung.
6 zeigt einen beispielhaften Prozess, der verwendet werden kann zum Einsetzen eines oder mehrerer Marker in ein Segment in Übereinstimmung mit einigen Ausführungsbeispielen der vorliegenden Erfindung.

Eingehende Beschreibung
Die Bezugnahme in dieser Beschreibung auf „ein Ausführungsbeispiel“ oder „das Ausführungsbeispiel“ bedeutet, dass ein bestimmtes Merkmal, eine Struktur oder eine Eigenschaft, die in Verbindung mit dem Ausführungsbeispiel beschrieben worden ist, in wenigstens einem Ausführungsbeispiel der vorliegenden Erfindung eingeschlossen ist. Das Auftreten des Ausdrucks „in einem Ausführungsbeispiel“ oder „ein Ausführungsbeispiel“ an verschiedenen Orten in dieser Beschreibung muss nicht notwendigerweise sich auf dasselbe Ausführungsbeispiel beziehen. Weiter können die verschiedenen Merkmale, Strukturen oder Eigenschaften eines oder mehrerer Ausführungsbeispiele miteinander kombiniert werden.
2 zeigt ein Computersystem 100 eines geeigneten Systems, in dem einige Ausführungsbeispiele der vorliegenden Erfindung verwendet werden können. Das Computersystem 100 kann ein Hostsystem 102, einen Bus 116 und eine Netzwerkkomponente 118 aufweisen.
Das Hostsystem 102 kann einen Chipsatz 105, einen Prozessor 110, einen Hostspeicher 112 und einen Speicher 114 aufweisen. Der Chipsatz 105 kann eine Kommunikation zwischen dem Prozessor 110, dem Hostspeicher 112, dem Speicher 114, dem Bus 116 als auch einem Graphikadapter schaffen, der zur Übertragung von Graphiken und Information zur Darstellung auf einer Displayeinheit (beide nicht dargestellt) verwendet werden kann. Beispielsweise kann der Chipsatz 105 einen Speicheradapter (nicht gezeigt) aufweisen, der eine Verbindung mit dem Speicher 114 herstellt. Beispielsweise kann der Speicheradapter zur Kommunikation mit dem Speicher 114 in Übereinstimmung mit wenigstens einem der folgenden Protokolle in der Lage sein: Small Computer Systems Interface (SCSI), Fibre Channel (FC), und/oder Serial Advanced Technology Attachment (S-ATA).
Bei einigen Ausführungsbeispielen kann der Chipsatz 105 eine Data-Moverlogik (nicht gezeigt) beinhalten, die dazu in der Lage ist, Übertragungen von Information in dem Hostsystem 102 oder zwischen dem Hostsystem 102 und der Netzwerkkomponente 118 durchzuführen. Der hier verwendete Begriff „ein Data-Mover“ bezieht sich auf ein Modul zum Bewegen von Daten von einer Quelle zu einem Bestimmungsort, ohne das Kemprozessormodul eines Hostprozessors, etwa dem Prozessor 110 zu verwenden oder ansonsten keine Zyklen eines Prozessors zu verwenden, um eine Datenkopie oder Bewegungsoperationen auszuführen. Durch Verwendung des Data-Movers zur Übertragung von Daten kann der Prozessor von dem Overhead zur Durchführung von Datenbewegungen befreit werden, was dazu führen kann, dass der Hostprozessor mit sehr viel langsameren Speichergeschwindigkeiten arbeitet verglichen mit den Geschwindigkeiten des Kernprozessormoduls. Ein Data-Mover kann, beispielsweise, eine Direkt Memory Access (DMA) Maschine beinhalten. Bei einigen Ausführungsbeispielen kann der Data-Mover als ein Teil eines Prozessors 110 implementiert sein, obwohl andere Komponenten des Computersystems 100 den Data-Mover beinhalten können.
Der Prozessor 110 kann als Complex Instruction Set Computer (CISC) oder Reduced Instruction Set Computer (RISC) Prozessoren, Mehrkern- oder jede andere Mikroprozessor oder zentrale Recheneinheit implementiert sein. Der Hostspeicher 112 kann als flüchtige Speichereinheit implementiert sein, wie, ohne darauf begrenzt zu sein, ein Random Access Memory (RAM), Dynamic Random Access Memory (DRAM) oder Static RAM (SRAM). Der Speicher 114 kann als eine nicht-flüchtige Speichereinheit implementiert sein, wie, ohne darauf begrenzt zu sein, ein Magnetplattenantrieb, ein optischer Plattenantrieb, ein Bandantrieb, eine Intervallspeichereinheit, eine zugeordnete Speichereinheit, ein Flashspeicher, ein Batterie gestützter synchroner DRAM (SDRAM), und/oder eine über ein Netzwerk zugreifbare Speichereinheit.
Der Bus 116 kann eine Kommunikation zwischen wenigstens dem Hostsystem 102 und der Netzwerkkomponente 118 als auch anderen peripheren Einheiten (nicht dargestellt) schaffen. Der Bus 116 kann serielle oder parallele Kommunikationen unterstützen. Der Bus 116 kann eine Knoten-zu-Knoten oder Knoten-zu-Mehrknoten unterstützen. Der Bus 116 kann wenigstens mit Peripheral Component Interconnect (PCI) kompatibel sein, wie er beispielsweise bei Peripheral Component Interconnect (PCI) Local Bus Specification, Revision 3.0, 2. Februar 2004, verfügbar von der PCI Special Interest Group, Portland, Oregon, USA (als auch dessen Revisionen) beschrieben ist, mit PCI Express beschrieben in The PCI Express Base Specification der PCI Special Interest Group, Revision 1,0a (als auch dessen Revisionen); PCI-x beschrieben in der PCI-X Spezifikation Rev. 1.1, 28. März 2005, verfügbar von der vorgenannten PCI Special Interest Group, Portland, Oregon, USA (als auch dessen Revisionen); und/oder Universal Serial Bus (USB) (und zugehörige Standards) als auch anderen Verbindungsstandards.
Die Netzwerkkomponente 118 kann dazu in der Lage sein, eine Kommunikation zwischen dem Hostsystem 102 und dem Netzwerk 120 wenigstens mit irgendeinem der anwendbaren Protokolle zu schaffen. Die Netzwerkkomponente 118 kann mit dem Hostsystem 102 unter Verwendung des Busses 116 kommunizieren. Bei einem Ausführungsbeispiel kann die Netzwerkkomponente 118 in dem Chipsatz 105 integriert sein. Die „Netzwerkkomponente“ kann jede Kombination von digitaler und/oder analoger Hardware und/oder Software auf einem I/O (Eingangs/Ausgangs) Subsystem einschließen, das ein oder mehrere zu übertragende Pakete und/oder über ein Netzwerk zu empfangende Pakete verarbeiten kann. Bei einem Ausführungsbeispiel kann das I/O Subsystem beispielsweise eine Netzwerkkomponentenkarte (NIC) aufweisen. Die Netzwerkkomponente kann, beispielsweise, eine MAC (Media Access Control) Schicht der Data Link Layer aufweisen, wie es in dem Open System Interconnection (OSI) Modell für Netzwerkprotokolle definiert ist. Das OSI Modell wird durch die International Organization for Standardization (ISO), ansässig in 1 Rue de Varembé, Postfach 56 CH-1211 Genf 20, Schweiz; definiert.
Bei einigen Ausführungsbeispielen beträgt die Netzwerkkomponente einer Reihe von DDP Segmenten, wenn mit Massendaten von einem Host zugeführt worden ist, die ansonsten zu groß zum Passen in ein einzelnes Segment sind. Bei einem Ausführungsbeispiel weist ein Hostsystem die Fähigkeit zum Abladen zu der Netzwerkkomponente wenigstens der Bestimmung und des Einbringens bestimmter Felder von IP, TCP, DDP und MPA Headern des DDP Segments. Bei einigen Ausführungsbeispielen weist das Hostsystem die Fähigkeit zu Abladeaufgaben zu der Netzwerkkomponente wenigstens auf: Unterteilen von Massendaten in Payload großen Portionen, Einbringen eines Pads in eine Netzwerkprotokolleinheit, Einbringen eines Markers in eine Netzwerkprotokolleinheit und Bestimmen und Einbringen eines CRC Werts in eine Netzwerkprotokolleinheit. Der Begriff „Netzwerkprotokolleinheit“, wie er hier verwendet wird, kann jedes Paket oder jedes Frame eines anderen Formats von Information mit einem Headerbereich und einem Payloadbereich aufweisen, die in Übereinstimmung mit jedweder Protokollspezifikation ausgebildet sind. Entsprechend können ein Hostprozessor (beispielsweise die CPU) oder eine andere Logik von den Aufgaben des Bildens von bestimmter Headerfelder, Aufteilen von Massendaten in Payloadgrößenabschnitte, Einsetzen von Pads, Einsetzen von Markern und Bestimmen und Einsetzen von CRC Werten befreit sein.
Bei einigen Ausführungsbeispielen kann die Netzwerkkomponente die Fähigkeit zum Bilden von Netzwerkprotokolleinheiten in Übereinstimmung mit TCP Large Send Offload (LSO) Schemen aufweisen. Eine geeignete TCP LSO Technik wird in dem Microsoft Windows Server 2003 Driver Development Kit (DDK) (2003) angeboten.
Das Netzwerk 120 kann jedes beliebige Netzwerk sein, etwa das Internet, ein Intranet, ein Lokal Area Network (LAN), ein Storage Area Network (SAN), ein Wide Area Network (WAN) oder ein drahtloses Netzwerk. Das Netzwerk 120 kann Verkehr mit der Netzwerkkomponente 118 austauschen unter Verwendung des Ethernet Standards, (beschrieben in IEEE802.3 und den zugehörigen Standards) oder jedem beliebigen Kommunikationsstandard.
3 zeigt ein Beispiel von Elementen, die bei einigen Ausführungsbeispielen der vorliegenden Erfindung verwendet werden können. Beispielsweise kann das System 200 einen Host 202 und eine Netzwerkkomponente 250 aufweisen. Bei einigen Ausführungsbeispielen kann der Host 202 die Netzwerkkomponente 250 oder eine andere Logik instruieren, wenigstens Abschnitte der Netzwerkprotokolleinheit zu erzeugen, die mit dem DDp Protokoll übereinstimmen. Bei einigen Ausführungsbeispielen kann der Host 202 die Netzwerkkomponente 250 oder eine andere Logik instruieren, wenigstens Felder von wenigstens DDP, MPA, TCP und/oder IP Protokollheadern zu erzeugen. Bei einigen Ausführungsbeispielen kann der Host 202 die Netzwerkkomponente 250 oder eine andere Logik instruieren, wenigstens Massendaten in Bereiche von Payloadgrößen zu unterteilen, Padding und Markers einzusetzen und in die Netzwerkprotokolleinheit einzusetzen.
Einige Ausführungsbeispiele des Host 202 können einen Hostspeicherpuffer 204, einen Stack 210 und einen Netzwerkkomponentendriven 212 aufweisen. Der Hostspeicherpuffer 204 kann wenigstens einen oder mehrere Abschnitte von Daten 206 und einen oder mehrere Headerschablonen 208 speichern. Daten 206 können in einem oder mehreren Netzwerkprotokolleinheiten übertragen werden in Übereinstimmung mit wenigstens dem DDP Protokoll. Die Headerschablone 208 kann Headerinformation beinhalten, die durch das DDP Protokoll vorgegeben ist. Beispielsweise kann die Headerschablone 208 wenigstens bestimmte abgeschlossene IP und TCP Headerfelder als auch einen abgeschlossenen RDMA Header aufweisen. Abgeschlossenen IP Headerfelder können die folgenden Felder aufweisen, die beschrieben sind in der IP Spezifikation: Quellen- und Destinations IP Adressen, Version, „Type of Service“, „Time of Live“, Protokoll ID. Abgeschlossene TCP Headerfelder können die folgenden Felder aufweisen, die in der TCP Spezifikation beschrieben sind: „TCP header length“, TCP Quellen- und Destinationsport, „segment acknowledgement number“, segment window“ und „Options“.
Das Stack 210 kann dazu in der Lage sein, die Übertragung von Daten unter Verwendung eines oder mehrerer Netzwerkprotokolleinheiten in Übereinstimmung wenigstens mit dem DDP Protokoll anzufordern. Zum Übertragen von Daten kann das Stack 210 in einigen Ausführungsbeispielen an den Netzwerkkomponententreiber 212 eine Übertragungsanforderung mit einem Zeiger auf relevante Daten ausgeben.
Der Netzwerkkomponententreiber 212 kann dazu in der Lage sein, einen oder mehrere Kontexte in Antwort auf eine Übertragungsanforderung zu erzeugen. Beispielsweise kann ein Kontext wenigstens aufweisen: Information, die einen Status einer Verbindung (beispielsweise TCP/IP Zustand und RDMA Zustand), die Bytezahl zu der nächsten Byteposition, in der ein Start eines nachfolgenden Markers einzusetzen ist als auch eine TCP Sequenzzahl, die zum Beibehalten der Protokollkontinuität unter einer Reihe von Frames in einer Verbindung, die zu einem unterschiedlichen Zeitpunkt ausgegeben werden, verwendet werden kann, beinhalten. In Antwort auf die Übertragungsanforderung kann der Netzwerkkomponententreiber 212 auch einen Kontextdeskriptor 214, Headerdeskriptoren 216 und Datendeskriptoren 218 erzeugen. Der Kontextdeskriptor 214 kann zu einem Kontext (nicht gezeigt) in dem Hostspeicher weisen. Der Headerdeskriptor 216 kann zu einer Headerschablone in dem Hostspeicher weisen. Der Datendeskriptor 218 kann zu Daten in dem Hostspeicher weisen. Ein Deskriptorring (nicht gezeigt) kann verwendet werden zum Übertragen von Headerdeskriptoren, Datendeskriptoren und Kontextdeskriptoren zu der Netzwerkkomponente 250.
Einige Ausführungsbeispiele der Netzwerkkomponente 250 kann eine Datenrückgewinnlogik 252, einen Kontextmananger 254, einen Prototyp Headerspeicher 258, eine Netzwerkprotokolleinheit (NPU) eine Formationslogik 260, eine Markereinsatzlogik 262, eine Paddingeinsatzlogik 264, eine DDp und MPA Headerupdatelogik 266, eine CRC Einsatzlogik 268, eine IP und TCP Headerupdatelogik 270 und eine Übertragungslogik 272 beinhalten. Die Datenrückgewinnlogik 252 kann wenigstens einen Rückholheader und Daten von dem Hostspeicherpuffer 204, die mit dem jeweiligen Headerdeskriptor und dem Datendeskriptor von dem Host 202 zugehörig ist, rückgewinnen. Beispielsweise kann die Datenrückgewinnlogik 252 einen Data-Mover aufweisen, der zum Übertragen von Daten und des Headers von dem Host 202 zu der Netzwerkkomponente 250 verwendet werden kann.
Der Kontextmanager 254 kann Kontexte, die dem Kontextdeskriptor 214 zugehörig sind in einem oder mehreren Kontextslots 256-0 bis 256-n speichern, wobei n ≥ 0. Der Kontextmanager 254 kann einen Kontext in einem Kontextslot speichern, der durch den Host 202 angegeben wird. Die Data-Moverlogikkontexte von dem Host 202 zu der Netzwerkkomponente 250 übertragen. Die Netzwerkkomponente 250 kann zum Bilden einer oder mehrerer Netzwerkprotokolleinheiten Kontexte verwenden.
Der Prototypheaderspeicher 258 kann einen Prototypheader basierend auf wenigstens einer Headerschablone bestimmen und speichern, die von dem Host 202 zurückgehalten worden ist, als auch den zugehörigen Kontext. Der Prototypheader kann einige Felder beinhalten, der von der Headerschablone von dem Host 202 geschaffen worden ist. Der Prototypheader kann einen oder mehrere Felder beinhalten, die von dem Prototypheaderspeicher 258 bestimmt sind. Der Prototypheaderspeicher 258 kann Headerfelder bestimmen, die wenigstens durch die folgenden Protokolle angegeben sind: IP, TCP, MPA und DDP. Beispielsweise können die Headerfelder, die von dem Protypheaderspeicher 258 bestimmt sind, aufweisen: Länge, IP Identifikation und IP Prüfsumme. Beispielsweise können die TCP Headerfelder, die von dem Prototypheaderspeicher 258 bestimmt worden sind aufweisen: „Sequence Number“, und TCP Flaggen, wie, ohne darauf begrenzt zu sein „FIN“ und „PSH“. Beispielsweise können die MPA Felder, die von dem Prototypheaderspeicher 258 bestimmt aufweisen: ULPDU Länge. Beispielsweise können die DDP Felder, die von dem Prototypheaderspeicher 258 bestimmt worden sind aufweisen: „last flag“, „tagged offset“ und „message offset“.
Die Formationslogik 260 der Netzwerkprotokolleinheit (NPU) kann ein DDP Segment zur Übertragung bilden jedoch mit einigen Headerfeldern, die noch abzuschließen sind als auch ohne Marker, optionalen Padding und CRC Wert. Die NPU Formationslogik 260 kann einen Payloadgrößenwert von Daten von dem Hostspeicher rückgewinnen. Die NPU Formationslogik 260 kann die Payloadgröße basierend wenigstens auf einem zugehörigen Kontext bestimmen, der die maximale Sequenzgröße und in Übereinstimmung mit relevanten Protokollen wie dem DDP Protokoll angeben. Die NPU Formationslogik 260 kann den Prototypheader von dem Prototypheaderspeicher 258 empfangen. Die NPU Formationslogik 260 kann Headerfelder in ein DDP Segment einsetzen unter Verwendung von Feldern, die in dem Prototypheader vorgesehen sind.
Die Markereinsetzlogik 262 kann basierend auf wenigstens der Information über den Prototypheader und dem Kontext in Übereinstimmung mit wenigstens MPA Protokoll ein Segment von der NPU Formationslogik 260 empfangen und eine oder mehrere Marker in dem Segment platzieren. Das Segment kann ein DDP Segment mit einigen IP, TCP, MPA, DDP und RDMA Protokollheaderfeldern sein, die abgeschlossen sind, aber mit einigen Headerfeldern, die noch abzuschließen sind und wenigstens Marker, das optionale Padding und einen CRC Wert nicht beinhaltet.
Die Paddingeinsatzlogik 264 kann selektiv einen Pad in das gegenwärtige Segment einsetzen in Übereinstimmung wenigstens mit dem MPA Protokoll. Beispielsweise kann das Pad null bis drei Bytes groß sein. Das Segment kann eine Netzwerkprotokolleinheit mit einigen abgeschlossenen IP, TCP, MPA, DDP und RDMA Protokollheaderfeldern haben und möglicherweise mit einem oder mehreren eingesetzten Markern, aber noch keine optionalen Padding oder einen CRC Wert beinhalten.
Die DDP und MPA Headerupdatelogik 266 kann einige DDP Felder basierend teilweise auf dem Kontext des Prototypheaders unter Übereinstimmung mit DDP und MPA Protokollen updaten. Beispielsweise können die folgenden DDP Felder upgedated werden: „last flag“, „tagged offset“ und „message offset“. Die DDP und MPA Headerupdatelogik 266 kann die ULPDU Längenfelder des MPA Headers basierend auf möglicherweise eingesetzte Marker und die Padgröße updaten.
Die CRC Einsetzlogik 268 kann einen CRC Wert über einem oder mehrere Bereiche des Segments in Übereinstimmung wenigstens mit dem MPA Protokoll bestimmen. Das Segment kann eine Netzwerkprotokolleinheit mit einigen abgeschlossenen IP, TCP, MPA, DDP und RDMA Protokollheaderfeldern sein und möglicherweise mit einem oder mehreren eingesetzten Markern und einem Pad, jedoch ohne einen CRC Wert. Die CRC Einsetzlogik 268 kann einen bestimmten CRC Wert in das Segment einsetzen. Bei einigen Ausführungsbeispielen können Integritätsvalidationswerte (andere als ein CRC Wert) basierend auf einem oder mehreren Abschnitten des Segments bestimmt werden.
Die IP und TCP Headerupdatelogik 270 kann Felder der IP und TCP Header updaten. Die IP und TCP Headerupdatelogik 270 kann die folgenden Felder ändern: TCP Sequenzzahl, IP Identifikationsfeld basierend auf dem gegenwärtigen Segment und in Übereinstimmung mit IP und TCP Protokollspezifikationen. Die IP und TCP Headerupdatelogik 270 kann die „TCP checksum“ und „Maximum Segment Size“ Felder basierend auf dem abgeschlossenen Segment und in Übereinstimmung mit den IP und TCP Protokollspezifikationen bestimmen. Das Segment kann eine Netzwerkprotokolleinheit mit einigen abgeschlossenen IP, TCP, MPA, DDP und RDMA Protokollheaderfeldern sein und möglicherweise mit einem oder mehreren eingesetzten Markern und einem Pad und mit einem CRC Wert. Die IP und TCP Headerupdatelogik 270 kann möglicherweise IP und TCP Headerfelder in dem Prototypheader, der von dem Prototypheaderspeicher 258 in Übereinstimmung mit IP und TCP Protokollen verwalten.
Die Übertragungslogik 272 kann die Möglichkeit zum Übertragen eines oder mehrerer Netzwerkprotokolleinheiten über eine gegenständliche Schnittstelle beinhalten.
Beispielsweise kann die übertragene eine oder mehrere Netzwerkprotokolleinheiten mit DDP übereinstimmen.
4 zeigt ein Flussdiagramm eines Prozesses 300, der verwendet werden kann zum Instruieren einer Netzwerkkomponente zum Bilden wenigstens einer Netzwerkprotokolleinheit zur Übertragung in Übereinstimmung mit einigen Ausführungsbeispielen der vorliegenden Erfindung.
In Block 302 kann ein Stack eine Übertragungsanforderung ausgeben. Beispielsweise kann der Stack anfordern, dass Massendaten in einem oder mehreren DDP Segmenten übertragen werden. Beispielsweise kann der Stack anfordern, dass ein oder mehrere Payloadwerte von Daten zur Übertragung in Übereinstimmung mit dem DDP Protokoll vorbereitet werden. Beispielsweise kann der Stack durch einen Hostcomputer oder eine andere Logik ausgeführt werden. Bei einigen Ausführungsbeispielen kann der Hostnetzwerkprotokolleinheitsbildungsaufgaben abladen wie eine oder mehrere Teile der Massendaten in Portionen von Payloadgröße, ein oder mehrere Protokollheaderfelder bestimmen, Einsetzen von Padding, Einsetzen von einem oder mehreren Markern und Bestimmen und Einsetzen eines CRC Werts.
In dem Block 304 kann der Host einen Headerdeskriptor, einen Datendeskriptor und einen Kontextdeskriptor in eine Netzwerkkomponente in Antwort auf die Übertragungsanforderung erzeugen und übertragen. Beispielsweise kann die Logik wie ein Netzwerkkomponenttreiber einen Kontext erzeugen, der der Übertragungsanforderung zugehörig ist. Der Headerdeskriptor kann sich auf einen Ort beziehen, an dem eine Headerschablone gespeichert ist. Die Headerschablone kann eine Information beinhalten, die durch das DDP Protokoll vorgeschrieben ist. Beispielsweise kann die Headerschablone dieselbe oder eine ähnliche Information beinhalten, wie diese von der Headerschablone 208, die früher beschrieben worden ist, gespeichert ist. Der Datendeskriptor kann sich auf einen Bereich eines Speichers beziehen, in dem Daten gespeichert sind, die zu übertragen sind. Die Daten können in einem oder mehreren DDP Protokollen übereinstimmend mit Netzwerkprotokolleinheiten übertragen werden.
5 zeigt einen beispielhaften Prozess 400, der von einer Netzwerkkomponente zum Bilden einer oder mehrerer Netzwerkprotokolleinheiten zur Übertragung in Übereinstimmung mit einigen Ausführungsbeispielen der vorliegenden Erfindung verwendet werden kann. Die eine oder die mehreren Netzwerkprotokolleinheiten können wenigstens mit dem DDP Protokoll übereinstimmen. Bei einigen Ausführungsbeispielen überträgt die Netzwerkkomponente eine Reihe von DDP Segmenten, wenn die mit Massendaten von einem Host übertragen werden, die sonst zu lang sind, um in ein einzelnes Segment zu passen.
Der Block 402 kann eine Netzwerkkomponente beinhalten, die Daten von einem Hostspeicherpuffer rückgewinnt. Die Daten können in Antwort auf eine Übertragungsanforderung oder eine andere Anforderung zum Übertragen von Daten von einer Hosteinheit durch ein Netzwerk rückgewonnen werden. Beispielsweise können die Daten von der Hosteinheit zu der Netzwerkkomponente unter Verwendung einer Data-Moverlogik übertragen werden.
Der Block 404 kann die Netzwerkkomponente, die eine variable „Count“ zum Angeben einer Größe der rückgewonnen Daten, die nicht in der Netzwerkprotokolleinheit zur Übertragung formatiert sind, setzt. Beispielsweise kann die Variable „Count“ eine Anzahl von Bytes in den rückgewonnen Daten angeben. Nachdem ein Teil der rückgewonnenen Daten zur Übertragung in einer Netzwerkprotokolleinheit von der Netzwerkkomponente formatiert sind, kann die Variable „Count“ um einen Betrag gleich der Größe von Daten, die zur Übertragung formatiert worden sind, reduziert werden.
Der Block 406 kann die Netzwerkkomponente beinhalten, die bestimmt, ob die Größe der rückgewonnenen Daten gleich oder größer ist als die maximale Payloadgröße. Die maximale Payloadgröße eines Rahmens kann die maximale Größe sein, die durch ein anwendbares Protokoll wie das DDP Protokoll vorgegeben ist, obwohl andere Protokolle verwendet werden können, und/oder den relevanten Kontext. Die Variable „segment-max“ kann eine maximale Payloadgröße eines Rahmens repräsentieren, der vorgegeben ist durch ein zugehöriges Protokoll und/oder den relevanten Kontext. Beispielsweise kann der Block 406 die Bestimmung, ob eine Variable „count“ größer ist oder gleich ist der Variablen „segment_max“. Wenn die Größe der rückgewonnenen Daten nicht gleich oder größer als die maximale Payloadgröße eines Rahmens ist, kann der Block 408 folgen. Wenn die Größe der rückgewonnenen Daten gleich oder größer als die maximale Payloadgröße eines Rahmens ist, kann der Block 410 folgen.
Der Block 408 kann die Netzwerkkomponente beinhalten, die eine Variable setzt, die eine gegenwärtige Größe des Segments gleich zu derjenigen zu der Größe der rückgewonnenen Daten angibt, die nicht zur Übertragung formatiert worden sind (d. h. Variable „Count“). Beispielsweise kann die Variable „segment_size“ eine gegenwärtige Größe des Segments repräsentieren. Beispielsweise kann der Block 408 das Setzen der Variable „segment_size“ gleich der Variablen „Count“ einschließen. Die Variable „segment_size“ kann sich ändern in Abhängigkeit davon, ob ein weiterer Inhalt zu dem Segment hinzugefügt wird. Der gebildete Frame kann als Zwergframe angesehen werden, da die Payloadgröße kleiner ist als eine vorgegebene maximale Größe. Der Block 412 kann dem Block 408 folgen.
Der Block 410 kann die Netzwerkkomponente beinhalten, die eine Variable setzt, die eine gegenwärtige Größe des Segments gleich derjenigen der maximalen Payloadgröße des Rahmens angibt. Zum Beispiel kann die Variable „segment_size“ eine gegenwärtige Größe des Segments angeben. Der Block 410 kann beispielsweise das Setzen der Variablen „segment size“ auf gleich der Variablen „segment-max“ beinhalten. Entsprechend können einige Daten, die in dem Block 402 rückgewonnen worden sind, übrig bleiben zur Verwendung in einer anderen Netzwerkprotokolleinheit. Der Block 412 kann dem Block 410 folgen.
Der Block 412 kann die Netzwerkkomponente beinhalten, die die Variable reduziert, die eine Größe der rückgewonnenen Datenspuren, die nicht formatiert worden sind, zur Übertragung durch die Netzwerkkomponente (d. h. Variable „Count“) durch einen Betrag der rückgewonnenen Daten, die in dem Block 408 oder 410 verteilt sind (d. h. die variable „segment size“).
Der Block 414 kann die Netzwerkkomponente beinhalten, die ein Segment bildet, das eine Netzwerkprotokolleinheit ist, die Header und eine Payload hat, die in Übereinstimmung mit dem DDP Protokoll gebildet ist. Die Header können IP, TCP, MPA, DDP und RDMA Header sein, wie dies durch das DDP Protokoll vorgegeben ist. Die Payload kann eine Menge von rückgewonnenen Daten mit einer Größe sein. die demjenigen des Satzes entweder in dem Block 408 oder dem Block 410 entspricht. Das Segment kann ein mit dem DDP Protokoll kompatibles Segment sein, aber mit einigen Headerfeldern, die noch zu vervollständigen sind als auch ohne Marker, optionale Padding und CRC Wert.
Der Block 416 kann das Updaten der Variablen, die eine Größe eines Segments zum Anzeigen, dass eine Netzwerkprotokolleinheit übereinstimmend mit dem DDP Protokoll zusammengesetzt ist, aber ohne Marker, ohne optionale Padding und ohne CRC Wert aufspürt. Beispielsweise kann die Größe der Header und der Payload von dem DDP Protokoll vorgegeben sein.
Der Block 418 kann das Updaten der Variablen beinhalten, die die Segmentgröße (d. h. Variable „segment size“) zum Beitragen zur Hinzufügung eines Pads und eines CRC Werts zu dem Segment angibt. Beispielsweise kann die Addition des Pads nachfolgend in dem Block 422 erfolgen, während die Addition eines CRC Werts zu dem Segment nachfolgend in dem Block 426 erfolgen kann. Beispielsweise kann sowohl der zugefügte Pad und der CRC Wert eine Größe haben, die von dem MPA Protokoll vorgegeben wird. Das Updaten der Variablen „segment_size“ zum Betrag zur Addition eines Pads und eines CRC Werts kann vor dem Einsetzen von Markern erfolgen, da die Anordnung von Markern ein Segment, das einen Pad und einen CRC Wert beinhaltet, in die Menge aufnehmen kann.
Der Block 420 kann das Eingeben eines oder mehrerer Marker in das Segment als auch das Updaten der Variablen, die die Segmentgröße (d. h. die Variable „segment_size“) angibt zum Angeben der Hinzufügung eines oder mehrerer Marker. Der eine oder die mehreren Marker können in Übereinstimmung mit dem MPA Protokoll eingesetzt werden. 6 schafft eine eingehende Beschreibung einer möglichen Art und Weise zum Einsetzen eines oder mehrerer Marker in Übereinstimmung mit einigen Ausführungsbeispielen der vorliegenden Erfindung, obwohl jede Technik zum Einsetzen eines oder mehrerer Marker verwendet werden kann.
Der Block 422 kann die Netzwerkkomponente, die ein Pad einsetzt, beinhalten. Beispielsweise kann der Pad null bis drei Bytes groß sein. Ein Pad kann in Übereinstimmung mit dem MPA Protokoll eingesetzt werden.
Der Block 424 kann das Updaten einiger DDP und MPA Headerfelder beinhalten. Beispielsweise können die folgenden DDP Felder upgedated werden: „last flag“, „tagged offset“ und „message offset“. Beispielsweise können die folgenden MPA Felder upgedated werden: ULPDU Längenfeld. Das ULPDU Längenfeld kann basierend auf einem möglicherweise eingesetztem Marker und der Padgröße upgedated werden.
Der Block 426 kann die Netzwerkkomponente beinhalten, die einen CRC Wert bestimmt und den CRC Wert in das Segment einsetzt. Beispielsweise kann der CRC Wert in Übereinstimmung mit dem MPA Protokoll bestimmt werden über einen oder mehrere Bereiche des Segments. Integritätsvalidationswerte (andere als ein CRC Wert) könen bestimmt und eingesetzt werden, die auf einem oder mehreren Bereichen des Segments basieren.
Der Block 428 kann die Netzwerkkomponente beinhalten, die das TCP und das IP Headerfeld des Segments updated. Beispielsweise kann der Header durch die Netzwerkkomponente erzeugt werden. Der Block 428 kann ein mit dem DDP übereinstimmendes Segment schaffen, das zur Übertragung auf ein Netzwerk bereit ist, obwohl andere Protokolle verwendet werden können.
Der Block 430 kann die Netzwerkkomponente beinhalten, die bestimmt, ob rückgewonnene Daten zur Verwendung zum Bilden einer Payload für einen anderen Rahmen verfügbar sind. Beispielsweise kann der Block 430 das Bestimmen beinhalten, ob der Wert von der Variablen „Count“ gespeichert wird, größer als null ist. Wenn rückgewonnene Daten zur Verwendung zur Bildung eines anderen Rahmens verfügbar sind, kann der Block 406 folgen. Wenn rückgewonnene Daten zur Verwendung zum Bilden eines anderen Frames verfügbar sind, kann der Prozess 400 enden.
6 zeigt einen beispielhaften Prozess 500, der in Übereinstimmung mit einigen Ausführungsbeispielen der vorliegenden Erfindung zum Einsetzen eines oder mehrerer Marker in ein Segment verwendet werden kann. Der Block 502 kann die Netzwerkkomponente beinhalten, die eine Variable rückgewinnt, die die Byteanzahl zu der Byteposition, in der ein Start eines nächsten Markers einzusetzen ist, angibt. Beispielsweise kann die Variabel „marker_offset“ eine Bytezahl angeben zu der Byteposition, in der ein Start eines nächsten Markers einzusetzen ist. Die Variable „marker_offset“ kann für die Netzwerkkomponente durch den Host oder eine andere Quelle in einem Kontext geschaffen werden. Beispielsweise kann die Variable „marker_offset“ verwendet werden, um eine Anzahl von übrig gebliebenen Bytes hinter einem Marker in einem vorangehenden Frame aufspüren, so dass die Markerpositionen zwischen aufeinander folgenden Frames beibehalten werden können. Beispielsweise können Marker eingesetzt werden, die von dem MPA Protokoll vorgegeben sind.
Der Block 504 kann die Netzwerkkomponente beinhalten, die eine Variable setzt, die eine Position eines Beginns eines nächsten Markers in dem jeweiligen Frame angibt, um gleich der Variablen zu sein, die die Bytezahl zu der Byteposition, in der ein Beginn eines nächsten Markers einzusetzen ist (d. h. den Variablen „marker_offsett“). Beispielsweise kann die Variable „next_marker“ eine Position eines Beginnens eines nächsten Markers in dem gegenwärtigen Frame relativ zu dem Beginn des gegenwärtigen Rahmens angeben. Beispielsweise kann der Block 504 das Setzen der Variablen „next_marker“, so dass diese der Variablen „marker_offset“ gleich ist, einschließen.
Der Block 506 kann die Netzwerkkomponente beinhalten, die eine Variable initialisiert, die zum Zählen von Bytepostion zum Bestimmen verwendet wird, ob ein nächster Marker einzusetzen ist. Beispielsweise kann die Variable „byte_num“ eine Byteposition wenigstens zum Zwecke des Bestimmens, ob ein nächster Marker einzusetzen ist, angeben. Beispielsweise kann der Block 506 das Setzen der Variablen „byte_num“ so dass diese gleich null ist, einschließen.
Der Block 508 kann die Netzwerkkomponente einschließen, die bestimmt, ob der nächst Marker in dem gegenwärtigen Segment zu bilden ist. Beispielsweise kann die Variable „segment_size“ die Größe des gegenwärtigen Segments angeben. Das gegenwärtige Segment kann eine Netzwerkprotokolleinheit sein, die in Übereinstimmung mit dem DDP Protokoll gebildet wird und dessen Größe zur Addition eines Pads und eines CRC Wertes beiträgt. Beispielsweise kann die Variable „segment_size“ von dem Prozess 400 gesetzt werden. Beispielsweise kann der Block 508 eine Bestimmung beinhalten, ob die Variable „next_marker“ kleiner oder gleich ist der zu der Variablen „segment_size“. Wenn der nächste Marker nicht mit dem gegenwärtigen Segment ausgebildet ist, kann der Block 510 folgen. Wenn der nächste Marker mit dem gegenwärtigen Segment auszubilden ist, kann der Block 550 folgen.
Der Block 510 kann die Netzwerkkomponente beinhalten, die eine Variable updated, die zum Angeben der Bytezahl zu der Byteposition verwendet wird, in dem ein Beginn eines nächsten Markers (d. h. die Variable „next_marker“) durch Reduzieren dieser Bytezahl durch die Bytegröße eines gegenwärtigen Segments (d. h. die Variable „segment_size“) einzusetzen ist. Entsprechend dem MPA Protokoll können die Marker alle 512 Bytes eingesetzt werden. Beispielsweise kann der Block 510 das Subtrahieren der Variablen „segment_size“ von der Variablen „next_marker“ beinhalten. Der Block 510 kann angewendet werden, wenn kein Marker in den gegenwärtigen Frame einzugeben ist.
Der Block 512 kann die nächste Netzwerkkomponente beinhalten, die die upgedatete Variable speichert, die verwendet worden ist zum Angeben der Bytezahl zu der Byteposition, in dem ein Beginn eines nächsten Markers in den relevanten Kontext einzusetzen ist. Beispielsweise kann der Block 512 das Speichern der upgedateten Bytezahl in die Byteposition beinhalten, in der ein Beginn eines nächsten Markers einzusetzen ist (upgedated in dem Block 510) als Variable „marker_offset“. Die Variable „marker_offset“ kann in einem Kontext zur Verwendung zum Bestimmen, ob und wo ein Marker in einem nächsten sequenziellen Frame zu speichern ist, gespeichert werden.
Der Block 550 kann die Netzwerkkomponente beinhalten, die bestimmt, ob die gegenwärtige Byteposition dort ist, wo der Beginn eines nächsten Markers einzusetzen ist. Beispielsweise kann der Block 550 eine Bestimmung beinhalten, ob die Variable „byte_num“ gleich der Variablen „next_marker“ ist. Wenn die gegenwärtige Bytepositionszahl nicht dort ist, wo ein nächster Marker einzusetzen ist, kann der Block 552 folgen. Wenn die gegenwärtige Bytepositionszahl ist, wo ein nächster Marker einzusetzen ist, kann der Block 560 folgen.
Der Block 552 kann das Inkrementieren der Bytezahl um eins beinhalten. Der Block 550 kann dem Block 552 folgen.
Der Block 560 kann die Netzwerkkomponente beinhalten, die einen Beginn eines Markers an der gegenwärtigen Byteposition angibt. Beispielsweise kann die gegenwärtige Bytposition durch eine Variable „byte_num“ repräsentiert werden. Unter dem MPA Protokoll hat der Marker (4) Bytes, obwohl jede Markergröße verwendet werden kann.
Der Block 562 kann die Netzwerkkomponente beinhalten, die die gegenwärtige Bytezahl um die Größe des eingesetzten Markers erhöht Beispielsweise kann der Block 562 das Erhöhen der Variablen „byte_num“ um vier beinhalten, obwohl jede andere Markergröße verwendet werden kann.
Der Block 564 kann die Netzwerkkomponente beinhalten, die die Größe eines gegenwärtigen Segments um die Größe des eingesetzten Markers erhöht. Beispielsweise kann die gegenwärtige Segmentgröße durch die Variable „segment_size“ repräsentiert werden. Beispielsweise kann der Block 564 das Erhöhen der Variablen „segment_size“ um vier beinhalten, obwohl jede andere Markergröße verwendet werden kann.
Der Block 566 kann die Netzwerkkomponente beinhalten, die das Setzen des Orts des nächsten Markers in einem nächsten sequentiellen Frame beinhaltet. Beispielsweise kann der nächste Markerort repräsentiert werden durch die Variable „marker_offset“. Entsprechend dem MPA Protokoll können die Marker alle 512 Bytes eingesetzt werden. Beispielsweise kann der Block 566 das Inkrementieren der Variablen „marker_offset“ um fündhundertzwölf (512) und das Subtrahieren einer Anzahl von Bytes in einer Bytezahl von dem Marker, der in dem Block 560 an das Ende des gegenwärtigen Frames eingesetzt ist, beinhalten. Andere Inkremente zwischen den Orten von Markern können verwendet werden.
Ausführungsbeispiele der vorliegenden Erfindung können implementiert werden durch eine oder eine Kombination aus: einem oder mehreren Mikrochips oder integrierten Schaltungen, die miteinander verbunden sind unter Verwendung einer Motherboard, einer harverdrahteten Logik, einer Software, die von einer Speichereinheit gespeichert und von einem Mikroprozessor ausgeführt wird, Firmenware, einem anwendungsspezifischen integrierten Schaltkreis (ASIC) und/oder einem feldprogrammierbaren Gatterarray (FPGA). Der Ausdruck „Logik“ kann beispielsweise eine Software oder eine Hardware und/oder eine Kombination aus einer Software und Hardware beinhalten.
Ausführungsbeispiele der vorliegenden Erfindung können beispielsweise ausgebildet sein als ein Computerprogrammprodukt, das einen oder mehrere maschinenlesbare Medien beinhaltet, die von einer Maschine ausführbaren Befehle speichert, bei deren Ausführung eine oder mehrere Maschinen wie ein Computer, ein Netzwerkcomputer oder andere elektronische Einheiten, in der eine oder mehre Maschinen, die Operationen in Übereinstimmung mit dieser vorliegenden Erfindung führt. Ein maschinen-lesbares Medium kann, ohne darauf begrenzt zu sein, aufweisen: Floppydisks, Disks, ROMs (Read Only Memories), RAMs (Random Access Memories), EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetische oder optische Karten, Flashspeicher oder andere Arten von medien/maschinen-lesbares Medien, die zum Speichern von einer Maschine ausführbaren Befehlen geeignet sind.
Weitere Ausführungsbeispiele der vorliegenden Erfindung können auch als ein Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer (beispielsweise eine Server) zu einem anfragenden Computer (beispielsweise einem Clienten) mit einem oder mit mehreren Datensignalen übertragen werden können, die in einem und/oder moduliert von einer Trägerwelle oder einem anderen fortschreitenden Medium über ein Kommunikationslink (beispielsweise einem Modem und/oder einer Netzwerkverbindung). Entsprechend kann das maschinen-lesbares Medium, wie es hier verwendet wird, eine Trägerwelle beinhalten, ohne dass dies erforderlich ist.
Die Zeichnungen und die vorangehende Beschreibung geben Beispiele der vorliegenden Erfindung. Obwohl als eine Anzahl von gesonderten funktionalen Punkten angegeben ist, versteht es der Fachmann, dass ein oder mehrere derartige Elemente auch zu einzelnen funktionellen Elementen kombiniert werden können. Alternativ können bestimmte Elemente in verschiedene funktionale Elemente aufgespalten werden. Elemente für ein Ausführungsbeispiel können zu einem anderen Ausführungsbeispiel hinzugefügt werden. Beispielsweise kann die Reihenfolge der hier beschriebenen Prozesse geändert werden und ist nicht auf die hier beschriebene Weise begrenzt. Der Schutzbereich der vorliegenden Erfindung ist jedoch in keiner Weise durch diese besonderen Ausführungsbeispiele begrenzt. Verschiedene Variationen, ob in der Beschreibung explizit angegeben oder nicht, etwa Unterschiede in der Struktur, der Dimension und der Verwendung des Materials sind möglich. Der Schutzbereich dieser Erfindung ist wenigstens so groß, wie er sich aus den beiliegenden Ansprüchen ergibt.

Claims

Verfahren mit: Übertragen (302) einer Anforderung von einer ersten Logik an eine zweite Logik, wobei die Anforderung eine Anforderung zum Bilden einer Netzwerkprotokolleinheit übereinstimmend mit dem Direct Data Placement (DDP)-Protokoll beihaltet; an der ersten Logik, Erzeugen mindestens eines Headerfelds für einen Headerabschnitt mindestens einer mit DDP übereinstimmenden Netzwerkprotokolleinheit; Liefern des erzeugten mindestens einen Headerfelds an die zweite Logik; an der zweiten Logik, Erzeugen mindestens eines Headerfelds; und an der zweiten Logik, selektives Bilden (304) mindestens einer mit dem DDP-Protokoll übereinstimmenden Netzwerkprotokolleinheit als Reaktion auf die Anforderung und basierend auf den erzeugten Header-Feldern von der ersten und zweiten Logik, wobei die Anforderung eine Identifizierung von Daten, eine Identifizierung eines Headers und eine Identifizierung eines Kontext beinhaltet und wobei jede der mindestens einen Netzprotokolleinheit Header- und Payload-Abschnitte aufweist.
Verfahren nach Anspruch 1, weiter mit: an einer zweiten Logik, Abrufen eines Teiles von Daten von der ersten Logik; und an der zweiten Logik, Bilden des Payload unter Verwendung des Abschnitts von Daten von der ersten Logik.
Verfahren nach Anspruch 1, weiter mit: an der zweiten Logik, Einsetzen eines Markers in wenigstens eine mit DDP übereinstimmende Netzwerkprotokolleinheit.
Verfahren nach Anspruch 1, weiter mit: an der zweiten Logik, Einsetzen eines Pads in wenigstens eine mit DDP übereinstimmende Netzwerkprotokolleinheit.
Verfahren nach Anspruch 1, weiter mit: an der zweiten Logik, Einsetzen eines Integritätsvalidationswerts in wenigstens eine mit DDP übereinstimmende Netzwerkprotokolleinheit.
Verfahren nach Anspruch 1, wobei das an der zweiten Logik erzeugte mindestens eine Headerfeld aus einer Gruppe ausgewählt ist, bestehend aus: einem DDP-Headerfeld, einem MPA-Headerfeld, einem TCP-Headerfeld und einem IP-Headerfeld.
Verfahren nach Anspruch 1, wobei die erzeugen Headerfelder ausgewählt sind aus einer Gruppe bestehend aus: einem RDMA-Headerfeld, einem TCP-Headerfeld und einem IP-Headerfeld.
Verfahren nach Anspruch 1, wobei das an der ersten Logik erzeugte mindestens eine Headerfeld mindestens eines umfasst aus: Quell- und Ziel-IP-Adressen, einer Version, einem Type of Service, einem Time to Live, einer Protokoll-ID, einer TCP-Headerlänge, einem TCP-Quellport, einem TCP-Zielport, einer Segmentbestätigungsnummer, einem Segmentfenster und Optionen.
Verfahren nach Anspruch 1, wobei die erste Logik ein Host-System umfasst und die zweite Logik eine Netzwerkkomponente umfasst.
Vorrichtung, die Folgendes umfasst: eine Netzwerkprotokolleinheitübertragungslogik (272); und eine Logik mit einem Prozessor, wobei der Prozessor eingerichtet ist, eine Bildung von mindestens einem Feld in einem Header einer Netzwerkprotokolleinheit anzufordern, die Netzwerkprotokolleinheitübertragungslogik (272) eingerichtet ist, mindestens ein Feld des Headers zu bilden, die Netzwerkprotokolleinheitübertragungslogik (272) eingerichtet ist, eine Netzwerkprotokolleinheit unter Verwendung mindestens eines Felds, das auf die Anforderung des Prozessors hin gebildet ist, und mindestens eines Felds, das von der Netzwerkprotokolleinheitübertragungslogik (272) gebildet ist, zu bilden, und die Logik dazu in der Lage ist, zu der Netzwerkprotokolleinheitübertragungslogik (272) eine oder mehrere Operationen abzuladen, die von dem Prozessor ausgeführt werden können und sich auf das Bilden einer Netzwerkprotokolleinheit übereinstimmend mit dem Direct Data Placement (DDP) beziehen, wobei die eine oder die mehreren Operationen ausgewählt sind aus einer Gruppe bestehend aus: Segmentieren eines Payloadabschnitts einer Netzwerkprotokolleinheit, Einsetzen eines Markers (262) in eine Netzwerkprotokolleinheit, Einsetzen eines Pads (264) in eine Netzwerkprotokolleinheit, Bestimmen eines Integritätsvalidierungswerts für eine Netzwerkprotokolleinheit und Einsetzen eines Integritätsvalidierungswerts (268) in eine Netzwerkprotokolleinheit.
Vorrichtung nach Anspruch 10, wobei, um mindestens ein Feld des Headers zu bilen, die Netzwerkprotokolleinheitübertragungslogik (272) eingerichtet ist, ein oder mehrere Headerfelder zu erzeugen, die aus einer Gruppe ausgewählt sind, bestehend aus: einem DDP-Headerfeld, einem MPA-Headerfeld, einem TCP-Headerfeld und einem IP-Headerfeld.
Vorrichtung nach Anspruch 10, wobei das Segmentieren eines Payloadabschnitts einer Netzwerkprotokolleinheit ein Abrufen eines Abschnitts von Daten mit einer Größe, die von dem DDP vorgegeben ist, aufweist.
Vorrichtung nach Anspruch 10, wobei der Integritätsvalidierungswert einen zyklischen Redundanzprüfwert aufweist.
Computerlesbares Medium mit auf diesem gespeicherten Befehlen, die bei einer Ausführung von einer Maschine die Maschine veranlassen zum: Ausgeben einer Anforderung zur Bildung einer mit dem Direct Data Placement (DDP) übereinstimmenden Netzwerkprotokolleinheit, Übersetzen der Anforderung in eine zweite Anforderung, Übertragen der zweiten Anforderung von einer ersten Logik zu einer zweiten Logik, wobei die erste Logik eingerichtet ist, mindestens ein Headerfeld für einen Headerabschnitt mindestens einer mit DDP übereinstimmenden Netzwerkprotokolleinheit zu erzeugen, die zweite Anforderung auf das erzeugte mindestens eine Headerfeld Bezug nimmt, und als Reaktion auf die zweite Anforderung, die zweite Logik eingerichtet ist, mindestens ein Headerfeld zu erzeugen, eine Netzwerkprotokolleinheit unter Verwendung des von der ersten Logik erzeugten mindestens einen Headerfelds und unter Verwendung des von der zweiten Logik erzeugten mindestens einen Headerfelds zu bilden, eine oder mehrere Operationen auszuführen, die aus einer Gruppe ausgewählt sind, bestehend aus: Segmentieren eines Payloadabschnitts einer Netzwerkprotokolleinheit, Einsetzen eines Markers in eine Netzwerkprotokolleinheit; Einsetzen eines Pads in eine Netzwerkprotokolleinheit, Bestimmen eines Integritätsvalidierungswerts für eine Netzprotokolleinheit und Einsetzen eines Integritätsvalidierungswerts in eine Netzwerkprotokolleinheit.
Computerlesbares Medium nach Anspruch 14, wobei die zweite Anforderung einen Header, Daten und einen Kontext referenziert.
Computerlesbares Medium nach Anspruch 14, wobei, um mindestens ein Headerfeld zu erzeugen, die zweite_Logik eingerichtet ist, ein oder mehrere Headerfelder zu erzeugen, die aus einer Gruppe ausgewählt sind, bestehend aus: einem DDP-Headerfeld, einem MPA-Headerfeld, einem TCP-Headerfeld und einem IP-Headerfeld.
Computerlesbares Medium nach Anspruch 14, wobei die Befehle, die bei ihrer Ausführung von einer Maschine die Maschine dazu veranlassen, eine Anforderung zur Bildung einer mit dem Direct Data Placement (DDP) übereinstimmenden Netzwerkprotokolleinheit auszugeben, einen Stack aufweisen.
Computerlesbares Medium nach Anspruch 14, wobei die Befehle, die bei ihrer Ausführung durch eine Maschine die Maschine zum Übersetzen der Anforderung in eine zweite Anforderung veranlassen, einen Netzwerkkomponententreiber aufweisen.
System, das Folgendes umfasst: ein Hostsystem (102) mit einem Prozessor (110) und einem Speicher (112), wobei das Hostsystem (102) aufweist: eine Logik zum Ausgeben einer Anforderung zur Bildung einer mit dem Direct Data Placement (DDP) übereinstimmenden Netzwerkprotokolleinheit; eine Netzwerkkomponente (118) zum Empfangen der Anforderung und, als Reaktion auf die Anforderung, Bilden einer mit dem DDP übereinstimmenden Netzwerkprotokolleinheit und wobei das Hostsystem (102) eine Logik zum Erzeugen mindestens eines Headerfelds für den Headerabschnitt der Netzwerkprotokolleinheit und Liefern des erzeugten mindestens einen Headerfelds an die Netzwerkkomponente (118) umfasst, die Netzwerkkomponente (118) eingerichtet ist, mindestens ein Headerfeld für den Headerabschnitt der Netzwerkprotokolleinheit zu erzeugen, die Netzwerkkomponente (118) eingerichtet ist, die Netzwerkprotokolleinheit unter Verwendung mindestens eines von dem Hostsystem (102) erzeugten Headerfelds und unter Verwendung mindestens eines von der Netzwerkkomponente (118) erzeugten Headerfelds zu bilden, und die Netzwerkkomponente (118) zum Ausführen einer oder mehrerer Operationen dient, ausgewählt aus einer Gruppe bestehend aus: Segmentieren eines Payloadabschnitts einer Netzwerkprotokolleinheit, Einsetzen eines Markers in eine Netzwerkprotokolleinheit, Einsetzen eines Pads in eine Netzwerkprotokolleinheit, Bestimmen eines Integritätsvalidierungswerts über eine Netzwerkprotokolleinheit und Einsetzen eines Integritätsvalidierungswerts in eine Netzwerkprotokolleinheit; und einem Display, das kommunikativ mit dem Hostsystem (102) gekoppelt ist.
System nach Anspruch 19, wobei, um mindestens ein Headerfeld für den Headerabschnitt der Netzwerkprotokolleinheit zu erzeugen, die Netzwerkkomponente (118) eingerichtet ist, ein oder mehrere Headerfelder zu erzeugen, dieaus einer Gruppe ausgewählt sind, bestehend aus: einem DDP-Headerfeld, einem MPA-Headerfeld, einem TCP-Headerfeld und einem IP-Headerfeld.