DE60030767T2

DE60030767T2 - Datenzuweisung zu threads in einem multi-threaded netzwerkprozessor

Info

Publication number: DE60030767T2
Application number: DE60030767T
Authority: DE
Inventors: Gilbert Framingham WOLRICH; Donald Shrewsbury HOOPER; Debra Sudbury BERNSTEIN; J. Matthew Worcester ADILETTA; William Southboro WHEELER
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1999-12-28
Filing date: 2000-12-08
Publication date: 2007-11-08
Anticipated expiration: 2020-12-09
Also published as: US20040098496A1; EP1242883B1; CN1643499A; US6625654B1; SG145543A1; WO2001048606A2; HK1046050A1; ATE339724T1; TW544629B; US7111296B2; EP1242883A2; DE60030767D1; US20020013861A1; AU4311601A; WO2001048606A3; CN100351798C

Description

HINTERGRUND
Die vorliegende Erfindung betrifft die Netzwerkpaketverarbeitung.
Parallelverarbeitung ist eine effiziente Form der Infarmationsverarbeitung von parallelen Events in einem Rechenprozess. Parallelverarbeitung verlangt die parallele Ausführung vieler Programme in einem Computer im Gegensatz zur sequentiellen Verarbeitung. Im Zusammenhang mit einem Parallelprozessor beinhaltet Parallelismus die Verrichtung von mehr als einer Sache gleichzeitig. Im Gegensatz zu einem seriellen Paradigma, bei dem alle Tasks nacheinander an einer einzelnen Station ausgeführt werden, oder einer Pipeline-strukturierten Maschine, in der Tasks in Spezialstationen ausgeführt werden, sind bei Parallelverarbeitung mehrere Stationen vorhanden, die jeweils alle Tasks ausführen können. Das heißt, im Allgemeinen arbeiten alle oder mehrere der Stationen gleichzeitig und unabhängig an denselben oder gemeinsamen Elementen eines Problems. Bestimmte Probleme sind für eine Lösung durch Anwenden von Parallelverarbeitung geeignet.
Douglas C. Schmidt und Tatsuya Suda: „The Performance of Alternative Threading Architectures for Parallel Communication Subsystems",
URL:http://www.us.wustl.edu/schmidt/PDF/JPDC-96.pdf,
offenbart von einer Netzwerkschnittstelle empfangene Netzwerkpakete. Eine Netzwerkschnittstelle oder ein Paketfilter führt Demultiplexieroperationen aus, um den Thread für die Assoziation mit jeder Meldung zu ermitteln. Meldungsparallelismus assoziiert einen separaten Thread mit jeder eingehenden Meldung.
ZUSAMMENFASSUNG
Die Erfindung ist in ihren verschiedenen Aspekten in den Hauptansprüchen unten definiert, auf die nunmehr Bezug genommen werden sollte. Vorteilhafte Merkmale sind in den Nebenansprüchen dargelegt.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockdiagramm eines Kommunikationssystems, das mit einem Hardware-gestützten Multithread-Prozessor arbeitet.
2 ist ein ausführliches Blockdiagramm des Hardware-gestützten Multithread-Prozessors von 1.
3 ist ein Blockdiagramm einer Mikromaschinen-Funktionseinheit, die in dem Hardware-gestützten Multithread-Prozessor der 1 und 2 eingesetzt wird.
4 ist ein Blockdiagramm einer in dem Hardwaregestützten Multithread-Prozessor verwendeten Speichersteuerung für eine Breitbandoperation.
5 ist ein Blockdiagramm einer in dem Hardwaregestützten Multithread-Prozessor verwendeten Speichersteuerung für latenzbegrenzte Operationen.
6 ist ein Blockdiagramm einer Kommunikationsbusschnittstelle im Prozessor von 1, das die bei der Programmthread-Signalgabe verwendete Software darstellt.
7A–7B sind bildliche Darstellungen und ein Fließschema, das für das Verständnis der Programmthread-Signalisierung mit einem COR-(Clear-On-Read)-Register nützlich ist.
8 ist ein Fließschema eines Inter-Thread-Signalisierungsprogramms.
9 ist ein Fließschema eines Programmthread-Statusberichtsverfahrens.
BESCHREIBUNG
Architektur:
Gemäß 1 beinhaltet ein Kommunikationssystem 10 einen parallelen, Hardware-gestützten Multithread-Prozessor 12. Der Hardware-gestützte Multithread-Prozessor 12 ist mit einem Bus wie z.B. einem PCI-(Peripheral Component Interconnect)-Bus 14, einem Speichersystem 16 und einem zweiten Bus 18 gekoppelt. Das System 10 ist besonders für Tasks nützlich, die in parallele Subtasks oder Funktionen gegliedert werden können. Der Hardware-gestützte Multithread-Prozessor 12 ist besonders für Tasks nützlich, die bandbreiten- anstatt latenzorientiert sind. Der Hardware-gestützte Multithread-Prozessor 12 hat mehrere Mikromaschinen 22 jeweils mit mehreren Hardware-gesteuerten Programmthreads, die gleichzeitig aktiv sein und unabhängig an einer Task arbeiten können.
Der Hardware-gestützte Multithread-Prozessor 12 beinhaltet auch eine Zentralsteuerung 20, die beim Laden von Microcode-Control für andere Ressourcen des Hardwaregestützten Multithread-Prozessors 12 assistieren, und führt andere allgemeine Computerfunktionen wie Handhabung von Protokollen, Ausnahmen, zusätzliche Unterstützung für Paketverarbeitung aus, wo die Mikromaschinen die Pakete für eine weiterführende Verarbeitung wie z.B. unter Grenzbedingungen weiterleiten. In einer Ausgestaltung ist der Prozessor 20 eine auf Strong Arm^® (Arm ist ein Warenzeichen von ARM Limited, Großbritannien) basierende Architektur. Der Universalmikroprozessor 20 hat ein Betriebssystem. Durch das Betriebssystem kann der Prozessor 20 Funktionen abrufen, um an Mikromaschinen 22a–22f zu arbeiten. Der Prozessor 20 kann jedes unterstützte Betriebssystem verwenden, vorzugsweise ein Echtzeit-Betriebssystem. Für den als Strong Arm Architektur implementierten Kernprozessor können Betriebssysteme wie z.B. Microsoft NT Real-Time, VXWorks und μCUS verwendet werden, ein Freeware-Betriebssystem, das über das Internet erhältlich ist.
Der Hardware-gestützte Multithread-Prozessor 12 beinhaltet auch mehrere Mikromaschinen 22a–22f. Die Mikromaschinen 22a–22f führen jeweils mehrere Programmzähler in Hardware und Zustände in Verbindung mit den Programmzählern. Es kann effektiv eine entsprechende Mehrzahl von Programmthread-Sätzen gleichzeitig auf jeder der Mikromaschinen 22a–22f aktiv sein, während zu jedem Zeitpunkt immer nur eine tatsächlich arbeitet.
In einer Ausgestaltung gibt es sechs Mikromaschinen 22a–22f, jeweils mit Kapazitäten zum Verarbeiten von vier Hardware-Programmthreads. Die sechs Mikromaschinen 22a–22f arbeiten mit Gemeinschaftsressourcen einschließlich dem Speichersystem 16 und den Busschnittstellen 24 und 28. Das Speichersystem 16 beinhaltet eine SDRAM-(Synchronous Dynamic Random Access Memory)-Steuerung 26a und eine SRAM-(Static Random Access Memory)-Steuerung 26b. Der SDRAM-Speicher 16a und die SDRAM-Steuerung 26a werden gewöhnlich zum Verarbeiten großer Datenvolumen verwendet, z.B. zum Verarbeiten von Netzwerknutzlasten von Netzwerkpaketen. Die SRAM-Steuerung 26b und der SRAM-Speicher 16b werden in einer Vernetzungsimplementation für latenzarme Schnellzugriff-Tasks eingesetzt, z.B. Zugreifen auf Lookup-Tabellen, Speicher für den Kernprozessor 20 usw.
Hardware-Kontextumlagerung ermöglicht es, dass andere Kontexte mit eindeutigen Programmzählern in derselben Mikromaschine laufen. Hardware-Kontextumlagerung synchronisiert auch den Vollzug von Tasks. So könnten z.B. zwei Programmthreads dieselbe Gemeinschaftsressource, z.B. SRAM, anfordern. Jede dieser separaten Funktionseinheiten, z.B. die FBUS-Schnittstelle 28, die SRAM-Steuerung 26a und die SDRAM-Steuerung 26b, melden, wenn sie eine angeforderte Task von einem der Mikromaschinen-Programmthread-Kontexten erledigt haben, einen Flag zum Signalisieren des Vollzugs einer Operation zurück. Wenn der Flag von der Mikromaschine empfangen wird, dann kann die Mikromaschine ermitteln, welcher Programmthread einzuschalten ist.
Als Netzwerkprozessor, z.B. ein Router, ist der Hardware-gestützte Multithread-Prozessor 12 mit Netzwerkgeräten wie z.B. einem Media-Access-Controller-Gerät verbunden, z.B. einem 10/100BaseT Octal MAC 13a oder einem Gigabit Ethernet-Gerät 13b. Im Allgemeinen kann der Hardware-gestützte Multithread-Prozessor 12 als Netzwerkprozessor mit jedem Kommunikationsgeräte- oder Schnittstellentyp verbunden werden, der/die große Datenmengen empfängt/sendet. Der Netzwerkprozessor kann als Router 10 in einer Vernetzungsanwendung dienen und Netzwerkpakete auf parallele Weise zwischen Geräten 13a, 13b leiten. Mit dem Hardware-gestützten Multithread-Prozessor 12 kann jedes Netzwerkpaket unabhängig verarbeitet werden.
Der Prozessor 12 beinhaltet eine Busschnittstelle 28, die den Prozessor mit dem zweiten Bus 18 verbindet. Die Busschnittstelle 28 koppelt in einer Ausgestaltung den Prozessor 12 mit dem so genannten FBUS 18 (FIFO-Bus). Die FBUS-Schnittstelle 28 ist verantwortlich für das Steuern und Verbinden des Prozessors 12 mit dem FBUS 18. Der FBUS 18 ist ein 64 Bit breiter FIFO-Bus, der als Schnittstelle zu MAC-(Media Access Controller)-Geräten verwendet wird. Der Prozessor 12 beinhaltet eine zweite Schnittstelle, z.B. eine PCI-Busschnittstelle 24, die andere auf dem PCI 14 Bus befindliche Systemkomponenten mit dem Prozessor 12 koppelt.
Die Funktionseinheiten sind mit einem oder mehreren internen Bussen gekoppelt. Die internen Busse sind duale 32-Bit-Busse (d.h. ein Bus zum Lesen und einer zum Schreiben). Der Hardware-gestützte Multithread-Prozessor 12 ist auch so aufgebaut, dass die Summe der Bandbreiten der internen Busse im Prozessor 12 die Bandbreite von mit dem Prozessor 12 gekoppelten externen Bussen übersteigt. Der Prozessor 12 beinhaltet einen internen Kernprozessorbus 32, z.B. einen ASB-Bus (Advanced System Bus), der den Prozessorkern 20 mit den Speichersteuerungen 26a, 26b und einem nachfolgend beschriebenen ASB-Umsetzer 30 koppelt. Der ASB-Bus ist eine Teilmenge des so genannten AMBA-Busses, der mit dem Strong Arm Prozessorkern verwendet wird. Der Prozessor 12 beinhaltet auch einen Privatbus 34, der die Mikromaschineneinheiten mit der SRAM-Steuerung 26b, dem ASB-Umsetzer 30 und der FBUS-Schnittstelle 28 koppelt. Ein Speicherbus 38 koppelt die Speichersteuerung 26a, 26b mit den Busschnittstellen 24 und 28 und dem Speichersystem 16 einschließlich dem für Boot-Operationen usw. verwendeten Flashrom 16c.
Gemäß 2 beinhaltet jede der Mikromaschinen 22a– 22f einen Zuteiler, der Flags untersucht, um die verfügbaren Programmthreads zu ermitteln, an denen zu arbeiten ist. Jeder Programmthread von jeder der Mikromaschinen 22a–22f kann auf die SDRAM-Steuerung 26a, die SDRAM-Steuerung 26b und die FBUS-Schnittstelle 28 zugreifen. Die SDRAM-Steuerung 26a und die SDRAM-Steuerung 26b beinhalten jeweils mehrere Warteschlangen zum Speichern ausstehender Speicherreferenzanforderungen. Die Warteschlangen halten entweder die Speicherreferenzen in Ordnung oder ordnen Speicherreferenzen so an, dass Speicherbandbreite optimiert wird.
Wenn das Speichersubsystem 16 mit von Natur aus unabhängigen Speicheranforderungen geflutet wird, dann kann der Prozessor 12 Speicherreferenzsortierung ausführen. Speicherreferenzsortierung reduziert Totzeiten oder Blasen, die bei Zugriffen auf SRAM auftreten. Speicherreferenzsortierung ermöglicht es dem Prozessor 12, Referenzen auf Speicher so zu organisieren, dass auf lange Folgen von Lesevorgängen lange Ketten von Schreibvorgängen folgen können.
Referenzsortierung hilft dabei, parallele Hardware-Kontext-Programmthreads zu führen. Referenzsortierung erlaubt das Verbergen von Vorladungen (Precharges) von einer DRAM-Bank zur anderen. Wenn das Speichersystem 16b zu einer ungeraden Bank und einer geraden Bank organisiert wird, während der Prozessor an der ungeraden Bank arbeitet, dann kann die Speichersteuerung 26b mit dem Vorladen der geraden Bank starten. Vorladen ist dann möglich, wenn Speicherreferenzen zwischen ungeraden und geraden Banken abwechseln. Durch Ordnen von Speicherreferenzen so, dass Zugriffe auf entgegengesetzte Bänke abgewechselt werden, verbessert der Prozessor 12 die SDRAM-Bandbreite. Zusätzlich können andere Optimierungen zur Anwendung kommen, wie zum Beispiel: Zusammenführungsoptimierungen, bei denen zusammenführbare Operationen vor dem Speicherzugriff zusammengeführt werden; Open-Page-Optimierungen, bei denen durch Untersuchen von Adressen eine geöffnete Speicherseite nicht neu geöffnet wird; Verkettung, die eine Spezialhandhabung zusammenhängender Speicherreferenzen und Auffrischungsmechanismen zulassen.
Die FBUS-Schnittstelle 28 unterstützt Sende- und Empfangsflags für jeden Port, den ein MAC-Gerät unterstützt, zusammen mit einem Interrupt-Flag, der anzeigt, wenn ein Service gerechtfertigt ist. Die FBUS-Schnittstelle 28 beinhaltet auch eine Steuerung 28a, die eine Kopfverarbeitung von eingehenden Paketen vom FBUS 18 ausführt. Die Steuerung 28a extrahiert die Paketköpfe und führt ein mikroprogrammierbares Ursprung/Ziel/Protokoll-Hash-Lookup (für Adressglättung verwendet) in SRAM durch. Wenn die Hash-Funktion nicht erfolgreich ist, dann wird der Paketkopf für eine zusätzliche Verarbeitung zum Prozessorkern 20 gesendet. Die FBUS-Schnittstelle 28 unterstützt die folgenden internen Datentransaktionen
FBUS-Einheit (Gemeinschaftsbus-SRAM) zu/von Mikromaschine
FBUS-Einheit (über Privatbus) Schreibvorgänge von SDRAM-Einheit
FBUS-Einheit (über Mbus) Lesevorgänge zu SDRAM
Der FBUS 18 ist ein standardmäßiger Industriebus und beinhaltet einen Datenbus, z.B. 64 Bit breit, und Seitenbandsteuerung für Adress- und Lese/Schreib-Steuerung. Die FBUS-Schnittstelle 28 bietet die Fähigkeit, große Datenmengen mit einer Reihe von Ein- und Ausgabe-FIFOs 29a–29b einzugeben. Von den FIFOs 29a–29b rufen die Mikromaschinen 22a–22f Daten von der SDRAM-Steuerung 26a ab oder weisen sie an, Daten von einem Empfangs-FIFO, in dem Daten von einem Gerät auf dem Bus 18 angekommen sind, in die FBUS-Schnittstelle 28 zu verlegen. Die Daten können über einen direkten Speicherzugriff durch die Speichersteuerung 26a zum SDRAM-Speicher 16a gesendet werden. Ebenso können die Mikromaschinen Daten vom SDRAM 26a zur Schnittstelle 28, hinaus zum FBUS 18, über die FBUS-Schnittstelle 28 leiten.
Datenfunktionen werden unter den Mikrosteuerungen verteilt. Konnektivität zum SRAM 26a, SDRAM 26b und FBUS 28 erfolgt über Befehlsanforderungen. Eine Befehlsanforderung kann eine Speicheranforderung oder eine FBUS-Anforderung sein. So kann eine Befehlsanforderung beispielsweise Daten von einem in einer Mikromaschine 22a befindlichen Register zu einer Gemeinschaftsressource verlegen, z.B. eine SDRAM-Position, eine SRAM-Position, eine Flash-Speicher- oder eine MAC-Adresse. Die Befehle werden zu jeder der Funktionseinheiten und den Gemeinschaftsressourcen ausgesendet. Die Gemeinschaftsressourcen brauchen die Daten jedoch nicht lokal gepuffert zu halten. Stattdessen greifen die Gemeinschaftsressourcen auf in den Mikromaschinen befindliche verteilte Daten zu. So können Mikromaschinen 22a–22f lokalen Zugang zu Daten haben und es braucht ihnen kein Zugang auf einem Bus gewährt werden, so dass keine Konkurrenz um den Bus entsteht. Mit diesem Merkmal gibt es eine 0-Zyklus-Verweilzeit zum Warten auf Daten innerhalb der Mikromaschinen 22a–22f.
Der Kernprozessor 20 kann auch auf die Gemeinschaftsressourcen zugreifen. Der Kernprozessor 20 hat eine direkte Kommunikation mit der SDRAM-Steuerung 26a zur Busschnittstelle 24 und zur SRAM-Steueurung 26b über den Bus 32. Zum Zugreifen auf die Mikromaschinen 22a–22f und zum Übertragen von Registern, die sich in beliebigen der Mikromaschinen 22a–22f befinden, greift der Kernprozessor 20 mittels des ASB-Umsetzers 30 über den Bus 34 auf die Mikromaschinen 22a–22f zu. Der ASB-Umsetzer 30 führt eine Adressumsetzung zwischen FBUS-Mikromaschinen-Transferregisterorten und Kernprozessoradressen (d.h. ASB-Bus) aus, so dass der Kernprozessor 20 auf Register zugreifen kann, die zu den Mikromaschinen 22a–22c gehören.
Die Mikromaschinen 22 können den Registersatz zwar zum Austauschen von Daten verwenden, aber es ist auch ein Notizblockspeicher 27 vorgesehen, so dass Mikromaschinen Daten in den Speicher schreiben können, so dass andere Mikromaschinen sie lesen können. Der Notizblock 27 ist mit dem Bus 34 gekoppelt.
Mikromaschinen:
3 zeigt ein Beispiel für eine der Mikromaschinen 22a–22f, z.B. die Mikromaschine 22f. Die Mikromaschine beinhaltet einen Steuerspeicher 70, der in einer Ausführung einen RAM von hier 1024 Worten von 32 Bit beinhaltet. Der RAM speichert ein Mikroprogramm, das vom Kernprozessor 20 geladen werden kann. Die Mikromaschine 22f beinhaltet auch Steuerlogik 72. Die Steuerlogik beinhaltet einen Befehlsdecoder 73 und PC-(Programmzähler)-Einheiten 72a–72d. Die vier Mikroprogrammzähler 72a–72d werden in Hardware geführt. Die Mikromaschine 22f beinhaltet auch Kontextevent-Umschaltlogik 74. Die Kontexteventlogik 74 empfängt Meldungen (z.B. SEQ_#_EVENT_RESPONSE; FBI_EVENT_RESPONSE; SRAM_EVENT_RESPONSE; SDRAM_EVENT_RESPONSE; und ASB_EVENT_RESPONSE) von jeder der Gemeinschaftsressourcen, z.B. SRAM 26a, SDRAM 26b oder Prozessorkern 20, Steuer- und Statusregister usw. Diese Meldungen geben Informationen darüber, ob eine angeforderte Funktion abgeschlossen ist. Je nachdem, ob eine von einem Programmthread angeforderte Funktion abgeschlossen ist und den Abschluss signalisiert hat oder nicht, muss der Programmthread auf das Vollzugssignal warten, und wenn der Programmthread zur Arbeit freigegeben ist, dann wird er auf eine verfügbare Programmthread-Liste (nicht dargestellt) gesetzt. Die Mikromaschine 22f kann maximal z.B. 4 Programmthreads verfügbar haben.
Zusätzlich zu Event-Signalen, die lokal auf einem ausführenden Programmthread sind, verwenden die Mikromaschinen 22 globale Signalisierungszustände. Mit Signalisierungszuständen kann ein ausführender Programmthread einen Signalzustand zu allen Mikromaschinen 22 rundsenden. Jeder Programmthread in den Mikromaschinen kann auf diese Signalisierungszustände abzweigen. Diese Signalisierungszustände können verwendet werden, um die Verfügbarkeit einer Ressource oder den Service-Bedarf einer Ressource zu ermitteln.
Die Kontext-Event-Logik 74 hat Arbitrierung für die vier (4) Programmthreads. In einer Ausgestaltung ist die Arbitrierung ein Round-Robin-Mechanismus. Es können auch andere Techniken zum Einsatz kommen, einschließlich Priority-Queuing oder Weighted-Fair-Queuing. Die Mikromaschine 22f beinhaltet auch einen EBOX-(Execution Box)-Datenweg 76, der eine Rechenlogikeinheit 76a und einen Universalregistersatz 76b aufweist. Die Rechenlogikeinheit 76a führt arithmetische und logische Funktionen sowie Verschiebungsfunktionen aus. Der Registersatz 76b hat eine relativ große Zahl von Universalregistern. In dieser Ausführung gibt es 64 Universalregister in einer ersten Bank, Bank A, und 64 in einer zweiten Bank, Bank B. Die Universalregister haben eine Fensterstruktur, so dass sie relativ und absolut adressierbar sind.
Die Mikromaschine 22f beinhaltet auch einen Schreibtransferregisterstapel 78 und einen Lesetransferstapel 80. Auch diese Register haben eine Fensterstruktur, so dass sie relativ und absolut adressierbar sind. Der Schreibtransferregisterstapel 78 ist dort, wo sich Schreibdaten zu einer Ressource befinden. Ebenso ist der Leseregisterstapel 80 für Rückgabedaten von einer Gemeinschaftsressource. Nach oder gleichzeitig mit der Datenankunft wird ein Event-Signal von der jeweiligen Gemeinschaftsressource, z.B. die SRAM-Steuerung 26a, die SDRAM-Steuerung 26b oder der Kernprozessor 20, an den Kontext-Event-Zuteiler 74 angelegt, der dann dem Programmthread mitteilt, dass die Daten verfügbar sind oder gesendet wurden. Beide Transferregisterbänke 78 und 80 sind über einen Datenpfad mit der EBOX (Execution Box) 76 verbunden. In einer Ausführung hat das Lesetransferregister 64 Register und das Schreibtransferregister 64 Register.
Jede Mikromaschine 22a–22f unterstützt die Multithread-Ausführung von vier Kontexten. Ein Grund hierfür ist, es einem Programmthread zu gestatten, die Ausführung zu starten, unmittelbar nachdem ein anderer Programmthread eine Speicherreferenz ausgibt und warten muss, bis diese Referenz fertig ist, bevor weitere Arbeit ausgeführt wird. Dieses Verhalten ist für die Unterhaltung einer effizienten Hardware-Ausführung der Mikromaschinen wesentlich, weil Speicherlatenz signifikant ist. Anders ausgedrückt, wenn nur eine einzelne Programmthread-Ausführung unterstützt würde, dann würden die Mikromaschinen recht viele Zyklen lang untätig warten, bis Referenzen zurückkommen, wodurch der Gesamtrechendurchsatz reduziert würde. Eine Multithread-Ausführung lässt es zu, dass Mikromaschinen Speicherlatenz verbergen, indem sie nützliche unabhängige Arbeiten über mehrere Programmthreads ausführen. Es sind zwei Synchronisationsmechanismen vorgesehen, damit ein Programmthread eine SRAM- oder SDRAM-Referenz ausgeben und dann auf den Zeitpunkt synchronisieren kann, an dem diese Referenz vollzogen wird.
Ein Mechanismus ist Sofortsynchronisation (Immediate Synchronisation). Bei Sofortsynchronisation gibt die Mikromaschine die Referenz aus und lagert sie sofort aus diesem Kontext aus. Dem Kontext wird signalisiert, wenn die entsprechende Referenz vollzogen ist. Nach der Signalisierung wird der Kontext wieder zur Ausführung eingelagert, wenn ein Kontextumlagerungsevent auftritt und er an der Reihe ist. Daher wird vom Standpunkt eines Befehlsstroms eines einzelnen Kontexts aus gesehen das Mikrowort nach der Ausgabe der Speicherreferenz erst dann ausgeführt, wenn die Referenz fertig ist.
Ein zweiter Mechanismus ist verzögerte Synchronisation (Delayed Synchronisation). Bei verzögerter Synchronisation gibt die Mikromaschine die Referenz aus und fährt dann mit der Ausführung einer anderen nützlichen Arbeit unabhängig von der Referenz fort. Irgendwann später könnte es notwendig werden, den Ausführungsstrom des Programmthread auf den Vollzug der ausgegebenen Referenz zu synchronisieren, bevor weitere Arbeiten ausgeführt werden. An diesem Punkt wird ein Synchronisationsmikrowort ausgeführt, das entweder den aktuellen Programmthread auslagert und ihn irgendwann später wieder einlagert, wenn die Referenz fertig ist, oder mit der Ausführung des aktuellen Programmthreads fortfährt, weil die Referenz bereits fertig ist. Eine verzögerte Synchronisation wird mit zwei verschiedenen Signalisierungsansätzen ausgeführt
Wenn die Speicherreferenz mit einem Transferregister assoziiert ist, dann wird das Signal, von dem der Programmthread ausgelöst wird, erzeugt, wenn das entsprechende Transferregister-Gültig-Bit gesetzt oder gelöscht ist. So würde beispielsweise einem SRAM-Lesevorgang, der Daten im Transferregister A ablegt, signalisiert, wenn das gültige Bit für A gesetzt ist. Wenn die Speicherreferenz mit dem Transfer-FIFO oder dem Empfangs-FIFO anstatt einem Transferregister assoziiert ist, dann wird das Signal erzeugt, wenn die Referenz in der SDRAM-Steuerung 26a fertig ist. Nur ein Signalzustand pro Kontext wird im Scheduler der Mikromaschinen gehalten, daher kann bei diesem Ansatz nur ein ausstehendes Signal existieren.
Gemäß 4 beinhaltet die SDRAM-Speichersteuerung 26a Speicherreferenz-Warteschlangen 90, bei denen Speicherreferenzanforderungen von den verschiedenen Mikromaschinen 22a–22f ankommen. Die Speichersteuerung 26a beinhaltet einen Zuteiler 91, der die nächste der Mikromaschinen-Referenzanforderungen dafür auswählt, zu einer der Funktionseinheiten zu gehen. Angesichts der Tatsache, dass eine der Mikromaschinen eine Referenzanforderung bereitstellt, kommt die Referenzanforderung durch die Adress- und Befehlswarteschlange 90 in der SDRAM-Steuerung 26a. Wenn in der Referenzanforderung ein Bit mit der Bezeichnung „optimiertes MEM-Bit" gesetzt ist, dann wird die eingehende Referenzanforderung entweder in die Gerade-Bank-Warteschlange 90a oder die Ungerade-Bank-Warteschlange 90b sortiert. Wenn in der Speicherreferenzanforderung kein Speicheroptimierungsbit gesetzt ist, dann geht die Referenzanforderung vorgabemäßig in eine Ordnungswarteschlange 90c. Die SDRAM-Steuerung 26 ist ein Betriebsmittel, das von der FBUS-Schnittstelle 28, dem Kernprozessor 20 und der PCI-Schnittstelle 24 gemeinsam genutzt wird. Die SDRAM-Steuerung 26 führt auch eine Zustandsmaschine zur Ausführung von atomaren READ-MODIFY-Write-Operationen. Die SDRAM-Steuerung 26 führt auch Byte-Justierung für Anforderungen von Daten vom SDRAM aus.
Die Ordnungswarteschlange 90c hält die Reihenfolge von Referenzanforderungen von den Mikromaschinen. Mit einer Serie von Ungerade- und Gerade-Bank-Referenzen ist es evtl. erforderlich, dass ein Signal nur nach dem Abschluss einer Folge von Speicherreferenzen sowohl zu den ungeraden als auch zu den geraden Bänken zurückgegeben wird. Wenn die Mikromaschine 22f die Speicherreferenzen in Ungerade- und Gerade-Bank-Referenzen sortiert und in einer der Bänke, z.B. der geraden Bank, die Speicherreferenzen vor der ungeraden Bank ausgehen, aber das Signal auf der letzten geraden Referenz aufgedrückt wird, dann wäre es denkbar, dass die Speichersteuerung 26a ein Signal zu einer Mikromaschine zurücksendet, dass die Speicheranforderung fertig war, obwohl die Ungerade-Bank-Referenz noch nicht erledigt war. Dies könnte ein Kohärenzproblem verursachen. Die Ordnungswarteschlange 90c lässt es zu, dass in einer Mikromaschine mehrere Speicherreferenzen ausstehen, von denen nur die letzte Speicherreferenz einen Vollzug zu signalisieren braucht.
Die SDRAM-Steuerung 26a beinhaltet auch eine Hochprioritätswarteschlange 90d. In der Hochprioritätswarteschlange 90d geht eine eingehende Speicherreferenz von einer der Mikromaschinen direkt zur Hochprioritätswarteschlange und wird mit einer höheren Priorität bearbeitet als andere Speicherreferenzen in den anderen Warteschlangen. Alle diese Warteschlangen, die Gerade-Bank-Warteschlange 90a, die Ungerade-Bank-Warteschlange 90b, die Ordnungswarteschlange 90c und die Hochprioritätswarteschlange, werden in einer einzigen RAM-Struktur ausgeführt, die logisch in vier unterschiedliche Fenster segmentiert ist, wobei jedes Fenster seinen eigenen Kopf- und Endezeiger hat. Da Füllen- und Leeren-Operationen nur eine einzige Eingabe und eine einzige Ausgabe sind, können sie in dieselbe RAM-Struktur gesetzt werden, um die Dichte von RAM-Strukturen zu erhöhen.
Die SDRAM-Steuerung 26a beinhaltet auch Kernbus-Schnittstellenlogik, d.h. den ASB-Bus 92. Die ASB-Busschnittstellenlogik 93 verbindet den Kernprozessor 20 mit der SDRAM-Steuerung 26a. Wenn es eingehende Daten vom Kernprozessor 20 über die ASB-Schnittstelle 92 gibt, dann können die Daten im MEM ASB-Gerät 98 gespeichert und nachfolgend aus dem MEM ASB Gerät 98 durch die SDRAM-Schnittstelle 110 zum SDRAM-Speicher 16a entfernt werden. Obwohl dies nicht dargestellt ist, kann dieselbe Warteschlangenstruktur für die Lesevorgänge vorgesehen werden. Die SDRAM-Steuerung 26a beinhaltet auch eine Maschine 97 zum Ziehen von Daten aus den Mikromaschinen und dem PCI-Bus.
Zusätzliche Warteschlangen beinhalten die PCI-Adresswarteschlange 94 und die ASB-Lesen/Schreib- Warteschlange 96, die eine Reihe von Anforderungen enthält. Die Speicheranforderungen werden über den Multiplexer 106 zur SDRAM-Schnittstelle 110 gesendet. Der Multiplexer 106 wird vom SDRAM-Zuteiler 91 gesteuert, der erfasst, wie voll die einzelnen Warteschlangen sind, sowie den Status der Anforderungen, und der aufgrund dessen eine Entscheidung über die Priorität auf der Basis eines in einem Prioritäts-Service-Steuerregister 100 gespeicherten programmierbaren Wert fällt.
5 zeigt die Speichersteuerung 26b für den SRAM. Die Speichersteuerung 26b beinhaltet eine Adress- und Befehlswarteschlange 120. Die Speichersteuerung 26b wird auf der Basis des Speicheroperationstyps, d.h. Lesen oder Schreiben, optimiert. Die Adress- und Befehlswarteschlange 120 beinhaltet eine Hochprioritätswarteschlange 120a, eine Lesewarteschlange 120b, die die vorherrschende Speicherreferenzfunktion ist, die ein SRAM ausführt, und eine Ordnungswarteschlange 120c, die im Allgemeinen alle Schreibvorgänge zum SRAM und alle Lesevorgänge beinhaltet, die zu nichtoptimieren sind. Obwohl dies nicht gezeigt ist, könnte die Adress- und Befehlswarteschlange 120 auch eine Schreibwarteschlange beinhalten.
Die SRAM-Steuerung 26b beinhaltet auch Kernbus-Schnittstellenlogik, d.h. den ASB-Bus 122. Die ASB-Busschnittstellenlogik 122 verbindet den Kernprozessor 20 mit der SRAM-Steuerung 26b. Die SRAM-Steuerung 26b beinhaltet auch eine Maschine 127 zum Ziehen von Daten aus den Mikromaschinen und dem PCI-Bus.
Die Speicheranforderungen werden über den Multiplexer 126 zur SRAM-Schnittstelle 140 gesendet. Der Multiplexer 126 wird vom SRAM-Zuteiler 131 gesteuert, der erfasst, wie voll die einzelnen Warteschlangen sind, sowie den Status der Anforderungen, und der anhand dessen eine Entscheidung über die Priorität auf der Basis eines in einem Prioritäts-Service-Steuerregister 130 gespeicherten programmierbaren Wertes fällt. Wenn die Steuerung zum Multiplexer 126 eine Speicherreferenzanforderung wählt, dann wird die Speicherreferenzanforderung zu einem Decoder 138 gesendet, wo sie decodiert und eine Adresse erzeugt wird.
Die SRAM-Einheit behält die Kontrolle über den Memory Mapped Off-Chip SRAM und den Expansion ROM. Die SRAM-Steuerung 26b kann z.B. 16 MB adressieren, von denen z.B. 8 MB für SRAM 16b gemappt und 8 MB für Sonderfunktionen reserviert sind wie: Boot-Kapazität über Flashrom 16c; und Konsolenportzugang für MAC-Geräte 13a, 13b und Zugang zu assoziierten (RMON) Zählern. Der SRAM wird für lokale Lookup-Tabellen und Warteschlangen-Managementfunktionen verwendet.
Die SRAM-Steuerung 26b unterstützt die folgenden Transaktionen:
Mikromaschinenanforderungen (über Privatbus) zu/von SRAM
Kernprozessor (über ASB-Bus) zu/von SRAM
Die Adress- und Befehlswarteschlange 120 beinhaltet auch eine Read-Lock-Fail-Warteschlange 120d. Die Read-Lock-Fail-Warteschlange 120d dient zum Aufnehmen von Lese-Speicherreferenzanforderungen, die aufgrund einer auf einem Speicherteil existierenden Sperre versagen.
6 zeigt die Kommunikation zwischen den Mikromaschinen 22 und der FBUS-Schnittstellenlogik (FBI). Die FBUS-Schnittstelle 28 in einer Netzwerkanwendung führt Kopfverarbeitung an eingehenden Paketen vom FBUS 18 durch. Eine Hauptfunktion, die die FBUS-Schnittstelle ausführt, ist die Extraktion von Paketköpfen und ein mikroprogrammierbares Ursprung/Ziel/Protokoll-Hash-Lookup im SRAM. Wenn die Hash-Funktion nicht erfolgreich ist, dann wird der Paketkopf zum Kernprozessor 28 für eine weitergehende Verarbeitung weitergeleitet.
Die FBI 28 hat einen Sende-FIFO 182, einen Empfangs-FIFO 183, eine Hash-Einheit 188 und FBI-Steuer- und Statusregister 189. Diese vier Einheiten kommunizieren mit den Mikromaschinen 22 über einen zeitmultiplexierten Zugriff auf den SRAM-Bus 38, der mit den Transferregistern 78, 80 in den Mikromaschinen verbunden ist. Das heißt, alle Kommunikationen zu und von den Mikromaschinen erfolgen über die Transferregister 78, 80. Die FBUS-Schnittstelle 28 hat eine Push-Zustandsmaschine 200 zum Pushen von Daten in die Transferregister während der Zeitzyklen, in denen der SRAM den SRAM-Datenbus NICHT verwendet (Teil von Bus 38), und eine Pull-Zustandsmaschine 202 zum Abrufen von Daten aus den Transferregistern in der jeweiligen Mikromaschine.
Die Hash-Einheit hat ein Paar FIFOs 188a, 188b. Die Hash-Einheit ermittelt, wenn die FBI 28 eine FBI hash-Anforderung empfangen hat. Die Hash-Einheit 188 ruft Hash-Keys von der anrufenden Mikromaschine 22 ab. Nach dem Abrufen und Hashen der Keys werden die Indexe zurück zur anrufenden Mikromaschine 22 gesendet. Es können unter einer einzigen FBI hash-Anforderung bis zu drei Hash-Vorgänge durchgeführt werden. Die Busse 34 und 38 gehen jeweils in eine Richtung: SDRAM_push/pull data und Sbus_push/pull_data. Jeder dieser Busse benötigt Steuersignale zum Senden von Lese/Schreib-Controls zu den Transferregistern der entsprechenden Mikromaschine 22.
Im Allgemeinen benötigen Transferregister Schutz vor dem sie kontrollierenden Kontext, um die Lesekorrektheit zu garantieren. Speziell, wenn ein Schreibtransferregister von einem thread_1 benutzt wird, um Daten zum SDRAM 16a zu senden, dann überschreibt thread_1 dieses Register erst dann, wenn das Signal zurück von der SDRAM-Steuerung 26a anzeigt, dass dieses Register weitergeleitet wurde und jetzt wiederverwendet werden kann. Nicht jeder Schreibvorgang braucht ein Signal zurück vom Ziel, das anzeigt, dass die Funktion vollzogen wurde, weil die Vollzugsreihenfolge, wenn der Programmthread auf dieselbe Befehlswarteschlange an diesem Ziel mit mehreren Anforderungen schreibt, innerhalb dieser Befehlswarteschlange garantiert wird, so dass nur der letzte Befehl eine Signalisierung zurück zum Programmthread benötigt. Wenn der Programmthread jedoch mehrere Befehlswarteschlangen verwendet (Ordnen und Lesen), dann werden diese Befehlswarteschlangen in separate Kontexttasks unterteilt, so dass die Ordnung über Kontextumlagerung bewahrt bleiben kann. Der zu Beginn dieses Absatzes gezeigte Ausnahmefall bezieht sich auf eine bestimmte Operationsklasse unter Verwendung eines unangeforderten PUSH zu Transferregistern von der FBI für FBUS-Statusinformationen. Um Lese/Schreib-Determinismus auf den Transferregistern zu schützen, legt die FBI beim Einrichten dieser speziellen FBI-Push-Operationen ein spezielles Push_protect-Signal an.
Jede Mikromaschine 22, die die freilaufende FBI-Push-Technik anwendet, muss vor dem Zugreifen auf die Transferregister durch die vereinbarten FBUS-Schnittstelle/Mikromaschine den Schutzflag testen. Ist der Flag nicht gesetzt, dann können die Mikromaschinen 22 auf die Transferregister zugreifen. Wenn der Flag gesetzt ist, dann muss der Kontext N Zyklen lang warten, bevor auf die Register zugegriffen werden kann. Diese Zahl wird a priori durch die Anzahl der gepushten Transferregister, plus einem Frontend-Schutzfenster, bestimmt. Die Mikromaschine testet diesen Flag, bewegt dann die Daten von den Lesetransferregistern zu GPRs in angrenzenden Zyklen, so dass die Push-Maschine nicht mit dem Mikromaschinen-Lesevorgang kollidiert.
Thread-Signalisierung für Paketverarbeitung
Für Paketverarbeitung werden spezielle Techniken wie z.B. Interthread-Kommunikationen zum Kommunizieren von Status, ein Selbstzerstörungsregister 210, damit Programmthreads Tasks selbst zuweisen können, und ein thread_done-Register 212 zum Bereitstellen eines globalen Programmthread-Kommunikationsprogramms benutzt. Das Zerstörungsregister 210 und ein thread_done-Register 212 können als Steuer- und Statusregister 189 ausgeführt werden. Sie sind der Deutlichkeit halber in der FBUS-Schnittstelle 28 außerhalb des mit CSR integrierten Blocks zu sehen. Netzwerkfunktionen werden im Netzwerkprozessor mit mehreren Programmthreads ausgeführt, z.B. Kontexte zum Verarbeiten von Netzwerkpaketen. So könnten z.B. Scheduler-Programmthreads in einer der Mikroprogrammmaschinen, z.B. 22a, ausgeführt werden, während Verarbeitungs-Programmthreads in den übrigen Maschinen ausgeführt werden könnten, z.B. 22b–22f. Die Programmthreads (Verarbeitungs- oder Planungsprogrammthreads) verwenden Interthread-Kommunikationen zum Kommunizieren von Status.
Programmthreads werden spezielle Tasks wie z.B. Empfangs- und Sende-Scheduling, Empfangsverarbeitung und Sendeverarbeitung usw. zugewiesen. Task-Zuweisung und Task-Vollzug werden zwischen Programmthreads durch Inter-Thread-Signalierung, Register mit spezialisierten Lese- und Schreibcharakteristiken, z.B. Selbstzerstörungsregister 210 und Thread-done-Register 212, SRAM 16b und im internen Notizblockspeicher 186 (6) gespeicherte Daten aufgrund von Operationen wie Bit setzen und Bit löschen übermittelt.
Der Netzwerkprozessor 10 beinhaltet ein allgemeines Kontextkommunikationssignalisierungsprotokoll, das es zulässt, dass jeder Kontext ein Signal setzt, das von jedem anderen Kontext erfasst werden kann. Dadurch können kooperierende Programmthreads ein Semaphor verwenden und so mit Microcode-gesteuerter Verarbeitung koordinieren.
Die Verarbeitung von Netzwerkpaketen kann mit mehreren Programmthreads erfolgen. Typischerweise gibt es für Netzwerkverarbeitung einen Empfangs-Scheduler, einen Sende-Scheduler und Verarbeitungsprogrammthreads. Ein Scheduler-(Empfangen oder Senden)-Programmthread koordiniert die Menge an zu verrichtender Arbeit und die Reihenfolge der Arbeit durch Verarbeitungsprogrammthreads. Der Scheduler-Programmthread weist Verarbeitungsprogrammthreads Tasks zu und in einigen Fällen können Verarbeitungsprogrammthreads Tasks anderen Verarbeitungsprogrammthreads zuweisen. So bestimmt beispielsweise ein Scheduler, welche Ports bedient werden müssen und weist Verarbeitungsprogrammthreads Tasks zu und koordiniert sie, um inhärente Speicherlatenz durch parallele Verarbeitung mehrerer Programmthreads zu überwinden.
In einigen Beispielen kann mit langsamen Ports ein Verarbeitungsprogrammthread die Verarbeitung an einem Teil eines Pakets und ein zweiter Verarbeitungsprogrammthread den Rest des Pakets verarbeiten, oder in einigen Fällen verwendet der Scheduler den nächsten verfügbaren Programmthread. Bei schnelleren Ports, z.B. Gigabit-Ports, wo 64-Byte-Pakete sehr schnell empfangen werden, kann der Scheduler M Pakete zum nächsten verfügbaren Programmthread zuweisen. Die Programmthreads signalisieren einander, welchen Teil eines Pakets der Programmthread verarbeitet hat, sowie seinen Status.
Ein Programmthread kann zum Verarbeiten der ersten 64 Byte eines Pakets zugewiesen werden. Wenn der Programmthread fertig ist, dann hat er Daten zum Setzen von Signalen zum Aufwecken des nächsten für die Verarbeitung der nächsten 64 Bytes zugewiesenen Programmthreads. Der Programmthread kann ein Register und eine Adresse des Registers auf eine zuvor zugewiesenen Speicherstelle schreiben, z.B. Notizblockregister. Der Programmthread setzt Signale zum Aufwecken des nächsten zum Bearbeiten des nächsten Byte des Pakets zugewiesenen Programmthread.
Mit Bezug auf die 7A–7B, das Selbstzerstörungsregister 210 erlaubt es einem Scheduler-Programmthread S (230 in 7B), Services von mehreren Programmthreads P_a–P_n anzufordern, die den angeforderten Service bereitstellen. Der erste Programmthread, z.B. P_i, der auf das self_destruct-Register 210 zugreift (232 in 7B), nimmt die Anforderung. Nach dem Lesen durch einen Programmthread wird das „Selbstzerstörungsregister" 210 genullt, d.h. gelöscht (234 in 7B). Andere Programmthreads, die diese Anforderung erfüllen können, erhalten keine aktive Anforderung mehr. So kann z.B. ein Programmkontext durch Schreiben auf das Selbstzerstörungsregister 210 eine Task zur Zuweisung zum ersten bereiten Kontexts anfordern. Ein Kontext prüft auf Zuweisung durch Lesen des „Selbstzerstörungsregisters" 210. Wenn der Wert des Selbstzerstörungsregisters O ist, dann ist gerade keine neue Task zur Zuweisung zum Programmthread verfügbar. Dies könnte anzeigen, dass es keine neuen Tasks gibt oder dass evtl. ein anderer Programmthread sich selbst für die Task zugewiesen und das Selbstzerstörungsregister 210 gelöscht hat. Wenn der Wert nicht null ist, wird der Inhalt des Selbstzerstörungsregisters zum Ermitteln der Task interpretiert und das Register wird nach dem Lesen durch den Kontext gelöscht. So warten Kontexte, die dieses Register zur Zuweisung lesen, bis die nächste Task-Anweisung auf das Register geschrieben wurde.
Gemäß 8 werden für Vernetzungsanwendungen typischerweise unterschiedliche Programmtexte zum Ausführen spezieller Systemtasks verwendet. Tasks sind u.a. das Empfangen von Planungsdaten, das Empfangen von Verarbeitungskontexten, das Senden einer Zuteilung, das Senden von Planungsdaten, das Senden von Füll- und Prozessorkernkommunikationen.
Der Empfangs-Scheduler leitet den Empfang von z.B. 64 oder 128 Bytes Eingangsdaten ein (242), indem er einen Befehl zur FBI-Schnittstelle 28 sendet, der einen Port vorgibt, von dem die Daten extrahiert werden, und das Empfangs-FIFO-Element zum Puffern dieser Daten, sowie den Mikromaschinenkontext, der nach dem Abrufen der Empfangsdaten zu avisieren ist.
Der Empfangs-Scheduler-Thread 244 sendet ein Signal zum vorgegebenen Mikromaschinen-Programmthread, das einen vorgegebenen Kontext aktiviert. Der Kontext liest das FBI-Empfangssteuerregister zum Einholen der notwendigen Empfangsinformationen zur Verarbeitung (d.h. Port, Empfangs-FIFO-Elementort, Byte-Zahl, Paketanfang, Paketende, Fehlerstatus). Wenn ein Paketanfang angezeigt wird, dann ist der Empfangs-Scheduler-Programmthread dafür verantwortlich zu ermitteln, wo im SDRAM die Daten gespeichert werden (d.h. die Ausgangswarteschlange zum Einführen des Pakets), und die Paketdaten auf den SDRAM zu schreiben. Wenn dies nicht der Anfang eines Pakets ist, dann ermittelt der Empfangsprogrammthread, wo die früheren Daten dieses Pakets gespeichert wurden, um mit der Verarbeitung 246 des Pakets fortzufahren. Wenn die Paketende-Anzeige empfangen wird (248) (oder nach dem ersten 64-Byte-Abschnitt, wenn die Empfangen-bis-Senden-Latenz optimiert wird), fügt der Empfangsprogrammthread das Paket zur Warteschlange hinzu, ermittelt durch Verarbeitung des Paketkopfes.
Die Programmthreads kommunizieren auch mit einer Gemeinschaftsressource durch einen Bit-Setzen- und Bit-Löschen-Mechanismus, der einen Bitvektor bereitstellt. Dieser Mechanismus erlaubt das Setzen und Löschen individueller Bits und das Ausführen eines Tests und das Setzen individueller Bits zum Steuern einer Gemeinschaftsressource. Der Bitvektor signalisiert, wenn Ausgangswarteschlangen nicht leer sind. Wenn ein Empfangsprogrammthread ein Paket in eine Warteschlange einreiht, dann setzt der Empfangs-Scheduler 250 ein Bit. Der Sende-Scheduler kann den Bitvektor untersuchen, um den Status aller Warteschlangen zu ermitteln.
Die Bit-Setzen- und Bit-Löschen-Operationen am Bitvektor können entweder im Notizblock-RAM oder -SRAM erfolgen. Wenn der Scheduler zwischen Programmthreads auf derselben Mikromaschine 22 kommuniziert, dann kann der Bitvektor im Registersatz gespeichert werden, weil jeder Kontext die Register des anderen Kontexts lesen kann. So wird z.B. ein Leer- oder Nicht-leer-Status jeder Ausgangswarteschlange durch einen Bitvektor im internen Notizblockspeicher unterstützt. Wenn ein Empfangsprogrammthread ein Paket in eine Warteschlange einreiht, dann verwendet der Empfangsprogrammthread den Notizblockbit-setzen-Befehl zum Setzen eines Bits im Warteschlangen-Statusbitvektor, um anzuzeigen, dass die Warteschlange jetzt wenigstens einen Eintrag hat. Der Sendezuteiler durchsucht (270) den Warteschlangen-Bitvektor nach Nicht-leer-Warteschlangen (z.B. Bit_x gesetzt), um sendebereite Pakete zu ermitteln. Wenn ein Paket aus einer Warteschlange zum Senden herausgenommen wird (272), wenn die Warteschlange leer wird (274), dann gibt der Sendezuteiler (276) einen Bit-Löschen-Befehl an das entsprechende Bit des Warteschlangen-Bitvektors aus.
Mit Bezug auf 9, das thread_done-Register ist auch auf der FBI 28 und ist ein Register, in dem Bits von verschiedenen Programmthreads gesetzt werden können. Jeder Programmthread kann z.B. zwei Bits zum Übermitteln seines Status zu allen anderen Programmthreads benutzen. Es kann auch ein Scheduler-Programmthread den Status aller seiner Verarbeitungsprogrammthreads lesen (292). Nach dem Vollzug einer Empfangstask (282) schreibt (284) ein „Empfangs"-Programmthread einen Vollzugscode in das „thread_done"-Register. Der Empfangs-Programmthread wird nach dem Schreiben in das thread done-Register inaktiv (286). Dieser Empfangs-Programmthread wartet auf ein anderes Signal von der FBI, das anzeigt, dass eine andere Empfangs-Task zugewiesen wurde. Programmthreads 1–16 haben 2-Bit-Felder für „thread_done_1", und Programmthreads 17–24 haben 2-Bit-Felder für „thread_done_2". Das 2-Bit-Feld lässt es zu, dass ein Programmthread unterschiedliche Task-Vollzugsebenen kommuniziert.
So kann beispielsweise der Scheduler den 2-Bit-Status „01" verwenden, um anzuzeigen, dass Daten zum SDRAM bewegt wurden, die Paketverarbeitung noch läuft und Zeiger gespeichert wurden; Bit 10 kann anzeigen, dass Daten zum SDRAM bewegt wurden, die Paketverarbeitung noch läuft und Zeiger nicht gespeichert wurden; und Bit 11 kann anzeigen, dass die Paketverarbeitung vollzogen ist. Somit können die Zustände 296a vom Empfänger-Scheduler-Programmthread zum Zuweisen (297a) eines anderen Thread zum Verarbeiten einer Task verwendet werden, wenn Daten verfügbar werden, während die Zustände 296b vom Empfangs-Scheduler zum Zuweisen (297b) desselben Threads verwendet werden können, um die Verarbeitung fortzusetzen, wenn die Daten verfügbar sind.
Die genaue Interpretation der Meldung kann von einer Software-Konvention festgelegt werden, die zwischen einem Scheduler-Programmthread und Verarbeitungsprogrammthreads festgelegt wird, die vom Scheduler-Programmthread aufgerufen wird. Das heißt, die Statusmeldungen können sich je nachdem ändern, ob die Konvention zum Empfangen (wie oben), zum Senden ist, usw. Im Allgemeinen beinhalten die Statusmeldungen „belegt", „nicht belegt", „nicht belegt, wartet aber". Die Statusmeldung „nicht belegt, wartet aber" signalisiert, dass der aktuelle Programmthread die Verarbeitung eines Teils eines Pakets abgeschlossen hat und vermutlich zur Ausführung einer Folgetask an dem Paket zugewiesen wird, wenn Daten verfügbar gemacht werden. Sie kann verwendet werden, wenn der Programmthread Daten von einem Port erwartet und keinen Kontext gespeichert hat, so dass er den Rest dieses Pakets verarbeiten soll.
Der Scheduler-Programmthread liest das „thread done" Register, um den Vollzugsstatus von Tasks zu ermitteln, die er anderen Programmthreads zugewiesen hat. Das „thread done" Register wird als Write-one-to-clear-Register implementiert, so dass der Scheduler nur die Felder löschen kann, die er erkannt hat.
Andere Ausgestaltungen
Es ist zu verstehen, dass die Erfindung zwar ausführlich in Verbindung mit der ausführlichen Beschreibung davon beschrieben wurde, dass die obige Beschreibung aber lediglich illustrativ sein und den Umfang der Erfindung nicht begrenzen soll, der durch die beiliegenden Ansprüche definiert wird. Weitere Aspekte, Vorteile und Modifikationen liegen im Rahmen der folgenden Ansprüche.

Claims

Verfahren zur Netzwerkpaketverarbeitung, das die folgenden Schritte umfasst: Empfangen von Netzwerkpaketen; und Arbeiten an Netzwerkpaketen mit einer Mehrzahl von Programm-Threads zum Verarbeiten der Pakete; wobei das Verfahren dadurch gekennzeichnet ist, dass mehrere Threads unterschiedliche Teile eines empfangenen Netzwerkpakets verarbeiten, wobei aufeinander folgende der mehreren Threads aufeinander folgende Teile des Netzwerkpakets verarbeiten.
Verfahren nach Anspruch 1, wobei die Arbeit das Verwenden von wenigstens einem Programm-Thread zum Prüfen eines Kopfteils des Pakets beinhaltet.
Verfahren nach Anspruch 2, wobei die Arbeit ferner das Signalisieren mit dem wenigstens einen Programm-Thread beinhaltet, dass ein Paketkopf verarbeitet wurde.
Verfahren nach Anspruch 1, wobei die Mehrzahl von Programm-Threads Scheduler-Programm-Threads (230) zum Planen von Aufgabenreihenfolgen zur Verarbeitung und Verarbeitungsprogramm-Threads (Pa–Pn) sind, die Pakete gemäß von den Scheduler-Programm-Threads (230) zugewiesenen Aufgabenzuweisungen verarbeiten.
Verfahren nach Anspruch 1, wobei jeder Programm-Thread eine Meldung auf ein Register (212) schreibt, die seinen aktuellen Status anzeigt.
Verfahren nach Anspruch 5, wobei die Interpretation der Meldung durch eine Software-Konvention festgelegt wird, die zwischen einem Scheduler-Programm-Thread (230) und Verarbeitungs-Programm-Threads (Pa–Pn) festgelegt wird, die vom Scheduler-Programm-Thread (230) abgerufen wird.
Verfahren nach Anspruch 5, wobei Statusmeldungen 'belegt', 'nicht belegt', 'nicht belegt, aber wartet' beinhalten.
Verfahren nach Anspruch 5, wobei eine Statusmeldung 'nicht belegt, aber wartet' beinhaltet und wobei der Status 'nicht belegt, aber wartet' signalisiert, dass der aktuelle Programm-Thread die Verarbeitung eines Teils eines Pakets vollendet hat und vermutlich zur Ausführung einer nachfolgenden Aufgabe an dem Paket zugewiesen wird, wenn Daten zur Fortsetzung der Verarbeitung des Programm-Threads zur Verfügung gestellt werden.
Verfahren nach Anspruch 5, wobei das Register ein global zugängiges Register (212) ist, das von allen aktuellen Programm-Threads gelesen oder beschrieben werden kann.
Verfahren nach Anspruch 4, wobei Scheduler-Programm-Threads jedes beliebige aus einer Mehrzahl von Verarbeitungsprogramm-Threads (Pa–Pn) zum Handhaben der Verarbeitung einer Aufgabe planen können.
Verfahren nach Anspruch 10, wobei der Scheduler-Programm-Thread (230) ein Register (210) mit einer Adresse schreibt, die einer Position der Daten für die Mehrzahl von Verarbeitungsprogramm-Threads entspricht.
Verfahren nach Anspruch 11, wobei ein ausgewählter aus der Mehrzahl von Verarbeitungsprogramm-Threads (Pa–Pn), die die Aufgabe handhaben können, das Register (210) liest, um die Position der Daten. einzuholen.
Verfahren nach Anspruch 12, wobei der ausgewählte aus der Mehrzahl von Verarbeitungsprogramm-Threads (Pa–Pn) das Register (210) liest, um die Position der Daten einzuholen und sich selbst zur Verarbeitung der vom Scheduler-Programm-Thread (230) angeforderten Aufgabe zuzuweisen.
Verfahren nach Anspruch 12, wobei der ausgewählte aus der Mehrzahl von Verarbeitungs-Threads (Pa–Pn) das Register (210) liest, um die Position der Daten einzuholen, während das Register durch Lesen des Registers (210) von dem Programm-Thread gelöscht wird, um sich selbst zur Verarbeitung der Aufgabe zuzuweisen.
Verfahren nach Anspruch 13, wobei ein anderer aus der Mehrzahl von Verarbeitungsprogramm-Threads (Pa–Pn), die der Aufgabe zugewiesen werden können, bei dem Versuch, das Register (210) zu lesen, nachdem es gelöscht wurde, einen Nullwert erhält, der anzeigt, dass dem Verarbeitungsprogramm-Thread derzeit keine Aufgabe zugewiesen werden kann.
Verfahren nach einem der vorherigen Ansprüche, wobei das empfangene Netzwerkpaket von einem Video-Access-Controller (13a, 13b) Port empfangen wird.
Verfahren nach einem der vorherigen Ansprüche, wobei ein Thread die Verarbeitung an einem Teil eines Pakets ausführt und ein zweiter Thread den Rest des Pakets verarbeitet.
Paralleler, Hardware-gestützter Multithread-Prozessor (12) zum Empfangen von Netzwerkpaketen, der Folgendes umfasst: einen Universalprozessor (20), der Systemfunktionen koordiniert; und eine Mehrzahl von Mikromaschinen (22), die mehrere Programm-Threads unterstütien und an den Netzwerkpaketen mit einer Mehrzahl von Programm-Threads arbeiten, um eine Verarbeitung der Pakete zu bewirken; wobei der Prozessor dadurch gekennzeichnet ist, dass: mehrere Threads unterschiedliche Teile eines empfangenen Netzwerkpakets verarbeiten, wobei aufeinander folgende der mehreren Threads aufeinander folgende Teile des Netzwerkpakets verarbeiten.
Prozessor (20) nach Anspruch 18, wobei eine aus der Mehrzahl von Mikromaschinen (22) Scheduler-Programm-Threads (230) ausführt und die übrigen Mikromaschinen (22) Verarbeitungsprogramm-Threads (Pa–Pn) ausführen.
Prozessor (20) nach Anspruch 18, der ferner ein globales Thread-Statusregister (212) umfasst, wobei jeder Programm-Thread eine Meldung auf das globale Statusregister (212) schreibt, die seinen aktuellen Status anzeigt.
Prozessor (20) nach Anspruch 20, wobei die Interpretation der Meldung durch eine Software-Konvention festgelegt ist, die zwischen einem Scheduler-Programm-Thread (230) und den Verarbeitungsprogramm-Threads (Pa–Pn) bestimmt wird, die vom Scheduler-Programm-Thread (230) abgerufen werden.
Prozessor (20) nach Anspruch 18, der ferner Folgendes umfasst: ein Einmal-Lesen-Register (210), wobei der Scheduler-Programm-Thread (230) das Einmal-Lesen-Register (210) mit einer Adresse schreibt, die einer Datenposition für die Mehrzahl von Verarbeitungsprogramm-Threads (Pa–Pn) entspricht, und wenn ein ausgewählter aus der Mehrzahl von Verarbeitungsprogramm-Threads (Pa–Pn) das Register (210) liest, um die Datenposition einzuholen, sich selbst zum Verarbeiten der Aufgabe zuweist, die von dem Scheduler-Programm-Thread (230) angefordert wurde, während das Register (210) durch Lesen des Registers durch den Programm-Thread gelöscht wird.
Prozessor (20) nach Anspruch 22, wobei ein anderer aus der Mehrzahl der Verarbeitungsprogramm-Threads (Pa–Pn), die der Aufgabe zugewiesen werden können, bei dem Versuch, das Einmal-Lesen-Register (210) zu lesen, nachdem es gelöscht wurde, einen Nullwert erhält, der anzeigt, dass dem Verarbeitungsprogramm-Thread (Pa–Pn) derzeit keine Aufgabe zugewiesen werden kann.
Prozessor nach einem der Ansprüche 18 bis 23, wobei das empfangene Netzwerkpaket von einem Video-Access-Controller (13a, 13b) Port empfangen wird.
Prozessor nach einem der Ansprüche 18 bis 24, wobei ein Thread die Verarbeitung an einem Teil eines Pakets ausführt und ein zweiter Thread den Rest eines Pakets verarbeitet,