DE102020111039A1

DE102020111039A1 - Geräteunterstützung bestellte und unbestellte transaktionsklassen

Info

Publication number: DE102020111039A1
Application number: DE102020111039.1A
Authority: DE
Inventors: Gregg B Lesartre; Derek Alan Sherlock
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2019-05-08
Filing date: 2020-04-23
Publication date: 2020-11-12
Also published as: US20200356497A1; CN111917815A; US11593281B2

Abstract

Ein Kommunikationsgerät, das einen Anforderer und einen Antwortenden enthält, kann mehrere Transaktionsklassen unterstützen, einschließlich einer geordneten Transaktionsklasse, während eine gegabelte Anforderungs- / Antwortarchitektur beibehalten wird. Bevor ein Antwortender eine nicht gebuchte Transaktionsantwort zum Senden auf einer Verbindung hat, erhält er vom Anforderer eine Anzeige, dass auf der Verbindung keine ausstehende gebuchte Transaktion vorliegt.

Description

HINTERGRUND
Bestimmte Systemverbindungskommunikationsprotokolle definieren verschiedene Pakettypen, die von an die Verbindung angeschlossenen Komponenten unterstützt werden müssen. Beispielsweise kann das Protokoll Leseanforderungen, Leseantworten, Schreibanforderungen, Schreibbestätigungen und verschiedene Steuerpakete definieren. Ältere Computersystemverbindungen wie PCle sorgen teilweise für korrektes Verhalten, indem bestimmte Fabric-Bestellregeln angegeben werden, um sicherzustellen, dass Transaktionen nur in der erwarteten Reihenfolge sichtbar werden. Einige Fabric-Verbindungen wie Gen-Z wurden entwickelt, um diese Anforderungen zu beseitigen und eine höhere Leistung und Zuverlässigkeit zu erzielen.
Figurenliste
Bestimmte Beispiele werden in der folgenden detaillierten Beschreibung und unter Bezugnahme auf die Zeichnungen beschrieben, in denen:

1 ein Beispielsystem darstellt, das einen Knoten auf einer Struktur enthält, der sowohl einen Anforderer als auch einen Antwortenden enthält;
2 ein beispielhaftes Gerät darstellt, das einen Anforderer und einen Antwortenden enthält;
3 ein beispielhaftes Gerät darstellt, das einen Anforderer und einen Antwortenden enthält;
4 ein Kommunikations-Bounce-Diagramm ist, das eine beispielhafte Reihe von Kommunikationen zwischen einem ersten Anforderer und einem Antwortenden an einem ersten Ziel und einem zweiten Anforderer und Antwortenden an einem zweiten Ziel darstellt; und
5 zeigt ein beispielhaftes Betriebsverfahren eines gegabelten Anforderers und eines Antwortenden.

DETAILLIERTE BESCHREIBUNG SPEZIFISCHER BEISPIELE
Implementierungen der beschriebenen Technologie stellen ein System bereit, das mehrere Transaktionsklassen unter Verwendung einer Split-Requester/ Responder-Architektur unterstützt. Die erste Transaktionsklasse kann eine entspannte Bestellung ermöglichen, bei der Pakete einander übergeben und in einer anderen Reihenfolge am Ziel ankommen können, als sie von der Quelle gesendet wurden. Die zweite Transaktionsklasse hat strengere Bestellanforderungen, bei denen bestimmte Pakettypen andere Pakettypen innerhalb der Klasse nicht passieren können. Beispielsweise kann die zweite Transaktionsklasse einen Pakettyp für gesendete Schreibanforderungen und einen Pakettyp für nicht gesendete Leseantworten enthalten, bei denen nicht gesendete Leseantworten möglicherweise keine gesendeten Schreibanforderungen weitergeben. Beispielsweise kann die erste Transaktionsklasse ein Satz von Kern-Punkt-zu-Punkt-Gen-Z-Pakettypen sein, während die zweite Transaktionsklasse ein Satz von Gen-Z-PCIe-kompatiblen Bestellpakettypen sein kann.
Ein Knoten kann eine geteilte Architektur aufweisen, bei der ein Anforderer und ein Antwortblock unabhängig voneinander Pakete in eine Struktur injizieren. Der Anforderer übernimmt das Einfügen von Transaktionsanforderungen, z. B. Leseanforderungen und Schreibanforderungen in die Fabric. Der Responder übernimmt das Einfügen von Transaktionsantworten, wie z. B. Leseantworten und Schreibbestätigungen, in die Fabric. In einigen Implementierungen wählen der Anforderer und der Antwortende Pakete unabhängig voneinander aus ihren jeweiligen Warteschlangen aus. Der Anforderer und der Antwortende injizieren Pakete der ersten Transaktionsklasse unabhängig von einer anderen in die Struktur.
Bei Antworten der zweiten Transaktionsklasse, die gebuchte Transaktionsanforderungen der zweiten Klasse nicht weitergeben können, fragt der Antwortende den Anforderer ab, um festzustellen, ob für dasselbe Ziel eine ausstehende gebuchte Transaktionsanforderung gebunden ist. Wenn eine ausstehende gebuchte Transaktion vorliegt, puffert der Antwortende die ausgewählte Antwort, bis der Anforderer angibt, dass die ausstehende gebuchte Transaktion nicht mehr aussteht. Diese Architektur ermöglicht es dem Responder, dieselbe Warteschlangen-, Arbitrierungs- und Injektionslogik zu verwenden, um Transaktionen beider Klassen zu verarbeiten, wodurch die Menge an zusätzlicher Logik reduziert wird, die zur Unterstützung beider Transaktionsklassen erforderlich ist. Darüber hinaus kann die Architektur ermöglichen, dass Transaktionen beider Klassen durch eine gemeinsame Routing-Logik innerhalb einer Switch-Struktur unterstützt werden, die die Anforderer und Antwortenden miteinander verbindet.
Einige Implementierungen unterstützen mehrere virtuelle Kanäle (VCs). VCs sind logische Paketströme, die über eine einzelne physische Verbindung gesendet werden. Beispielsweise kann eine Komponente mehrere VCs verwenden, um die Paketdifferenzierung zu ermöglichen, um unterschiedliche Dienstraten, Dienstqualitätsniveaus (QoS) bereitzustellen, Mehrweg- und dynamisches Routing zu erleichtern, Deadlocks zu verhindern oder andere Merkmale. Ein Paket kann einem VC zugewiesen werden, indem eine VC-Kennung als ein dem Paket zugeordnetes Informationselement eingeschlossen wird.
In einigen Implementierungen werden Pakete der zweiten Transaktionsklasse (Anforderungs- und Antwortpakete) auf einem virtuellen Kanal übertragen, der von den virtuellen Kanälen getrennt ist, die zum Übertragen der Pakete der ersten Transaktionsklasse verwendet werden. In anderen Implementierungen werden Anforderungspakete der zweiten Transaktionsklasse auf einem oder mehreren virtuellen Kanälen übertragen und Antwortpakete der zweiten Transaktionsklasse werden auf einem oder mehreren verschiedenen virtuellen Kanälen übertragen. Diese beiden Implementierungen können die Informationen des virtuellen Kanals verwenden, um die Bestellanforderungen für gebuchte Transaktionsanforderungen der zweiten Klasse aufrechtzuerhalten. Beispielsweise kann in beiden dieser Implementierungen die Fabric dieselbe Route auf alle gesendeten Anforderungspakete von einer Quelle zu einem Ziel anwenden.
In einigen Implementierungen können die für Pakete der zweiten Transaktionsklasse verwendeten virtuellen Kanäle von den für Pakete der ersten Transaktionsklasse verwendeten virtuellen Kanälen getrennt sein. Dies kann beispielsweise ermöglichen, dass die Pakete der zweiten Transaktionsklasse eine statische Route durch die Fabric basierend auf dem virtuellen Kanal haben, ohne das Routing der Pakete der ersten Transaktionsklasse zu beeinflussen. In anderen Implementierungen können Pakete beider Klassen dieselben virtuellen Kanäle verwenden. Beispielsweise können Leseantworten beider Transaktionsklassen auf demselben virtuellen Kanal gesendet werden, während Schreibanforderungen einer Klasse auf einem anderen virtuellen Kanal gesendet werden als Schreibanforderungen der anderen Klasse. Als weiteres Beispiel können Schreib- und Leseanforderungen beider Transaktionsklassen auf demselben virtuellen Kanal (denselben virtuellen Kanälen) gesendet werden, und andere Informationselemente können von der Struktur zum geordneten Routing der gebuchten Transaktionsanforderungen der zweiten Transaktionsklasse verwendet werden.
1 zeigt ein Beispiel einer Vielzahl von Knoten, die über eine paketvermittelte Struktur 108 verbunden sind. Die Knoten 101, 118, 119, 120 können verschiedene Komponenten sein. Beispielsweise kann ein Knoten einen Prozessor oder ein System auf einem Chip (SOC) mit einem integrierten Speicher oder Speichercontroller, ein Speichermodul wie einen dynamischen Direktzugriffsspeicher (DRAM), einen nichtflüchtigen Speicher (NVM) oder eine Speicherklasse enthalten Speichermodul (SCM), eine Grafikkarte oder ein anderer Beschleuniger, ein Netzwerkcontroller, ein Switch, ein digitaler Signalprozessor, eine benutzerdefinierte anwendungsspezifische integrierte Schaltung (ASIC) oder ein feldprogrammierbares Gate-Array (FPGA) oder ein anderes Gerät, das über einen Speicher kommuniziert -Semantisches Kommunikationsprotokoll. In dem speichersemantischen Protokoll entspricht die Kommunikation einer Lade- / Speicherprozessorarchitektur. Die Kommunikation zwischen Komponenten kann unter Verwendung von Lese- und Schreibanforderungen an bestimmte Adressen durchgeführt werden, beispielsweise auf der Ebene der Byteadresse. Die Lese- und Schreibanforderungen sind jedoch nicht notwendigerweise auf das Lesen und Schreiben von Daten in den Speicher oder den byteadressierbaren Speicher beschränkt. Beispielsweise kann ein Beschleuniger einen Bereich von Adressen verfügbar machen, aus denen gelesen und in die geschrieben werden kann, um auf eine Beschleuniger-Arbeitswarteschlange zuzugreifen oder aus einer Abschlusswarteschlange zu lesen.
In dem dargestellten Beispiel sind die Knoten über eine Switch Fabric 108 verbunden. Die Vermittlungsstruktur 108 kann mehrere Paketvermittler umfassen, die die Komponenten in einer Topologie verbinden, wie beispielsweise einer Gesamttopologie. In anderen Beispielen können die Knoten auf verschiedene Arten miteinander verbunden sein. Beispielsweise können die Knoten Switch-Attached, Direct-Attached oder Daisy-Chained sein.
Jede Knotenkomponente 101, 118, 119, 120 enthält eine Komponentenschnittstelle. Verschiedene Komponenten können Schnittstellenkonfigurationen haben. Beispielsweise haben die Knoten 101 und 120 Schnittstellen 105, 117, die einen Anforderer 102, 114 und einen Responder 103, 115 umfassen; Der Knoten 118 hat eine Schnittstelle 113, die einen Anforderer, aber keinen Antwortenden umfasst. und der Knoten 119 hat eine Schnittstelle 116, die einen Antwortenden, aber keinen Anforderer umfasst. In dieser Architektur senden die Anforderer 102, 114, 113 Anforderungen an die Antwortenden 103, 115, 116 und die Antwortenden 103, 115, 116 senden Antworten auf empfangene Anforderungen. Zur Erläuterung ist jeder Schnittstellenblock (dh jeder Anforderer 120, 114, 113 und jeder Antwortende 103, 112, 110) mit einer individuellen Verbindung 106, 107, 109-112 zu der Struktur 108 dargestellt. In einigen Bereitstellungen sind die einzelnen Links möglicherweise eher logisch als physisch. Beispielsweise können die Verbindungen 106 und 107 durch Zeitmultiplex auf einer einzelnen Duplexverbindung implementiert werden, oder es kann ein anderes Verfahren zum Bereitstellen dedizierter logischer Verbindungen auf einer gemeinsam genutzten physischen Verbindung verwendet werden.
In diesem Beispiel unterstützen der Anforderer 102 und der Antwortende 103 der Schnittstelle 105 eine erste Transaktionsklasse und eine zweite Transaktionsklasse.
Die erste Transaktionsklasse enthält mehrere speichersemantische Pakettypen, die ein entspanntes Ordnungsmodell aufweisen. Beispielsweise kann die erste Transaktionsklasse Leseanforderungen, Leseantworten und Schreibanforderungen enthalten.
Die Leseanforderungen können von den Anforderern 102, 114, 113 an die Antwortenden 103, 115, 116 übertragen werden. Dies sind Pakete, die das Auslesen und Zurückgeben von Daten von einer durch die Leseanforderung definierten Speicheradresse anfordern. Die Leseantworten werden von den Antwortenden 103, 115, 116 an die Anforderer 102, 114, 113 übertragen, um die von einer entsprechenden Leseanforderung angeforderten Daten zurückzugeben. Die erste Transaktionsklasse kann einen oder mehrere Arten von Leseanforderungen enthalten. Beispielsweise kann die erste Transaktionsklasse verschiedene Arten von Leseanforderungen zum Lesen von N Datenbytes ab einer angegebenen Adresse enthalten, wobei N je nach Anforderungstyp variiert (z. B. kann die Komponente eine Leseanforderung zum Lesen von 32 unterstützen 32 Datenbytes, beginnend mit einer in der Anforderung enthaltenen Adresse oder eine „Read 64“ -Anforderung zum Lesen von 64 Datenbytes, beginnend mit einer in der Anforderung enthaltenen Adresse).
Schreibanforderungen werden von Anforderern übertragen und sind Pakete, die das Schreiben von Daten an eine bestimmte Adresse anfordern. Die Schreibanforderungen können eine Startspeicheradresse und eine Nutzlast enthalten, die an der Startspeicheradresse in den Speicher geschrieben werden sollen. In einigen Implementierungen können die Schreibanforderungen durch ein Bestätigungspaket bestätigt werden, das vom Antwortenden nach Ausführung des angeforderten Schreibvorgangs gesendet wird. In anderen Implementierungen können die Schreibanforderungen von den empfangenden Antwortenden nicht bestätigt werden. In weiteren Implementierungen kann die Architektur sowohl bestätigte als auch nicht bestätigte Schreibanforderungen innerhalb der ersten Transaktionsklasse unterstützen.
Die zweite Transaktionsklasse umfasst gebuchte Schreibanforderungen, nicht gebuchte Anforderungen und Antworten.
Für eine gesendete Anfrage muss nicht auf eine Antwort zum Abschluss der Anfrage gewartet werden, um den Erfolg oder Misserfolg der Anfrage anzuzeigen. Wenn beispielsweise eine gesendete Schreibanforderung ausgegeben wird, kann die Quelle der Anforderung die Anforderung als abgeschlossen behandeln, sobald ihr Anforderer die Anforderung an die Fabric sendet, ohne auf den Empfang einer Bestätigung von einem empfangenden Antwortenden zu warten. Beispielsweise kann die Komponente innerhalb der anfordernden Quelle, die die Übertragung der Anforderung verursacht hat, wie z. B. eine auf dem Knoten ausgeführte Anwendung oder ein Betriebssystem, die gesendete Anforderung als abgeschlossen behandeln, sobald der Anforderer die gestellte Anforderung sendet.
Eine nicht veröffentlichte Anforderung erfordert eine Abschlussantwort, um den Erfolg oder Misserfolg der Anforderung anzuzeigen oder die angeforderten Daten bereitzustellen. Wenn der oben genannte Speichercontroller beispielsweise einen nicht gesendeten Lesevorgang ausgibt, muss der Speichercontroller warten, bis die angeforderten Daten von einem Antwortenden zurückgegeben werden. Als weiteres Beispiel kann die zweite Transaktionsklasse auch nicht gebuchte Schreibanforderungen enthalten. Ein Anforderer, der eine nicht gebuchte Schreibanforderung ausstellt, wartet auf eine Schreibbestätigung, bevor er auf eine Weise handelt, die den Abschluss der nicht gebuchten Schreibanforderung voraussetzt.
Die zweite Transaktionsklasse verfügt über ein Bestellmodell, bei dem gebuchte Anfragen nicht gebuchte Anfragen und Antworten an dasselbe Ziel weiterleiten können und keine Anfrage oder Antwort eine gebuchte Anfrage an dasselbe Ziel weiterleiten kann. Beispielsweise kann das Bestellmodell ein PCIe-kompatibles Bestellmodell sein.
In einigen Implementierungen können die erste und die zweite Transaktionsklasse Pakettypen oder -formate gemeinsam nutzen. Beispielsweise kann ein Metadaten-Tag, wie beispielsweise ein Informationselement in einem Schreibanforderungspaket-Header, angeben, ob die Schreibanforderung der ersten Transaktionsklasse oder der zweiten Transaktionsklasse angehört. Wenn die Anforderung der zweiten Klasse angehört, kann ein Informationselement außerdem angeben, ob es sich bei der Anforderung um eine gebuchte oder eine nicht gebuchte Anfrage handelt.
Zurück zu 1 sendet der Antwortende 103 Transaktionen der ersten Klasse unabhängig von Transaktionen der ersten Klasse, die vom Anforderer 102 gesendet werden. Beispielsweise kann der Antwortende 103 Warteschlangen- und Prioritätsschiedsentscheidungen unabhängig von der vom Anforderer 102 durchgeführten Warteschlangen- und Prioritätsschiedsentscheidung durchführen. Beispielsweise kann der Antwortende 103 eine Leseantwortwarteschlange ausstehender Leseantworten aufweisen, um sie an Anforderer auf anderen Knoten 118-120 zu senden. Der Antwortende kann eine Leseantwort aus der Warteschlange auswählen und die Leseantwort über die Verbindung 107 senden, unabhängig vom Status von Anforderungen, die der Anforderer 102 möglicherweise in seinen eigenen Warteschlangen hat oder die auf der Fabric 108 anstehen.
In einigen Fällen sind die Antwortenden 103, 115, 116 so konfiguriert, dass sie Bestätigungen an Anforderer für gebuchte Transaktionsanforderungen der zweiten Transaktionsklasse senden. In einigen Fällen können diese Bestätigungen nach Eingang der gesendeten Transaktionsanforderung beim Antwortenden bereitgestellt werden. In anderen Fällen können diese Bestätigungen bereitgestellt werden, nachdem die angeforderte Transaktion abgeschlossen wurde.
Beispielsweise sendet der Antwortende 115 für eine gesendete Schreibanforderung in einigen Implementierungen die Empfangsbestätigung der gesendeten Schreibanforderung unabhängig davon, ob die Daten innerhalb der Anforderung auf sein Medium geschrieben wurden oder nicht. Dies kann implementiert werden, wenn geschriebene Daten für einen nachfolgenden Lesevorgang sichtbar sind, bevor die Daten tatsächlich auf das Medium des Antwortenden geschrieben werden. Dies kann beispielsweise implementiert werden, wenn der Antwortende einen nachfolgenden Lesevorgang aus einem Schreibpuffer ausführen kann, während der Schreibvorgang parallel ausgeführt wird.
In anderen Implementierungen sendet der Antwortende 115 die Empfangsbestätigung, nachdem die Schreibanforderung abgeschlossen wurde. Dies kann beispielsweise auftreten, wenn ein Schreibvorgang für einen nachfolgenden Lesevorgang erst sichtbar ist, wenn er auf dem Medium des Antwortenden gespeichert ist. Als weiteres Beispiel kann dies auftreten, wenn ein Schreibvorgang persistent sein muss und auf einem nichtflüchtigen Datenspeichermedium festgeschrieben werden muss, bevor er als persistent behandelt werden kann. (Im Vergleich dazu wird in einem Beispiel, in dem ein Schreibvorgang vor nachfolgenden Lesevorgängen dauerhaft sein muss, der Responder jedoch einen durch Batterie oder Kondensator gesicherten flüchtigen Cache für sein nichtflüchtiges Medium enthält, die gesendete Schreibbestätigung möglicherweise gesendet, bevor der Responder die Daten an seinen festschreibt nichtflüchtiges Medium.)
Der Anforderer 102 verwendet die Bestätigungen, um Transaktionsanforderungen zu buchen, um die Abhängigkeit einer gesendeten Transaktionsanforderung der zweiten Transaktionsklasse auf der Fabric zu verfolgen. Mit anderen Worten, der Anforderer 102 zeigt an, dass eine gebuchte Transaktion von dem Zeitpunkt an, an dem sie auf der Fabric 108 gesendet wird, bis zu dem Zeitpunkt, an dem eine Bestätigung des Durchlaufs vom Ziel empfangen wird, ansteht. In einigen Implementierungen wird diese Bestätigung nicht an die Quelle der Anforderung gesendet. Mit anderen Worten, da die anfordernde Komponente die gebuchte Transaktionsanforderung als vollständig behandeln konnte, als die gebuchte Transaktionsanforderung gesendet wurde, benötigt sie keine Bestätigung, dass die gebuchte Transaktionsanforderung empfangen wurde.
Das System umfasst ferner einen Kommunikationskanal 104 zwischen dem Antwortenden 103 und dem Anforderer 102. Der Antwortende 103 verwendet den Kanal 104, um eine Anzeige von dem Anforderer 102 zu empfangen, die angibt, ob der Anforderer 102 eine ausstehende vorhergesagte Transaktionsanforderung der zweiten Transaktionsklasse hat, bevor er eine nicht gebuchte Transaktionsantwort der zweiten Transaktionsklasse sendet. Beispielsweise kann der Kanal 104 eine Bus- oder andere Kommunikationsverbindung zwischen dem Anforderer 102 und dem Antwortenden 103 sein, kann ein Port zu einem Registersatz, einer Tabelle oder einer anderen Datenstruktur sein, die der Anforderer 102 verwaltet, oder ein anderer Kanal.
In einigen Implementierungen sendet der Antwortende 104 keine nicht gebuchte Antwort an ein Ziel, wenn eine ausstehende gebuchte Transaktion der zweiten Transaktionsklasse vorliegt, die vom Anforderer an dieses Ziel gesendet wurde. Wenn beispielsweise der Antwortende 103 eine Transaktionsantwort aus der zweiten Klasse auswählt, die für den Knoten X bestimmt ist (d. H. Einer der Knoten 118 oder 120), fragt der Antwortende 103 den Anforderer ab, um festzustellen, ob eine ausstehende gebuchte Transaktionsanforderung vorliegt für Knoten X. In anderen Implementierungen sendet der Antwortende 104 keine nicht gebuchte Antwort der zweiten Transaktionsklasse an ein Ziel, wenn eine ausstehende gebuchte Transaktion der zweiten Transaktionsklasse vorliegt, die vom Anforderer an ein Ziel gesendet wurde.
In einigen Fällen verzögert der Antwortende 103 das Senden der nicht gebuchten Transaktionsantwort, bis der Anforderer 102 keine ausstehende vorhergesagte Transaktionsanforderung für dasselbe Ziel wie die nicht gebuchte Transaktion hat. Beispielsweise kann der Antwortende 103 nicht gebuchte Transaktionsantworten puffern, bis er den Hinweis erhält, dass keine vorher gesendete Transaktionsanforderung an dasselbe Ziel vorliegt. Durch Warten auf den Abschluss dieser veröffentlichten Schreibanforderungen vor dem Ausgeben der Leseantwort entfällt bei dieser Lösung die Notwendigkeit, dass der Rest der Fabric die Reihenfolge dieser Flows verwaltet. Die Leseantwort kann die gesendete Anforderung nicht bestehen, da die Anforderung bereits abgeschlossen wurde.
zeigt ein Beispielgerät mit einem gegabelten Anforderer und Responder. Beispielsweise kann die Vorrichtung 201 eine Implementierung einer Vorrichtung wie des Knotens 1 101 sein, wie in Bezug auf 1 beschrieben. Die dargestellten Systemkomponenten sind als Logikblöcke dargestellt, die in Hardware als digitale Schaltung, als Firmware oder Software, die in einem nicht vorübergehenden Medium wie einem Flash-Speicher oder einem ROM gespeichert ist, oder als eine Kombination davon implementiert werden können.
Die Vorrichtung 201 umfasst einen Systemberechnungsknoten mit einem Anforderer 204 und einem Antwortenden 205. Zu Erklärungszwecken umfasst die Vorrichtung 201 eine CPU 202, die eine Speichersteuerung 203 umfasst, die mit dem Anforderer 204 und dem Antwortenden 204 gekoppelt ist, sowie einen lokalen Speicher 222. Wie oben diskutiert, kann in anderen Implementierungen die Vorrichtung 201 ein Speichermodul sein, wie beispielsweise ein dynamischer Direktzugriffsspeicher (DRAM), ein nichtflüchtiger Speicher (NVM) oder ein Speicherklassenspeichermodul (SCM). In einer solchen Implementierung könnte das Gerät anstelle einer CPU 202 eine Mediensteuerung mit einer Schnittstelle zu einem Speicher oder einer Speichervorrichtung und einer Schnittstelle zu dem Anforderer 204 und dem Antwortenden 205 enthalten. In weiteren Implementierungen kann die Vorrichtung 201 eine Grafikkarte oder ein anderer Beschleuniger, eine Netzwerksteuerung, ein Schalter, ein digitaler Signalprozessor, eine kundenspezifische anwendungsspezifische integrierte Schaltung (ASIC) oder ein feldprogrammierbares Gate-Array (FPGA) oder eine andere Vorrichtung sein, die kommuniziert unter Verwendung eines speichersemantischen Kommunikationsprotokolls.
Die Vorrichtung 201 umfasst einen Anforderer 204 zur Unterstützung einer ersten Transaktionsklasse und einer zweiten Transaktionsklasse. Der Anforderer umfasst mehrere Anforderungsübertragungswarteschlangen 206, 208, 210, 212. In diesem Beispiel unterstützt der Anforderer vier virtuelle Kanäle (VCs) und verwaltet für jeden virtuellen Kanal eine separate Übertragungswarteschlange 206, 208, 210, 212. Während der Anforderer 204 mit vier VCs dargestellt ist, können Implementierungen eine größere oder kleinere Anzahl von VCs oder nur einen einzelnen Kanal aufweisen (was als implizite VC angesehen werden kann). In einigen Implementierungen erzeugt die Speichersteuerung 203 oder die CPU 202 die zu übertragenden Pakete und platziert sie direkt in den Warteschlangen 206, 208, 210, 212, einschließlich der Zuweisung der Pakete zu ihrer VC. In anderen Implementierungen sendet die CPU 202 Anforderungen wie Lade- oder Speicheranforderungen an den Anforderer 204, den Responder 205 oder eine dazwischenliegende Komponente (nicht dargestellt), die dann die geeigneten Transaktionspakete erzeugt, um die CPU-Anforderung zu implementieren.
Jede Warteschlange 206, 208, 210, 212 ist jeweils mit einem Warteschlangen-Arbiter 207, 209, 211, 213 gekoppelt. Der Warteschlangen-Arbiter 207, 209, 211, 213 wählt ein Paket aus seiner jeweiligen Warteschlange 206, 208, 210, 212 aus. Beispielsweise kann der Warteschlangen-Arbiter 207 einen von verschiedenen Arten einer prioritätsbasierten Paketauswahl anwenden, um ein Paket aus der Warteschlange auszuwählen. Die verschiedenen Schiedsrichter 207, 209, 211, 213 können unterschiedliche Priorisierungstechniken anwenden oder können dieselbe Technik anwenden. In einigen Implementierungen sind einige oder alle der Schiedsrichter 207, 209, 211, 213 nicht vorhanden, und stattdessen sind die Warteschlangen 206, 208, 210, 212 FIFO-Puffer (First-In, First-Out).
Ein VC-Arbiter 214 wählt ein Paket zum Senden aus den Kandidatenpaketen von den verschiedenen VCs aus (dh von den verschiedenen Warteschlangen-Arbitern 207, 209, 211, 213 oder vom Kopf der FIFO-Puffer, wenn keine Warteschlangenarbitrierung vorliegt). Der VC-Arbiter 214 kann verschiedene unterschiedliche Arbitrierungsalgorithmen anwenden, um das Paket für die Übertragung auszuwählen. Beispielsweise kann der Arbiter 214 eine Round-Robin-Technik, eine altersbasierte Priorisierung oder eine gewichtete Version eines dieser Algorithmen anwenden, um das Paket für die Übertragung auszuwählen. Das ausgewählte Paket wird an den Anforderungs-Transceiver 215 zur Injektion auf eine Verbindung 223 in die Struktur 224 zur Übertragung an das Ziel des Pakets gesendet.
Der Anforderer 204 umfasst ferner mehrere Empfangswarteschlangen 218, 219, 220, 221. Jede Empfangswarteschlange 218, 219, 220, 221 entspricht einer der vom Anforderer 204 unterstützten VCs. Beispielsweise können die Empfangswarteschlangen 218, 219, 220, 221 FIFO-Puffer sein, die Antworten auf Anforderungen speichern, die zuvor vom Anforderer gesendet wurden.
Der Anforderer 204 umfasst ferner einen Verfolger 216, der das Ende-zu-Ende-Durchlaufen von gebuchten Transaktionsanforderungen der zweiten Transaktionsklasse verfolgt. In diesem Beispiel ist der Tracker 216 mit dem Transceiver 215 gekoppelt und zwischen dem VC-Arbiter 214 und dem Transceiver 215 angeordnet. Dies ermöglicht es dem Verfolger 216, Pakete zu untersuchen, bevor sie übertragen werden, und gebuchte Transaktionsanforderungen der zweiten Transaktionsklasse zu verfolgen. In anderen Implementierungen kann sich der Tracker 216 außerhalb der Sende- und Empfangspfade des Hauptpakets befinden. Beispielsweise kann der Verfolger 216 den Bus zwischen dem VC-Arbiter 214 und dem Transceiver 215 abhören, um zu bestimmen, wann eine gesendete Transaktionsanforderung gesendet wird.
Der Verfolger 216 ist ferner mit einer Datenstruktur 217 gekoppelt, die er verwaltet, um während des Flugs gebuchte Transaktionsanforderungen der zweiten Transaktionsklasse zu verfolgen. Der Verfolger 216 kann die Datenstruktur auf verschiedene Arten aufrechterhalten. Beispielsweise kann die Datenstruktur 217 eine Tabelle sein, in der jeder Eintrag einer im Flug veröffentlichten Transaktionsanforderung entspricht. Beispielsweise kann jeder Eintrag ein Ziel und eine ID einer im Flug gebuchten Transaktion enthalten. Wenn der Transceiver 215 eine Bestätigung der Durchquerung einer gebuchten Transaktion empfängt, kann der Verfolger 216 den Eintrag löschen, der der gebuchten Transaktion entspricht. Als weiteres Beispiel kann jeder Eintrag eine Ziel-ID und einen Zähler enthalten, den der Tracker jedes Mal erhöht, wenn eine gebuchte Transaktion an die entsprechende ID gesendet wird, und jedes Mal verringert wird, wenn eine gebuchte Transaktionsbestätigung empfangen wird. In diesem Beispiel kann der Tracker den Tabelleneintrag löschen, wenn der Zähler 0 erreicht.
Wie oben erläutert, kann eine gebuchte Transaktionsanforderung nach ihrer Übertragung als abgeschlossen behandelt werden. Beispielsweise kann eine Anwendung, die auf der CPU 202 ausgeführt wird, eine gesendete Schreibanforderung behandeln, sobald sie in die Struktur 224 injiziert wird. Dementsprechend können die vom Anforderer 204 empfangenen gebuchten Transaktionsüberquerungsbestätigungen verworfen werden, nachdem der Verfolger 216 die Bestätigung verwendet, um das Durchlaufen der Transaktionsanforderung zu verfolgen. Befindet sich der Tracker 216 beispielsweise im Pfad zwischen den Empfangswarteschlangen 218, 219, 220, 221, kann der Tracker 216 gebuchte Transaktionsüberquerungsbestätigungen verwerfen, ohne sie an die Empfangswarteschlangenverwaltungslogik weiterzuleiten.
Die Vorrichtung 201 umfasst ferner einen Antwortenden 205, um eine erste Transaktionsklasse und eine zweite Transaktionsklasse zu unterstützen. Der Antwortende 205 umfasst mehrere Empfangswarteschlangen 238, 239, 240, 241. Beispielsweise können die Empfangswarteschlangen 238, 239, 240, 241 FIFO-Puffer sein, die empfangene Anforderungen speichern. In diesem Beispiel unterstützt der Responder vier virtuelle Kanäle (VCs) und verwaltet für jede VC eine separate Empfangswarteschlange 238, 239, 240, 241. In einigen Beispielen sind einige oder alle der vom Responder 205 unterstützten VCs dieselben VCs wie die vom Anforderer 204 unterstützten. Zum Beispiel können die VCs durch ID-Nummern unterschieden werden und die vom Responder unterstützten VCs können die gleichen oder einen überlappenden Satz von ID-Nummern haben.
Wie oben beschrieben, empfängt der Antwortende Anforderungen von anderen Anforderern über die Struktur 224. Diese Anforderungen werden in den Warteschlangen 238, 239, 240, 241 in die Warteschlange gestellt. Die Anforderungen werden dann an die Speichersteuerung 203 übergeben, die die Anforderung bedient, oder die Anforderung an eine andere Komponente übergeben, die bedient werden soll. Beispielsweise ruft die Speichersteuerung 203 beim Empfangen einer Leseanforderung, die Daten in dem lokalen Speicher 222 anfordert, die Daten aus dem Speicher ab und gibt die Daten zur Übertragung an die Anforderung in einem Leseantwortpaket an den Antwortenden 205 zurück.
Der Antwortende 205 umfasst mehrere Antwortübertragungswarteschlangen 229, 231, 233, 235. In diesem Beispiel unterstützt der Responder vier virtuelle Kanäle (VCs) und verwaltet für jeden virtuellen Kanal eine separate Übertragungswarteschlange 229, 231, 233, 235. In einigen Implementierungen kann der Antwortende 205 Antwortpakete der zweiten Transaktionsklasse auf einer anderen VC senden, als der Anforderer 204 zum Senden von Anforderungspaketen der zweiten Transaktionsklasse verwendet.
In einigen Implementierungen erzeugt der Speichercontroller 203 oder die CPU 202 zu sendende Antwortpakete und platziert sie direkt in den Warteschlangen 229, 231, 233, 235, einschließlich der Zuweisung der Pakete zu ihrer VC. In einem anderen Beispiel gibt die Speichersteuerung 203 oder eine andere Komponente die Daten in einem Roh- oder anderen Format zurück, und der Antwortende 205 oder eine dazwischenliegende Komponente packt die Daten in ein geeignetes Antwortpaket und platziert die Antwort in einer der Warteschlangen 229, 231, 233 235.
Der Antwortende 205 enthält einen ausstehenden Transaktionsprüfer 225. Der Prüfer 225 enthält eine Seitenbandschnittstelle 226 in den Warteschlangen 229, 231, 233, 235. In einigen Implementierungen überwacht der Prüfer 225 Antwortpakete, wenn sie in die Warteschlangen 229, 231, 233, 235 eintreten. In anderen Implementierungen sind eine oder mehrere der VCs (und daher Warteschlangen) Antworten der zweiten Transaktionsklasse zugeordnet. In diesen Implementierungen kann der Prüfer 225 nur die Antwortpakete überwachen, die in die dedizierten Warteschlangen gestellt werden.
Wenn in diesem Beispiel ein überwachtes Antwortpaket der zweiten Transaktionsklasse angehört, markiert der Prüfer 225 das Paket als nicht verfügbar zum Senden und fragt den Anforderer 204 über eine Schnittstelle 242 ab, um einen Hinweis auf das Ende-zu-Ende-Durchlaufen einer gebuchten Transaktion zu erhalten Anfrage. Beispielsweise kann die Schnittstelle 242 mit dem Verfolger 216 oder der Datenstruktur 217 gekoppelt sein. In einer Implementierung kann der Prüfer 225 eine Antwortziel-ID (dh die Quelle der Anforderung, die die Antwort erfordert) aus dem überwachten Paket abrufen und die Antwortziel-ID senden, um zu prüfen, ob eine ausstehende vorhergehende gesendete Transaktion mit demselben Zielknoten wie vorliegt die nicht gepostete Antwort. In einer anderen Implementierung prüft der Prüfer 225, ob eine vorhergehende gebuchte Transaktion aussteht. Sobald der Prüfer 225 eine Antwort empfängt, die angibt, dass keine ausstehende gebuchte Transaktion vorliegt, löscht der Prüfer 225 das Nichtverfügbarkeitsetikett aus dem in die Warteschlange gestellten Antwortpaket.
In einem anderen Beispiel kann die Komponente, die die Antwortpakete der zweiten Transaktionsklasse generiert, die Pakete mit dem nicht verfügbaren Tag erstellen. Als weiteres Beispiel werden nicht verfügbare Tags nicht verwendet. Stattdessen werden Antwortpakete der zweiten Transaktionsklasse erst dann als verfügbar markiert, wenn der Prüfer 225 vom Anforderer 204 feststellt, dass die vorhergehende gebuchte Schreibtransaktion der zweiten Transaktionsklasse abgeschlossen wurde. In diesem Beispiel wählen die Warteschlangenschiedsrichter 230, 232, 234, 236 nur aus Transaktionen der zweiten Klasse mit Verfügbarkeitstags aus.
Jede Warteschlange 229, 231, 233, 235 ist mit einem Warteschlangen-Arbiter 230, 232, 234 bzw. 236 gekoppelt. Der Warteschlangen-Arbiter 230, 232, 234, 236 wählt ein Paket aus seiner jeweiligen Warteschlange 229, 231, 233, 235 aus. Der Warteschlangen-Arbiter 230, 232, 234, 236 kann eine von verschiedenen Arten einer prioritätsbasierten Paketauswahl anwenden, um ein Paket aus der Warteschlange auszuwählen. Die verschiedenen Schiedsrichter 230, 232, 234, 236 können unterschiedliche Priorisierungstechniken anwenden oder können dieselbe Technik anwenden. In einigen Implementierungen sind einige oder alle der Schiedsrichter 230, 232, 234, 236 nicht vorhanden, und stattdessen sind die Warteschlangen 230, 232, 234, 236 FIFO-Puffer (First-In, First-Out).
Die Warteschlangen-Arbiter 230, 232, 234, 236, die Warteschlangen verwalten, die Antworten der zweiten Transaktionsklasse speichern, sind so konfiguriert, dass sie keine Pakete mit einem Nichtverfügbarkeits-Tag auswählen. Dementsprechend puffern die anwendbaren Warteschlangen 230, 232, 234, 236 die Transaktionsantwort, bis die Nichtverfügbarkeits-Tags gelöscht sind. Wie oben beschrieben, wird das Nichtverfügbarkeitstag eines Antwortpakets gelöscht, nachdem der Prüfer eine Anzeige erhalten hat, dass vorhergehende gebuchte Transaktionen der zweiten Transaktionsklasse (entweder eine vorhergehende gebuchte Transaktion oder eine vorhergehende gebuchte Transaktion an dasselbe Ziel, abhängig von der Implementierung) abgeschlossen sind. to-end-Durchquerung.
In einer Implementierung mit FIFO-Warteschlangen und ohne Warteschlangenschiedsrichter 229, 231, 233, 235 kann der Prüfer 225 die Pakete aus der Warteschlange entfernen oder verhindern, dass sie bis zum Empfang der Anzeige in die Warteschlange gestellt werden, anstatt die Antwortpakete der zweiten Transaktionsklasse zu markieren dass die vorhergehenden veröffentlichten Schreibanforderungen der zweiten Klasse die End-to-End-Durchquerung abgeschlossen haben.
Ein VC-Arbiter 237 wählt ein Paket aus, das aus den Kandidatenpaketen von den verschiedenen VCs (dh von den verschiedenen Warteschlangenschiedsrichtern 230, 232, 234, 236 oder vom Kopf der FIFO-Puffer, wenn keine Warteschlangenarbitrierung vorliegt) gesendet werden soll. Der VC-Arbiter 237 kann verschiedene unterschiedliche Arbitrierungsalgorithmen anwenden, um das Paket für die Übertragung auszuwählen. Beispielsweise kann der Arbiter 237 eine Round-Robin-Technik, eine altersbasierte Priorisierung oder eine gewichtete Version eines dieser Algorithmen anwenden, um das Paket für die Übertragung auszuwählen. Das ausgewählte Paket wird an den AntwortTransceiver 227 zur Injektion auf eine Verbindung 228 in die Struktur 224 zur Übertragung an das Ziel des Pakets gesendet.
Der Antwortende 205 ist ferner konfiguriert, um eine End-to-End-Durchquerungsbestätigung an einen externen Anforderer zu senden, nachdem er eine gebuchte Transaktionsanforderung der zweiten Transaktionsklasse von dem externen Anforderer empfangen hat. In einigen Implementierungen kann die Logik im Responder 205, wie beispielsweise der Prüfer 225, die Bestätigungen erzeugen und senden. Beispielsweise kann der Prüfer 225 an die Empfangswarteschlangen gekoppelt sein und diese überwachen und die Durchquerungsbestätigungen erzeugen. In diesem Beispiel kann der Prüfer 225 dann die Verfahrbestätigung in eine der Übertragungswarteschlangen 229, 231, 233, 235 einreihen. In anderen Implementierungen können die Durchquerungsbestätigungen erzeugt werden, nachdem eine Anforderung abgeschlossen wurde, wie oben in Bezug auf 1 diskutiert.
zeigt ein Beispielgerät mit einem gegabelten Anforderer und Responder. Beispielsweise kann die Vorrichtung 301 eine Implementierung einer Vorrichtung wie des Knotens 1 101 sein, wie in Bezug auf 1 beschrieben. Die dargestellten Systemkomponenten sind als Logikblöcke dargestellt, die in Hardware als digitale Schaltung, als Firmware oder Software, die in einem nicht vorübergehenden Medium wie einem Flash-Speicher oder einem ROM gespeichert ist, oder als eine Kombination davon implementiert werden können.
Die Vorrichtung 301 umfasst einen Systemberechnungsknoten mit einem Anforderer 304 und einem Antwortenden 305. Zu Erklärungszwecken umfasst die Vorrichtung 301 eine CPU 302, die eine Speichersteuerung 303 umfasst, die mit dem Anforderer 304 und dem Antwortenden 305 gekoppelt ist, sowie einen lokalen Speicher 322. Diese Elemente können wie in Bezug auf die CPU 202, die Speichersteuerung 203 und den lokalen Speicher 222 beschrieben sein. Wie oben diskutiert, kann in anderen Implementierungen die Vorrichtung 301 ein Speichermodul sein, wie beispielsweise ein dynamischer Direktzugriffsspeicher (DRAM), ein nichtflüchtiger Speicher (NVM) oder ein Speicherklassenspeichermodul (SCM), eine Grafikkarte oder ein anderer Beschleuniger, einen Netzwerkcontroller, einen Switch, einen DSP, einen ASIC, ein FPGA oder ein anderes Gerät, das unter Verwendung eines semantischen Speichersprotokolls kommuniziert.
Die Vorrichtung 301 umfasst ferner einen Anforderer 304, um eine erste Transaktionsklasse und eine zweite Transaktionsklasse zu unterstützen. Der Anforderer umfasst mehrere Anforderungsübertragungswarteschlangen 306, 308, 310, 312. In diesem Beispiel unterstützt der Anforderer vier virtuelle Kanäle (VCs) und verwaltet für jeden virtuellen Kanal eine separate Übertragungswarteschlange 306, 308, 310, 312. In diesem Beispiel sind die Warteschlangen 306, 308, 310, 312 FIFO-Puffer. Jeder Puffer ist mit einem VC-Arbiter 314 gekoppelt, der ein Paket auswählt, das von den Köpfen der Puffer gesendet werden soll. Der VC-Arbiter 314 kann verschiedene unterschiedliche Arbitrierungsalgorithmen anwenden, wie in Bezug auf den VC-Arbiter 214 beschrieben. In anderen Implementierungen können die Warteschlangen mit Warteschlangenschiedsrichtern gekoppelt sein, die Kandidatenpakete aus den Warteschlangen 306, 308, 310, 312 auswählen
Der Anforderer 304 umfasst ferner mehrere Empfangswarteschlangen 318, 319, 320, 321. Jede Empfangswarteschlange 318, 319, 320, 321 entspricht einer der vom Anforderer 304 unterstützten VCs. Beispielsweise können die Empfangswarteschlangen 318, 319, 320, 321 FIFO-Puffer sein, die Antworten auf Anforderungen speichern, die zuvor vom Anforderer gesendet wurden.
Der Anforderer 304 umfasst ferner einen Verfolger 316, der das Ende-zu-Ende-Durchlaufen von gebuchten Transaktionsanforderungen der zweiten Transaktionsklasse verfolgt. In diesem Beispiel ist der Tracker 316 mit dem Transceiver 315 gekoppelt und zwischen dem VC-Arbiter 314 und dem Transceiver 315 angeordnet. Dies ermöglicht es dem Verfolger 316, Pakete zu untersuchen, bevor sie übertragen werden, und gebuchte Transaktionsanforderungen der zweiten Transaktionsklasse zu verfolgen. In anderen Implementierungen kann der Verfolger 316 außerhalb der Sende- und Empfangspfade des Hauptpakets angeordnet sein. Beispielsweise kann der Verfolger 316 den Bus zwischen dem VC-Arbiter 314 und dem Transceiver 315 abhören, um zu bestimmen, wann eine gesendete Transaktionsanforderung gesendet wird.
Der Verfolger 316 ist ferner mit einer Datenstruktur 317 gekoppelt, die er verwaltet, um während des Flugs gebuchte Transaktionsanforderungen der zweiten Transaktionsklasse zu verfolgen. Der Verfolger 316 kann die Datenstruktur auf verschiedene Arten aufrechterhalten. Beispielsweise kann die Datenstruktur 317 eine Tabelle sein, in der jeder Eintrag einer im Flug veröffentlichten Transaktionsanforderung entspricht. Beispielsweise kann jeder Eintrag ein Ziel und eine ID einer im Flug gebuchten Transaktion enthalten. Wenn der Transceiver 315 eine Bestätigung der Durchquerung einer gebuchten Transaktion empfängt, kann der Verfolger 316 den Eintrag löschen, der der gebuchten Transaktion entspricht. Als weiteres Beispiel kann jeder Eintrag eine Ziel-ID und einen Zähler enthalten, den der Tracker jedes Mal erhöht, wenn eine gebuchte Transaktion an die entsprechende ID gesendet wird, und jedes Mal verringert wird, wenn eine gebuchte Transaktionsbestätigung empfangen wird. In diesem Beispiel kann der Tracker den Tabelleneintrag löschen, wenn der Zähler 0 erreicht.
Die Vorrichtung 301 umfasst ferner einen Antwortenden 305, um eine erste Transaktionsklasse und eine zweite Transaktionsklasse zu unterstützen. Der Antwortende 305 umfasst mehrere Empfangswarteschlangen 338, 339, 340, 341. Beispielsweise können die Empfangswarteschlangen 338, 339, 340, 341 FIFO-Puffer sein, die empfangene Anforderungen speichern. In diesem Beispiel unterstützt der Responder vier virtuelle Kanäle (VCs) und verwaltet für jede VC eine separate Empfangswarteschlange 338, 339, 340, 341. In einigen Beispielen sind einige oder alle vom Responder 305 unterstützten VCs VCs, die mit denen identisch sind, die vom Anforderer 304 unterstützt werden. Zum Beispiel können die VCs durch ID-Nummern unterschieden werden und die vom Responder unterstützten VCs können die gleichen oder einen überlappenden Satz von ID-Nummern haben.
Wie oben beschrieben, empfängt der Antwortende Anforderungen von anderen Anforderern über die Struktur 324. Diese Anforderungen werden in den Warteschlangen 338, 339, 340, 341 in die Warteschlange gestellt. Die Anforderungen werden dann an die Speichersteuerung 303 weitergeleitet, die die Anforderung bedient, oder die Anforderung an eine andere Komponente weitergeleitet, die bedient werden soll. Beispielsweise ruft die Speichersteuerung 303 beim Empfangen einer Leseanforderung, die Daten in dem lokalen Speicher 322 anfordert, die Daten aus dem Speicher ab und gibt die Daten an den Antwortenden 305 zur Übertragung an die Anforderung in einem Leseantwortpaket zurück.
Der Antwortende 305 umfasst mehrere Antwortübertragungswarteschlangen 329, 331, 333, 335. In diesem Beispiel unterstützt der Responder vier virtuelle Kanäle (VCs) und verwaltet für jeden virtuellen Kanal eine separate Übertragungswarteschlange 329, 331, 333, 335. In einigen Implementierungen kann der Antwortende 305 Antwortpakete der zweiten Transaktionsklasse auf einer anderen VC senden, als der Anforderer 304 zum Senden von Anforderungspaketen der zweiten Transaktionsklasse verwendet.
In einigen Implementierungen erzeugt der Speichercontroller 303 oder die CPU 302 zu übertragende Antwortpakete und platziert sie direkt in den Warteschlangen 329, 331, 333, 335, einschließlich der Zuweisung der Pakete zu ihrer VC. In einem anderen Beispiel gibt die Speichersteuerung 303 oder eine andere Komponente die Daten in einem Roh- oder anderen Format zurück, und der Antwortende 305 oder eine dazwischenliegende Komponente packt die Daten in ein geeignetes Antwortpaket und platziert die Antwort in einer der Warteschlangen 329, 331, 333 335.
In diesem Beispiel ist jede Sendewarteschlange 329, 331, 333, 335 ein FIFO-Puffer, der mit einem VC-Arbiter 337 gekoppelt ist. In anderen Beispielen können die Warteschlangen mit Warteschlangenschiedsrichtern gekoppelt sein, wie in Bezug auf 2 beschrieben. Der VC-Arbiter 337 wählt ein Paket zum Senden aus den Kandidatenpaketen von den Köpfen der FIFO-Puffer 329, 331, 333, 335 aus. Der VC-Arbiter 337 kann verschiedene Arbitrierungstechniken anwenden, wie sie in Bezug auf den VC-Arbiter 227 beschrieben sind. Das ausgewählte Paket wird an den Responder-Transceiver 327 zur Injektion auf eine Verbindung 328 in die Fabric 324 zur Übertragung an das Ziel des Pakets gesendet.
Der Responder 305 umfasst ferner einen Enqueuer 325. Der Enqueuer 325 ist mit einer Schnittstelle 342 mit dem Anforderer 304 verbunden, um eine Anzeige des Ende-zu-Ende-Durchlaufs einer gebuchten Transaktionsanforderung vom Verfolger zu empfangen. Beispielsweise kann die Schnittstelle 342 mit dem Verfolger 316 oder der Datenstruktur 317 gekoppelt sein. Wenn der Arbiter 337 eine Antwort der zweiten Transaktionsklasse, wie beispielsweise eine nicht gebuchte Leseantwort, zur Übertragung auf der Verbindung 328 auswählt, prüft der Enqueuer 325, ob eine ausstehende gebuchte Transaktion vorliegt, die vom Anforderer 304 gesendet wird. Beispielsweise kann der Enqueuer 325 prüfen, ob eine ausstehende gebuchte Transaktion mit demselben Ziel wie die nicht gebuchte Antwort vorliegt. Alternativ kann der Enqueuer 325 prüfen, ob an einem Ziel eine ausstehende gebuchte Transaktion vorliegt.
Der Anforderer 305 umfasst ferner einen Transceiver 327, um die ausgewählte Transaktionsantwort basierend auf der Anzeige zu übertragen. Beispielsweise kann der Antwortende 305 die ausgewählte Transaktionsantwort in einem Puffer 326 puffern, während eine ausstehende gebuchte Transaktion vorliegt, die die Übertragung der ausgewählten Antwort verhindert. Der Puffer 326 kann so bemessen sein, dass er mehrere ausstehende Antworten puffert. Beispielsweise kann der Puffer 326 gemäß der typischen Roundtrip-Latenz von auf der Fabric veröffentlichten Transaktionen und der Paketübertragungsrate des Antwortenden dimensioniert werden.
Der Antwortende 305 ist ferner konfiguriert, um eine Ende-zu-Ende-Durchquerungsbestätigung an einen externen Anforderer zu senden, nachdem er eine gebuchte Transaktionsanforderung der zweiten Transaktionsklasse von dem externen Anforderer empfangen hat. In einigen Implementierungen kann die Logik in dem Antwortenden 305, wie dem Transceiver 327 oder dem Enqueuer 225, die Bestätigungen erzeugen und senden. In anderen Implementierungen können die anderen Systemkomponenten die Durchlaufantwort erzeugen, nachdem die entsprechende Anforderung abgeschlossen wurde.
4 zeigt ein beispielhaftes Netzwerk-Bounce-Diagramm einer beispielhaften Reihe von Kommunikationen zwischen einem Anforderer 402 und einem Antwortenden 401 an einem ersten Zielgerät A und einem zweiten Anforderer 405 und einem Antwortenden 406 an einem zweiten Zielgerät B. Die Kommunikationsgeräte sind über ein Switch-Netzwerk miteinander verbunden, das durch Switch 1 403 und Switch 2 404 dargestellt wird.
In diesem Beispiel sendet der Anforderer A 402 eine Schreibanforderung der ersten Klasse (WR ¹ 407) und eine gesendete Schreibanforderung der zweiten Klasse (PWR ² 408) an den Antwortenden B 406. Der Antwortende B 406 führt die angeforderten Schreibvorgänge aus und sendet eine Bestätigung PWR-ACK ² 411 an PWR ² 408. In verschiedenen Implementierungen kann der Antwortende B 406 auch eine Bestätigung von WR ¹ senden. Aus Gründen der Klarheit wird diese Bestätigung jedoch in 3 weggelassen. Die Transaktionsanforderungen der ersten Klasse sind nicht erforderlich, um eine Bestellbeziehung zu Transaktionen der zweiten Klasse aufrechtzuerhalten. In diesem Beispiel leitet Switch 1 403 PWR ² 408 vor WR ¹ 407 weiter und kehrt die Reihenfolge der Transaktionen im Vergleich zu ihrer ursprünglichen Übertragungsreihenfolge um.
Hier gibt der Anforderer B 405 eine Leseanforderung der zweiten Klasse (RD ² 410) und eine Leseanforderung der ersten Klasse (RD ¹ 409) an den Antwortenden A 401 aus. Der Antwortende A 401 empfängt die Leseanforderungen und bereitet das Senden der Leseantworten RD-RSP ¹ 412 und RD-RSP ² 413 vor, die die angeforderten Daten enthalten.
Vor dem Senden von RD-RSP ² 413 fragt Responder A 401 den Anforderer A 402 ab, um festzustellen, ob eine ausstehende gebuchte Transaktion an Ziel B vorliegt. Wenn der Anforderer A 402 die Abfrage 414 empfängt, hat er PWR-ACK ² 411 noch nicht empfangen. Dementsprechend antwortet der Anforderer A 402 in Antwort auf die Abfrage 414 415, dass eine ausstehende gebuchte Transaktion an Ziel B vorliegt. Als Antwort puffert der Antwortende A 401 RD-RSP ² 413 und sendet sie nicht. Im Fall von RD ¹ 409 gehört die Transaktion zur ersten Klasse, sodass der Responder A 401 RD-RSP ¹ 412 an den Anforderer B 405 sendet, ohne zu prüfen, ob eine ausstehende Schreibanforderung an Ziel B vorliegt.
In dieser Implementierung wiederholt der Antwortende A 401 die Abfrage 416 an den Anforderer A 402, um festzustellen, ob eine ausstehende gebuchte Transaktion an Ziel B vorliegt. Der Anforderer A 402 hat vor der Abfrage 416 PWR-ACK ² 411 empfangen. Dementsprechend antwortet der Anforderer A 402 417, dass keine ausstehende gebuchte Transaktion an Ziel B vorliegt. Der Antwortende A 401 sendet dann RD-RSP ² an den Anforderer B 405. In einer alternativen Implementierung verzögert der Anforderer A 402 das Senden der Antwort an die Abfrage 414, bis die gesendete Schreibbestätigung PWR-ACK ² empfangen wurde. In dieser Implementierung zeigt das Fehlen einer Antwort an, dass eine ausstehende geschriebene Schreibanforderung der zweiten Transaktionsklasse vorliegt, und der Antwortende A 401 puffert RD-RSP ² bis nach dem Empfang der Antwort.
5 zeigt ein Betriebsverfahren eines Geräts mit einem Anforderer und einem Antwortenden. Beispielsweise kann der Knoten 101 von 1, die Vorrichtung 201 von 2, die Vorrichtung 301 von 3 oder das Ziel A von 3 wie in Bezug auf 5 beschrieben arbeiten.
Das Verfahren umfasst Block 501. Block 501 enthält einen Anforderer, der eine gesendete Anforderung an ein Ziel aus einer Anforderungswarteschlange auswählt. Wie oben erläutert, kann der Anforderer eine Anforderung von der Anforderungswarteschlange unabhängig von der vom Antwortenden durchgeführten Warteschlange und Arbitrierung anfordern. Die Anforderungswarteschlange kann auch nicht gepostete Anforderungen enthalten. Die gebuchte Anfrage stammt aus einer bestellten Transaktionsklasse, und nicht gebuchte Anfragen können aus einer ungeordneten Transaktionsklasse oder der bestellten Transaktionsklasse stammen. Wie oben erläutert, kann der Anforderer beispielsweise mehrere Transaktionsklassen unterstützen, einschließlich einer geordneten Transaktionsklasse und einer ungeordneten Transaktionsklasse. In der bestellten Transaktionsklasse können gebuchte Transaktionsanforderungen (z. B. gebuchte Schreibanforderungen) nicht gebuchte Anfragen und nicht gebuchte Antworten (einschließlich Abschluss- oder Bestätigungspakete) an dasselbe Ziel weiterleiten, und keine Anfrage oder Antwort kann eine gebuchte Anfrage an die weiterleiten gleiches Ziel. Beispielsweise kann das Bestellmodell ein PCIe-kompatibles Bestellmodell sein. In der ungeordneten Transaktionsklasse können sich alle Anforderungen und Antworten von einem Ziel zum anderen gegenseitig auf der Fabric übergeben.
Das Verfahren umfasst ferner Block 502. Block 502 enthält den Anforderer, der die gesendete Anforderung an das Ziel sendet. Beispielsweise kann Block 502 den Anforderer umfassen, der die gesendete Anforderung auf einem ersten virtuellen Kanal sendet. Wie oben diskutiert, kann Block 502 ferner das Senden der Anforderung unabhängig von Antworten umfassen, die vom Antwortenden übertragen werden.
Das Verfahren umfasst ferner Block 503. Block 503 enthält den Anforderer, der einen Flugstatus der gesendeten Anforderung verfolgt. Beispielsweise kann Block 503 ferner den Anforderer umfassen, der eine Bestätigung vom Ziel empfängt. Hier kann Block 503 das Verfolgen der gesendeten Anfrage als während des Flugs, wenn sie an das Ziel gesendet wird, und als Antwort auf die Bestätigung das Aktualisieren des Status der gesendeten Anfrage während des Flugs umfassen. Beispielsweise kann der Anforderer den Status der gesendeten Anforderung während des Flugs aktualisieren, indem er die Anforderung in einer Datenstruktur als vollständig markiert oder die Verfolgungsdaten für die Anforderung aus der Datenstruktur entfernt.
Das Verfahren umfasst ferner Block 504. Block 504 umfasst einen Antwortenden, der eine erste Antwort auf das Ziel aus einer Antwortwarteschlange auswählt. Wie oben erläutert, kann der Antwortende die erste Antwort aus der Antwortwarteschlange auswählen, unabhängig davon, ob der Anforderer die gesendete Anforderung aus der Anforderungswarteschlange auswählt. In einigen Implementierungen kann die Antwortwarteschlange eine Mischung von Antworten aus der ungeordneten Transaktionsklasse und der geordneten Transaktionsklasse enthalten.
Das Verfahren umfasst ferner Block 505. Block 505 umfasst den Antwortenden, der ein Signal vom Anforderer empfängt, das angibt, dass die gesendete Anforderung im Flug ist. Beispielsweise kann Block 505 den Antwortenden enthalten, der den Anforderer abfragt, um zu bestimmen, ob als Antwort auf die Auswahl der ersten Antwort eine während des Fluges gesendete Anforderung an das Ziel vorliegt. Das empfangene Signal kann eine Antwort auf den Antwortenden sein, der den Anforderer abfragt.
Das Verfahren umfasst ferner Block 506. Block 506 umfasst den Antwortenden, der die erste Antwort puffert, bis der Antwortende ein Signal vom Anforderer empfängt, das angibt, dass die gesendete Anforderung nicht im Flug ist. Beispielsweise kann der Antwortende die Blöcke 505 und 506 wiederholen, um den Anforderer wiederholt abzufragen, bis der Antwortende das Signal empfängt, dass die gesendete Anforderung nicht im Flug ist. Als weiteres Beispiel kann der Anforderer das Senden des Signals als Antwort auf die Abfrage verzögern, bis die gesendete Anforderung nicht mehr im Flug ist.
Das Verfahren umfasst ferner Block 507. Block 507 umfasst den Antwortenden, der die erste Antwort an den Anforderer am Ziel sendet. Beispielsweise kann Block 507 das Senden der Antwort auf einem anderen virtuellen Kanal als dem umfassen, der vom Anforderer zum Senden der gesendeten Anforderung verwendet wird. Als ein anderes Beispiel kann Block 507 das Senden der Antwort auf demselben virtuellen Kanal wie die gesendete Anforderung umfassen.
In der vorstehenden Beschreibung werden zahlreiche Einzelheiten dargelegt, um ein Verständnis für die hier offenbarten Beispiele bereitzustellen. Implementierungen können jedoch ohne einige oder alle dieser Details durchgeführt werden. Andere Implementierungen können Modifikationen und Abweichungen von den oben diskutierten Details enthalten. Es ist beabsichtigt, dass die beigefügten Ansprüche solche Änderungen und Variationen abdecken, die in den Rahmen der Beispiele fallen.

Claims

System, das Folgendes umfasst: einen Anforderer zur Unterstützung einer ersten Transaktionsklasse und einer zweiten Transaktionsklasse; und einen Antwortenden zur Unterstützung der ersten Klasse von Transaktionen und der zweiten Klasse von Transaktionen; worin Der Antwortende sendet Transaktionen der ersten Klasse unabhängig von Transaktionen der ersten Klasse, die vom Anforderer gesendet werden, und Der Antwortende muss vom Anforderer eine Anzeige erhalten, die angibt, ob der Anforderer eine ausstehende vorhergesagte Transaktionsanforderung der zweiten Transaktionsklasse hat, bevor er eine nicht gebuchte Transaktionsantwort der zweiten Transaktionsklasse sendet.
System nach Anspruch 1, wobei Der Anforderer muss die Anzeige bereitstellen, nachdem er eine Bestätigung erhalten hat, dass die ausstehende gesendete Transaktionsanforderung ein Ziel erreicht hat.
System nach Anspruch 1, wobei Der Antwortende muss den Anforderer abfragen, bevor er eine nicht gebuchte Transaktionsantwort der zweiten Transaktionsklasse sendet Die Anzeige ist als Antwort auf die Abfrage.
System nach Anspruch 1, wobei Der Antwortende verzögert das Senden der nicht gebuchten Transaktionsantwort, bis der Anforderer keine ausstehende vorhergesagte Transaktionsanforderung der zweiten Transaktionsklasse für dasselbe Ziel wie die nicht gebuchte Transaktionsantwort hat.
System nach Anspruch 1, wobei Der Antwortende verzögert das Senden der nicht gebuchten Transaktionsantwort, bis der Antwortende keine ausstehenden vorhergesagten Transaktionsanforderungen der zweiten Klasse mehr hat.
System nach Anspruch 1, wobei Der Antwortende sendet Bestätigungen an empfangene gebuchte Transaktionsanforderungen der zweiten Klasse, wobei die Bestätigungen gesendet werden, bevor die angeforderten gesendeten Transaktionen abgeschlossen sind.
System nach Anspruch 1, wobei Der Antwortende sendet die nicht gebuchte Transaktionsantwort auf einem von der gebuchten Transaktionsanforderung getrennten virtuellen Kanal.
System nach Anspruch 1, wobei Der Antwortende wählt Antworten zum Senden aus, unabhängig von den vom Anforderer zum Senden ausgewählten Anforderungen, und puffert ausgewählte nicht gesendete Antworten der zweiten Transaktionsklasse, bis die Anzeige empfangen wird.
Einrichtung, Folgendes umfassend: einen Anforderer zur Unterstützung einer ersten Transaktionsklasse und einer zweiten Transaktionsklasse, umfassend: eine Anforderungswarteschlange; einen Anforderungsschiedsrichter zum Auswählen von Transaktionsanforderungen aus der Anforderungswarteschlange zur Übertragung; einen Anforderungstransceiver zum Senden der Transaktionsanforderung; und einen Verfolger, um das Ende-zu-Ende-Durchlaufen von gebuchten Transaktionsanforderungen der zweiten Transaktionsklasse zu verfolgen; und verfahren, Folgendes umfassend: eine Antwortwarteschlange; einen Antwort-Arbiter zum Auswählen einer Transaktionsantwort aus der Antwortwarteschlange; eine Schnittstelle zum Anforderer, um eine Anzeige des End-to-End-Durchlaufs einer gebuchten Transaktionsanforderung vom Verfolger zu erhalten; einen Antworttransceiver zum Übertragen der Transaktionsantwort basierend auf der Anzeige, wann die Transaktionsantwort der zweiten Transaktionsklasse angehört.
Vorrichtung nach Anspruch 9, wobei der Antwortende ferner umfasst: Ein Puffer zum Speichern der Transaktionsantwort, wenn die Transaktionsantwort der zweiten Transaktionsklasse angehört und die Anzeige angibt, dass eine zuvor gebuchte Transaktionsanforderung der zweiten Transaktionsklasse die End-to-End-Durchquerung nicht abgeschlossen hat.
Vorrichtung nach Anspruch 9, wobei der Antwortende ferner umfasst: Ein Puffer zum Speichern der Transaktionsantwort, wenn die Transaktionsantwort der zweiten Transaktionsklasse angehört, und die Anzeige zeigt an, dass eine zuvor gesendete Transaktionsanforderung der zweiten Transaktionsklasse, die an denselben Zielknoten wie die ausgewählte Transaktionsantwort adressiert ist, das Ende bis Ende nicht abgeschlossen hat. Ende der Durchquerung.
Vorrichtung nach Anspruch 9, wobei der Transceiver Bestätigungen von End-to-End-Durchläufen von gebuchten Transaktionsanforderungen der zweiten Transaktionsklasse empfangen soll.
Vorrichtung nach Anspruch 9, wobei der Responder ist ein End-to-End - Traversal - Bestätigung an einen externen Anforderer zu übertragen , nachdem eine Gesendete Transaktionsanforderung der zweiten Transaktionsklasse von dem externen Anforderer empfing.
Vorrichtung nach Anspruch 9, wobei die Antworteinrichtung ist, die Transaktionsantwort auf einen anderen virtuellen Kanal als der Anfrage zu übertragen Sender die Transaktionsanforderung zu übertragen ist.
Vorrichtung nach Anspruch 9, wobei die Schnittstelle verwendet, um den Tracker zum Abfragen der Anzeige , bevor die Antwort - Arbiter wählt eine Transaktionsantwort des zweiten Transaktionsklasse zu erhalten.
Vorrichtung nach Anspruch 9, wobei die Schnittstelle verwendet, um den Tracker abzufragen , um die Anzeige nach der Reaktion Arbiter wählt eine Transaktionsantwort des zweiten Transaktionsklasse zu erhalten.
Verfahren, Folgendes umfassend: einen Anforderer, der eine gebuchte Anfrage an ein Ziel aus einer Anforderungswarteschlange auswählt, wobei die gebuchte Anfrage aus einer bestellten Transaktionsklasse stammt und die Anforderungswarteschlange eine Anfrage aus einer ungeordneten Transaktionsklasse enthält; der Anforderer, der die gesendete Anfrage an das Ziel sendet; der Anforderer verfolgt den Status der gesendeten Anfrage während des Fluges; einen Antwortenden, der eine erste Antwort auf das Ziel aus einer Antwortwarteschlange auswählt, wobei die erste Antwort von der geordneten Transaktionsklasse und die Antwortwarteschlange eine zweite Antwort von der ungeordneten Transaktionsklasse enthält; der Antwortende erhält ein Signal vom Anforderer, das angibt, dass die gesendete Anforderung im Flug ist; und Der Antwortende puffert die erste Antwort, bis der Antwortende ein Signal vom Anforderer empfängt, das angibt, dass die gesendete Anforderung nicht im Flug ist.
Verfahren nach Anspruch 17, ferner Folgendes umfassend: Der Antwortende wählt die erste Antwort aus der Antwortwarteschlange aus, unabhängig davon, ob der Anforderer die gesendete Anforderung aus der Anforderungswarteschlange auswählt.
Verfahren nach Anspruch 17, ferner Folgendes umfassend: Der Anforderer erhält eine Bestätigung vom Ziel und aktualisiert als Antwort den Status der gesendeten Anforderung während des Flugs.
Verfahren nach Anspruch 17, ferner Folgendes umfassend: als Antwort auf die Auswahl der ersten Antwort fragt der Antwortende den Anforderer ab, um festzustellen, ob eine während des Fluges gesendete Anforderung der bestellten Transaktionsklasse an das Ziel vorliegt; worin: Der Antwortende empfängt das Signal als Antwort auf den Antwortenden, der den Anforderer abfragt.