DE60019401T2 - Verfahren und gerät für die dynamische und stapelweise verarbeitung von paketen mit einer netzwerkschnittstelle - Google Patents

Verfahren und gerät für die dynamische und stapelweise verarbeitung von paketen mit einer netzwerkschnittstelle Download PDF

Info

Publication number
DE60019401T2
DE60019401T2 DE60019401T DE60019401T DE60019401T2 DE 60019401 T2 DE60019401 T2 DE 60019401T2 DE 60019401 T DE60019401 T DE 60019401T DE 60019401 T DE60019401 T DE 60019401T DE 60019401 T2 DE60019401 T2 DE 60019401T2
Authority
DE
Germany
Prior art keywords
packet
flow
header
data
package
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE60019401T
Other languages
English (en)
Other versions
DE60019401D1 (de
Inventor
Shimon Muller
Denton Gentry
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Application granted granted Critical
Publication of DE60019401D1 publication Critical patent/DE60019401D1/de
Publication of DE60019401T2 publication Critical patent/DE60019401T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9063—Intermediate storage in different physical parts of a node or terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/60—Software-defined switches
    • H04L49/602—Multilayer or multiprotocol switching, e.g. IP switching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9084—Reactions to storage capacity overflow
    • H04L49/9089—Reactions to storage capacity overflow replacing packets in a storage arrangement, e.g. pushout
    • H04L49/9094—Arrangements for simultaneous transmit and receive, e.g. simultaneous reading/writing from/to the storage element
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/30—Peripheral units, e.g. input or output ports
    • H04L49/3009—Header conversion, routing tables or routing tags
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/30—Peripheral units, e.g. input or output ports
    • H04L49/3018—Input queuing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/351—Switches specially adapted for specific applications for local area network [LAN], e.g. Ethernet switches
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/354—Switches specially adapted for specific applications for supporting virtual local area networks [VLAN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Description

  • INHALTSVERZEICHNIS
    • HINTERGRUND
    • ZUSAMMENFASSUNG
    • KURZBESCHREIBUNG DER FIGUREN
    • AUSFÜHRLICHE BESCHREIBUNG
    • Einleitung
    • Eine Ausführungsform einer Hochleistungs-Netzschnittstellenschaltung
    • Ein beispielhaftes Paket
    • Eine Ausführungsform eines Kopfanalysealgorithmus
    • Dynamische Kopfanalysebefehle in einer Ausführungsform der Erfindung
    • Eine Ausführungsform einer Flussdatenbank
    • Eine Ausführungsform eines Flussdatenbankmanagers
    • Eine Ausführungsform eines Lastverteilers
    • Eine Ausführungsform einer Paketwarteschlange
    • Eine Ausführungsform einer Steuerwarteschlange
    • Eine Ausführungsform einer DMA-Maschine
    • Eine Ausführungsform eines dynamischen Paketstapel-Moduls
    • PATENTANSPRÜCHE
  • HINTERGRUND
  • Diese Erfindung bezieht sich auf die Gebiete der Computersysteme und der Computernetze. Insbesondere bezieht sich die vorliegende Erfindung auf eine Netzschnittstellenschaltung (NIC) zum Verarbeiten von Kommunikationspaketen, die zwischen einem Computernetz und einem Host-Computersystem ausgetauscht werden.
  • Die Schnittstelle zwischen einem Computer und einem Netz ist häufig ein Engpass für Nachrichten, die zwischen dem Computer und dem Netz übergeben werden. Obgleich die Computerleistung (z. B. die Prozessorgeschwindigkeit) im Laufe der Jahre exponentiell gestiegen ist und die Übertragungsgeschwindigkeiten von Computernetzen ähnliche Zunahmen erfahren haben, sind Ineffizienzen in Bezug auf die Art und Weise, in der Netzschnittstellenschaltungen Nachrichten behandeln, immer offensichtlicher geworden. Mit jeder inkrementellen Zunahme der Computer- oder Netzgeschwindigkeit wird immer offensichtlicher, dass die Schnittstelle zwischen dem Computer und dem Netz nicht Schritt halten kann. Diese Ineffizienzen betreffen mehrere Grundprobleme in Bezug auf die Art und Weise, in der die Kommunikation zwischen einem Netz und einem Computer behandelt wird.
  • Die heutigen am weitesten verbreiteten Formen von Netzen neigen dazu, paketgestützt zu sein. Diese Arten von Netzen einschließlich des Internet und vieler lokaler Netze übertragen Informationen in Form von Paketen. Jedes Paket wird durch eine Ursprungs-Endstation getrennt erzeugt und gesendet und durch eine Ziel-Endstation getrennt empfangen und verarbeitet. Außerdem kann jedes Paket z. B. in einem Netz mit Bustopologie durch zahlreiche Stationen empfangen und verarbeitet werden, die sich zwischen der Ursprungs- und der Ziel-Endstation befinden.
  • Ein Grundproblem bei Paketnetzen ist, dass jedes Paket sowohl in der Ursprungs- als auch in der Ziel-Endstation durch mehrere Protokolle oder Protokollebenen (gemeinsam als ein "Protokollstapel" bekannt) verarbeitet werden muss. Wenn die zwischen Stationen übertragenen Daten länger als eine bestimmte Mindestlänge sind, werden die Daten in mehrere Abschnitte unterteilt, wobei jeder Abschnitt durch ein getrenntes Paket übermittelt wird. Die Datenmenge, die ein Paket übermitteln kann, ist allgemein durch das Netz begrenzt, das das Paket befördert, und wird häufig als eine größte Übertragungseinheit (MTU) ausgedrückt. Die ursprüngliche Aggregation von Daten ist gelegentlich als ein "Datagramm" bekannt, wobei jedes Paket, das einen Teil eines einzelnen Datagramms übermittelt, sehr ähnlich wie die anderen Pakete des Datagramms verarbeitet wird.
  • Allgemein werden Kommunikationspakete wie folgt verarbeitet. In der Ursprungs-Endstation wird jeder getrennte Datenabschnitt eines Datagramms durch einen Protokollstapel verarbeitet. Während dieser Verarbeitung werden zu dem Datenabschnitt mehrere Protokollköpfe (z. B. TCP, IP, Ethernet) hinzugefügt, um ein Paket zu bilden, das über das Netz übertragen werden kann. Das Paket wird von einer Netzschnittstellenschaltung empfangen, die das Paket an die Ziel-Endstation oder an einen Host-Computer, der die Ziel-Endstation bedient, überträgt. In der Ziel-Endstation wird das Paket durch den Protokollstapel in der entgegengesetzten Richtung wie in der Ursprungs-Endstation verarbeitet. Während der Verarbeitung werden die Protokollköpfe in der entgegengesetzten Reihenfolge zu der, in der sie angebracht wurden, entfernt. Somit wird der Datenabschnitt wiedergewonnen und kann für einen Anwender, ein Anwendungsprogramm usw. verfügbar gemacht werden.
  • Somit durchlaufen mehrere verwandte Pakete (z. B. Pakete, die Daten aus einem Datagramm übermitteln) auf serielle Weise (d. h. paketweise) im Wesentlichen den gleichen Prozess. Je mehr Daten übertragen werden müssen, desto mehr Pakete müssen gesendet werden, wobei jedes in jeder Richtung durch den Protokollstapel getrennt behandelt und verarbeitet wird. Natürlich ist der Bedarf, der dem Prozessor einer Endstation auferlegt wird, umso größer, je mehr Pakete verarbeitet werden müssen. Die Anzahl der Pakete, die verarbeitet werden müssen, wird durch andere Faktoren als nur die in einem Datagramm gesendete Datenmenge beeinflusst. Zum Beispiel brauchen weniger Pakete gesendet zu werden, während die Datenmenge, die in einem Paket gekapselt werden kann, zunimmt. Wie oben festgestellt wurde, kann ein Paket aber je nach Art des verwendeten Netzes eine größte zulässige Größe haben (wobei z. B. die größte Übertragungseinheit für Standard-Ethernet-Verkehr etwa 1500 Bytes sind). Die Geschwindigkeit des Netzes beeinflusst außerdem die Anzahl der Pakete, die eine NIC in einer gegebenen Zeitdauer behandeln kann. Zum Beispiel kann ein Gigabit-Ethernet-Netz, das mit der Spitzenkapazität arbeitet, erfordern, dass eine NIC etwa 1,48 Millionen Pakete pro Sekunde empfängt. Somit kann die Anzahl der Pakete, die durch einen Protokollstapel zu verarbeiten sind, dem Prozessor eines Computers eine erhebliche Last auferlegen. Die Situation wird durch die Notwendigkeit verschärft, jedes Paket getrennt zu verarbeiten, obgleich jedes im Wesentlichen auf die gleiche Weise verarbeitet wird.
  • Ein verwandtes Problem zu der gesonderten Verarbeitung der Pakete ist die Art und Weise, in der Daten während der Datensendung und des Datenempfangs zwischen einem "Anwenderraum" (z. B. der Datenablage eines Anwendungsprogramms) und einem "Systemraum" (z. B. einem Systemspeicher) verschoben werden. Derzeit werden die Daten einfach aus einem Speicherbereich, der einem Anwender oder Anwendungsprogramm zugewiesen ist, in einen anderen Speicherbereich, der der Verwendung durch den Prozessor gewidmet ist, kopiert. Da jeder Abschnitt eines Datagramms, der in einem Paket übertragen wird, getrennt (z. B. byteweise) kopiert werden kann, ist eine nicht triviale Menge an Prozessorzeit erforderlich, wobei häufige Übertragungen eine große Menge der Speicherbusbandbreite verbrauchen können. Beispielhaft kann jedes Byte der Daten in einem Paket, das von dem Netz empfangen wird, für über das Netz übertragene Daten aus dem Systemraum in einer getrennten Kopieroperation aus dem Systemraum gelesen und in den Anwenderraum geschrieben werden und umgekehrt. Obgleich der Systemraum allgemein einen geschützten (z. B. vor Manipulation durch Anwenderprogramme geschützten) Speicherbereich bereitstellt, tut die Kopieroperation vom Standpunkt einer Netzschnittstellenschaltung aus gesehen nichts Nützliches. Stattdessen riskiert sie eine Überlastung des Host-Prozessors und die Verzögerung seiner Fähigkeit, schnell zusätzlichen Netzverkehr von der NIC anzunehmen. Somit kann das getrennte Kopieren der Daten jedes Pakets insbesondere in einer schnellen Netzumgebung sehr ineffizient sein.
  • Außer der ineffizienten Übertragung von Daten (z. B. immer nur die Daten eines Pakets) ist die Verarbeitung der Köpfe aus von dem Netz empfangenen Paketen ebenfalls ineffizient. Obgleich es in Bezug auf die Werte innerhalb der Köpfe der Pakete für ein besonderes Protokoll eine gewisse Änderung geben kann, besitzt jedes Paket, das einen Teil eines einzelnen Datagramms übermittelt, allgemein die gleichen Protokollköpfe (z. B. Ethernet, IP und TCP). Allerdings wird jedes Paket durch den gleichen Protokollstapel einzeln verarbeitet, was somit mehrere Wiederholungen gleicher Operationen für verwandte Pakete erfordert. Die aufeinander folgende Verarbeitung nicht verwandter Pakete durch verschiedene Protokollstapel ist wahrscheinlich wesentlich weniger effizient als die fortschreitende Verarbeitung einer Anzahl verwandter Pakete durch immer nur einen Protokollstapel.
  • Ein weiteres Grundproblem, das die Wechselwirkung zwischen derzeitigen Netzschnittstellenschaltungen und Host-Computersystemen betrifft, ist, dass die Kombination häufig nicht die erhöhten Prozessorbetriebsmittel nutzt, die in Mehrpro zessor-Computersystemen verfügbar sind. Mit anderen Worten, derzeitige Versuche, die Verarbeitung der Netzpakete (z. B. über einen Protokollstapel) auf effiziente Weise auf eine Anzahl von Protokollen zu verteilen, sind allgemein ineffektiv. Insbesondere kommt die Leistung derzeitiger NICs den erwarteten oder gewünschten linearen Leistungsgewinnen, von denen erwartet werden kann, dass sie aus der Verfügbarkeit mehrerer Prozessoren realisiert werden können, nicht nahe. In einigen Mehrprozessorsystemen wird z. B. aus der Verwendung von mehr als 4–6 Prozessoren wenig Verbesserung in Bezug auf die Verarbeitung des Netzverkehrs realisiert.
  • Außerdem kann die Rate, mit der Pakete von einer Netzschnittstellenschaltung zu einem Host-Computer oder zu einer anderen Kommunikationsvorrichtung übertragen werden, möglicherweise nicht mit der Rate der Paketankunft an der Netzschnittstelle schritthalten. Das eine oder andere Element des Host-Computers (z. B. ein Speicherbus, ein Prozessor) kann überlastet sein oder auf andere Weise unfähig sein, Pakete ausreichend ohne Zögern anzunehmen. In diesem Fall können eines oder mehrere Pakete fallengelassen oder verworfen werden. Das Fallenlassen von Paketen kann veranlassen, dass eine Netzentität einigen Verkehr neu sendet, wobei eine Netzverbindung eine Neuinitialisierung erfordern kann, falls zu viele Pakete fallengelassen werden. Ferner kann das Fallenlassen eines Pakets oder Pakettyps anstelle eines anderen einen erheblichen Unterschied des Gesamtnetzverkehrs verursachen. Falls z. B. ein Steuerpaket fallengelassen wird, kann die entsprechende Netzverbindung ernsthaft beeinflusst werden, wobei sie wegen der normalerweise kleinen Größe eines Steuerpakets wenig tun kann, um die Paketsättigung der Netzschnittstellenschaltung zu mildern. Somit kann der Netzverkehr stärker als nötig verschlechtert werden, wenn das Fallenlassen der Pakete nicht in einer Art und Weise ausgeführt wird, die die Wirkung auf viele Netzverbindungen verteilt oder für bestimmte Arten von Paketen Zugeständnisse macht.
  • Somit liefern die derzeitigen NICs keine angemessene Leistung, um die heutigen High-End-Computersysteme und Hochgeschwindigkeitsnetze miteinander zu verbinden. Außerdem kann eine Netzschnittstellenschaltung, die keine Zugeständnisse für einen überlasteten Host-Computer machen kann, die Leistungsfähigkeit des Computers verschlechtern.
  • US-A-5 870 394 offenbart ein Verfahren und eine Vorrichtung zum Wiederzusam mensetzen von Datenpaketen zu Nachrichten. Die Datenpakete enthalten Nutzinformationsabschnitte und Kopfabschnitte, die Kanaldarstellungen enthalten, um den Paketen zugeordnete Kanäle zu identifizieren. Die Vorrichtung enthält einen Wiederzusammensetzungsprozessor, um für jeden Kanal eine Liste der Verbindungsangaben von Adressenzeigern auf den Speicher, in dem die Nutzinformationsabschnitte der Pakete gespeichert werden, aufrechtzuerhalten.
  • WO-A-99 00945 offenbart ein verteiltes Mehrschichtnetzelement, um Pakete, während sie empfangen werden, anhand dessen zu vermitteln oder zu lenken, wie frühere Pakete des gleichen Flusses vermittelt worden sind.
  • ZUSAMMENFASSUNG
  • In einer Ausführungsform der Erfindung werden ein System und ein Verfahren zum Identifizieren eines Pakets innerhalb eines besonderen Kommunikationsflusses durch eine Kommunikationsvorrichtung wie etwa eine Netzschnittstelle geschaffen. Insbesondere kann ein Kommunikationsfluss ein erstes Paket enthalten, das von der Netzschnittstelle an einen Host-Computer übertragen wird. Anhand eines Identifizierers des Flusses kann für den Host-Computer ein weiteres Paket in dem gleichen Fluss identifiziert werden. Um die Effizienz der Behandlung des Netzverkehrs zu erhöhen, können die Flusspakete daraufhin durch einen Protokollstapel in einem Host-Computer kollektiv verarbeitet werden.
  • In dieser Ausführungsform empfängt eine Hochleistungs-Netzschnittstelle eines Host-Computers ein Paket von einem Netz. Informationen innerhalb eines Kopfabschnitts des Pakets werden zusammengesetzt, um einen Flussschlüssel zu erzeugen, der den Kommunikationsfluss, die Verbindung oder die Schaltung zu identifizieren, der/die das Paket enthält. Beispielhaft enthält der Flussschlüssel die Identifizierer der Quell- und der Ziel-Entität, die das Paket austauschen. In einer Ausführungsform der Erfindung werden Flussschlüssel von einem oder von mehreren Kommunikationsflüssen in einer Flussdatenbank gespeichert, die durch eine Flussnummer indiziert wird und durch ein Flussdatenmanagement-Modul administriert werden kann. Falls die Datenbank den Flussschlüssel des empfangenen Pakets noch nicht enthält, kann der Kommunikationsfluss des empfangenen Pakets ein neuer Fluss bei der Netzschnittstelle sein. In diesem Fall wird der Fluss durch Speichern seines Flussschlüssels und möglicherweise weiterer den Fluss betreffender Informationen in der Datenbank registriert. Somit kann der Fluss eines Pakets durch seinen Flussschlüssel und/oder durch seine Flussnummer identifiziert werden.
  • Das Paket wird in einem Paketspeicher (z. B. in einer Warteschlange) gespeichert, um auf die Übertragung zu dem Host-Computer zu warten, wobei die Flussnummer des Pakets in einem Flussspeicher eines dynamischen Paketstapel-Moduls gespeichert wird. Wenn das Paket übertragen wird oder davor steht, übertragen zu werden, wird der Flussspeicher durchsucht, um zu bestimmen, ob ein weiteres in dem Paketspeicher gespeichertes Paket ein Teil des gleichen Kommunikationsflusses ist (z. B. die gleiche Flussnummer oder den gleichen Flussschlüssel besitzt).
  • Falls in dieser Ausführungsform ein weiteres Paket die gleiche Flussnummer besitzt, wird der Host-Computer durch Speichern eines Anzeigers wie etwa eines Deskriptors in einem Host-Speicher gewarnt. In einer weiteren Ausführungsform der Erfindung wird ein anderer Anzeiger in einem Host-Speicher gespeichert, falls kein weiteres Paket mit der gleichen Flussnummer ermittelt wird. Zum Beispiel kann ein anderer Anzeiger gespeichert werden, falls bestimmt wird, dass das Paket das letzte Paket seines Kommunikationsflusses ist. Je nach dem gespeicherten Anzeiger kann der Host-Computer die Verarbeitung des Pakets verzögern, um auf ein weiteres Paket mit der gleichen Flussnummer zu warten.
  • Außerdem enthält das dynamische Paketstapel-Modul in einer vorliegenden Ausführungsform der Erfindung einen Controller. Der Controller versucht, den Flussspeicher mit Informationen zu bevölkern, die in dem Paketspeicher gespeicherten Paketen zugeordnet oder von ihnen abgeleitet sind. Beispielhaft speichert jeder Eintrag in dem Flussspeicher in dieser Ausführungsform eine Flussnummer des Pakets und einen Anzeiger dafür, ob der Eintrag gültig ist. Ein Eintrag kann annulliert werden, wenn sein Paket an den Host-Computer übertragen wird, wobei er gleichzeitig durch einen anderen Eintrag ersetzt wird.
  • In einer Ausführungsform der Erfindung sind nur Pakete zur dynamischen Paketstapelung berechtigt, die zu einem oder mehreren einer Menge im Voraus gewählter Protokolle konform sind. In dieser Ausführungsform kann ein Kopfanalysealgorithmus-Modul so konfiguriert werden, dass es bestimmt, ob ein empfangenes Paket in Übereinstimmung mit einem der Protokolle formatiert ist. Falls das empfangene Paket mit den im Voraus gewählten Protokollen kompatibel ist, kann es ebenfalls die weiteren Verarbeitungseffizienzen wie etwa das Wiederzusammensetzen von Daten aus mehreren Paketen in einem Fluss oder das Verteilen der Verarbeitung der Pakete auf mehrere Prozessoren in einem Mehrprozessorsystem nutzen.
  • KURZBESCHREIBUNG DER FIGUREN
  • 1A ist ein Blockschaltplan, der eine Netzschnittstellenschaltung (NIC) zum Empfangen eines Pakets von einem Netz in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt.
  • 1B ist ein Ablaufplan, der ein Verfahren des Betriebs der NIC aus 1A zum Übertragen eines von einem Netz empfangenen Pakets an einen Host-Computer in Übereinstimmung mit einer Ausführungsform der Erfindung veranschaulicht.
  • 2 ist ein Diagramm eines über ein Netz übertragenen und in einer Netzschnittstellenschaltung empfangenen Pakets in einer Ausführungsform der Erfindung.
  • 3 ist ein Blockschaltplan, der einen Kopfanalysealgorithmus einer Netzschnittstellenschaltung zum syntaktischen Analysieren eines Pakets in Übereinstimmung mit einer Ausführungsform der Erfindung zeigt.
  • 4A–4B enthalten einen Ablaufplan, der ein Verfahren zum syntaktischen Analysieren eines von einem Netz empfangenen Pakets bei einer Netzschnittstellenschaltung in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
  • 5 ist ein Blockschaltplan, der eine Netzschnittstellenschaltungs-Flussdatenbank in Übereinstimmung mit einer Ausführungsform der Erfindung zeigt.
  • 6A–6E enthalten einen Ablaufplan, der ein Verfahren für das Management einer Netzschnittstellenschaltungs-Flussdatenbank in Übereinstimmung mit einer Ausführungsform der Erfindung veranschaulicht.
  • 7 ist ein Ablaufplan, der ein Verfahren zum Verteilen der Verarbeitung der Netzpakete auf mehrere Prozessoren in einem Host-Computer in Übereinstim mung mit einer Ausführungsform der Erfindung veranschaulicht.
  • 8 ist ein Diagramm der Paketwarteschlange für eine Netzschnittstellenschaltung in Übereinstimmung mit einer Ausführungsform der Erfindung.
  • 9 ist ein Diagramm einer Steuerwarteschlange für eine Netzschnittstellenschaltung in Übereinstimmung mit einer Ausführungsform der Erfindung.
  • 10 ist ein Blockschaltplan einer DMA-Maschine zum Übertragen eines von einem Netz empfangenen Pakets an einen Host-Computer in Übereinstimmung mit einer Ausführungsform der Erfindung.
  • 11 enthält Diagramme von Datenstrukturen für das Management der Speicherung von Netzpaketen in Host-Speicherpuffern in Übereinstimmung mit einer Ausführungsform der Erfindung.
  • 12A–12B sind Diagramme eines Frei-Deskriptors, eines Abschluss-Deskriptors und eines Datenfelds freier Puffer in Übereinstimmung mit einer Ausführungsform der Erfindung.
  • 13 ist ein Diagramm eines dynamischen Paketstapel-Moduls in Übereinstimmung mit einer Ausführungsform der Erfindung.
  • 14A–14B enthalten einen Ablaufplan, der ein Verfahren zum dynamischen Durchsuchen eines Speichers veranschaulicht, der Informationen enthält, die Pakete betreffen, die auf die Übertragung zu einem Host-Computer warten, um ein Paket in dem gleichen Kommunikationsfluss wie ein Paket, das übertragen wird, zu ermitteln, in Übereinstimmung mit einer Ausführungsform der Erfindung.
  • 15 zeigt einen Satz dynamischer Befehle zum syntaktischen Analysieren eines Pakets in Übereinstimmung mit einer Ausführungsform der Erfindung.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Die folgende Beschreibung wird gegeben, um zu ermöglichen, dass irgendein Fachmann auf dem Gebiet die Erfindung herstellt und verwendet, wobei sie im Kontext besonderer Anwendungen der Erfindung und ihrer Anforderungen gebo ten wird. Verschiedene Änderungen an den offenbarten Ausführungsformen sind für den Fachmann auf dem Gebiet leicht sichtbar, wobei die hier definierten allgemeinen Prinzipien auf weitere Ausführungsformen und Anwendungen angewendet werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen. Somit soll die vorliegende Erfindung nicht auf die gezeigten Ausführungsformen beschränkt sein, sondern dem weitesten Umfang entsprechen, der mit den hier offenbarten Prinzipien und Merkmalen konsistent ist.
  • Insbesondere werden im Folgenden Ausführungsformen der Erfindung in Form einer Netzschnittstellenschaltung (NIC) beschrieben, die Kommunikationspakete empfängt, die in Übereinstimmung mit bestimmten mit dem Internet kompatiblen Kommunikationsprotokollen formatiert sind. Allerdings erkennt der Fachmann auf dem Gebiet, dass die vorliegende Erfindung nicht auf mit dem Internet kompatible Kommunikationsprotokolle beschränkt ist und leicht zur Verwendung mit anderen Protokollen und in anderen Kommunikationsvorrichtungen als einer NIC angepasst werden kann.
  • Die Programmumgebung, in der eine vorliegende Ausführungsform der Erfindung ausgeführt wird, enthält beispielhaft einen Universalcomputer oder eine Spezialvorrichtung wie etwa einen Handcomputer. Einzelheiten dieser Vorrichtungen (z. B. Prozessor, Speicher, Datenablage, Eingabe/Ausgabe-Ports und Anzeige) sind allgemein bekannt und werden aus Klarheitsgründen weggelassen.
  • Außerdem könnten die Techniken der vorliegenden Erfindung selbstverständlich unter Verwendung einer Vielzahl von Technologien implementiert werden. Zum Beispiel können die hier beschriebenen Verfahren in Software, die in einem programmierbaren Mikroprozessor ausgeführt wird, oder in Hardware, die entweder eine Kombination von Mikroprozessoren oder andere speziell konstruierte anwendungsspezifische integrierte Schaltungen, programmierbare Logikvorrichtungen oder verschiedene Kombinationen davon nutzt, implementiert werden. Insbesondere können die hier beschriebenen Verfahren durch eine Reihe von einem Computer ausführbarer Befehle implementiert werden, die sich in einem Speichermedium wie etwa einer Trägerwelle, einem Plattenlaufwerk oder einem anderen computerlesbaren Medium befinden.
  • Einleitung
  • In einer Ausführungsform der vorliegenden Erfindung ist eine Netzschnittstellenschaltung (NIC) so konfiguriert, dass sie zwischen einem Host-Computersystem und einem Netz wie etwa dem Internet ausgetauschte Kommunikationspakete empfängt und verarbeitet. Insbesondere ist die NIC so konfiguriert, dass sie Pakete empfängt und manipuliert, die in Übereinstimmung mit einem Protokollstapel (z. B. einer Kombination von Kommunikationsprotokollen) formatiert sind, der durch ein mit der NIC gekoppeltes Netz unterstützt wird.
  • Ein Protokollstapel kann in Bezug auf den Sieben-Schicht-ISO-OSI-Modellrahmen (Modellrahmen der International Standards Organization – Open Systems Interconnection) beschrieben werden. Somit enthält ein beispielhafter Protokollstapel in der Schicht vier das Transport Control Protocol (TCP), in der Schicht drei das Internet Protocol (IP) und in der Schicht zwei das Ethernet. Für Diskussionszwecke kann der Begriff "Ethernet" hier zur gemeinsamen Bezugnahme auf die genormte Spezifikation 802.3 des IEEE (Institute of Electrical and Electronics Engineers) sowie auf die Version zwei der nicht genormten Form des Protokolls verwendet werden. Wo verschiedene Formen des Protokolls unterschieden werden müssen, kann die Normform durch Aufnahme der Bezeichnung "802.3" identifiziert sein.
  • Weitere Ausführungsformen der Erfindung sind so konfiguriert, dass sie mit Nachrichten arbeiten, die sich an andere Protokolle, und zwar sowohl an solche, die derzeit bekannt sind (z. B. AppleTalk, IPX (Internetwork Packet Exchange) usw.), als auch an solche, die derzeit unbekannt sind, halten. Die durch diese Erfindung geschaffenen Verfahren sind leicht für neue Kommunikationsprotokolle anpassbar.
  • Außerdem kann die Verarbeitung der im Folgenden beschriebenen Pakete in anderen Kommunikationsvorrichtungen als einer NIC ausgeführt werden. Zum Beispiel können ein Modem, ein Switch, ein Router oder ein anderer Kommunikationsport oder eine andere Kommunikationsvorrichtung (z. B. seriell, parallel, USB, SCSI) ähnlich konfiguriert sein und betrieben werden.
  • In im Folgenden beschriebenen Ausführungsformen der Erfindung empfängt eine NIC im Auftrag eines Host-Computersystems oder einer anderen Kommunikati onsvorrichtung ein Paket von einem Netz. Die NIC analysiert das Paket (z. B. durch Wiedergewinnen bestimmter Felder aus einem oder mehreren seiner Protokollköpfe) und ergreift Maßnahmen, um die Effizienz zu erhöhen, mit der das Paket an seine Ziel-Entität übertragen oder geliefert wird. Die im Folgenden diskutierte Ausrüstung und die im Folgenden diskutierten Verfahren zum Erhöhen der Effizienz der Verarbeitung oder Übertragung von Paketen, die vom Netz empfangen werden, kann ebenfalls für Pakete verwendet werden, die sich in der entgegengesetzten Richtung (d. h. von der NIC zu dem Netz) bewegen.
  • Eine Technik, die auf ankommenden Netzverkehr angewendet werden kann, enthält das Untersuchen oder syntaktische Analysieren eines oder mehrerer Köpfe eines ankommenden Pakets (z. B. der Köpfe für die Protokolle der Schichten zwei, drei und vier), um die Quell- und Ziel-Entität des Pakets zu identifizieren und möglicherweise bestimmte weitere Informationen wiederzugewinnen. Unter Verwendung von Identifizierern der übermittelnden Entitäten als ein Schlüssel können Daten aus mehreren Paketen vereinigt oder wieder zusammengesetzt werden. Ein von einer Quell-Entität zu einer Ziel-Entität gesendetes Datagramm wird typisch über mehrere Pakete übertragen. Das Vereinigen von Daten von mehreren verwandten Paketen (z. B. Paketen, die Daten aus dem gleichen Datagramm übermitteln) ermöglicht somit, dass ein Datagramm wieder zusammengesetzt und kollektiv an einen Host-Computer übertragen wird. Daraufhin kann das Datagramm auf hocheffiziente Weise an die Ziel-Entität geliefert werden. Zum Beispiel kann eher, als Daten aus immer nur einem Paket (und immer nur ein Byte) in getrennten "Kopier"-Operationen zu liefern, eine "Seitenwechsel"-Operation ausgeführt werden. In einem Seitenwechsel kann, möglicherweise im Austausch für eine leere oder ungenutzte Seite, eine gesamte Speicherseite an Daten an die Ziel-Entität geliefert werden.
  • In einer weiteren Technik werden die von einem Netz empfangenen Pakete in einer Warteschlange angeordnet, damit sie auf die Übertragung an einen Host-Computer warten. Während sie auf die Übertragung warten, können mehrere verwandte Pakete für den Host-Computer identifiziert werden. Nachdem sie übertragen worden sind, können sie eher als eine Gruppe durch den Host-Prozessor als seriell (z. B. immer nur eines) verarbeitet werden.
  • Eine abermals weitere Technik betrifft das Einreichen einer Anzahl verwandter Pakete an einen einzelnen Prozessor eines Mehrprozessor-Host-Computersys tems. Dadurch, dass die zwischen verschiedenen Paaren von Quell- und Ziel-Entitäten beförderten Pakete auf verschiedene Prozessoren verteilt werden, kann die Verarbeitung der Pakete durch ihre jeweiligen Protokollstapel verteilt werden, während die Pakete weiter in ihrer richtigen Reihenfolge gehalten werden.
  • Die oben diskutierten Techniken zum Erhöhen der Effizienz, mit der Pakete verarbeitet werden, können eine Kombination aus Hardware- und Software-Modulen enthalten, die sich in einer Netzschnittstelle und/oder in einem Host-Computersystem befinden. In einer besonderen Ausführungsform analysiert ein Analysealgorithmus-Modul in einer NIC des Host-Computers syntaktisch die Kopfabschnitte der Pakete. Beispielhaft enthält das Analysealgorithmus-Modul ein Mikroprogrammwerk, das in Übereinstimmung mit einem Satz ersetzbarer Befehle arbeitet, die als Mikrocode gespeichert sind. Unter Verwendung von aus den Paketen extrahierten Informationen können mehrere Pakete von einer Quell-Entität zu einer Ziel-Entität identifiziert werden. Ein Hardware-Wiederzusammensetzungs-Modul in der NIC kann daraufhin die Daten von den mehreren Paketen sammeln. Ein weiteres Hardware-Modul in der NIC ist so konfiguriert, dass es verwandte Pakete, die auf die Übertragung zu dem Host-Computer warten, erkennt, so dass sie eher kollektiv als seriell durch einen geeigneten Protokollstapel verarbeitet werden können. Daraufhin können die wieder zusammengesetzten Daten und die Köpfe der Pakete an den Host-Computer geliefert werden, so dass geeignete Software (z. B. ein Gerätetreiber für die NIC) die Köpfe verarbeiten kann und die Daten an die Ziel-Entität liefern kann.
  • Wo der Host-Computer mehrere Prozessoren enthält, kann ein Lastverteiler (der ebenfalls in Hardware in der NIC implementiert sein kann) einen Prozessor zur Verarbeitung der Köpfe der mehreren Pakete durch einen Protokollstapel auswählen.
  • In einer weiteren Ausführungsform der Erfindung wird ein System geschaffen, um ein Paket von einer NIC willkürlich zu verwerfen, wenn die NIC mit Paketen, die auf die Übertragung zu einem Host-Computer warten, gesättigt oder nahezu gesättigt ist.
  • Eine Ausführungsform einer Hochleistungs-Netzschnittstellenschaltung
  • 1A zeigt eine NIC 100, die in Übereinstimmung mit einer beispielhaften Aus führungsform der Erfindung konfiguriert ist. Es folgt eine kurze Beschreibung des Betriebs und der Wechselwirkung der verschiedenen Module der NIC 100 in dieser Ausführungsform. In den nachfolgenden Abschnitten werden Beschreibungen gegeben, die ausführlichere Einzelheiten enthalten.
  • In der NIC 100 kann durch ein (in 1A nicht gezeigtes) Medienzugangssteuerungs-Modul (MAC-Modul) ein Kommunikationspaket vom Netz 102 empfangen werden. Das MAC-Modul führt die niedere Verarbeitung des Pakets wie etwa das Lesen des Pakets von dem Netz, das Ausführen einer gewissen Fehlerprüfung, das Erfassen von Paketfragmenten, das Erfassen von Jumbo-Paketen, das Entfernen der Schicht-Eins-Präambel usw. aus.
  • Daraufhin empfängt ein Eingangsportverarbeitungs-Modul (IPP-Modul) 104 das Paket. Das IPP-Modul speichert das gesamte Paket so, wie es von dem MAC-Modul oder vom Netz empfangen wurde, in einer Paketwarteschlange 116, wobei ein Abschnitt des Pakets in den Kopfanalysealgorithmus 106 kopiert wird. In einer Ausführungsform der Erfindung kann das IPP-Modul 104 als ein Koordinator von Sorten wirken, um das Paket auf die Übertragung zu einem Host-Computersystem vorzubereiten. In dieser Rolle kann das IPP-Modul 104 von verschiedenen Modulen der NIC 100 Informationen empfangen, die ein Paket betreffen, und diese Informationen an andere Module versenden.
  • Der Kopfanalysealgorithmus 106 analysiert einen Kopfabschnitt des Pakets syntaktisch, um verschiedene Informationsstücke wiederzugewinnen, die zum Identifizieren verwandter Pakete (z. B. mehrerer Pakete von einer gleichen Quell-Entität für eine Ziel-Entität) verwendet werden und die die nachfolgende Verarbeitung der Pakete beeinflussen. In der veranschaulichten Ausführungsform kommuniziert der Kopfanalysealgorithmus 106 mit dem Flussdatenbankmanager (FDBM) 108, der eine Flussdatenbank (FDB) 110 administriert. Insbesondere übergibt der Kopfanalysealgorithmus 106 an den FDBM 108 eine Anfrage, um zu bestimmen, ob zwischen der Quell-Entität, die ein Paket gesendet hat, und der Ziel-Entität ein (unten beschriebener) gültiger Kommunikationsfluss vorhanden ist. Die Ziel-Entität kann ein Anwendungsprogramm, ein Kommunikations-Modul oder ein anderes Element eines Host-Computersystems, das das Paket empfangen soll, enthalten.
  • In der veranschaulichten Ausführungsform der Erfindung enthält ein Kommunika tionsfluss eines oder mehrere Datagrammpakete von einer Quell-Entität zu einer Ziel-Entität. Ein Fluss kann durch einen Flussschlüssel identifiziert werden, der durch den Kopfanalysealgorithmus 106 aus dem Quellidentifizierer und aus dem Zielidentifizierer, die aus dem Paket wiedergewonnen werden, zusammengesetzt wird. In einer Ausführungsform der Erfindung enthält ein Flussschlüssel Adressen- und/oder Portinformationen für die Quell- und für die Ziel-Entität aus den Schicht-Drei-Protokollköpfen (z. B. IP) und/oder aus den Schicht-Vier-Protokollköpfen (z. B. TCP) des Pakets.
  • Für die veranschaulichte Ausführungsform der Erfindung ist ein Kommunikationsfluss ähnlich einer TCP-Ende-Ende-Verbindung, wobei er aber allgemein eine kürzere Dauer besitzt. Insbesondere kann die Dauer eines Flusses in dieser Ausführungsform auf die Zeit begrenzt sein, die zum Empfangen aller Pakete erforderlich ist, die einem einzelnen von der Quell-Entität an die Ziel-Entität übergebenen Datagramm zugeordnet sind.
  • Somit übergibt der Kopfanalysealgorithmus 106 für das Flussmanagement den Flussschlüssel des Pakets an den Flussdatenbankmanager 108. Außerdem kann der Kopfanalysealgorithmus andere das Paket betreffende Informationen, die aus dem Paket wiedergewonnen wurden (z. B. die Länge des Pakets), an den Flussdatenbankmanager liefern.
  • Der Flussdatenbankmanager 108 durchsucht in Reaktion auf eine vom Kopfanalysealgorithmus 106 empfangene Anfrage die FDB 110. Beispielhaft speichert die Flussdatenbank 110 Informationen, die jeden gültigen Kommunikationsfluss betreffen, an dem eine durch die NIC 100 bediente Ziel-Entität beteiligt ist. Somit aktualisiert der FDBM 108 die FDB 110 bei Bedarf je nach den von dem Kopfanalysealgorithmus 106 empfangenen Informationen. Außerdem ordnet der FDBM 108 in dieser Ausführungsform der Erfindung dem empfangenen Paket einen Operations- oder Aktionscode zu. Ein Operationscode kann verwendet werden, um zu identifizieren, ob ein Paket Teil eines neuen oder vorhandenen Flusses ist, ob das Paket Daten oder nur Steuerinformationen enthält, um die Datenmenge in dem Paket zu identifizieren, um zu identifizieren, ob die Paketdaten mit verwandten Daten (z. B. weiteren Daten in einem von der Quell-Entität an die Ziel-Entität gesendeten Datagramm) wieder zusammengesetzt werden können usw. Der FDBM 108 kann aus dem Paket wiedergewonnene und durch den Kopfanalysealgorithmus 106 gelieferte Informationen zur Auswahl eines geeigneten Operations codes verwenden. Daraufhin wird der Operationscode des Pakets zusammen mit einem Index des Flusses des Pakets innerhalb der FDB 110 an den Kopfanalysealgorithmus zurückgegeben.
  • In einer Ausführungsform der Erfindung kann die Kombination aus Kopfanalysealgorithmus 106, FDBM 108 und FDB 110 oder eine Teilmenge dieser Module wegen ihrer Rolle beim Klassifizieren oder Identifizieren des in der NIC 100 empfangenen Netzverkehrs als Verkehrsklassifizierer bekannt sein.
  • In der veranschaulichten Ausführungsform übergibt der Kopfanalysealgorithmus 106 den Flussschlüssel des Pakets außerdem an den Lastverteiler 112. In einem Host-Computersystem mit mehreren Prozessoren kann der Lastverteiler 112 bestimmen, zu welchem Prozessor ein ankommendes Paket zur Verarbeitung durch den richtigen Protokollstapel zu leiten ist. Der Lastverteiler 112 kann z. B. sicherstellen, dass verwandte Pakete zu einem einzelnen Prozessor geleitet werden. Dadurch, dass alle Pakete in einem Kommunikationsfluss oder in einer Ende-Ende-Verbindung zu einem einzelnen Prozessor gesendet werden, kann die richtige Reihenfolge der Pakete erzwungen werden. In einer alternativen Ausführungsform der Erfindung kann der Lastverteiler 112 weggelassen sein. In einer alternativen Ausführungsform kann der Kopfanalysealgorithmus 106 außerdem direkt mit anderen Modulen der NIC 100 neben dem Lastverteiler und dem Flussdatenbankmanager kommunizieren.
  • Nachdem der Kopfanalysealgorithmus 106 ein Paket syntaktisch analysiert hat, ändert oder aktualisiert somit der FDBM 108 die FDB 110, während der Lastverteiler 112 einen Prozessor in dem Host-Computersystem zum Verarbeiten des Pakets identifiziert. Nach diesen Aktionen gibt der Kopfanalysealgorithmus verschiedene Informationen an das IPP-Modul 104 zurück. Diese Informationen können beispielhaft den Flussschlüssel des Pakets, einen Index des Flusses des Pakets innerhalb der Flussdatenbank 110, einen Identifizierer eines Prozessors in dem Host-Computersystem und verschiedene andere das Paket betreffende Daten (z. B. seine Länge, eine Länge eines Paketkopfs) enthalten.
  • Nun kann das Paket in der Paketwarteschlange 116 gespeichert werden, die Pakete zur Manipulation durch die DMA-Maschine (Direktspeicherzugriffsmaschine) 120 hält und an einen Host-Computer überträgt. Außer dem Speichern des Pakets in einer Paketwarteschlange kann für das Paket ein entsprechender Eintrag in der Steuerwarteschlange 118 vorgenommen werden, wobei Informationen, die den Fluss des Pakets betreffen, außerdem an das dynamische Paketstapel-Modul 122 übergeben werden können. Die Steuerwarteschlange 118 enthält für jedes Paket in der Paketwarteschlange 116 verwandte Steuerinformationen.
  • Das Paketstapel-Modul 122 stützt sich auf Informationen, die die Pakete in der Paketwarteschlange 116 betreffen, um die Stapelverarbeitung (d. h. die kollektive Verarbeitung) der Köpfe von mehreren verwandten Paketen zu ermöglichen. In einer Ausführungsform der Erfindung warnt das Paketstapel-Modul 122 den Host-Computer über die Verfügbarkeit der Köpfe von verwandten Paketen, so dass sie kollektiv verarbeitet werden können.
  • Obgleich die Verarbeitung der Protokollköpfe eines Pakets in einer Ausführungsform der Erfindung durch einen Prozessor in einem Host-Computersystem ausgeführt wird, können die Protokollköpfe in einer weiteren Ausführungsform durch einen Prozessor verarbeitet werden, der sich in der NIC 100 befindet. In der ersteren Ausführungsform kann die Software in dem Host-Computer (z. B. ein Gerätetreiber für die NIC 100) die Vorteile zusätzlichen Speichers und eines ersetzbaren oder aktualisierbaren Prozessors genießen (z. B. kann der Speicher ergänzt werden und der Prozessor durch ein schnelleres Modell ersetzt werden).
  • Während der Speicherung eines Pakets in der Paketwarteschlange 116 kann der Prüfsummengenerator 114 eine Prüfsummenoperation ausführen. Die Prüfsumme kann als ein Nachsatz zu dem Paket zu der Paketwarteschlange hinzugefügt werden. Beispielhaft erzeugt der Prüfsummengenerator 114 eine Prüfsumme aus einem Abschnitt des vom Netz 102 empfangenen Pakets. In einer Ausführungsform der Erfindung wird eine Prüfsumme aus dem TCP-Abschnitt eines Pakets (z. B. aus dem TCP-Kopf und aus den TCP-Daten) erzeugt. Falls ein Paket nicht gemäß dem TCP-Protokoll formatiert ist, kann eine Prüfsumme an einem anderen Abschnitt des Pakets erzeugt werden und das Ergebnis bei Bedarf in der späteren Verarbeitung angepasst werden. Falls die durch den Prüfsummengenerator 114 berechnete Prüfsumme z. B. nicht an dem richtigen Abschnitt des Pakets berechnet wurde, kann die Prüfsumme angepasst werden, um den richtigen Abschnitt zu erfassen. Diese Anpassung kann durch Software, die in einem Host-Computersystem arbeitet, (z. B. durch einen Gerätetreiber) vorgenommen werden. In einer alternativen Ausführungsform der Erfindung kann der Prüfsummengenerator 114 weggelassen sein oder mit einem weiteren Modul der NIC 100 verschmolzen sein.
  • Aus den durch den Kopfanalysealgorithmus 106 erhaltenen Informationen und den durch den Flussdatenbankmanager 108 administrierten Flussinformationen kann das durch die NIC 100 bediente Host-Computersystem in der veranschaulichten Ausführungsform den Netzverkehr sehr effizient verarbeiten. Zum Beispiel können Datenabschnitte verwandter Pakete durch die DMA-Maschine 120 wieder zusammengesetzt werden, um Aggregationen zu bilden, die effizienter manipuliert werden können. Außerdem können die Daten durch Zusammensetzen der Daten in Puffer von der Größe einer Speicherseite durch "Seitenwechsel", in dem eine gesamte durch die DMA-Maschine 120 gefüllte Speicherseite gleichzeitig geliefert wird, effizienter zu einer Ziel-Entität übertragen werden. Somit kann ein Seitenwechsel den Platz mehrerer Kopieroperationen einnehmen. Währenddessen können die Kopfabschnitte der wieder zusammengesetzten Pakete durch ihren geeigneten Protokollstapel ähnlich als eine Gruppe verarbeitet werden.
  • Wie bereits beschrieben wurde, kann die Verarbeitung des Netzverkehrs durch geeignete Protokollstapel in einer weiteren Ausführungsform der Erfindung in einem Mehrprozessor-Host-Computersystem effizient verteilt werden. In dieser Ausführungsform weist der Lastverteiler 112 verwandte Pakete (z. B. Pakete in demselben Kommunikationsfluss) demselben Prozessor zu oder verteilt sie an denselben Prozessor. Insbesondere können Pakete mit der gleichen Quell- und Zieladresse in ihren Schicht-Drei-Protokollköpfen (z. B. IP-Köpfen) und/oder mit dem gleichen Quell- und Zielport in ihren Schicht-Vier-Protokollköpfen (z. B. TCP-Köpfen) an einen einzelnen Prozessor gesendet werden.
  • In der in 1A veranschaulichten NIC sind die oben diskutierten Verarbeitungsverbesserungen (z. B. Wiederzusammensetzen von Daten, Stapelverarbeitung von Paketköpfen, Verteilung der Protokollstapelverarbeitung) für vom Netz 102 empfangene Pakete möglich, die in Übereinstimmung mit einem oder mehreren im Voraus gewählten Protokollstapeln formatiert sind. In dieser Ausführungsform der Erfindung ist das Netz 102 das Internet und die NIC 100 somit so konfiguriert, dass sie Pakete unter Verwendung eines oder mehrerer Protokollstapel verarbeitet, die mit dem Internet kompatibel sind. Pakete, die nicht in Übereinstimmung mit den im Voraus gewählten Protokollen konfiguriert sind, werden ebenfalls verarbeitet, können aber nicht den vollen Umfang der Verarbeitungseffizienzen nutzen, die für Pakete bereitgestellt werden, die die im Voraus gewählten Protokolle erfüllen.
  • Zum Beispiel können Pakete, die nicht mit einem der im Voraus gewählten Protokollstapel übereinstimmen, zur Verarbeitung in einem Mehrprozessorsystem eher anhand der Schicht-Zwei-Quell- und Zieladresse (z. B. Medienzugangskontrolle) der Pakete als ihrer Schicht-Drei- oder Schicht-Vier-Adressen verteilt werden. Die Verwendung von Schicht-Zwei-Identifizierern liefert weniger Granularität für die Lastverteilungsprozedur, so dass die Verarbeitung der Pakete möglicherweise weniger gleichförmig verteilt wird, als w00enn die Schicht-Drei/Vier-Identifizierer verwendet würden.
  • 1B zeigt ein Verfahren der Verwendung der NIC 100 aus 1A zum Empfangen eines Pakets vom Netz 102 und zu dessen Übertragen an einen Host-Computer. Der Zustand 130 ist ein Startzustand, der möglicherweise durch die Initialisierung oder durch das Zurücksetzen der NIC 100 charakterisiert ist.
  • Im Zustand 132 wird durch die NIC 100 ein Paket vom Netz 102 empfangen. Wie bereits beschrieben wurde, kann das Paket in Übereinstimmung mit einer Vielzahl von Kommunikationsprotokollen formatiert sein. Das Paket kann durch ein MAC-Modul empfangen und anfangs manipuliert werden, bevor es an ein IPP-Modul übergeben wird.
  • Im Zustand 134 wird ein Abschnitt des Pakets kopiert und an den Kopfanalysealgorithmus 106 übergeben. Der Kopfanalysealgorithmus 106 analysiert das Paket daraufhin syntaktisch, um aus einem oder aus mehreren seiner Köpfe und/oder seiner Daten Werte zu extrahieren. Aus einigen der wiedergewonnenen Informationen wird ein Flussschlüssel erzeugt, um den Kommunikationsfluss zu identifizieren, der das Paket enthält. Der Grad oder Umfang, in dem das Paket syntaktisch analysiert wird, kann von seinen Protokollen abhängen, da der Kopfanalysealgorithmus so konfiguriert sein kann, dass er Köpfe verschiedener Protokolle in verschiedenen Tiefen syntaktisch analysiert. Insbesondere kann der Kopfanalysealgorithmus 106 für eine spezifische Menge von Protokollen oder Protokollstapeln optimiert sein (wobei z. B. seine Operationsbefehle für sie konfiguriert sein können). Falls das Paket zu einem oder zu mehreren der angegebenen Protokolle konform ist, kann es umfassender syntaktisch analysiert werden als ein Paket, das sich an keines der Protokolle hält.
  • Im Zustand 136 werden die aus dem Kopf des Pakets extrahierten Informationen an den Flussdatenbankmanager 108 und/oder an den Lastverteiler 112 weitergeleitet. Der FDBM verwendet die Informationen, um in der Flussdatenbank 110 einen Fluss aufzubauen, falls für diesen Kommunikationsfluss noch keiner vorhanden ist. Falls für den Fluss des Pakets bereits ein Eintrag vorhanden ist, kann er aktualisiert werden, so dass er den Empfang eines neuen Flusspakets widerspiegelt. Ferner erzeugt der FDBM 108 einen Operationscode, um eine oder mehrere Kenndaten oder Bedingungen des Pakets zusammenzufassen. Der Operationscode kann von anderen Modulen der NIC 100 verwendet werden, um das Paket auf geeignete Weise zu behandeln. Der Operationscode wird zusammen mit einem Index (z. B. einer Flussnummer) des Flusses des Pakets in der Flussdatenbank an den Kopfanalysealgorithmus zurückgegeben.
  • Falls der Host-Computer mehrere Prozessoren enthält, weist der Lastverteiler 112 dem Paket im Zustand 138 eine Prozessornummer zu und gibt die Prozessornummer an den Kopfprozessor zurück. Beispielhaft identifiziert die Prozessornummer, welcher Prozessor das Paket in dem Host-Computer durch seinen Protokollstapel führen soll. In einer alternativen Ausführungsform der Erfindung, insbesondere dann, wenn der Host-Computer nur aus einem einzelnen Prozessor besteht, kann der Zustand 138 weggelassen sein.
  • Im Zustand 140 wird das Paket in der Paketwarteschlange 116 gespeichert. Während der Inhalt des Pakets in der Paketwarteschlange angeordnet wird, kann der Prüfsummengenerator 114 eine Prüfsumme berechnen. Der Prüfsummengenerator kann durch das IPP-Modul 104 darüber informiert werden, an welchem Abschnitt des Pakets die Prüfsumme zu berechnen ist. Die berechnete Prüfsumme wird als ein Nachsatz zu dem Paket zu der Paketwarteschlange hinzugefügt. In einer Ausführungsform der Erfindung wird das Paket etwa zur gleichen Zeit in der Paketwarteschlange gespeichert, zu der eine Kopie eines Kopfabschnitts des Pakets an den Kopfanalysealgorithmus 106 geliefert wird.
  • Außerdem werden im Zustand 140 Steuerinformationen für das Paket in der Steuerwarteschlange 118 gespeichert, wobei Informationen, die den Fluss des Pakets betreffen,0 (z. B. die Flussnummer, der Flussschlüssel) an das dynamische Paketstapel-Modul 122 geliefert werden können.
  • Im Zustand 142 bestimmt die NIC 100, ob das Paket bereit ist, zum Host-Computerspeicher übertragen zu werden. Die veranschaulichte Prozedur wartet, bis es bereit ist, übertragen zu werden.
  • Wenn das Paket bereit ist, übertragen zu werden (z. B., wenn das Paket am Kopf der Paketwarteschlange ist oder wenn der Host-Computer das Paket vor diesem Paket in der Paketwarteschlange empfängt), bestimmt das dynamische Paketstapel-Modul 122 im Zustand 144, ob bald ein verwandtes Paket übertragen wird. Wenn es der Fall ist, wird der Host-Computer gewarnt, dass bald ein verwandtes Paket folgen wird, wenn das vorliegende Paket an den Host-Speicher übertragen wird. Daraufhin kann der Host-Computer die Pakete (z. B. durch ihren Protokollstapel) als eine Gruppe verarbeiten.
  • Im Zustand 146 wird das Paket (z. B. über eine Direktspeicherzugriffsoperation) an den Host-Computerspeicher übertragen. Außerdem wird der Host-Computer im Zustand 148 darüber informiert, dass das Paket übertragen wurde. Im Zustand 150 endet die veranschaulichte Prozedur.
  • Die oben beschriebene Prozedur ist nur ein Verfahren, die Module der NIC 100 dazu zu verwenden, ein einzelnes Paket von einem Netz zu empfangen und es an ein Host-Computersystem zu übertragen. Im Umfang der Erfindung werden außerdem weitere geeignete Verfahren betrachtet.
  • Ein beispielhaftes Paket
  • 2 ist ein Diagramm eines beispielhaften Pakets, das durch die NIC 100 vom Netz 102 empfangen wird. Das Paket 200 enthält einen Datenabschnitt 202 und einen Kopfabschnitt 204 und kann außerdem einen Nachsatzabschnitt 206 enthalten. Je nach der Netzumgebung, die das Paket 200 durchläuft, kann seine maximale Größe (z. B. seine größte Übertragungseinheit oder MTU) begrenzt sein.
  • In der veranschaulichten Ausführungsform enthält der Datenabschnitt 202 Daten, die innerhalb eines Computersystems (z. B. Anwender, Anwendungsprogramm, Betriebssystem) oder eines Kommunikationsteilsystems des Computers an eine Ziel-Entität oder empfangende Entität geliefert werden. Der Kopfabschnitt 204 enthält einen oder mehrere Köpfe, die dem Datenabschnitt durch die Quell-Entität oder Ursprungsentität oder durch ein Computersystem, das die Quell-Entität enthält, vorangestellt worden sind. Normalerweise entspricht jeder Kopf einem anderen Kommunikationsprotokoll.
  • In einer typischen Netzumgebung wie etwa dem Internet werden einzelne Köpfe innerhalb des Kopfabschnitts 204 angebracht (z. B. vorangestellt), während das Paket durch die verschiedenen Schichten eines Protokollstapels (z. B. einer Menge von Protokollen zur Kommunikation zwischen Entitäten) in dem sendenden Computersystem verarbeitet wird. Zum Beispiel zeigt 2 die Protokollköpfe 210, 212, 214 und 216, die den Schichten eins bis vier eines geeigneten Protokollstapels entsprechen. Jeder Protokollkopf enthält Informationen, die durch das empfangende Computersystem zu verwenden sind, während das Paket durch den Protokollstapel empfangen und verarbeitet wird. Schließlich wird jeder Protokollkopf entfernt und der Datenabschnitt 202 wiedergewonnen.
  • In einer Ausführungsform der Erfindung werden ein System und ein Verfahren zum syntaktischen Analysieren des Pakets 200 geschaffen, um verschiedene Bits an Informationen wiederzugewinnen. In dieser Ausführungsform wird das Paket 200 syntaktisch analysiert, um den Beginn des Datenabschnitts 202 zu identifizieren und einen oder mehrere Werte für Felder innerhalb des Kopfabschnitts 204 wiederzugewinnen. Beispielhaft entspricht allerdings der Schicht-Eins-Protokollkopf oder die Schicht-Eins-Präambel 210 einer Spezifikation der Hardwareebene, die mit der Codierung einzelner Bits zusammenhängt. Schicht-Eins-Protokolle werden allgemein lediglich für den physikalischen Prozess des Sendens oder Empfangs des Pakets über einen Leiter benötigt. Somit wird die Schicht-Eins-Präambel 210 in dieser Ausführungsform der Erfindung vom Paket 200 entfernt, kurz nachdem es durch die NIC 100 empfangen worden ist, und somit nicht syntaktisch analysiert.
  • Der Umfang, in dem der Kopfabschnitt 204 syntaktisch analysiert wird, kann davon abhängen, wie viele der in dem Kopfabschnitt repräsentierten Protokolle, falls überhaupt, mit einer Menge im Voraus gewählter Protokolle übereinstimmen. Zum Beispiel kann die Prozedur des syntaktischen Analysierens abgekürzt oder abgebrochen werden, wenn bestimmt worden ist, dass einer der Köpfe des Pakets einem nicht unterstützten Protokoll entspricht.
  • Insbesondere ist die NIC 100 in einer Ausführungsform der Erfindung hauptsächlich für Internetverkehr konfiguriert. Somit wird ein Paket 200 in dieser Ausführungsform nur dann umfassend syntaktisch analysiert, wenn das Schicht-Zwei- Protokoll das Ethernet (entweder das herkömmliche Ethernet oder das Ethernet 802.3 mit oder ohne Markierung virtueller lokaler Netze) ist, das Schicht-Drei-Protokoll das IP (Internet Protocol) ist und das Schicht-Vier-Protokoll das TCP (Transport Control Protocol) ist. Pakete, die sich an andere Protokolle halten, können in gewissem (z. B. geringerem) Umfang syntaktisch analysiert werden. Allerdings kann die NIC 100 so konfiguriert werden, dass sie praktisch den Kopf irgendeines Kommunikationsprotokolls unterstützt und syntaktisch analysiert. Beispielhaft sind die Protokollköpfe, die syntaktisch analysiert werden, und der Umfang, in dem sie syntaktisch analysiert werden, durch die Konfiguration eines Befehlssatzes für den Betrieb des Kopfanalysealgorithmus 106 bestimmt.
  • Wie oben beschrieben wurde, hängen die Protokolle, die den Köpfen 212, 214 und 216 entsprechen, von der Netzumgebung ab, in der ein Paket gesendet wird. Außerdem hängen die Protokolle von den kommunizierenden Entitäten ab. Zum Beispiel kann ein von einer Netzschnittstelle empfangenes Paket ein Steuerpaket sein, das zwischen den Medienzugangs-Controllern für das Quell- und für das Zielcomputersystem ausgetauscht wird. In diesem Fall enthält das Paket wahrscheinlich nur minimale oder keine Daten und möglicherweise keinen Schicht-Drei-Protokollkopf 214 oder Schicht-Vier-Protokollkopf 216. Steuerpakete werden typisch für verschiedene Zwecke in Bezug auf das Management einzelner Verbindungen verwendet.
  • Ein weiterer Kommunikationsfluss oder eine weitere Kommunikationsverbindung könnte zwei Anwendungsprogramme betreffen. In diesem Fall kann ein Paket wie in 2 gezeigt die Köpfe 212, 214 und 216 enthalten und außerdem zusätzliche Köpfe enthalten, die sich auf höhere Schichten eines Protokollstapels (z. B. auf die Kommunikationssteuerungsschicht, auf die Darstellungsschicht und auf die Anwendungsschicht im ISO-OSI-Modell) beziehen. Außerdem können einige Anwendungen Köpfe oder kopfähnliche Informationen innerhalb des Datenabschnitts 202 enthalten. Zum Beispiel kann der Datenabschnitt 202 für eine Network-File-System-Anwendung (NFS-Anwendung) NFS-Köpfe enthalten, die sich auf einzelne NFS-Datagramme beziehen. Ein Datagramm kann als eine Zusammenfassung von Daten definiert sein, die von einer Entität zu einer anderen gesendet werden, und kann Daten enthalten, die in mehreren Paketen übertragen werden. Mit anderen Worten, die Menge der Daten, die ein Datagramm bilden, kann größer sein als die Menge der Daten, die in einem Paket enthalten sein können.
  • Eine Ausführungsform eines Kopfanalysealgorithmus
  • 3 zeigt den Kopfanalysealgorithmus 106 aus 1A in Übereinstimmung mit einer vorliegenden Ausführungsform der Erfindung. Beispielhaft enthält der Kopfanalysealgorithmus 106 einen Kopfspeicher 302 und einen Analysealgorithmus 304, wobei der Analysealgorithmus 304 einen Befehlsspeicher 306 enthält. Obgleich der Kopfspeicher 302 und der Befehlsspeicher 306 in 3 als verschiedene Module gezeigt sind, sind sie in einer alternativen Ausführungsform der Erfindung zusammenhängend. Vorteilhaft sind die hier beschriebenen Verfahren zum syntaktischen Analysieren eines Pakets leicht für Pakete anpassbar, die in Übereinstimmung mit praktisch irgendeinem Kommunikationsprotokoll formatiert sind.
  • In der veranschaulichten Ausführungsform analysiert der Analysealgorithmus 304 einen im Kopfspeicher 302 gespeicherten Kopf syntaktisch in Übereinstimmung mit Befehlen, die im Befehlsspeicher 306 gespeichert sind. Wie oben diskutiert wurde, sind die Befehle zum syntaktischen Analysieren besonderer Protokolle oder eines besonderen Protokollstapels bestimmt. In einer Ausführungsform der Erfindung ist der Befehlsspeicher 306 modifizierbar (wobei der Speicher z. B. als RAM, EPROM, EEPROM oder dergleichen implementiert ist), so dass neue oder modifizierte Befehle zum syntaktischen Analysieren heruntergeladen oder auf andere Weise installiert werden können. Die Befehle zum syntaktischen Analysieren eines Pakets werden im folgenden Abschnitt weiter diskutiert.
  • In 3 wird ein Kopfabschnitt eines im (in 1A gezeigten) IPP-Modul 104 gespeicherten Pakets in den Kopfspeicher 302 kopiert. Beispielhaft werden eine spezifische Anzahl von Bytes (z. B. 114) zu Beginn des Pakets kopiert. In einer alternativen Ausführungsform der Erfindung kann der Abschnitt eines Pakets, der kopiert wird, eine andere Größe haben. Die besondere Menge eines in den Kopfspeicher 302 kopierten Pakets sollte ausreichend sein, um einen oder mehrere Protokollköpfe oder wenigstens ausreichend Informationen (z. B. gleich, ob in einem Kopf- oder Datenabschnitt des Pakets enthalten) zum Wiedergewinnen der im Folgenden beschriebenen Informationen zu erfassen. Der im Kopfspeicher 302 gespeicherte Kopfabschnitt braucht den Schicht-Eins-Kopf, der vor der oder in Verbindung mit der Verarbeitung des Pakets durch das IPP-Modul 104 entfernt worden ist, nicht zu enthalten.
  • Nachdem ein Kopfabschnitt des Pakets im Kopfspeicher 302 gespeichert worden ist, analysiert der Analysealgorithmus 304 den Kopfabschnitt syntaktisch in Übereinstimmung mit den im Befehlsspeicher 306 gespeicherten Befehlen. Die Befehle für den Betrieb des Analysealgorithmus 304 wenden in der derzeit beschriebenen Ausführungsform die Formate ausgewählter Protokolle an, um den Inhalt des Kopfspeichers 302 zu durchschreiten und spezifische Informationen wiederzugewinnen. Insbesondere sind die Spezifikationen der Kommunikationsprotokolle allgemein bekannt und umfassend verfügbar. Somit kann ein Protokollkopf durch Bezugnahme auf die Protokollspezifikationen byteweise oder auf andere Weise durchlaufen werden. Somit ist der Analysealgorithmus in einer vorliegenden Ausführungsform der Erfindung dynamisch, wobei die aus einem Feld eines Kopfs wiedergewonnenen Informationen häufig die Art und Weise ändern, in der ein weiterer Teil syntaktisch analysiert wird.
  • Zum Beispiel ist bekannt, dass das Typfeld eines Pakets, das sich an die herkömmliche Form des Ethernet (z. B. Version zwei) hält, bei dem dreizehnten Byte des (Schicht-Zwei-)Kopfs beginnt. Im Vergleich dazu beginnt das Typfeld eines Pakets, das der Version IEEE 802.3 des Ethernet folgt, bei dem einundzwanzigsten Byte des Kopfs. Falls das Paket einen Teil einer Nachricht eines Virtual Local Area Network (VLAN) bildet (was beispielhaft das Markieren oder Kapseln eines Ethernet-Kopfs betrifft), ist das Typfeld an nochmals anderen Plätzen. Somit werden in einer vorliegenden Ausführungsform der Erfindung die Werte in bestimmten Feldern wiedergewonnen und getestet, um sicherzustellen, dass die aus einem Kopf benötigten Informationen dem richtigen Abschnitt des Kopfs entnommen werden. Einzelheiten, die die Form eines VLAN-Pakets betreffen, sind in Spezifikationen für die Formen IEEE 802.3p und IEEE 802.3q des Ethernet-Protokolls zu finden.
  • Außerdem hängt der Betrieb des Kopfanalysealgorithmus 106 von weiteren Unterschieden zwischen den Protokollen wie etwa davon, ob das Paket Version vier oder Version sechs des Internet Protocol verwendet usw., ab. Spezifikationen für die Versionen vier und sechs des IP sind in den RFCs (Request For Comment) 791 bzw. 2460 der IETF (Internet Engineering Task Force) aufzufinden.
  • Je mehr Protokolle dem Analysealgorithmus 304 "bekannt" sind, auf desto mehr Protokolle kann ein Paket. getestet werden und desto komplizierter kann das syntaktische Analysieren des Kopfabschnitts eines Pakets werden. Die Protokolle, die durch den Analysealgorithmus 304 syntaktisch analysiert werden können, sind lediglich durch die Befehle beschränkt, in Übereinstimmungen mit denen er arbeitet. Somit können durch Ergänzen oder Ersetzen der im Befehlsspeicher 306 gespeicherten Befehle zum syntaktischen Analysieren durch den Kopfanalysealgorithmus 106 praktisch alle bekannten Protokolle behandelt werden und praktisch irgendwelche Informationen aus den Köpfen eines Pakets wiedergewonnen werden.
  • Natürlich kann die Operation des syntaktischen Analysierens abgeschlossen werden, wenn ein Paketkopf nicht zu einem erwarteten oder vermuteten Protokoll konform ist. In diesem Fall ist das Paket möglicherweise nicht für eine weitere der durch die NIC 100 gebotenen Effizienzverbesserungen (z. B. Datenwiederzusammensetzung, Paketstapelung, Lastverteilung) geeignet.
  • Beispielhaft werden die aus dem Kopf eines Pakets wiedergewonnenen Informationen bei der Verarbeitung dieses Pakets durch andere Abschnitte der NIC 100 verwendet. Zum Beispiel wird im Ergebnis der durch den Analysealgorithmus 304 ausgeführten syntaktischen Analyse des Pakets ein Flussschlüssel erzeugt, um den Kommunikationsfluss oder die Kommunikationsverbindung zu identifizieren, der/die das Paket enthält. Beispielhaft wird der Flussschlüssel dadurch zusammengesetzt, dass eine oder mehrere Adressen, die einer oder mehreren der kommunizierenden Entitäten entsprechen, verkettet werden. In einer vorliegenden Ausführungsform wird ein Flussschlüssel aus einer Kombination der Quell- und der Zieladresse, die dem IP-Kopf entnommen wird, und des Quell- und des Zielports, die dem TCP-Kopf entnommen werden, gebildet. Für andere Anwendungsdatagramme, die dem Datenabschnitt des Pakets entnommen werden, können andere Merkmale der kommunizierenden Entitäten wie etwa die Ethernet-Quelladresse und -Zieladresse (die dem Schicht-Zwei-Kopf entnommen werden), NFS-Dateikennungen oder Quell- und Zielidentifizierer verwendet werden.
  • Die kommunizierenden Entitäten können mit höherer Auflösung unter Verwendung von Merkmalen identifiziert werden, die den höheren Schichten des einem Paket zugeordneten Protokollstapels entnommen werden. Somit kann eine Kombination von IP- und TCP-Merkmalen die Entitäten mit größerer Eigenheit als die Schicht-Zwei-Informationen identifizieren.
  • Neben einem Flussschlüssel erzeugt der Analysealgorithmus 304 außerdem einen Steuer- oder Statusanzeiger, um zusätzliche Informationen in Bezug auf das Paket zusammenzufassen. In einer Ausführungsform der Erfindung enthält ein Steueranzeiger eine Folgenummer (z. B. die einem TCP-Kopf entnommene TCP-Folgenummer), um die richtige Reihenfolge der Pakete beim Wiederzusammensetzen ihrer Daten sicherzustellen. Außerdem kann der Steueranzeiger zeigen, ob bestimmte Merker in den Köpfen des Pakets gesetzt oder gelöscht sind, ob das Paket irgendwelche Daten enthält und, falls das Paket Daten enthält, ob die Daten eine bestimmte Größe überschreiten. Weitere Daten sind für die Aufnahme in den Steueranzeiger ebenfalls geeignet, wobei er lediglich durch die Informationen begrenzt ist, die in dem durch den Analysealgorithmus 304 syntaktisch analysierten Abschnitt des Pakets verfügbar sind.
  • In einer Ausführungsform der Erfindung liefert der Kopfanalysealgorithmus 106 den Flussschlüssel und den gesamten Steueranzeiger oder einen Abschnitt davon an den Flussdatenbankmanager 108. Wie in einem folgenden Abschnitt diskutiert wird, administriert der FDBM 108 eine Datenbank oder eine andere Datenstruktur, die Informationen enthält, die für durch die NIC 100 gehende Kommunikationsflüsse relevant sind.
  • In weiteren Ausführungsformen der Erfindung erzeugt der Analysealgorithmus 304 zusätzliche aus dem Kopf eines Pakets abgeleitete Informationen zur Verwendung durch andere Module der NIC 100. Zum Beispiel kann der Kopfanalysealgorithmus 106 den Versatz des Daten- oder Nutzinformationsabschnitts eines von einem Netz empfangenen Pakets vom Beginn des Pakets oder von einem anderen Punkt berichten. Wie oben beschrieben wurde, folgt der Datenabschnitt eines Pakets typisch auf den Kopfabschnitt, während auf ihn ein Nachsatzabschnitt folgen kann. Weitere Daten, die der Kopfanalyseabschnitt 106 berichten kann, enthalten den Platz in dem Paket, an dem eine Prüfsummenoperation beginnen sollte, den Platz in dem Paket, an dem die Schicht-Drei- und/oder Schicht-Vier-Köpfe beginnen, Diagnosedaten, Nutzinformationen usw. Der Begriff "Nutzinformationen" wird häufig zur Bezugnahme auf den Datenabschnitt eines Pakets verwendet. Insbesondere liefert der Kopfanalysealgorithmus 106 in einer Ausführungsform der Erfindung einen Nutzinformationsversatz und eine Nutzinformationsgröße an die Steuerwarteschlange 118.
  • Unter geeigneten Umständen kann der Kopfanalysealgorithmus 106 außerdem (z. B. an das IPP-Modul 104 und/oder an die Steuerwarteschlange 118) berichten, dass das Paket nicht in Übereinstimmung mit den Protokollen formatiert ist, zu deren Manipulation der Analysealgorithmus 304 konfiguriert ist. Dieser Bericht kann die Form eines Signals (z. B. des im Folgenden beschriebenen No_Assist-Signals), einer Warnung, eines Merkers oder eines anderen Anzeigers annehmen. Das Signal kann jedes Mal angehoben oder ausgegeben werden, wenn festgestellt wird, dass das Paket ein anderes Protokoll widerspiegelt als die im Voraus gewählten Protokolle, die mit den oben beschriebenen Verarbeitungsverbesserungen (z. B. Datenwiederzusammensetzung, Stapelverarbeitung von Paketköpfen, Lastverteilung) kompatibel sind. Zum Beispiel kann der Analysealgorithmus 304 in einer Ausführungsform der Erfindung so konfiguriert sein, dass er die Pakete unter Verwendung des TCP in der Schicht vier, des IP in der Schicht drei und des Ethernet in der Schicht zwei syntaktisch analysiert und effizient verarbeitet. In dieser Ausführungsform wird ein IPX-Paket (Internetwork-Packet-Exchange-Paket) nicht als kompatibel betrachtet, weshalb IPX-Pakete nicht zur Datenwiederzusammensetzung und Stapelverarbeitung gesammelt werden.
  • In einer Ausführungsform der Erfindung werden die verschiedenen oben beschriebenen Informationsstücke am Schluss des syntaktischen Analysierens an die richtigen Module der NIC 100 verteilt. Danach bestimmt der Flussdatenbankmanager 108 (wie auch in einem folgenden Abschnitt beschrieben ist), ob dem aus dem Paket abgeleiteten Flussschlüssel ein aktiver Fluss zugeordnet ist, wobei er einen in der nachfolgenden Verarbeitung zu verwendenden Operationscode einstellt. Außerdem sendet das IPP-Modul 104 das Paket an die Paketwarteschlange 116. Außerdem kann das IPP-Modul 104 einige der durch den Kopfanalysealgorithmus 106 extrahierten Informationen empfangen und sie an ein weiteres Modul der NIC 100 übergeben.
  • In der in 3 gezeigten Ausführungsform der Erfindung wird ein gesamter Kopfabschnitt eines empfangenen Pakets, das syntaktisch zu analysierend ist, kopiert und daraufhin in einer Entwicklung syntaktisch analysiert, wonach der Kopfanalysealgorithmus seine Aufmerksamkeit auf ein weiteres Paket richtet. Allerdings können in einer alternativen Ausführungsform an einem einzelnen Paket mehrere Operationen des Kopierens und/oder des syntaktischen Analysierens ausgeführt werden. Insbesondere kann in einer ersten Entwicklung ein Anfangskopfabschnitt des Pakets in den Kopfanalysealgorithmus 106 kopiert und durch ihn syntaktisch analysiert werden, wonach ein weiterer Kopfabschnitt in den Kopfanalysealgorithmus 106 kopiert und in einer zweiten Entwicklung syntaktisch analysiert werden kann. Ein Kopfabschnitt in einer Entwicklung kann sich teilweise oder vollständig mit dem Kopfabschnitt einer weiteren Entwicklung überschneiden. Auf diese Weise können selbst dann umfangreiche Köpfe syntaktisch analysiert werden, wenn der Kopfspeicher 302 eine beschränkte Größe hat. Ähnlich kann mehr als eine Operation erforderlich sein, um einen vollständigen Befehlssatz zum syntaktischen Analysieren eines Pakets in den Befehlsspeicher 306 zu laden. Beispielhaft kann ein erster Abschnitt der Befehle geladen und ausgeführt werden, wonach weitere Befehle geladen werden.
  • Nunmehr anhand der 4A–4B ist ein Ablaufplan dargestellt, der ein Verfahren veranschaulicht, mit dem ein Kopfanalysealgorithmus einen Kopfabschnitt eines Pakets, das in einer Netzschnittstellenschaltung von einem Netz empfangen worden ist, syntaktisch analysieren kann. In dieser Implementierung ist der Kopfanalysealgorithmus für das syntaktische Analysieren von Paketen, die zu einer Menge im Voraus gewählter Protokolle (oder Protokollstapel) konform sind, konfiguriert oder optimiert. Für Pakete, die diese Kriterien erfüllen, werden aus dem Kopfabschnitt verschiedene Informationen wiedergewonnen, um beim Wiederzusammensetzen der Datenabschnitte verwandter Pakete (z. B. Pakete, die Daten aus einem einzigen Datagramm enthalten) zu helfen. Weitere verbesserte Merkmale der Netzschnittstellenschaltung können ebenfalls ermöglicht werden.
  • Insbesondere enthalten die durch den Kopfanalysealgorithmus erzeugten Informationen einen Flussschlüssel, mit dem der Kommunikationsfluss oder die Kommunikationsverbindung identifiziert werden kann, der/die das empfangene Paket enthält. In einer Ausführungsform der Erfindung können Daten aus Paketen mit dem gleichen Flussschlüssel identifiziert und wieder zusammengesetzt werden, so dass sie ein Datagramm bilden. Außerdem können Köpfe von Paketen mit dem gleichen Flussschlüssel kollektiv durch ihren Protokollstapel (z. B. eher als seriell) verarbeitet werden.
  • In einer weiteren Ausführungsform der Erfindung werden die von dem Kopfanalysealgorithmus wiedergewonnenen Informationen außerdem verwendet, um die Verarbeitung des von einem Netz empfangenen Netzverkehrs zu verteilen. Zum Beispiel können mehrere Pakete mit dem gleichen Flussschlüssel an einen einzelnen Prozessor eines Mehrprozessor-Host-Computersystems eingereicht werden.
  • In dem in den 4A–4B veranschaulichten Verfahren entspricht die Menge der im Voraus gewählten Protokolle Kommunikationsprotokollen, die häufig über das Internet übertragen werden. Insbesondere enthält eine Menge von Protokollen, die in diesem Verfahren umfassend syntaktisch analysiert werden können, die Folgenden. In der Schicht zwei: Ethernet (herkömmliche Version), Ethernet 802.3, Ethernet-VLAN (Virtual Local Area Network) und Ethernet-VLAN 802.3. In der Schicht drei: IPv4 (ohne Optionen) und IPv6 (ohne Optionen). Schließlich werden in dem veranschaulichten Verfahren in der Schicht vier nur TCP-Protokollköpfe (mit oder ohne Optionen) syntaktisch analysiert. In alternativen Ausführungsformen der Erfindung analysieren Kopfanalysealgorithmen syntaktisch Pakete, die durch andere Protokollstapel formatiert worden sind. Insbesondere kann eine NIC in Übereinstimmung mit den häufigsten in einem gegebenen Netz verwendeten Protokollstapeln konfiguriert werden, die die mit dem in den 4A–4B veranschaulichten Kopfanalysealgorithmusverfahren kompatiblen Protokolle enthalten können oder nicht enthalten können.
  • Wie oben beschrieben wurde, kann ein empfangenes Paket, das nicht den durch ein gegebenes Verfahren syntaktisch analysierten Protokollen entspricht, gekennzeichnet werden und der Analysealgorithmus für dieses Paket abgeschlossen werden. Da die Protokolle, gemäß denen ein Paket formatiert worden ist, in dem vorliegenden Verfahren nur dadurch bestimmt werden können, dass bestimmte Kopffeldwerte untersucht werden, kann die Bestimmung, dass ein Paket nicht zu der gewählten Menge von Protokollen konform ist, praktisch jederzeit während der Prozedur vorgenommen werden. Somit besitzt das veranschaulichte Verfahren der syntaktischen Analyse als ein Ziel die Identifizierung von Paketen, die nicht die Formatierungskriterien für das Wiederzusammensetzen von Daten erfüllen.
  • Im Folgenden werden verschiedene Protokollkopffelder diskutiert, die in Köpfen für die gewählten Protokolle erscheinen. Kommunikationsprotokolle, die mit einer Ausführungsform der vorliegenden Erfindung kompatibel sein können (z. B. Protokolle, die durch einen Kopfanalysealgorithmus syntaktisch analysiert werden können) sind mit größerer Ausführlichkeit in einer Anzahl von Literaturhinweisen beschrieben. Sie brauchen deshalb hier nicht in aller Einzelheit betrachtet zu werden. Außerdem ist das veranschaulichte Verfahren des syntaktischen Analysierens eines Kopfabschnitts eines Pakets für die ausgewählten Protokolle lediglich ein Verfahren, um die im Folgenden beschriebenen Informationen zu sammeln. Weitere Sammelprozeduren, die hierzu fähig sind, sind gleichfalls geeignet.
  • In einer vorliegenden Ausführungsform der Erfindung ist die veranschaulichte Prozedur als eine Kombination aus Hardware und Software implementiert. Zum Beispiel können durch ein Mikroprogrammwerk aktualisierbare Mikrocodebefehle zum Ausführen der Prozedur ausgeführt werden. Alternativ können diese Befehle festgesetzt (z. B. in einem Nur-Lese-Speicher gespeichert) sein oder durch einen Prozessor oder Mikroprozessor ausgeführt werden.
  • In den 4A–4B ist der Zustand 400 ein Startzustand, während dessen durch die (in 1A gezeigte) NIC 100 ein Paket empfangen wird und die Anfangsverarbeitung ausgeführt wird. Für diese Prozedur ist die NIC 100 mit dem Internet gekoppelt. Die Anfangsverarbeitung kann eine Prüfung auf grundlegende Fehler und die Entfernung der Schicht-Eins-Präambel enthalten. Nach der Anfangsverarbeitung wird das Paket durch das (ebenfalls in 1A gezeigt) IPP-Modul 104 gehalten. In einer Ausführungsform der Erfindung enthält der Zustand 400 eine logische Schleife, in der der Kopfanalysealgorithmus in einem Leerlauf- oder Wartezustand bleibt, bis ein Paket empfangen wird.
  • Im Zustand 402 wird ein Kopfabschnitt des Pakets in den Speicher (z. B. in den Kopfspeicher 302 aus 3) kopiert. In einer vorliegenden Ausführungsform der Erfindung werden eine vorgegebene Anzahl von Bytes (z. B. 114 Bytes) zu Beginn des Pakets kopiert. In alternativen Ausführungsformen der Erfindung werden Paketabschnitte mit verschiedenen Größen kopiert, deren Größen von dem Ziel geleitet sind, genug von dem Paket zu kopieren, um die erforderlichen Kopfinformationen zu erfassen und/oder zu identifizieren. Beispielhaft wird das vollständige Paket durch das IPP-Modul 104 aufbewahrt, während die folgenden syntaktischen Analyseoperationen ausgeführt werden, obgleich das Paket alternativ vor Abschluss der syntaktischen Analyse in der Paketwarteschlange 116 gespeichert wird.
  • Außerdem kann im Zustand 402 ein Zeiger initialisiert werden, der beim syntaktischen Analysieren des Pakets zu verwenden ist. Da die Schicht-Eins-Präambel entfernt worden ist, sollte der in den Speicher kopierte Kopfabschnitt mit dem Schicht-Zwei-Protokollkopf beginnen. Somit wird der Zeiger anfangs beispielhaft so gesetzt, dass er auf das zwölfte Byte des Schicht-Zwei-Protokollkopfs zeigt, wobei der Zwei-Byte-Wert an der Stelle des Zeigers gelesen wird. Je nachdem, welches Protokoll die Schicht zwei des Protokollstapels des Pakets bildet, können diese zwei Bytes Teil einer Anzahl verschiedener Felder sein. Zum Beispiel können diese zwei Bytes das Typfeld eines herkömmlichen Ethernet-Kopfs, das Längenfeld eines 802.3-Ethernet-Kopfs oder das TPID-Feld (Tag-Protocol-IDentifier-Feld) eines VLAN-markierten Kopfs umfassen.
  • Im Zustand 404 wird eine erste Untersuchung des Schicht-Zwei-Kopfs vorgenommen, um zu bestimmen, ob er einen VLAN-markierten Schicht-Zwei-Protokollkopf enthält. Beispielhaft hängt diese Bestimmung davon ab, ob die zwei Bytes an der Zeigerstelle den Hexadezimalwert 8100 speichern. Wenn das der Fall ist, befindet sich der Zeiger wahrscheinlich in dem TPID-Feld eines VLAN-markierten Kopfs. Falls es kein VLAN-Kopf ist, geht die Prozedur zum Zustand 408 über.
  • Falls der Schicht-Zwei-Kopf dagegen ein VLAN-markierter Kopf ist, wird im Zustand 406 das CFI-Bit (Canonical-Format-Indicator-Bit) untersucht. Falls das CFI-Bit gesetzt ist (z. B. gleich eins ist), springt die veranschaulichte Prozedur zum Zustand 430, nach dem sie austritt. In dieser Ausführungsform der Erfindung zeigt das CFI-Bit, wenn es gesetzt ist, an, dass das Format des Pakets nicht mit den im Voraus gewählten Protokollen kompatibel ist (d. h. ihnen nicht entspricht) (dass z. B. das Schicht-Zwei-Protokoll nicht das Ethernet oder das 802.3-Ethernet ist). Falls das CFI-Bit gelöscht (z. B. gleich null ist), wird der Zeiger (z. B. um vier Bytes) inkrementiert, um ihn im nächsten Feld zu positionieren, das überprüft werden muss.
  • Im Zustand 408 wird der Schicht-Zwei-Kopf weiter geprüft. Obgleich jetzt bekannt ist, ob dies ein VLAN-markierter Kopf ist, kann der Kopf, je nachdem, ob der Zustand 408 über den Zustand 406 oder direkt vom Zustand 404 erreicht worden ist, entweder das herkömmliche Ethernet-Format oder das 802.3-Ethernet-Format widerspiegeln. Zu Beginn des Zustands 408 ist der Zeiger entweder im zwölften oder im sechzehnten Byte des Kopfs, die beide einem Längenfeld oder einem Typfeld entsprechen können. Insbesondere dann, wenn der Zwei-Byte-Wert an der durch den Zeiger identifizierten Stelle kleiner als 0600 (hexadezimal) ist, entspricht das Paket dem 802.3-Ethernet, wobei der Zeiger selbstverständlich ein Längenfeld identifiziert. Ansonsten ist das Paket ein herkömmliches Ethernet-Paket (z. B. der Version zwei), wobei der Zeiger ein Typfeld identifiziert.
  • Falls das Schicht-Zwei-Protokoll das 802.3-Ethernet ist, wird die Prozedur im Zustand 410 fortgesetzt. Falls das Schicht-Zwei-Protokoll das herkömmliche Ethernet ist, wird das Typfeld auf die Hexadezimalwerte 0800 und 08DD getestet. Falls das getestete Feld einen dieser Werte hat, ist außerdem bestimmt worden, dass das Schicht-Drei-Protokoll des Pakets das Internet Protocol ist. In diesem Fall wird die veranschaulichte Prozedur im Zustand 412 fortgesetzt. Falls das Feld schließlich ein Typfeld mit einem anderen Wert als 0800 oder 86DD (hexadezimal) ist, stimmt das Schicht-Drei-Protokoll das Pakets mit den im Voraus gewählten Protokollen, gemäß denen der Kopfanalysealgorithmus konfiguriert wurde, überein. Somit wird die Prozedur im Zustand 430 fortgesetzt und endet daraufhin.
  • In einer Ausführungsform der Erfindung wird das Paket im Zustand 408 untersucht, um zu bestimmen, ob es ein Jumbo-Ethernet-Rahmen ist. Diese Bestimmung würde wahrscheinlich vor der Entscheidung vorgenommen, ob der Schicht-Zwei-Kopf zum Ethernet oder zum 802.3-Ethernet konform ist. Beispielhaft kann die Bestimmung des Jumbo-Rahmens anhand der Größe des Pakets vorgenommen werden, die durch das IPP-Modul 104 oder durch ein MAC-Modul berichtet werden kann. Falls das Paket ein Jumbo-Rahmen ist, kann die Prozedur im Zustand 410 fortgesetzt werden; ansonsten kann sie im Zustand 412 wieder aufgenommen werden.
  • Im Zustand 410 überprüft die Prozedur, dass das Schicht-Zwei-Protokoll das 802.3-Ethernet mit einer LLC-SNAP-Kapselung ist. Insbesondere wird der Zeiger (z. B. um zwei Bytes) vorgerückt und der auf das Längenfeld in dem Schicht-Zwei-Kopf folgende Sechs-Byte-Wert wiedergewonnen und untersucht. Falls der Kopf ein 802.3-Ethernet-Kopf ist, ist das Feld das LLC_SNAP-Feld, das einen Wert AAAA03000000 (hexadezimal) haben sollte. Die Originalspezifikation für einen LLC-SNAP-Kopf ist in der Spezifikation für IEEE 802.2 zu finden. Falls der Wert in dem LLC_SNAP-Feld des Pakets mit dem erwarteten Wert übereinstimmt, wird der Zeiger weitere sechs Bytes inkrementiert, das Zwei-Byte-802.3-Ethernet-Typfeld gelesen und die Prozedur im Zustand 412 fortgesetzt. Falls die Werte nicht übereinstimmen, ist das Paket nicht zu den angegebenen Protokollen konform, wobei die Prozedur in den Zustand 430 eintritt und daraufhin endet.
  • Im Zustand 412 wird der Zeiger (z. B. um weitere zwei Bytes) vorgerückt, um den Beginn des Schicht-Drei-Protokollkopfs zu lokalisieren. Diese Zeigerstellung kann zur späteren Verwendung beim schnellen Identifizieren des Beginns des Kopfs gesichert werden. Nun ist bekannt, dass das Paket zu einem akzeptierten Schicht-Zwei-Protokoll (z. B. herkömmliches Ethernet, Ethernet mit VLAN-Markierung oder 802.3-Ethernet mit LLC-SNAP) konform ist, wobei es nun geprüft wird, um sicherzustellen, dass das Schicht-Drei-Protokoll des Pakets das IP ist. Wie oben diskutiert wurde, werden in der veranschaulichten Ausführungsform lediglich solche Pakete umfassend durch den Kopfanalysealgorithmus verarbeitet, die zu dem IP-Protokoll konform sind.
  • Falls der Wert des Typfelds in dem (im Zustand 402 oder im Zustand 410 wiedergewonnenen) Schicht-Zwei-Kopf 0800 (hexadezimal) ist, wird beispielhaft erwartet, dass das Schicht-Drei-Protokoll das IP, Version vier, ist. Falls der Wert 86DD (hexadezimal) ist, wird erwartet, dass das Schicht-Drei-Protokoll das IP, Version sechs, ist. Somit wird im Zustand 412 das Typfeld geprüft, wobei die Prozedur je nachdem, ob der hexadezimale Wert 0800 oder 86DD ist, im Zustand 414 oder im Zustand 418 fortgesetzt wird.
  • Im Zustand 414 wird die Konformität des Schicht-Drei-Kopfs mit Version vier des IP überprüft. In einer Ausführungsform der Erfindung wird das Versionsfeld des Schicht-Drei-Kopfs getestet, um sicherzustellen, dass es den hexadezimalen Wert 4 enthält, der der Version vier des IP entspricht. Falls im Zustand 414 bestätigt wird, dass der Schicht-Drei-Kopf die IP-Version vier ist, wird die Prozedur im Zustand 416 fortgesetzt; andernfalls geht die Prozedur zum Zustand 430 über und endet daraufhin im Zustand 432.
  • Im Zustand 416 werden verschiedene Informationsstücke aus dem IP-Kopf gesichert. Diese Informationen können die IHL (IP-Kopflänge), die Gesamtlänge, das Protokoll- und/oder das Fragmentversatzfeld enthalten. Die IP-Quelladresse und die IP-Zieladresse können ebenfalls gespeichert werden. Der Quelladressenwert und der Zieladressenwert sind in Version vier des IP jeweils vier Bytes lang. Diese Adressen werden wie oben beschrieben verwendet, um einen Flussschlüssel zu erzeugen, der den Kommunikationsfluss identifiziert, in dem das Paket gesendet wurde. Das Gesamtlängenfeld speichert die Größe des IP-Segments dieses Pakets, das beispielhaft den IP-Kopf, den TCP-Kopf und den Datenabschnitt des Pakets enthält. Die TCP-Segmentgröße des Pakets (z. B. die Größe des TCP-Kopfs zuzüglich der Größe des Datenabschnitts des Pakets) kann dadurch berechnet werden, dass von dem Gesamtlängenwert zwanzig Bytes (die Größe des Kopfs der IP-Version vier) subtrahiert werden. Nach Zustand 416 rückt die veranschaulichte Prozedur zum Zustand 422 vor.
  • Im Zustand 418 wird die Konformität des Schicht-Drei-Kopfs mit Version sechs des IP überprüft, indem das Versionsfeld auf den Hexadezimalwert 6 getestet wird. Falls das Versionsfeld diesen Wert nicht enthält, geht die veranschaulichte Prozedur zum Zustand 430 über.
  • Im Zustand 420 werden die Werte der Nutzdatenlänge (z. B. die Größe des TCP-Segments) und das Nächster-Kopf-Feld zuzüglich der IP-Quelladresse und der IP-Zieladresse gesichert. Die Quelladresse und die Zieladresse sind in Version sechs des IP jeweils sechzehn Bytes lang.
  • Im Zustand 422 der veranschaulichten Prozedur wird bestimmt, ob der IP-Kopf (entweder Version vier oder Version sechs) anzeigt, dass der Schicht-Vier-Kopf TCP ist. Beispielhaft wird das Protokollfeld eines Version-Vier-IP-Kopfs getestet, während das Nächster-Kopf-Feld eines Version-Sechs-Kopfs getestet wird. Auf jeden Fall sollte der Wert 6 (hexadezimal) sein. Daraufhin wird der Zeiger gegebenenfalls inkrementiert (z. B. zwanzig Bytes für IP-Version vier, vierzig Bytes für IP-Version sechs), um den Beginn des TCP-Kopfs zu erreichen. Falls im Zustand 422 bestimmt wird, dass der Schicht-Vier-Kopf nicht TCP ist, rückt die Prozedur zum Zustand 430 vor und endet im Endzustand 432.
  • In einer Ausführungsform der Erfindung können im Zustand 422 andere Felder eines Version-Vier-IP-Kopfs getestet werden, um sicherzustellen, dass das Paket die Kriterien für die verbesserte Verarbeitung durch die NIC 100 erfüllt. Zum Beispiel zeigt ein anderer IHL-Feldwert als 5 (hexadezimal) an, dass die IP-Optionen für dieses Paket gesetzt sind, wobei die syntaktische Analyseoperation in diesem Fall abgebrochen wird. Ein anderer Fragmentierungsfeldwert als null zeigt an, dass das IP-Segment des Pakets ein Fragment ist, in welchem Fall die syntaktische Analyse ebenfalls abgebrochen wird. Auf jeden Fall springt die Prozedur zum Zustand 430 und endet daraufhin im Endzustand 432.
  • Im Zustand 424 wird der TCP-Kopf des Pakets syntaktisch analysiert, wobei verschiedene Daten von ihm gesammelt werden. Insbesondere werden der TCP-Quellportwert und der TCP-Zielportwert gesichert. Die TCP-Folgenummer, die verwendet wird, um die richtige Wiederzusammensetzung der Daten aus mehre ren Paketen sicherzustellen, wird ebenfalls gesichert. Ferner werden die Werte mehrerer Komponenten des Merkerfelds – beispielhaft das URG-Bit (Dringend-Bit), das PSH-Bit (Schiebe-Bit), das RST-Bit (Rücksetzbit), das SYN-Bit (Synch-Bit) und das FIN-Bit (Abschlussbit) – gesichert. In einer Ausführungsform der Erfindung signalisieren diese Merker verschiedene auszuführende Aktionen oder verschiedene bei der Behandlung des Pakets zu betrachtende Status.
  • Im Zustand 424 können andere Signale oder Status erzeugt werden, die die von dem TCP-Kopf empfangenen Informationen widerspiegeln. Zum Beispiel kann der Punkt gesichert werden, von dem eine Prüfsummenoperation beginnen soll (beispielhaft der Beginn des TCP-Kopfs); wobei der Endpunkt einer Prüfsummenoperation ebenfalls gesichert werden kann (beispielhaft das Ende des Datenabschnitts des Pakets). Durch Multiplizieren des Werts des Kopflängenfelds des TCP-Kopfs mit vier kann ein Versatz zu dem Datenabschnitt des Pakets identifiziert werden. Daraufhin kann durch Subtrahieren des Versatzes zu dem Datenabschnitt von der Größe des gesamten TCP-Segments die Größe des Datenabschnitts berechnet werden.
  • Im Zustand 426 wird durch Verketten der IP-Quelladresse und der IP-Zieladresse sowie des TCP-Quellports und des TCP-Zielports ein Flussschlüssel zusammengesetzt. Wie bereits beschrieben wurde, kann der Flussschlüssel verwendet werden, um einen Kommunikationsfluss oder eine Kommunikationsverbindung zu identifizieren, wobei er von anderen Modulen der NIC 100 verwendet werden kann, um den Netzverkehr effizienter zu verarbeiten. Obgleich sich die Größen der Quelladresse und der Zieladresse zwischen den IP-Versionen vier und sechs unterscheiden (z. B. jeweils vier Bytes bzw. sechzehn Bytes), haben in der derzeit beschriebenen Ausführungsform der Erfindung alle Flussschlüssel eine einheitliche Größe. Insbesondere sind sie in dieser Ausführungsform einschließlich des Zwei-Byte-TCP-Quellports und des Zwei-Byte-TCP-Zielports sechsunddreißig Bytes lang. Flussschlüssel, die aus Paketköpfen des IP, Version vier, erzeugt werden, werden bei Bedarf (z. B. mit vierundzwanzig Leerbytes) aufgefüllt, um den zugeordneten Platz des Flussschlüssels zu füllen.
  • Im Zustand 428 wird ein Steuerungs- oder Statusanzeiger zusammengesetzt, um verschiedene Informationen an eines oder an mehrere Module der NIC 100 zu liefern. In einer Ausführungsform der Erfindung enthält ein Steueranzeiger die TCP-Folgenummer des Pakets, einen Merker oder Identifizierer (z. B. eines oder mehrere Bits), der anzeigt, ob das Paket Daten enthält (z. B., ob die TCP-Nutzinformationsgröße größer als null ist), einen Merker, der anzeigt, ob der Datenabschnitt des Pakets eine im Voraus bestimmte Größe übersteigt, und einen Merker, der anzeigt, ob bestimmte Einträge in dem TCP-Merkerfeld im Voraus bestimmten Werten gleichwertig sind. Der letztere Merker kann z. B. dazu verwendet werden, ein weiteres Modul der NIC 100 darüber zu informieren, dass Komponenten des Merkerfelds eine besondere Konfiguration haben oder nicht. Nach dem Zustand 428 endet die veranschaulichte Prozedur mit dem Zustand 432.
  • In den Zustand 430 kann an mehreren verschiedenen Punkten der veranschaulichten Prozedur eingetreten werden. Zum Beispiel wird in diesen Zustand eingetreten, wenn bestimmt wird, dass ein Kopfabschnitt, der durch einen Kopfanalysealgorithmus syntaktisch analysiert wird, nicht konform zu den oben identifizierten im Voraus gewählten Protokollstapeln ist. Im Ergebnis wird viel von den oben beschriebenen Informationen nicht wiedergewonnen. Eine praktische Folge der Unfähigkeit, diese Informationen wiederzugewinnen, ist, dass sie daraufhin nicht an andere Module der NIC 100 geliefert werden können und die hier beschriebene verbesserte Verarbeitung für dieses Paket nicht ausgeführt werden kann. Insbesondere können in der vorliegenden Ausführungsform der Erfindung, wie auch zuvor diskutiert wurde, an syntaktisch analysierten Paketen eine oder mehrere verbesserte Operationen ausgeführt werden, um die Effizienz zu erhöhen, mit der sie verarbeitet werden. Beispielhafte Operationen, die angewendet werden können, enthalten das Wiederzusammensetzen von Daten aus verwandten Paketen (z. B. aus Paketen, die Daten aus einem einzelnen Datagramm enthalten), die Stapelverarbeitung von Paketköpfen durch einen Protokollstapel, die Lastverteilung oder den Lastverbund der Protokollstapelverarbeitung, die effiziente Übertragung von Paketdaten an eine Ziel-Entität usw.
  • In der veranschaulichten Prozedur wird im Zustand 430 ein Merker oder Signal (beispielhaft als No_Assist bezeichnet) gesetzt oder gelöscht, um anzuzeigen, dass das derzeit vom IPP-Modul 104 gehaltene Paket (z. B. das, das gerade durch den Kopfanalysealgorithmus verarbeitet wird) zu keinem der im Voraus gewählten Protokollstapel konform ist. Auf diesen Merker oder auf dieses Signal kann sich ein anderes Modul der NIC 100 stützen, wenn es entscheidet, ob eine der verbesserten Operationen auszuführen ist.
  • Im Zustand 430 kann ein weiterer Merker oder ein weiteres Signal gesetzt oder gelöscht werden, um einen Prüfsummenparameter zu initialisieren, der anzeigt, dass eine Prüfsummenoperation, falls sie ausgeführt wird, zu Beginn des Pakets (z. B. ohne Versatz in das Paket) ausgeführt werden sollte. Beispielhaft können inkompatible Pakete nicht syntaktisch analysiert werden, um einen geeigneteren Punkt zu bestimmen, von dem die Prüfsummenoperation beginnen soll. Nach dem Zustand 430 endet die Prozedur mit dem Endzustand 432.
  • Nach dem syntaktischen Analysieren eines Pakets kann der Kopfanalysealgorithmus die von dem Paket erzeugten Informationen an eines oder mehrere Module der NIC 100 verteilen. Zum Beispiel wird der Flussschlüssel in einer Ausführungsform der Erfindung an den Flussdatenbankmanager 108, an den Lastverteiler 112 und an die Steuerwarteschlange 118 und/oder an die Paketwarteschlange 116 geliefert. Beispielhaft wird der Steueranzeiger an den Flussdatenbankmanager 108 geliefert. Diese und weitere Steuerinformationen wie etwa die TCP-Nutzinformationsgröße, der TCP-Nutzinformationsversatz und das No_Assist-Signal können an das IPP-Modul 104 zurückgegeben und an die Steuerwarteschlange 118 geliefert werden. An das IPP-Modul 104, an die Paketwarteschlange 116 und/oder an die Steuerwarteschlange 118 können nochmals zusätzliche Steuer- und/oder Diagnoseinformationen wie etwa Versätze zu dem Schicht-Drei- und/oder Schicht-Vier-Kopf geliefert werden. An den Prüfsummengenerator 114 können Prüfsummeninformationen (z. B. ein Startpunkt und entweder ein Endpunkt oder eine andere Einrichtung zum Identifizieren eines Abschnitts des Pakets, von dem eine Prüfsumme zu berechnen ist) geliefert werden.
  • Nachdem ein empfangenes Paket in der NIC 100 (z. B. durch den Kopfanalysealgorithmus 106) syntaktisch analysiert worden ist, werden die Pakete in der veranschaulichten Ausführungsform der Erfindung in dem Host-Computersystem (z. B. durch ihre jeweiligen Protokollstapel) weiter verarbeitet. Allerdings führt die NIC 100 in einer alternativen Ausführungsform der Erfindung außerdem eine oder mehrere nachfolgende Verarbeitungsschritte aus, nachdem ein Paket syntaktisch analysiert worden ist. Zum Beispiel kann die NIC 100 einen oder mehrere Protokollprozessoren zur Verarbeitung eines oder mehrerer Protokollköpfe des Pakets enthalten.
  • Befehle zum dynamischen syntaktischen Analysieren des Kopfs in einer Ausführungsform der Erfindung
  • In einer Ausführungsform der vorliegenden Erfindung analysiert der Kopfanalysealgorithmus 106 ein von einem Netz empfangenes Paket gemäß einer dynamischen Befehlsfolge. Die Befehle können im Befehlsspeicher (z. B. RAM, SRAM, DRAM, Flash) des Kopfanalysealgorithmus gespeichert werden, der umprogrammierbar ist oder auf andere Weise mit neuen oder zusätzlichen Befehlen aktualisiert werden kann. In einer Ausführungsform der Erfindung kann Software, die in einem Host-Computer arbeitet, (z. B. ein Gerätetreiber) einen Satz von syntaktischen Analysebefehlen zur Speicherung in dem Speicher des Kopfanalysealgorithmus herunterladen.
  • Die Anzahl und das Format der in einem Befehlsspeicher des Kopfanalysealgorithmus gespeicherten Befehle können an eines/einen oder an mehrere spezifische Protokolle oder Protokollstapel angepasst werden. Somit kann ein für eine Zusammenstellung von Protokollen konfigurierter Befehlssatz oder ein aus dem Befehlssatz konstruiertes Programm durch einen anderen Befehlssatz oder durch ein anderes Programm aktualisiert oder ersetzt werden. Für bei der Netzschnittstelle empfangene Pakete, die in Übereinstimmung mit den gewählten Protokollen formatiert sind, (z. B. "kompatible" Pakete), wie sie durch Analysieren oder syntaktisches Analysieren der Pakete bestimmt werden, werden wie hier beschrieben verschiedene Verbesserungen in der Behandlung des Netzverkehrs möglich. Insbesondere können Pakete aus einem Datagramm, die in Übereinstimmung mit einem gewählten Protokoll konfiguriert sind, in einem Host-Computer zur effizienten Übertragung wieder zusammengesetzt werden. Außerdem können die Kopfabschnitte dieser Pakete eher kollektiv als seriell verarbeitet werden. Außerdem kann die Verarbeitung der Pakete aus verschiedenen Datagrammen durch einen Mehrprozessor-Host-Computer unter den Prozessoren kollektiv ausgeführt oder verteilt werden. Somit ist es ein Ziel einer dynamischen syntaktischen Kopfanalyseoperation, ein Protokoll zu identifizieren, in Übereinstimmung mit dem ein empfangenes Paket formatiert worden ist, oder zu bestimmen, ob ein Paketkopf zu einem besonderen Protokoll konform ist.
  • Die in Kürze ausführlich diskutierte 15 stellt eine beispielhafte Reihe von Befehlen zum syntaktischen Analysieren der Schicht-Zwei-, Schicht-Drei- und Schicht-Vier-Köpfe eines Pakets dar, um zu bestimmen, ob sie Ethernet, IP oder TCP sind. Die veranschaulichten Befehle enthalten ein mögliches Programm oder einen möglichen Mikrocode zum Ausführen einer syntaktischen Analyseoperation. Nachdem ein besonderer Satz von syntaktischen Analysebefehlen in einen Analysealgorithmusspeicher geladen worden ist, können eine Anzahl verschiedener Programme zusammengesetzt werden. Somit stellt 15 lediglich eines aus einer Anzahl von Programmen dar, die aus den gespeicherten Befehlen erzeugt werden können. Die in 15 dargestellten Befehle können durch ein Mikroprogrammwerk, durch einen Prozessor, durch einen Mikroprozessor oder durch ein anderes, ähnliches Modul, das sich innerhalb einer Netzschnittstellenschaltung befindet, ausgeführt oder durchgeführt werden.
  • Insbesondere können für verschiedene Kommunikationsprotokolle andere Befehlssätze und andere Programme abgeleitet werden und auf andere Schichten eines Protokollstapels erweitert werden. Zum Beispiel könnte ein Befehlssatz zum syntaktischen Analysieren von NFS-Paketen (Network-File-System-Paketen) erzeugt werden. Beispielhaft wären diese Befehle so konfiguriert, dass sie Schicht-Fünf- und Schicht-Sechs-Köpfe syntaktisch analysieren, um zu bestimmen, ob sie ein entfernter Prozeduraufruf (RPC) bzw. eine externe Datendarstellung (XDR) sind. Andere Befehle könnten so konfiguriert sein, dass sie einen Abschnitt der Daten des Pakets syntaktisch analysieren (was als Schicht sieben betrachtet werden kann). Ein NFS-Kopf kann als ein Teil des Schicht-Sechs-Protokollkopfs des Pakets oder als ein Teil der Daten des Pakets betrachtet werden.
  • Ein Typ eines durch ein Mikroprogrammwerk ausgeführten Befehls kann so konstruiert sein, dass er ein besonderes Feld eines Pakets (z. B. an einem spezifischen Versatz innerhalb des Pakets) auffindet und den an diesem Versatz gespeicherten Wert mit einem Wert vergleicht, der diesem Feld in einem besonderen Kommunikationsprotokoll zugeordnet ist. Zum Beispiel kann ein Befehl erfordern, dass das Mikroprogrammwerk einen Wert in einem Paketkopf an einem Versatz untersucht, der einem Typfeld eines Ethernet-Kopfs entspricht. Durch Vergleich des tatsächlich in dem Paket gespeicherten Werts mit dem für das Protokoll erwarteten Wert kann das Mikroprogrammwerk bestimmen, ob das Paket zu dem Ethernet-Protokoll konform zu sein scheint. Beispielhaft hängt der nächste in dem syntaktischen Analyseprogramm angewendete Befehl davon ab, ob der vorangehende Vergleich erfolgreich war. Somit hängen die besonderen durch das Mikroprogrammwerk angewendeten Befehle und die Folge, in der sie angewendet werden, davon ab, welche Protokolle durch die Köpfe des Pakets repräsentiert werden.
  • Das Mikroprogrammwerk kann innerhalb jedes in einem Paket enthaltenen Kopfs einen oder mehrere Feldwerte testen. Je mehr Felder getestet werden, von denen festgestellt wird, dass sie sich mit dem Format eines bekannten Protokolls vereinbaren lassen, desto höher ist die Wahrscheinlichkeit, dass das Paket zu diesem Protokoll konform ist. Ein Kommunikationsprotokoll kann recht verschieden von einem anderen Protokoll sein und somit für verschiedene Protokolle die Untersuchung verschiedener Teile der Paketköpfe erfordern. Beispielhaft kann das syntaktische Analysieren eines Pakets im Fall eines Fehlers oder da bestimmt wurde, dass das Paket, das syntaktisch analysiert wird, nicht konform zu dem Protokoll bzw. zu den Protokollen ist, für das/die die Befehle bestimmt ist/sind, enden.
  • Jeder Befehl in 15 kann durch eine Zahl und/oder einen Namen identifiziert werden. Ein besonderer Befehl kann eine Vielzahl anderer Aufgaben als das Vergleichen eines Kopffelds mit einem erwarteten Wert ausführen. Zum Beispiel kann ein Befehl einen weiteren Befehl aufrufen, einen anderen Abschnitt eines Paketkopfs untersuchen, initialisiert werden, ein Register oder eine andere Datenstruktur laden oder konfigurieren, auf die Ankunft und auf das syntaktische Analysieren eines anderen Pakets vorbereiten usw. Insbesondere kann in Erwartung einer Operation, die in der Netzschnittstelle ausgeführt wird, nachdem das Paket syntaktisch analysiert worden ist, ein Register oder eine andere Speicherstruktur konfiguriert werden. Zum Beispiel kann ein Programmbefehl in 15 eine Ausgabeoperation identifizieren, die je nach dem Erfolg oder Nichterfolg des Vergleichs eines aus dem Paket extrahierten Werts mit einem erwarteten Wert ausgeführt oder nicht ausgeführt werden kann. Eine Ausgabeoperation kann einen Wert in einem Register speichern, ein Register für Operationen nach dem syntaktischen Analysieren konfigurieren (z. B. ein Argument oder einen Operator laden), ein Register löschen, um auf ein neues Paket zu warten, usw.
  • Um einen Versatz in ein Paket zu identifizieren, das syntaktisch analysiert wird, kann ein Zeiger verwendet werden. In einer Ausführungsform befindet sich ein solcher Zeiger anfangs am Beginn des Schicht-Zwei-Protokollstapels. Allerdings befindet sich der Zeiger in einer anderen Ausführungsform an einem spezifischen Platz innerhalb eines besonderen Kopfs (z. B. unmittelbar nach der Schicht-Zwei-Zieladresse und/oder nach der Schicht-Zwei-Quelladresse), wenn das syntakti sche Analysieren beginnt. Beispielhaft wird der Zeiger durch das Paket inkrementiert, während die syntaktische Analyseprozedur ausgeführt wird. In einer alternativen Ausführungsform können aber Versätze zu interessierenden Bereichen in dem Paket gegenüber einem oder mehreren bekannten oder berechneten Plätzen berechnet werden.
  • In dem in 15 gezeigten syntaktischen Analyseprogramm wird in Inkrementen von zwei Bytes (z. B. Sechzehn-Bit-Wörtern) durch den Kopf navigiert (z. B. der Zeiger vorgerückt). Außerdem werden dort, wo ein besonderes Feld eines Kopfs mit einem bekannten oder erwarteten Wert verglichen wird, bis zu zwei Bytes gleichzeitig aus dem Feld extrahiert. Ferner kann dann, wenn ein Wert oder ein Kopffeld zur Speicherung in einem Register oder in einer anderen Datenstruktur kopiert wird, die Menge der Daten, die in einer Operation kopiert werden können, in Vielfachen von Zwei-Byte-Einheiten oder in anderen Einheiten kollektiv (z. B. in einzelnen Bytes) ausgedrückt werden. In einer alternativen Ausführungsform der Erfindung kann diese Maßeinheit (z. B. zwei Bytes) erhöht oder verringert werden. Die Änderung der Maßeinheit kann die Genauigkeit ändern, mit der ein Kopf syntaktisch analysiert oder ein Kopfwert extrahiert werden kann.
  • In der in 15 veranschaulichten Ausführungsform der Erfindung enthält ein in den Befehlsspeicher des Kopfanalysealgorithmus geladener Befehlssatz eine Anzahl möglicher Operationen, die während des Tests eines Pakets auf Kompatibilität mit ausgewählten Protokollen ausgeführt werden können. Das Programm 1500 wird aus dem Befehlssatz erzeugt. Somit ist das Programm 1500 lediglich ein mögliches Programm, ein möglicher Mikrocode oder eine mögliche Befehlsfolge, das/der/die aus dem verfügbaren Befehlssatz ausgeführt werden kann.
  • In dieser Ausführungsform ermöglicht der geladene Befehlssatz die folgenden sechzehn Operationen, die an einem Paket, das syntaktisch analysiert wird, ausgeführt werden können. Spezifische Implementierungen dieser Operationen im Programm 1500 werden im Folgenden besonders ausführlich diskutiert. Selbstverständlich sind diese Befehle dem Wesen nach beispielhaft und beschränken nicht die Zusammensetzung von Befehlssätzen in anderen Ausführungsformen der Erfindung. Außerdem kann in einem besonderen syntaktischen Analyseprogramm oder syntaktischen Analysemikrocode irgendeine Teilmenge dieser Operationen verwendet werden. Ferner können mehrere Befehle die gleiche Operation verwenden und verschiedene Wirkungen haben.
  • Eine CLR_REG-Operation ermöglicht die selektive Initialisierung von Registern oder anderen Datenstrukturen, die im Programm 1500 verwendet werden, und möglicherweise von Datenstrukturen, die in Funktionen verwendet werden, die ausgeführt werden, nachdem ein Paket syntaktisch analysiert worden ist. Die Initialisierung kann das Speichern des Werts null enthalten. In den verbleibenden Operationen werden eine Anzahl beispielhafter Register identifiziert, die durch eine CLR_REG-Operation initialisiert werden können.
  • Eine LD_FID-Operation kopiert eine veränderliche Datenmenge von einem besonderen Versatz innerhalb des Pakets in ein Register, das so konfiguriert ist, dass es den Flussschlüssel oder einen anderen Flussidentifizierer eines Pakets speichert. Dieses Register kann als ein FLOWID-Register bezeichnet werden. Die Wirkung einer LD_FID-Operation ist kumulativ. Mit anderen Worten, jedes Mal, wenn sie für ein Paket aufgerufen wird, werden die erzeugten Daten an die zuvor gespeicherten Flussschlüsseldaten angehängt.
  • Eine LD_SEQ-Operation kopiert eine veränderliche Datenmenge von einem besonderen Versatz innerhalb des Pakets in ein Register, das so konfiguriert ist, dass es die Folgenummer (z. B. eine TCP-Folgenummer) eines Pakets speichert. Diesem Register kann die Bezeichnung SEQNO zugewiesen werden. Diese Operation ist ebenfalls kumulativ – der zweite Aufruf und nachfolgende Aufrufe dieser Operation für das Paket veranlassen, dass die identifizierten Daten an zuvor gespeicherte Daten angehängt werden.
  • Eine LD_CTL-Operation lädt einen Wert von einem angegebenen Versatz in dem Paket in ein CONTROL-Register. Das CONTROL-Register kann einen Steueranzeiger enthalten, um zu identifizieren, ob ein Paket für die Datenwiederzusammensetzung, für die Paketstapelung, für die Lastverteilung oder für andere verbesserte Funktionen der NIC 100 geeignet ist. Insbesondere kann ein Steueranzeiger anzeigen, ob für das Paket ein No_Assist-Merker gesetzt werden sollte, ob das Paket irgendwelche Daten enthält, ob die Menge der Paketdaten größer als ein vorgegebener Schwellenwert ist usw. Somit kann der in einer LD_CTL-Operation in ein CONTROL-Register geladene Wert die Behandlung des Pakets nach der syntaktischen Analyse beeinflussen.
  • Eine LD_SAP-Operation lädt einen Wert von einem veränderlichen Versatz innerhalb des Pakets in das CONTROL-Register. Der geladene Wert kann den Ethertype des Pakets enthalten. In einer Option, die einer LD_SAP-Operation zugeordnet sein kann, kann der Versatz des Schicht-Drei-Kopfs des Pakets ebenfalls in dem CONTROL-Register oder anderswo gespeichert werden. Falls das Paket zum Ethernet- und zum IP-Protokoll konform ist, kann der Schicht-Drei-Kopf eines Pakets sofort auf sein Schicht-Zwei-Ethertype-Feld folgen.
  • Eine LD_R1-Operation kann verwendet werden, um einen Wert von einem veränderlichen Versatz innerhalb des Pakets in ein (z. B. R1 genanntes) temporäres Register zu laden. Ein temporäres Register kann für eine Vielzahl von Aufgaben wie etwa für das Akkumulieren von Werten zur Bestimmung der Länge eines Kopfs oder eines anderen Abschnitts des Pakets verwendet werden. Eine LD_R1-Operation kann außerdem veranlassen, dass ein Wert von einem anderen veränderlichen Versatz in einem (z. B. R2 genannten) zweiten temporären Register gespeichert wird. Die während des syntaktischen Analysierens eines Pakets in den Registern R1 und/oder R2 gespeicherten Werte können kumulativ oder nicht kumulativ sein.
  • Eine LD_L3-Operation kann einen Wert aus dem Paket in ein Register laden, das so konfiguriert ist, dass es den Platz des Schicht-Drei-Kopfs des Pakets speichert. Dieses Register kann L3OFFSET genannt werden. In einem optionalen Verfahren zum Aufrufen dieser Operation kann sie zum Laden eines festen Werts in das L3OFFSET-Register verwendet werden. Als eine weitere Option kann die LD_L3-Operation einen in einem temporären Register (z. B. R1) gespeicherten Wert zu dem Wert addieren, der in dem L3OFFSET-Register gespeichert wird.
  • Eine LD_SUM-Operation speichert den Startpunkt innerhalb des Pakets, von dem eine Prüfsumme berechnet werden sollte. Das Register, in dem dieser Wert gespeichert wird, kann ein CSUMSTART-Register genannt werden. In einem alternativen Aufruf dieser Operation wird ein fester oder vorgegebener Wert in dem Register gespeichert. Als eine weitere Option kann die LD_SUM-Operation einen in einem temporären Register (z. B. R1) gespeicherten Wert zu dem Wert addieren, der in dem CSUMSTART-Register gespeichert wird.
  • Eine LD_HDR-Operation lädt einen Wert in ein Register, das so konfiguriert ist, dass es den Platz in dem Paket speichert, an dem der Kopfabschnitt geteilt werden kann. Der Wert, der gespeichert wird, kann z. B. während der Übertragung des Pakets an den Host-Computer verwendet werden, um einen Datenabschnitt des Pakets an einem anderen Platz als den Kopfabschnitt zu speichern. Somit kann der geladene Wert den Beginn der Paketdaten oder den Beginn eines besonderen Kopfs identifizieren. In einem Aufruf einer LD_HDR-Operation kann der gespeicherte Wert aus einer vorliegenden Stellung eines oben beschriebenen Zeigers der syntaktischen Analyse berechnet werden. In einem weiteren Aufruf kann ein fester oder vorgegebener Wert gespeichert werden. Als eine nochmals weitere Alternative können ein in einem temporären Register (z. B. R1) gespeicherter Wert und/oder eine Konstante zu dem geladenen Wert addiert werden.
  • Eine LD_LEN-Operation speichert die Länge der Nutzdaten des Pakets in einem Register (z. B. in einem PAYLOADLEN-Register).
  • Eine IM_FID-Operation hängt an den vorhandenen Inhalt des oben beschriebenen FLOWID-Registers einen festen oder vorgegebenen Wert an oder addiert ihn zu ihm.
  • Eine IM_SEQ-Operation hängt an den Inhalt des oben beschriebenen SEQNO-Registers einen festen oder vorgegebenen Wert an oder addiert ihn zu ihm.
  • Eine IM_SAP-Operation lädt oder speichert einen festen oder vorgegebenen Wert in dem oben beschriebenen CSUMSTART-Register.
  • Eine IM_R1-Operation kann einen vorgegebenen Wert in einem oder in mehreren temporären Registern (z. B. R1, R2) addieren oder laden.
  • Eine IM_CTL-Operation lädt oder speichert einen festen oder vorgegebenen Wert in dem oben beschriebenen CONTROL-Register.
  • Eine ST_FLAG-Operation lädt einen Wert von einem angegebenen Versatz in dem Paket in ein FLAGS-Register. Der geladene Wert kann eines oder mehrere Felder oder Merker aus einem Paketkopf enthalten.
  • Die den oben und anderswo in diesem Abschnitt beschriebenen Operationen und Registern zugewiesenen Bezeichnungen sind dem Wesen nach lediglich beispielhaft und beschränken in keiner Weise die Operationen und syntaktischen Analysebefehle, die in anderen Ausführungsformen der Erfindung verwendet werden können.
  • Die Befehle im Programm 1500 enthalten ein Befehlsnummernfeld 1502, das eine Nummer eines Befehls innerhalb des Programms enthält, und ein Befehlsnamenfeld 1504, das einen Namen eines Befehls enthält. In einer alternativen Ausführungsform der Erfindung können das Befehlsnummernfeld und das Befehlsnamenfeld verschmolzen sein oder kann eines von ihnen weggelassen sein.
  • Das Befehlsinhaltsfeld 1506 enthält mehrere Abschnitte zur Ausführung eines Befehls. Ein "Extraktionsmasken"-Abschnitt eines Befehls ist eine Zwei-Byte-Maske in Hexadezimalschreibweise. Eine Extraktionsmaske identifiziert einen zu kopierenden oder zu extrahierenden Abschnitt eines Paketkopfs, der von dem momentanen Paketversatz (z. B. der momentanen Stellung des Zeigers der syntaktischen Analyse) beginnt. Beispielhaft wird jedes Bit im Kopf des Pakets, das in dem Hexadezimalwert einer Eins entspricht, zum Vergleich in einen Vergleichs- oder Testwert kopiert. Zum Beispiel bedeutet ein Wert von 0xFF00 in dem Extraktionsmaskenabschnitt eines Befehls, dass das gesamte erste Byte bei dem momentanen Paketversatz zu kopieren ist, während der Inhalt des zweiten Bytes irrelevant ist. Ähnlich bedeutet eine Extraktionsmaske von 0x3FFF, dass alle Bits bis auf die zwei höchstwertigen Bits des ersten Bytes zu kopieren sind. Unabhängig davon, was aus dem Paket kopiert wurde, wird aus dem extrahierten Inhalt ein Zwei-Byte-Wert konstruiert. Beispielhaft wird der Rest des Werts mit Nullen aufgeführt. Bei Bedarf kann das Format einer Extraktionsmaske (oder einer im Folgenden beschriebenen Ausgabemaske) so angepasst werden, dass es die Little-Endian- oder die Big-Endian-Darstellung widerspiegelt.
  • Einer oder mehrere Befehle in einem syntaktischen Analyseprogramm können keine aus dem Paket an der Zeigerstelle extrahierten Daten erfordern, um ihre Ausgabeoperation ausführen zu können. Diese Befehle können einen Extraktionsmaskenwert von 0x0000 haben, um anzuzeigen, dass jedes Bit des Werts ausmaskiert ist, obgleich weiter ein Zwei-Byte-Wert von der Zeigerstellung wiedergewonnen wird. Somit liefert eine solche Extraktionsmaske einen eindeutigen Wert null. Dieser Befehlstyp kann verwendet werden, wenn z. B. eine Ausgabeoperation ausgeführt werden muss, bevor ein weiterer beträchtlicher Abschnitt an Kopfdaten mit einer anderen Extraktionsmaske als 0x0000 extrahiert wird.
  • Ein "Vergleichswert"-Abschnitt eines Befehls ist ein Zwei-Byte-Hexadezimalwert, mit dem der extrahierte Paketinhalt zu vergleichen ist. Der Vergleichswert kann ein Wert sein, von dem bekannt ist, dass er in einem besonderen Feld eines spezifischen Protokollkopfs gespeichert werden soll. Der Vergleichswert kann einen Wert enthalten, mit dem der extrahierte Abschnitt des Kopfs übereinstimmen sollte oder zu dem er eine angegebene Beziehung haben sollte, damit das Paket als kompatibel mit den im Voraus gewählten Protokollen angesehen wird.
  • Ein "Operator"-Abschnitt eines Befehls identifiziert einen Operator, der bedeutet, wie der extrahierte Wert und der Vergleichswert zu vergleichen sind. Beispielhaft bedeutet EQ, dass sie auf Gleichheit zu testen sind, bedeutet NE, dass sie auf Ungleichheit zu testen sind, bedeutet LT, dass der extrahierte Wert kleiner als der Vergleichswert sein muss, damit der Vergleich erfolgreich ist, bedeutet GE, dass der extrahierte Wert größer oder gleich dem Vergleichswert sein muss usw. Ein Befehl, der auf die Ankunft eines neuen syntaktisch zu analysierenden Pakets wartet, kann eine Operation von NP verwenden. Andere Operatoren für andere Funktionen können hinzugefügt werden und die vorhandenen Operatoren können anderen Monikern zugewiesen werden.
  • Ein "Erfolgsversatz"-Abschnitt eines Befehls zeigt die Anzahl der Zwei-Byte-Einheiten an, um die der Zeiger vorzurücken ist, falls der Vergleich zwischen dem extrahierten Wert und dem Testwert erfolgreich ist. Ein "Erfolgsbefehls"-Abschnitt eines Befehls identifiziert den nächsten Befehl im Programm 1500, der auszuführen ist, falls der Vergleich erfolgreich ist.
  • Ähnlich geben der "Misserfolgsversatz"-Abschnitt und der "Misserfolgsbefehls"-Abschnitt die Anzahl der Zwei-Byte-Einheiten, die der Zeiger vorzurücken ist, bzw. den nächsten auszuführenden Befehl, falls der Vergleich fehlschlägt, an. Obgleich die Versätze in dieser Ausführungsform der Erfindung in Einheiten von zwei Bytes (z. B. Sechzehn-Bit-Wörtern) ausgedrückt sind, können sie in einer alternativen Ausführungsform der Erfindung kleinere oder größere Einheiten sein. Ferner kann ein Befehl wie oben erwähnt durch eine Nummer oder einen Namen identifiziert sein.
  • Nicht alle Befehle in einem Programm werden notwendig für jedes Paket, das syntaktisch analysiert wird, verwendet. Zum Beispiel kann ein Programm Befehle zum Testen auf mehr als einen Typ oder eine Version eines Protokolls in einer besonderen Schicht enthalten. Insbesondere testet das Programm 1500 in der Schicht drei entweder auf Version vier oder auf Version sechs des IP-Protokolls. Somit hängen die Befehle, die für ein gegebenes Paket tatsächlich ausgeführt werden, vom Format des Pakets ab. Wenn ein Paket mit einem gegebenen Programm soviel wie möglich syntaktisch analysiert worden ist oder bestimmt worden ist, dass das Paket zu einem gewählten Protokoll konform oder nicht konform ist, kann die syntaktische Analyse aufhören oder ein Befehl zum Anhalten der syntaktischen Analyseprozedur ausgeführt werden. Beispielhaft zeigt ein nächster Befehlsabschnitt eines Befehls (z. B. der "Erfolgsbefehl" oder der "Misserfolgsbefehl") mit dem Wert "DONE" den Abschluss der syntaktischen Analyse eines Pakets an. Ein DONE-Befehl oder ein ähnlicher Befehl kann ein Leerbefehl sein. Mit anderen Worten, "DONE" kann einfach bedeuten, dass das syntaktische Analysieren für das vorliegende Paket abzuschließen ist. Andernfalls kann ein DONE-Befehl wie der Befehl achtzehn aus dem Programm 1500 eine gewisse Aktion ausführen, um (z. B. durch Initialisieren eines Registers) auf ein neues Paket zu warten.
  • Die verbleibenden Abschnitte des Befehlsinhaltsfelds 1506 werden verwendet, um eine Ausgabe oder eine andere Datenspeicheroperation anzugeben und abzuschließen. Insbesondere entspricht ein "Ausgabeoperations-"Abschnitt eines Befehls in dieser Ausführungsform den Operationen, die in dem geladenen Befehlssatz enthalten sind. Somit identifiziert der Ausgabeoperationsabschnitt eines Befehls für das Programm 1500 eine der sechzehn oben beschriebenen Operationen. Die im Programm 1500 verwendeten Ausgabeoperationen werden im Folgenden in Verbindung mit den einzelnen Befehlen weiter beschrieben.
  • Ein "Operationsargument"-Abschnitt eines Befehls enthält eines oder mehrere Argumente oder Felder, die zu speichern, zu laden oder auf andere Weise in Verbindung mit der Ausgabeoperation des Befehls zu verwenden sind. Beispielhaft nimmt der Operationsargumentabschnitt die Form eines Mehrbit-Hexadezimalwerts an. Für das Programm 1500 haben die Operationsargumente eine Größe von elf Bits. Ein Argument oder ein Abschnitt eines Arguments kann je nach der Ausgabeoperation verschiedene Bedeutungen haben. Zum Beispiel kann ein Operationsargument einen oder mehrere Zahlenwerte enthalten, die in einem Register zu speichern sind oder die zu verwenden sind, um einen Abschnitt eines Kopfs aufzufinden oder abzugrenzen. Andererseits kann ein Argumentbit einen Merker enthalten, um eine Aktion oder einen Status zu signalisieren. Insbesondere kann ein Argumentbit angeben, dass ein besonderes Register zurückzusetzen ist; kann eine Menge von Argumentbits einen Versatz in einen Paketkopf zu einem in einem Register zu speichernden Wert enthalten usw. Beispielhaft wird der durch ein Operationsargument angegebene Versatz auf den Platz der Stellung des Zeigers der syntaktischen Analyse angewendet, bevor der Zeiger wie durch den anwendbaren Erfolgsversatz oder Misserfolgsversatz angegeben vorgerückt wird. Die im Programm 1500 verwendeten Operationsargumente werden im Folgenden ausführlicher erläutert.
  • Ein "Operationsfreigabe"-Abschnitt eines Befehlsinhaltsfelds gibt an, ob oder wann eine Ausgabeoperation eines Befehls auszuführen ist. Insbesondere kann die Ausgabeoperation eines Befehls in der veranschaulichten Ausführungsform der Erfindung je nach dem Ergebnis des Vergleichs zwischen einem aus einem Kopf extrahierten Wert und dem Vergleichswert ausgeführt werden oder nicht ausgeführt werden. Zum Beispiel kann eine Ausgabefreigabe auf einen ersten Wert (z. B. auf null) gesetzt werden, falls die Ausgabeoperation nie auszuführen ist. Falls sie nur dann auszuführen ist, wenn der Vergleich dem Operator genügt, kann sie andere Werte (z. B. eins oder zwei) annehmen. Eine Operationsfreigabe kann einen nochmals anderen Wert (z. B. drei) annehmen, falls sie immer auszuführen ist.
  • Ein "Verschiebe"-Abschnitt eines Befehls enthält einen Wert, der anzeigt, wie ein Ausgabewert zu verschieben ist. Eine Verschiebung kann erforderlich sein, da verschiedene Protokolle gelegentlich erfordern, dass Werte unterschiedlich formatiert werden. Außerdem kann ein Wert, der eine Länge oder einen Platz eines Kopfs oder eines Kopffelds anzeigt, eine Verschiebung erfordern, um die durch den Wert repräsentierte richtige Größe zu widerspiegeln. Da das Programm 1500 so konstruiert ist, dass es Zwei-Byte-Einheiten verwendet, kann z. B. ein Wert verschoben werden müssen, falls er andere Einheiten (z. B. Bytes) widerspiegeln soll. Ein Verschiebewert zeigt in einer vorliegenden Ausführungsform die Anzahl der Stellen (z. B. Bits) an, die ein Ausgabewert nach rechts zu verschieben ist. In einer weiteren Ausführungsform der Erfindung kann ein Verschiebewert einen anderen Verschiebetyp oder eine andere Verschieberichtung repräsentieren.
  • Schließlich gibt eine "Ausgabemaske" an, wie ein Wert, der in einem Register oder in einer anderen Datenstruktur gespeichert wird, zu formatieren ist. Wie oben dargelegt wurde, kann eine Ausgabeoperation erfordern, dass ein extrahierter, berechneter oder zusammengesetzter Wert gespeichert wird. Die Ausgabemaske ist ähnlich wie die Extraktionsmaske ein Zwei-Byte-Hexadezimalwert. In dieser Ausführungsform der Erfindung ist für jede Stelle in der Ausgabemaske, die eine Eins enthält, das entsprechende Bit in dem durch die Ausgabeoperation und/oder durch das Operationsargument identifizierten Zwei-Byte-Wert zu speichern. Zum Beispiel zeigt ein Wert 0xFFFF an, dass der angegebene Zwei-Byte-Wert so, wie er ist, zu speichern ist. Beispielhaft wird für jede Stelle in der Ausgabemaske, die eine Null enthält, eine Null gespeichert. Somit zeigt ein Wert 0xF000 an, dass die höchstwertigen vier Bits des ersten Bytes zu speichern sind, während der Rest des gespeicherten Werts irrelevant ist und mit Nullen aufgefüllt werden kann.
  • Eine Ausgabeoperation "NONE" kann verwendet werden, um anzuzeigen, dass keine Ausgabeoperation auszuführen oder zu speichern ist, wobei in diesem Fall andere Befehlsabschnitte, die sich auf die Ausgabe beziehen, ignoriert werden können oder angegebene Werte (z. B. alles Nullen) enthalten können. Allerdings kann in dem in 15 gezeigten Programm eine CLR_REG-Ausgabeoperation, die die selektive Neuinitialisierung der Register ermöglicht, mit einem Operationsargument von null verwendet werden, um effektiv keine Ausgabe auszuführen. Insbesondere gibt ein Operationsargument von null für die Operation CLR_REG an, dass keine Register zurückzusetzen sind. In einer alternativen Ausführungsform der Erfindung könnte der Operationsfreigabeabschnitt eines Befehls auf einen Wert (z. B. null) gesetzt werden, der anzeigt, dass die Ausgabeoperation nie auszuführen ist.
  • Selbstverständlich repräsentieren das Format und die Folge der Befehle in 15 nur ein Verfahren des syntaktischen Analysierens eines Pakets, um zu bestimmen, ob es zu einem besonderen Kommunikationsprotokoll konform ist. Insbesondere sind die Befehle so konstruiert, dass sie einen oder mehrere Abschnitte eines oder mehrerer Paketköpfe für den Vergleich mit bekannten oder erwarteten Werten untersuchen und bei Bedarf ein Register oder einen anderen Speicherplatz konfigurieren oder laden. Die Befehle zum syntaktischen Analysieren eines Pakets können irgendwelche von einer Anzahl von Formen annehmen und in einer Vielzahl von Folgen ausgeführt werden, ohne den Umfang der Erfindung zu überschreiten.
  • Nunmehr können anhand von 15 die Befehle im Programm 1500 ausführlich beschrieben werden. Vor der Ausführung des in 15 gezeigten Programms be findet sich ein Zeiger der syntaktischen Analyse am Beginn des Schicht-Zwei-Kopfs eines Pakets. Die Stellung des Zeigers der syntaktischen Analyse kann zur leichten Bezugnahme und Aktualisierung während der syntaktischen Analyseprozedur in einem Register gespeichert sein. Insbesondere kann die Stellung des Zeigers der syntaktischen Analyse als ein Versatz (z. B. vom Beginn des Schicht-Zwei-Kopfs) beim Berechnen der Stellung einer besonderen Stellung innerhalb eines Kopfs verwendet werden.
  • Das Programm 1500 beginnt mit einem WAIT-Befehl (z. B. einem Befehl null), der auf ein neues Paket wartet (z. B. durch den Operator NP angezeigt) und, wenn eines empfangen worden ist, einen Zeiger der syntaktischen Analyse auf das zwölfte Byte des Schicht-Zwei-Kopfs einstellt. Dieser Versatz zu dem zwölften Byte wird durch den Erfolgsversatzabschnitt des Befehls angezeigt. Der WAIT-Befehl wird in sich geschleift, bis ein Paket empfangen wird. Außerdem wird eine CLR_REG-Operation durchgeführt, wobei aber die Operationsfreigabeeinstellung anzeigt, dass sie nur dann durchgeführt wird, wenn der Vergleich erfolgreich ist (z. B., wenn ein neues Paket empfangen wird).
  • Die angegebene CLR_REG-Operation arbeitet gemäß dem Operationsargument (d. h. 0x3FF) des WAIT-Befehls. In dieser Ausführungsform entspricht jedes Bit des Arguments einem Register oder einer anderen Datenstruktur. Die in dieser Operation initialisierten Register können die Folgenden enthalten: ADDR (z. B. zum Speichern der Adresse oder des Platzes des Zeigers der syntaktischen Analyse), FLOWID (z. B. zum Speichern des Flussschlüssels des Pakets), SEQNO (z. B. zum Speichern einer TCP-Folgenummer), SAP (z. B. der Ethertype des Pakets) und PAYLOADLEN (z. B. eine Nutzinformationslänge). Die folgenden zum Speichern bestimmter Versätze konfigurierten Register können ebenfalls zurückgesetzt werden: FLOWOFF (z. B. Versatz innerhalb des FLOWID-Registers), SEQOFF (z. B. der Versatz innerhalb des SEQNO-Registers), L3OFFSET (z. B. der Versatz des Schicht-Drei-Kopfs des Pakets), HDRSPLIT (z. B. der Platz zum Teilen des Pakets) und CSUMSTART (z. B. der Startplatz zum Berechnen einer Prüfsumme). Außerdem können einer oder mehrere Status- oder Steueranzeiger (z. B. das CONTROL- oder das FLAGS-Register) zum Berichten des Status eines oder mehrerer Merker eines Paketkopfs zurückgesetzt werden. Außerdem können eines oder mehrere temporäre Register (z. B. R1, R2) oder andere Datenstrukturen ebenfalls initialisiert werden. Diese Register sind lediglich beispielhaft für die Datenstrukturen, die in einer Ausführungsform der Erfindung verwendet werden können. In anderen Ausführungsformen können für die gleichen oder für andere Ausgabeoperationen andere Datenstrukturen verwendet werden.
  • Temporäre Register wie etwa R1 und/oder R2 können im Programm 1500 verwendet werden, um verschiedene Köpfe und Kopffelder zu verfolgen. Die Anzahl möglicher Kombinationen von Kommunikationsprotokollen und die Wirkung dieser verschiedenen Kombinationen auf die Struktur und das Format der Köpfe eines Pakets sind anzuerkennen. Von einem Paket, das zu einem Protokoll oder zu einer Menge von Protokollen konform ist, können mehr Informationen zu untersuchen oder zu sammeln sein als von einem Paket, das zu einem anderen Protokoll oder zu einer anderen Menge von Protokollen konform ist. Falls z. B. Erweiterungsköpfe mit einem Internet-Protocol-Kopf verwendet werden, müssen möglicherweise die Werte von diesen Erweiterungsköpfen und/oder ihre Längen gespeichert werden, während diese Werte nicht erforderlich sind, falls keine Erweiterungsköpfe verwendet werden. Bei der Berechnung eines besonderen Versatzes wie etwa z. B. eines Versatzes zum Beginn des Datenabschnitts eines Pakets müssen möglicherweise mehrere Register aufrechterhalten und ihre Werte kombiniert oder addiert werden. In diesem Beispiel kann ein Register oder ein temporäres Register die Größe oder das Format eines Erweiterungskopfs verfolgen, während ein anderes Register den Basis-IP-Kopf verfolgt.
  • Der VLAN-Befehl (z. B. der Befehl eins) untersucht das Zwei-Byte-Feld bei der Stellung des Zeigers der syntaktischen Analyse (möglicherweise ein Typ-, Längen- oder TPID-Feld) auf einen Wert, der einen VLAN-markierten Kopf anzeigt (z. B. 8100 hexadezimal). Falls der Kopf VLAN-markiert ist, wird der Zeiger um zwei Bytes (z. B. um eine Zwei-Byte-Einheit) inkrementiert und die Ausführung mit dem Befehl CFI fortgesetzt; andernfalls wird die Ausführung mit dem 802.3-Befehl fortgesetzt. Auf jeden Fall zeigt die Operationsfreigabe des Befehls an, dass eine IM_CTL-Operation stets auszuführen ist.
  • Wie oben beschrieben wurde, veranlasst eine IM_CTL-Operation, dass ein Steuerregister oder eine andere Datenstruktur mit einem oder mit mehreren Merkern bevölkert wird, um den Status oder die Bedingung eines Pakets zu berichten. Ein Steueranzeiger kann anzeigen, ob ein Paket für die verbesserte Verarbeitung geeignet ist (z. B., ob für das Paket ein No_Assist-Signal erzeugt werden sollte), ob ein Paket irgendwelche Daten enthält und, wenn das der Fall ist, ob die Größe des Datenabschnitts einen angegebenen Schwellenwert übersteigt. Das Operationsargument 0x00A für den VLAN-Befehl enthält den in dem Steuerregister zu speichernden Wert, wobei die einzelnen Bits des Arguments besonderen Merkern entsprechen. Beispielhaft können die den eben beschriebenen Bedingungen zugeordneten Merker in dieser IM_CTL-Operation auf eins oder wahr gesetzt werden.
  • Ein CFI-Befehl (z. B. der Befehl zwei) untersucht das CFI-Bit oder den CFI-Merker in einem Schicht-Zwei-Kopf. Falls das CFI-Bit gesetzt ist, ist das Paket nicht für die Verarbeitungsverbesserungen einer vorliegenden Ausführungsform der Erfindung geeignet, wobei die syntaktische Analyseprozedur durch Aufrufen des Befehls DONE (z. B. des Befehls achtzehn) endet. Falls das CFI-Bit nicht gesetzt ist, wird der Zeiger um weitere zwei Bytes inkrementiert und die Ausführung mit dem 802.3-Befehl fortgesetzt. Wie oben erläutert wurde, zeigt eine Null-Ausgabeoperation (z. B. "NONE") an, dass keine Ausgabeoperation ausgeführt wird. Außerdem stellt ferner der Ausgabefreigabewert (z. B. null) sicher, dass keine Ausgabeoperation ausgeführt wird.
  • Im 802.3-Befehl (z. B. im Befehl drei) wird (je nach Stelle des Zeigers und Format des Pakets) ein Typ- oder Längenfeld untersucht, um zu bestimmen, ob das Schicht-Zwei-Format des Pakets das herkömmliche Ethernet oder das 802.3-Ethernet ist. Falls der Wert in dem Kopffeld das 802.3-Ethernet anzuzeigen scheint (z. B. einen kleineren Hexadezimalwert als 0600 enthält), wird der Zeiger um zwei Bytes (auf das, was ein LLC-SNAP-Feld sein sollte) inkrementiert und die Ausführung mit dem LLC_1-Befehl fortgesetzt. Andernfalls kann das Schicht-Zwei-Protokoll als das herkömmliche Ethernet betrachtet werden und die Ausführung mit dem IPV4_1 Befehl fortgesetzt werden. In dieser Ausführungsform der Erfindung enthält der 802.3-Befehl keine Ausgabeoperation.
  • In den Befehlen LLC_1 und LLC_2 (z. B. in den Befehlen vier und fünf) wird ein vermutetes Schicht-Zwei-LLC-SNAP-Feld untersucht, um sicherzustellen, dass das Paket zu dem 802.3-Ethernet-Protokoll konform ist. Im LLC_1-Befehl wird ein erster Teil des Felds getestet und, falls erfolgreich, der Zeiger um zwei Bytes inkrementiert und im LLC_2-Befehl ein zweiter Teil getestet. Falls der LLC_2-Befehl erfolgreich war, wird der Zeiger der syntaktischen Analyse um vier Bytes vorgerückt, um etwas zu erreichen, was ein Typfeld sein sollte, und die Ausführung mit dem IPV4_1-Befehl fortgesetzt. Falls einer der Tests fehlschlägt, wird dagegen aus der syntaktischen Analyseprozedur ausgetreten. Während des Tests des LLC-SNAP-Felds wird in der veranschaulichten Ausführungsform der Erfindung keine Ausgabeoperation ausgeführt.
  • Im IPV4_1-Befehl (z. B. im Befehl sechs) sollte der Zeiger der syntaktischen Analyse bei einem Ethernet-Typfeld sein. Dieses Feld wird untersucht, um zu bestimmen, ob das Schicht-Drei-Protokoll einer Version vier des Ethernet Protocol zu entsprechen scheint. Falls dieser Test erfolgreich ist (falls z. B. das Typfeld einen Hexadezimalwert 0800 enthält), wird der Zeiger um zwei Bytes auf den Beginn des Schicht-Drei-Kopfs vorgerückt und die Ausführung des Programms 1500 mit dem IPV4_2-Befehl fortgesetzt. Falls der Test erfolglos war, wird die Ausführung mit dem IPV6_1-Befehl fortgesetzt. Unabhängig von den Testergebnissen zeigt der Operationsfreigabewert (z. B. drei) an, dass die angegebene LD_SAP-Ausgabeoperation immer ausgeführt wird.
  • Wie zuvor beschrieben wurde, wird in einer LD_SAP-Operation der Ethertyp (oder Dienstzugangspunkt) eines Pakets in einem Register gespeichert. Ein Teil des Operationsarguments von 0x100, insbesondere die sechs niedrigstwertigen Bits (z. B. null), bildet einen Versatz zu einem Zwei-Byte-Wert, der den Ethertyp enthält. Da der Zeiger der syntaktischen Analyse im vorliegenden Kontext bereits bei dem Typfeld ist, das den Ethertyp enthält, ist der Versatz in diesem Beispiel null. Der Rest des Operationsarguments bildet in der derzeit beschriebenen Ausführungsform einen Merker, der angibt, dass die Startstelle des Schicht-Drei-Kopfs (z. B. ein Versatz vom Beginn des Pakets) (z. B. in dem L3OFFSET-Register) ebenfalls gesichert wird. Insbesondere ist bekannt, dass sich der Beginn des Schicht-Drei-Kopfs unmittelbar hinter dem Zwei-Byte-Typfeld befindet.
  • Der IPV4_2-Befehl (z. B. der Befehl sieben) testet ein vermutetes Schicht-Drei-Versionsfeld, um sicherzustellen, dass das Schicht-Drei-Protokoll die Version vier des IP ist. Insbesondere gibt eine Spezifikation für die Version vier des IP an, dass die ersten vier Bits des Schicht-Drei-Kopfs einen Wert 0x4 enthalten. Falls der Test fehlschlägt, endet die Prozedur der syntaktischen Analyse mit dem Befehl DONE. Falls der Test erfolgreich ist, wird der Zeiger um sechs Bytes vorgerückt und der IPV4_3-Befehl aufgerufen.
  • Die angegebene LD_SUM-Operation, die nur dann ausgeführt wird, wenn der Vergleich im IPV4_2-Befehl erfolgreich ist, zeigt an, dass ein Versatz zum Beginn eines Punkts, von dem eine Prüfsumme berechnet werden kann, gespeichert werden sollte. Insbesondere sollte in der derzeit beschriebenen Ausführungsform der Erfindung (unter der Annahme, dass der Schicht-Vier-Kopf TCP ist) eine Prüfsumme vom Beginn des TCP-Kopfs berechnet werden. Der Wert des Operationsarguments (z. B. 0x00A) zeigt an, dass sich die Prüfsumme immer zwanzig Bytes (z. B. zehn Zwei-Byte-Inkremente) von dem momentanen Zeiger befindet. Somit wird zur Stellung des Zeigers der syntaktischen Analyse ein Wert von zwanzig Bytes addiert und das Ergebnis in einem Register oder in einer anderen Datenstruktur (z. B. in dem CSUMSTART-Register) gespeichert.
  • Der IPV4_3-Befehl (z. B. der Befehl acht) ist dafür gedacht zu bestimmen, ob der IP-Kopf des Pakets eine IP-Fragmentierung anzeigt. Falls der in Übereinstimmung mit der Extraktionsmaske aus dem Kopf extrahierte Wert nicht gleich dem Vergleichswert ist, zeigt das Paket eine Fragmentierung an. Falls eine Fragmentierung erfasst wird, wird das Paket als für die hier diskutierten Verarbeitungsverbesserungen ungeeignet betrachtet und die Prozedur (z. B. über den DONE-Befehl) verlassen. Andernfalls wird der Zeiger um zwei Bytes inkrementiert und nach Ausführung einer LD_LEN-Operation der IPV4_4-Befehl aufgerufen.
  • In Übereinstimmung mit der LD_LEN-Operation wird die Länge des IP-Segments gesichert. Das veranschaulichte Operationsargument (z. B. 0x03E) enthält einen Versatz zu dem Gesamtlängenfeld, wo sich der Wert befindet. Insbesondere bilden die niedrigstwertigen sechs Bits den Versatz. Da der Zeiger bereits über dieses Feld hinaus vorgerückt ist, enthält das Operationsargument einen negativen Wert. Dieser Binärwert (z. B. 111110) kann verwendet werden, um den Dezimalwert von minus zwei zu repräsentieren. Somit wird der vorliegende Versatz des Zeigers minus vier Bytes (z. B. zwei Zwei-Byte-Einheiten) in einem Register oder in einer anderen Datenstruktur (z. B. in dem PAYLOADLEN-Register) gesichert. Zur Darstellung eines negativen Versatzes kann irgendein anderes geeignetes Verfahren verwendet werden. Andernfalls kann die IP-Segmentlänge gesichert werden, während der Zeiger (z. B. während eines vorangehenden Befehls) an einem Platz ist, der dem Gesamtlängenfeld vorausgeht.
  • Im IPV4_4-Befehl (z. B. im Befehl neun) wird ein Ein-Byte-Protokollfeld untersucht, um zu bestimmen, ob das Schicht-Vier-Protokoll das TCP zu sein scheint. Wenn das der Fall ist, wird der Zeiger um vierzehn Bits vorgerückt und die Ausführung mit dem TCP_1-Befehl fortgesetzt; andernfalls endet die Prozedur.
  • Die angegebene LD_FID-Operation, die nur dann ausgeführt wird, wenn der Vergleich im IPV4_4-Befehl erfolgreich ist, enthält das Wiedergewinnen des Flussschlüssels des Pakets und dessen Speichern in einem Register oder an einer anderen Stelle (z. B. in dem FLOWID-Register). Damit der Vergleich im IPV4_4-Befehl erfolgreich ist, müssen die Schicht-Drei- und Schicht-Vier-Köpfe des Pakets zu IP (Version vier) bzw. TCP konform sein. Wenn das der Fall ist, wird ein gesamter Flussschlüssel (z. B. die IP-Quelladresse und die IP-Zieladresse zuzüglich der TCP-Quellportnummer und der TCP-Zielportnummer) zusammenhängend im Kopfabschnitt des Pakets gespeichert. Insbesondere enthält der Flussschlüssel den letzten Abschnitt des IP-Kopfs und den Anfangsabschnitt des TCP-Kopfs und kann in einer Operation extrahiert werden. Somit enthält das Operationsargument (z. B. 0x182) zwei Werte, die zum Auffinden und Begrenzen des Flussschlüssels erforderlich sind. Beispielhaft identifizieren die niedrigstwertigen sechs Bits des Arguments (z. B. 0x02) einen Versatz von der Zeigerstellung in Zwei-Bit-Einheiten zum Beginn des Flussschlüssels. Die anderen fünf Bits des Arguments (z. B. 0x06) identifizieren in Zwei-Byte-Einheiten die Größe des zu speichernden Flussschlüssels.
  • Im IPV6_1-Befehl (z. B. im Befehl zehn), der auf den Misserfolg des durch den IPV4_1-Befehl ausgeführten Vergleichs folgt, sollte der Zeiger der syntaktischen Analyse bei einem Schicht-Zwei-Typfeld sein. Falls der Test erfolgreich ist (z. B., falls das Typfeld einen Hexadezimalwert von 86DD hält), wird nach Ausführung einer LD_SUM-Operation der IPV6_2-Befehl ausgeführt und der Zeiger um zwei Bytes zum Beginn des Schicht-Drei-Protokolls inkrementiert. Falls der Test erfolglos ist, wird die Prozedur verlassen.
  • Die angegebene LD_SUM-Operation im IPV6_1-Befehl ist ähnlich der im IPV4_2-Befehl durchgeführten Operation, nutzt aber ein anderes Argument. Es ist wieder die Prüfsumme vom Beginn des TCP-Kopfs (unter der Annahme, dass der Schicht-Vier-Kopf TCP ist) zu berechnen. Somit enthält das angegebene Operationsargument (z. B. 0x015) einen Versatz zum Beginn des TCP-Kopfs einundzwanzig Zwei-Byte-Schritte voraus. Der angezeigte Versatz wird zur vorliegenden Zeigerstellung addiert und in einem Register oder in einer anderen Datenstruktur (z. B. in dem CSUMSTART-Register) gesichert.
  • Um weiter sicherzustellen, dass das Schicht-Drei-Protokoll die Version sechs des IP ist, testet der IPV6_2-Befehl (z. B. der Befehl elf) ein vermutetes Schicht-Drei- Versionsfeld. Falls der Vergleich fehlschlägt, endet die Prozedur der syntaktischen Analyse mit dem Aufruf des DONE-Befehls. Falls er erfolgreich ist, wird der IPV6_3-Befehl aufgerufen. Die IM_R1-Operation, die in dieser Ausführungsform nur dann ausgeführt wird, wenn der Vergleich erfolgreich ist, sichert die Länge des IP-Kopfs von einem Nutzinformationslängenfeld. Das Gesamtlängenfeld (z. B. die IP-Segmentgröße) eines Kopfs des IP, Version vier, enthält die Größe des Version-Vier-Kopfs. Dagegen enthält das Nutzinformationslängenfeld (z. B. die IP-Segmentgröße) eines Kopfs des IP, Version sechs, nicht die Größe des Version-Sechs-Kopfs. Somit wird die Größe des Version-Sechs-Kopfs gesichert, die durch die niedrigstwertigen acht Bits des Ausgabearguments identifiziert ist (z. B. 0x14, was zwanzig Zwei-Byte-Einheiten anzeigt). Beispielhaft identifiziert der Rest des Arguments die Datenstruktur (z. B. das temporäre Register R1), in der die Kopflänge zu speichern ist. Wegen des Unterschieds der Größe der Schicht-Drei-Köpfe zwischen den Protokollen wird die Kopfgröße in einer Ausführungsform der Erfindung in verschiedenen Einheiten angegeben, um eine höhere Genauigkeit zu ermöglichen. Insbesondere wird die Größe des Kopfs in einer Ausführungsform der Erfindung in Bytes im IPV6_2-Befehl angegeben, wobei das Ausgabeargument in diesem Fall 0x128 sein könnte.
  • In dieser Ausführungsform untersucht der IPV6_3-Befehl (z. B. der Befehl zwölf) keinen Kopfwert. In dieser Ausführungsform zeigt die Kombination einer Extraktionsmaske 0x0000 mit einem Vergleichswert 0x0000 an, dass vor der nächsten Untersuchung eines Abschnitts eines Kopfs eine Ausgabeoperation erwünscht ist. Nach Ausführung der LD_FID-Operation wird der Zeiger der syntaktischen Analyse um sechs Bytes zu einem Nächster-Kopf-Feld des Version-Sechs-IP-Kopfs vorgerückt. Da der Extraktionsmaskenwert und der Vergleichswert beide 0x0000 sind, sollte der Vergleich nie fehlschlagen und der Misserfolgsbefehlszweig nie aufgerufen werden.
  • Wie zuvor beschrieben wurde, speichert eine LD_FID-Operation einen Flussschlüssel in einem geeigneten Register oder in einer anderen Datenstruktur (z. B. in dem FLOWID-Register). Beispielhaft enthält das Operationsargument 0x484 zwei Werte zum Identifizieren und Begrenzen des Flussschlüssels. Insbesondere zeigen die niedrigstwertigen sechs Bits (z. B. 0x04) an, dass sich der Flussschlüsselabschnitt bei einem Versatz von acht Bytes (z. B. vier Zwei-Byte-Inkrementen) von der momentanen Zeigerstellung befindet. Der Rest des Operationsarguments (z. B. 0x12) zeigt an, dass sechsunddreißig Bytes (z. B. das dezimale Äquivalent von 0x12 Zwei-Byte-Einheiten) von dem berechneten Versatz zu kopieren sind. In der veranschaulichten Ausführungsform der Erfindung wird der gesamte Flussschlüssel einschließlich der Schicht-Drei-Quelladresse und der Schicht-Drei-Zieladresse sowie der Schicht-Vier-Quellports und der Schicht-Vier-Zielports unversehrt kopiert.
  • Im IPV6_4-Befehl (z. B. in Befehl dreizehn) wird ein vermutetes Nächster-Kopf-Feld untersucht, um zu bestimmen, ob das Schicht-Vier-Protokoll des Protokollstapels des Pakets TCP zu sein scheint. Wenn das der Fall ist, schreitet die Prozedur um sechsunddreißig Bytes (z. B. achtzehn Zwei-Byte-Einheiten) vor und wird der TCP_1-Befehl aufgerufen; andernfalls wird die Prozedur (z. B. über den DONE-Befehl) verlassen. Falls der Wert in dem Nächster-Kopf-Feld 0x06 ist, wird die LD_LEN-Operation ausgeführt. Wie oben beschrieben wurde, speichert diese Operation die IP-Segmentgröße. Das Argument (z. B. 0x03F) enthält noch einmal einen negativen Versatz, in diesem Fall von minus eins. Dieser Versatz zeigt an, dass sich das gewünschte Nutzinformationslängenfeld zwei Bytes vor der derzeitigen Stellung des Zeigers befindet. Somit wird der negative Versatz zu der derzeitigen Zeigerstellung addiert und das Ergebnis in einem geeigneten Register oder einer anderen Datenstruktur (z. B. in dem PAYLOADLEN-Register) gesichert.
  • In den Befehlen TCP_1, TCP_2, TCP_3 und TCP_4 (z. B. in den Befehlen vierzehn bis siebzehn) werden – mit Ausnahme bestimmter Merker, die in den Ausgabeoperationen des Befehls angegeben sind – keine Kopfwerte untersucht, sondern verschiedene Daten aus dem TCP-Kopf des Pakets gesichert. In der veranschaulichten Ausführungsform enthalten die Daten, die gesichert werden, eine TCP-Folgenummer, eine TCP-Kopflänge und einen oder mehrere Merker. Für jeden Befehl wird die angegebene Operation ausgeführt und der nächste Befehl aufgerufen. Wie oben beschrieben wurde, schlägt ein Vergleich zwischen dem Vergleichswert 0x0000 und einem Extraktionswert null, wie er in jedem dieser Befehle verwendet wird, nie fehl. Nach dem TCP_4-Befehl kehrt die Prozedur der syntaktischen Analyse zum WAIT-Befehl zurück und wartet auf ein neues Paket.
  • Für die LD_SEQ-Operation im TCP_1-Befehl enthält das Operationsargument (z. B. 0x081) zwei Werte zum Identifizieren und Extrahieren einer TCP-Folgenummer. Die niedrigstwertigen sechs Bits (z. B. 0x01) zeigen an, dass sich die Folgenummer zwei Bytes von der momentanen Stellung des Zeigers befindet. Der Rest des Arguments (z. B. 0x2) zeigt die Anzahl der Zwei-Byte-Einheiten an, die von dieser Stelle kopiert werden müssen, um die Folgenummer zu erfassen. Beispielhaft wird die Folgenummer in dem SEQNO-Register gespeichert.
  • Für die ST_FLAG-Operation im TCP_2-Befehl wird das Operationsargument (z. B. 0x145) dazu verwendet, ein Register (z. B. das FLAGS-Register) mit Merkern zu konfigurieren, die in einer Aufgabe nach dem syntaktischen Analysieren zu verwenden sind. Die sechs niedrigstwertigen Bits (z. B. 0x05) bilden einen Versatz in Zwei-Byte-Einheiten zu einem Zwei-Byte-Abschnitt des TCP-Kopfs, der Merker enthält, die beeinflussen können, ob das Paket für Verbesserungen der vorliegenden Erfindung für die Verarbeitung nach dem syntaktischen Analysieren geeignet ist. Zum Beispiel können sich die Merker URG, PSH, RST, SYN und FIN an der Versatzstelle befinden und zum Konfigurieren des Registers verwendet werden. Die Ausgabemaske (z. B. 0x002F) zeigt an, dass lediglich bestimmte Abschnitte (z. B. Bits) des Merkerfelds des TCP-Kopfs zu speichern sind.
  • Die LD_R1-Operation des TCP_3-Befehls ist ähnlich der im IPV6_2-Befehl durchgeführten Operation. Ein Operationsargument 0x205 enthält hier einen Wert (z. B. die niedrigstwertigen sechs Bits), der einen Versatz von fünf Zwei-Byte-Einheiten von der momentanen Zeigerstellung identifiziert. Dieser Platz sollte ein Kopflängenfeld enthalten, das in einer durch den Rest des Arguments identifizierten Datenstruktur (z. B. im temporären Register R1) zu speichern ist. Die Ausgabemaske (z. B. 0xF000) zeigt an, dass nur die ersten vier Bits gesichert werden (z. B. hat das Kopflängenfeld nur eine Größe von vier Bits).
  • In der veranschaulichten Ausführungsform muss der aus dem Kopflängenfeld extrahierte Wert möglicherweise angepasst werden, um die Verwendung von Zwei-Byte-Einheiten (z. B. Sechzehn-Bit-Wörtern) zu widerspiegeln. Somit wird der aus dem Feld extrahierte und durch die Ausgabemaske (z. B. 0xF000) konfigurierte Wert in Übereinstimmung mit dem Verschiebeabschnitt des TCP_3-Befehls, wenn er gespeichert wird, um elf Stellen nach rechts verschoben, um die Berechnungen zu vereinfachen.
  • Die LD_HDR-Operation des TCP_4-Befehls veranlasst das Laden eines Versatzes zu dem ersten Byte der Paketdaten nach dem TCP-Kopf. Beispielhaft können Pakete, die mit einem im Voraus gewählten Protokollstapel kompatibel sind, an einem gewissen Punkt in einen Kopf- und einen Datenabschnitt geteilt werden. Das Sichern eines Versatzes zu dem Datenabschnitt erleichtert nun das spätere Trennen des Pakets. Beispielhaft enthalten die niedrigstwertigen sieben Bits des 0x0FF-Operationsarguments ein erstes Element des Versatzes zu den Daten. Der Fachmann auf dem Gebiet erkennt, dass das Bitmuster (z. B. 1111111) gleich minus eins ist. Somit wird ein Versatzwert gleich dem momentanen Zeiger der syntaktischen Analyse (z. B. der Wert in dem ADDR-Register) minus zwei Bytes – der den Beginn des TCP-Kopfs ermittelt – gesichert. Der Rest des Arguments bedeutet, dass zu diesem Versatz der Wert einer temporären Datenstruktur (z. B. des temporären Registers R1) zu addieren ist. In diesem besonderen Kontext wird der in dem vorangehenden Befehl gesicherte Wert (z. B. die Länge des TCP-Kopfs) addiert. Diese zwei Werte werden verbunden, um einen Versatz zum Beginn der Paketdaten zu bilden, der in einem geeigneten Register oder in einer anderen Datenstruktur (z. B. in dem HDRSPLIT-Register) gespeichert wird.
  • Schließlich gibt der DONE-Befehl (z. B. der Befehl achtzehn), wie bereits oben erwähnt wurde, das Ende des syntaktischen Analysierens eines Pakets an, wenn bestimmt wird, dass das Paket nicht zu einem oder zu mehreren der Protokolle, die den veranschaulichten Befehlen zugeordnet sind, konform ist. Dies kann als ein "Reinigungs"-Befehl betrachtet werden. Insbesondere gibt die LD_CTL-Ausgabeoperation mit einem Operationsargument 0x001 an, dass in dem oben in Verbindung mit dem VLAN-Befehl beschriebenen Steuerregister ein No_Assist-Merker (z. B. auf eins) zu setzen ist. Der wie an anderer Stelle beschriebene No_Assist-Merker kann verwendet werden, um andere Module der Netzschnittstelle darüber zu informieren, dass das vorliegende Paket für eine oder mehrere anderswo beschriebene Verarbeitungsverbesserungen ungeeignet ist.
  • Das veranschaulichte Programm oder der veranschaulichte Mikrocode zeigt nur ein Verfahren des syntaktischen Analysierens eines Pakets. Es können andere Programme, die die gleichen Befehle in einer anderen Folge oder insgesamt andere Befehle mit ähnlichen oder unterschiedlichen Formaten haben, verwendet werden, um Abschnitte des Kopfs zu untersuchen und zu speichern und Register und andere Datenstrukturen zu konfigurieren.
  • Die Effizienzgewinne, die aus der Anwendung der verbesserten Verarbeitung einer vorliegenden Ausführungsform der Erfindung realisiert werden können, gleichen die zum syntaktischen Analysieren eines Pakets mit dem veranschaulichten Programm erforderliche Zeit mehr als aus. Auch wenn ein Kopfanalysealgorithmus ein Paket in einer NIC in einer momentanen Ausführungsform syntak tisch analysiert, muss das Paket möglicherweise immer noch durch einen Prozessor in einem Host-Computer durch seinen Protokollstapel weiter verarbeitet werden (um z. B. die Protokollköpfe zu entfernen). Dies vermeidet die Belastung der Kommunikationsvorrichtung (z. B. der Netzschnittstelle) mit einer solchen Aufgabe.
  • Eine Ausführungsform einer Flussdatenbank
  • 5 zeigt eine Flussdatenbank (FDB) 110 gemäß einer Ausführungsform der Erfindung. Beispielhaft ist die FDB 110 unter Verwendung einer wieder beschreibbaren Speicherkomponente (z. B. RAM, SRAM, DRAM) als ein CAM (inhaltsadressierter Speicher) implementiert. In dieser Ausführungsform enthält die FDB 110 einen assoziativen Abschnitt 502 und einen assoziierten Abschnitt 504 und kann durch eine Flussnummer 506 indiziert werden.
  • Der Umfang der Erfindung beschränkt nicht die Form oder Struktur der Flussdatenbank 110. In alternativen Ausführungsformen der Erfindung kann praktisch irgendeine Form einer Datenstruktur, entweder monolithisch oder segmentiert (z. B. Datenbank, Tabelle, Warteschlange, Liste, Datenfeld), verwendet werden, die in Hardware oder Software implementiert sein kann. Die veranschaulichte Form der FDB 110 ist lediglich eine Art, nützliche Informationen aufrechtzuerhalten, die die Kommunikationsflüsse durch die NIC 100 betreffen. Die Struktur eines CAM ermöglicht vorteilhaft eine hocheffiziente und schnelle Assoziativdurchsuchung.
  • In der veranschaulichten Ausführungsform der Erfindung ermöglichen die in der FDB 110 gespeicherten Informationen und der (im Folgenden beschriebene) Betrieb des Flussdatenbankmanagers (FDBM) 108 Funktionen wie etwa die Datenwiederzusammensetzung, die Stapelverarbeitung von Paketköpfen und weitere Verbesserungen. Diese Funktionen können kurz wie folgt beschrieben werden.
  • Eine Form der Datenwiederzusammensetzung enthält die Wiederzusammensetzung oder Kombination von Daten aus mehreren verwandten Paketen (z. B. Paketen aus einem einzigen Kommunikationsfluss oder aus einem einzigen Datagramm). Ein Verfahren für die Stapelverarbeitung von Paketköpfen hat eher die kollektive als die paketweise Verarbeitung von Protokollköpfen von mehreren verwandten Paketen durch einen Protokollstapel zur Folge. Eine weitere beispielhafte Funktion der NIC 100 enthält die Verteilung oder kollektive Nutzung dieser Protokollstapelverarbeitung (und/oder weiterer Funktionen) unter den Prozessoren in einem Mehrprozessor-Host-Computersystem. Eine nochmals weitere mögliche Funktion der NIC 100 ist es, die Übertragung wieder zusammengesetzter Daten in einer effizienten Aggregation (z. B. einer Speicherseite) zu einer Ziel-Entität (z. B. einem Anwendungsprogramm) zu ermöglichen, um dadurch die stückweise und stark ineffiziente Übertragungen der Daten immer nur eines Pakets zu vermeiden. Somit ist es in dieser Ausführungsform der Erfindung ein Zweck der FDB 110 und des FDBM 108, Informationen zur Verwendung der NIC 100 und/oder eines Host-Computersystems beim Freigeben, Sperren oder Ausführen einer oder mehrerer dieser Funktionen zu erzeugen.
  • Der assoziative Abschnitt 502 der FDB 110 in 5 speichert den Flussschlüssel jedes gültigen Flusses, der für eine durch die NIC 100 bediente Entität bestimmt ist. Somit enthält der assoziative Abschnitt 502 in einer Ausführungsform der Erfindung die IP-Quelladresse 510, die IP-Zieladresse 512, den TCP-Quellport 514 und den TCP-Zielport 516. Wie in einem früheren Abschnitt beschrieben wurde, können diese Felder durch den Kopfanalysealgorithmus 106 aus einem Paket extrahiert und an den FDBM 108 geliefert werden.
  • Obgleich jede durch die NIC 100 bediente Ziel-Entität an mehreren Kommunikationsflüssen oder Ende-Ende-TCP-Verbindungen teilnehmen kann, gibt es zwischen einer besonderen Quell-Entität und einer besonderen Ziel-Entität immer nur einen Fluss. Somit sollte jeder Flussschlüssel im assoziativen Abschnitt 502, der einem gültigen Fluss entspricht, gegenüber allen anderen gültigen Flüssen eindeutig sein. In alternativen Ausführungsformen der Erfindung ist der assoziative Abschnitt 502 aus verschiedenen Feldern gebildet, die alternative Flussschlüsselformen widerspiegeln, die durch die Protokolle, die durch den Kopfanalysealgorithmus syntaktisch analysiert werden, und durch die Informationen, die zum Identifizieren von Kommunikationsflüssen verwendet werden, bestimmt werden können.
  • In der veranschaulichten Ausführungsform enthält der assoziierte Abschnitt 504 einen Flussgültigkeitsanzeiger 520, eine Flussfolgenummer 522 und einen Flussaktivitätsanzeiger 524. Diese Felder liefern Informationen, die den Fluss betreffen, der durch den in dem entsprechenden Eintrag im assoziativen Abschnitt 502 gespeicherten Flussschlüssel identifiziert ist. Die Felder des assoziierten Abschnitts 504 können durch den FDBM 108 wie im folgenden Abschnitt beschrieben wiedergewonnen und/oder aktualisiert werden.
  • In dieser Ausführungsform zeigt der Flussgültigkeitsanzeiger 520 an, ob der assoziierte Fluss gültig oder ungültig ist. Beispielhaft wird der Flussgültigkeitsanzeiger so gesetzt, dass er einen gültigen Fluss anzeigt, wenn das erste Datenpaket in einem Fluss empfangen wird, wobei er jedes Mal, wenn ein Abschnitt des Datagramms (z. B. ein Paket) eines Flusses richtig empfangen wird, neu gesetzt werden kann, um die Gültigkeit eines Flusses wieder geltend zu machen.
  • Nachdem das letzte Datenpaket in einem Fluss empfangen worden ist, kann der Flussgültigkeitsanzeiger 520 als ungültig gekennzeichnet werden. Außerdem kann der Flussgültigkeitsanzeiger jedes Mal, wenn ein Fluss aus einem anderen Grund als dem Empfang eines letzten Datenpakets abgebaut (z. B. abgeschlossen oder abgebrochen) wird, gesetzt werden, um einen ungültigen Fluss anzuzeigen. Zum Beispiel kann ein Paket in der falschen Reihenfolge gegenüber anderen Paketen eines Datagramms empfangen werden, kann ein Steuerpaket empfangen werden, das anzeigt, dass eine Datenübertragung oder ein Datenfluss gerade abgebrochen wird, kann ein Versuch unternommen werden, einen Fluss neu aufzubauen oder neu zu synchronisieren (wobei in diesem Fall der Originalfluss abgebrochen wird) usw. In einer Ausführungsform der Erfindung ist der Flussgültigkeitsanzeiger 520 ein einzelnes Bit, ein Merker oder ein Wert.
  • In der veranschaulichten Ausführungsform enthält die Flussfolgenummer 522 eine Folgenummer des nächsten Datenabschnitts, der in dem assoziierten Fluss erwartet wird. Da das Datagramm, das in einem Fluss gesendet wird, typisch über mehrere Pakete empfangen wird, liefert die Flussfolgenummer einen Mechanismus, um sicherzustellen, dass die Pakete in der richtigen Reihenfolge empfangen werden. Zum Beispiel setzt die NIC 100 in einer Ausführungsform der Erfindung die Daten aus mehreren Paketen eines Datagramms wieder zusammen. Um dieses Wiederzusammensetzen auf die effizienteste Weise auszuführen, müssen die Pakete der Reihe nach empfangen werden. Somit speichert die Flussfolgenummer 522 einen Identifizierer zum Identifizieren des nächsten Datenpakets oder -abschnitts, das/der empfangen werden sollte.
  • In einer Ausführungsform der Erfindung entspricht die Flussfolgenummer 522 dem TCP-Folgenummernfeld, das in TCP-Protokollköpfen zu finden ist. Die TCP-Folgenummer eines Pakets identifiziert die Stellung der Daten des Pakets in Bezug auf andere Daten, die in einem Datagramm gesendet werden. Für Pakete und Flüsse, die andere Protokolle als das TCP betreffen, kann ein alternatives Verfahren verwendet werden, um den Empfang der Daten in der richtigen Reihenfolge zu überprüfen oder sicherzustellen.
  • Der Flussaktivitätsanzeiger 524 widerspiegelt in der veranschaulichten Ausführungsform die Neuheit der Aktivität eines Flusses oder, mit anderen Worten, das Alter eines Flusses. In dieser Ausführungsform der Erfindung ist der Flussaktivitätsanzeiger 524 einem Zähler wie etwa einem (in 5 nicht gezeigten) Flussaktivitätszähler zugeordnet. Der Flussaktivitätszähler wird jedes Mal aktualisiert (z. B. inkrementiert), wenn ein Paket als Teil eines bereits in der Flussdatenbank 110 gespeicherten Flusses empfangen wird. Der aktualisierte Zählerwert wird daraufhin in dem Flussaktivitätsanzeigerfeld des Flusses des Pakets gespeichert. Außerdem kann der Flussaktivitätszähler jedes Mal inkrementiert werden, wenn ein erstes Paket eines neuen Flusses empfangen wird, der zu der Datenbank hinzugefügt wird. In einer alternativen Ausführungsform wird ein Flussaktivitätszähler nur für Pakete aktualisiert, die Daten enthaften (während er z. B. für Steuerpakete nicht aktualisiert wird). In einer nochmals weiteren alternativen Ausführungsform werden mehrere Zähler verwendet, um die Flussaktivitätsanzeiger verschiedener Flüsse zu aktualisieren.
  • Da nicht immer bestimmt werden kann, wann ein Kommunikationsfluss geendet hat (z. B. kann das letzte Paket verloren gegangen sein), kann der Flussaktivitätsanzeiger verwendet werden, um Flüsse zu identifizieren, die veraltet sind oder aus einem anderen Grund abgebaut werden sollten. Falls die Flussdatenbank 110 z. B. vollständig bevölkert zu sein scheint (wobei z. B. der Flussgültigkeitsanzeiger 520 für jede Flussnummer gesetzt ist), wenn das erste Paket eines neuen Flusses empfangen wird, kann der Fluss mit dem niedrigsten Flussaktivitätsanzeiger durch den neuen Fluss ersetzt werden.
  • In der veranschaulichten Ausführungsform der Erfindung kann sich die Größe der Felder in der FDB 110 von einem Eintrag zum anderen unterscheiden. Zum Beispiel sind die IP-Quelladresse und die IP-Zieladresse in Version vier des Protokolls vier Bytes groß, während sie in Version sechs sechzehn Bytes groß sind. In einer alternativen Ausführungsform der Erfindung können die Einträge für ein besonderes Feld die gleiche Größe haben, wobei kleinere Einträge bei Bedarf aufgefüllt werden.
  • In einer weiteren alternativen Ausführungsform der Erfindung können Felder innerhalb der FDB 110 zusammengeführt werden. Insbesondere kann der Flussschlüssel eines Flusses als eine einzige Entität oder als ein einziges Feld gespeichert werden, anstatt als eine Anzahl getrennter Felder wie in 5 gezeigt gespeichert zu werden. Ähnlich sind in 5 der Flussgültigkeitsanzeiger 520, die Flussfolgenummer 522 und der Flussaktivitätsanzeiger 524 als getrennte Einträge gezeigt. Allerdings können in einer alternativen Ausführungsform der Erfindung einer oder mehrere dieser Einträge kombiniert sein. Insbesondere enthalten der Flussgültigkeitsanzeiger 520 und der Flussaktivitätsanzeiger 524 in einer alternativen Ausführungsform einen einzigen Eintrag mit einem ersten Wert (z. B. null), wenn der zugeordnete Fluss des Eintrags ungültig ist. Solange der Fluss gültig ist, wird der kombinierte Eintrag aber inkrementiert, während Pakete empfangen werden, und bei Abschluss des Flusses auf den ersten Wert zurückgesetzt.
  • In einer Ausführungsform der Erfindung enthält die FDB 110 maximal vierundsechzig Einträge, die durch die Flussnummer 506 indiziert sind, was somit ermöglicht, dass die Datenbank vierundsechzig gültige Flüsse gleichzeitig verfolgt. In alternativen Ausführungsformen der Erfindung können je nach der Größe des für die Flussdatenbank 110 zugeordneten Speichers mehr oder weniger Einträge zulässig sein. Außer durch die Flussnummer 506 kann ein Fluss durch seinen (im assoziativen Abschnitt 502 gespeicherten) Flussschlüssel identifizierbar sein.
  • In der veranschaulichten Ausführungsform der Erfindung ist die Flussdatenbank 110 leer (wobei z. B. alle Felder mit Nullen gefüllt sind), wenn die NIC 100 initialisiert wird. Wenn das erste Paket eines Flusses empfangen wird, analysiert der Kopfanalysealgorithmus 106 syntaktisch einen Kopfabschnitt des Pakets. Wie in einem früheren Abschnitt beschrieben wurde, setzt der Kopfanalysealgorithmus einen Flussschlüssel zum Identifizieren des Flusses zusammen und entnimmt weitere Informationen, die das Paket und/oder den Fluss betreffen. Der Flussschlüssel und die weiteren Informationen werden an den Flussdatenbankmanager 108 übergeben. Daraufhin durchsucht der FDBM 108 die FDB 110 nach einem aktiven Fluss, der dem Flussschlüssel zugeordnet ist. Da die Datenbank leer ist, gibt es keine Übereinstimmung.
  • In diesem Beispiel wird der Flussschlüssel somit dadurch (z. B. als Flussnummer null) gespeichert, dass die IP-Quelladresse, die IP-Zieladresse, der TCP-Quellport und der TCP-Zielport in die entsprechenden Felder kopiert werden. Daraufhin wird der Flussgültigkeitsanzeiger 520 so gesetzt, dass er einen gültigen Fluss anzeigt, wobei die Flussfolgenummer 522 aus der (beispielhaft von dem Kopfanalysealgorithmus gelieferten) TCP-Folgenummer abgeleitet wird und der Flussaktivitätsanzeiger 524 auf einen Anfangswert (z. B. auf eins) gesetzt wird, der aus einem Zeiger abgeleitet werden kann. Ein Verfahren zum Erzeugen einer geeigneten Flussfolgenummer, die verwendet werden kann, um zu überprüfen, dass der nächste für den Fluss empfangene Datenabschnitt in der richtigen Reihenfolge empfangen wird, ist es, die TCP-Folgenummer und die Größe der Daten des Pakets zu addieren. Je nach Konfiguration des Pakets (z. B. je nachdem, ob das SYN-Bit in einem Merkerfeld des TCP-Kopfs des Pakets gesetzt ist) muss die Summe aber möglicherweise (z. B. durch Addieren von eins) angepasst werden, um den nächsten erwarteten Datenabschnitt richtig zu identifizieren.
  • Wie oben beschrieben wurde, ist ein Verfahren zum Erzeugen eines geeigneten Anfangswerts für einen Flussaktivitätsanzeiger das Kopieren eines Zählerwerts, der für jedes als Teil eines Flusses empfangene Paket inkrementiert wird. Zum Beispiel kann ein Flussaktivitätszähler für das erste Paket, das nach Initialisieren der NIC 100 empfangen wird, auf den Wert eins inkrementiert werden. Dieser Wert kann daraufhin im Flussaktivitätsanzeiger 524 für den zugeordneten Fluss gespeichert werden. Das nächste als Teil des gleichen (oder eines neuen) Flusses empfangene Paket veranlasst, dass der Zähler auf zwei inkrementiert wird, wobei dieser Wert in dem Flussaktivitätsanzeiger für den zugeordneten Fluss gespeichert wird. In diesem Beispiel sollten keine zwei Flüsse mit Ausnahme bei der Initialisierung, wenn sie alle null sein können oder einen anderen im Voraus bestimmten Wert haben können, den gleichen Flussaktivitätsanzeiger haben.
  • Beim Empfang und syntaktischen Analysieren eines späteren in der NIC 100 empfangenen Pakets wird die Flussdatenbank nach einem gültigen Fluss durchsucht, der mit dem Flussschlüssel dieses Pakets übereinstimmt. Beispielhaft werden nur die Flussschlüssel aktiver Flüsse (z. B. jener Flüsse, für die der Flussgültigkeitsanzeiger 520 gesetzt ist) durchsucht. Alternativ können alle Flussschlüssel (z. B. alle Einträge im assoziativen Abschnitt 502) durchsucht werden, wobei aber nur dann eine Übereinstimmung berichtet wird, wenn sein Flussgültigkeitsanzeiger einen gültigen Fluss anzeigt. Bei einem CAM wie etwa der FDB 110 in 5 können Flussschlüssel und Flussgültigkeitsanzeiger parallel durchsucht werden.
  • Falls ein späteres Paket den nächsten Datenabschnitt für einen vorangegangenen Fluss (z. B. Flussnummer null) enthält, wird der Fluss geeignet aktualisiert. In einer Ausführungsform der Erfindung hat dies zur Folge, dass die Flussfolgenummer 522 aktualisiert und der Flussaktivitätsanzeiger 524 inkrementiert wird, um diese jüngste Aktivität zu widerspiegeln. Der Flussgültigkeitsanzeiger 520 kann ebenfalls gesetzt werden, um die Gültigkeit des Flusses anzuzeigen, obgleich er bereits anzeigen sollte, dass der Fluss gültig ist.
  • Während neue Flüsse identifiziert werden, werden sie auf ähnliche Weise wie der erste Fluss zur FDB 110 hinzugefügt. Wenn ein Fluss abgebrochen oder abgebaut wird, wird der zugeordnete Eintrag in der FDB 110 annulliert. In einer Ausführungsform der Erfindung wird der Flussgültigkeitsanzeiger 520 für den abgeschlossenen Fluss lediglich gelöscht (z. B. gleich null gesetzt). In einer weiteren Ausführungsform werden eines oder mehrere Felder eines abgeschlossenen Flusses gelöscht oder auf einen beliebigen oder vorgegebenen Wert gesetzt. Aufgrund des Bündelwesens des Netzpaketverkehrs werden alle oder die meisten Daten von einem Datagramm allgemein in einer kurzen Zeitdauer empfangen. Somit braucht jeder gültige Fluss in der FDB 110 normalerweise lediglich für kurze Zeitdauer aufrechterhalten zu werden, woraufhin sein Eintrag zum Speichern eines anderen Flusses verwendet werden kann.
  • Wegen der begrenzten Speichermenge, die in einer Ausführungsform der Erfindung für die Flussdatenbank 110 verfügbar ist, kann die Größe jedes Felds begrenzt sein. In dieser Ausführungsform sind für die IP-Quelladresse 510 sechzehn Bytes zugeordnet und sind für die IP-Zieladresse 512 sechzehn Bytes zugeordnet. Für IP-Adressen mit einer kürzeren Länge als sechzehn Bytes kann der Zusatzraum mit Nullen aufgefüllt werden. Ferner sind dem TCP-Quellport 514 und dem TCP-Zielport 516 jeweils zwei Bytes zugeordnet. Außerdem enthält der Flussgültigkeitsanzeiger 520 in dieser Ausführungsform ein Bit, sind der Flussfolgenummer 522 vier Bytes zugeordnet und sind dem Flussaktivitätsanzeiger 524 ebenfalls vier Bytes zugeordnet.
  • Wie oben beschrieben wurde, ist ein Fluss ähnlich, aber nicht gleich, einer Ende-Ende-TCP-Verbindung. Eine TCP-Verbindung kann für eine verhältnismäßig ver längerte Zeitdauer vorhanden sein, die ausreicht, mehrere Datagramme von einer Quell-Entität an eine Ziel-Entität zu übertragen. Dagegen kann ein Fluss lediglich für ein Datagramm vorhanden sein. Somit können während einer Ende-Ende-TCP-Verbindung mehrere Flüsse (z. B. einmal für jedes Datagramm) auf- und abgebaut werden. Wie oben beschrieben wurde, kann ein Fluss aufgebaut (z. B. zur FDB 110 hinzugefügt und als gültig gekennzeichnet) werden, wenn die NIC 100 den ersten Datenabschnitt in einem Datagramm erfasst, und abgebaut (z. B. in der FDB 110 als ungültig gekennzeichnet) werden, wenn der letzte Datenabschnitt empfangen wird. Beispielhaft hat jeder während einer einzigen Ende-Ende-TCP-Verbindung aufgebaute Fluss den gleichen Flussschlüssel, da die zum Bilden des Flussschlüssels verwendeten Schicht-Drei- und Schicht-Vier-Adressenidentifizierer und Schicht-Drei- und Schicht-Vier-Portidentifizierer die gleichen bleiben.
  • In der veranschaulichten Ausführungsform bestimmt die Größe der Flussdatenbank 110 (z. B. die Anzahl der Flusseinträge) die maximale Anzahl von Flüssen, die zu einer Zeit verschachtelt (z. B. gleichzeitig aktiv) sein können, während die Funktionen des Datenwiederzusammensetzens und der Stapelverarbeitung der Protokollköpfe freigegeben sind. Mit anderen Worten, in der in 5 gezeigten Ausführungsform kann die NIC 100 vierundsechzig Flüsse aufbauen und Pakete von bis zu vierundsechzig verschiedenen Datagrammen empfangen (d. h. können vierundsechzig Flüsse aktiv sein), ohne dass ein Fluss abgebaut wird. Falls eine Maximalzahl der Flüsse durch die NIC 100 bekannt wäre, könnte die Flussdatenbank 110 auf die entsprechende Anzahl von Einträgen beschränkt sein.
  • Da ein Fluss in der derzeit beschriebenen Ausführungsform nur ein Datagramm dauert und da die Pakete eines Datagramms wegen des Bündelwesens des Paketverkehrs allgemein in kurzer Zeitdauer empfangen werden, kann die Flussdatenbank klein gehalten werden. Die kurze Dauer eines Flusses gleicht eine beschränkte Anzahl von Einträgen in der Flussdatenbank aus. Falls die FDB 110 in einer Ausführungsform der Erfindung mit aktiven Flüssen gefüllt ist und ein neuer Fluss (d. h. ein erster Datenabschnitt in einem neuen Datagramm) begonnen wird, wird der älteste (z. B. der am wenigsten kurz zuvor aktive) Fluss durch den neuen ersetzt.
  • In einer alternativen Ausführungsform der Erfindung können Flüsse für irgendeine Anzahl von Datagrammen (oder ein anderes Maß des Netzverkehrs) oder für eine angegebene Zeitdauer oder für einen angegebenen Zeitbereich aktiv gehalten werden. Wenn ein Datagramm endet, kann z. B. sein Fluss in der FDB 110 "offen" gehalten werden (d. h. nicht abgebaut werden), falls die Datenbank nicht voll ist (z. B., wenn der Eintrag des Flusses nicht für einen anderen Fluss benötigt wird). Dieses Schema kann den effizienten Betrieb der NIC 100 weiter verbessern, falls ein weiteres Datagramm mit dem gleichen Flussschlüssel empfangen wird. Insbesondere wird die am Aufbau eines weiteren Flusses beteiligte Zusatzbelastung vermieden und können mehr Datenwiederzusammensetzung und Paketstapelbearbeitung (wie im Folgenden beschrieben) ausgeführt werden. Vorteilhaft kann ein Fluss in der Flussdatenbank 110 offen gehalten werden, bis die Ende-Ende-TCP-Verbindung, die den Fluss enthält, endet.
  • Eine Ausführungsform eines Flussdatenbankmanagers
  • Die 6A–6E zeigen ein Verfahren des Betriebs eines Flussdatenbankmanagers (FDBM) wie etwa des Flussdatenbankmanagers 108 aus 1A für das Management der Flussdatenbank (FDB) 110. Beispielhaft speichert und aktualisiert der FDBM 108 in der Flussdatenbank 110 gespeicherte Flussinformationen, wobei er einen Operationscode für ein durch die NIC 100 empfangenes Paket erzeugt. Außerdem baut der FDBM 108 einen Fluss ab (ersetzt, entfernt oder annulliert er auf andere Weise z. B. einen Eintrag in der FDB 110), wenn der Fluss abgeschlossen oder abgebrochen wird.
  • In einer Ausführungsform der Erfindung widerspiegelt der Operationscode eines Pakets die Kompatibilität des Pakets mit im Voraus bestimmten Kriterien zur Ausführung einer oder mehrerer Funktionen der NIC 100 (z. B. Datenwiederzusammensetzung, Stapelverarbeitung von Paketköpfen, Lastverteilung). Mit anderen Worten, je nach dem Operationscode eines Pakets können andere Module der NIC 100 eine dieser Funktionen ausführen oder nicht ausführen.
  • In einer weiteren Ausführungsform der Erfindung zeigt ein Operationscode einen Paketstatus an. Zum Beispiel kann ein Operationscode anzeigen, dass ein Paket: keine Daten enthält, ein Steuerpaket ist, mehr als eine angegebene Menge Daten enthält, das erste Paket eines neuen Flusses ist, das letzte Paket eines vorhandenen Flusses ist, außer der Reihe ist, einen bestimmten Merker (z. B. in einem Protokollkopf) enthält, der nicht einen erwarteten Wert besitzt (und somit möglicherweise einen Ausnahmeumstand anzeigt), usw.
  • Der Betrieb des Flussdatenbankmanagers 108 hängt von den vom Kopfanalysealgorithmus 106 gelieferten Paketinformationen und von den der Flussdatenbank 110 entnommenen Daten ab. Nachdem der FDBM 108 die Paketinformationen und/oder -daten verarbeitet hat, werden die Steuerinformationen (z. B. der Operationscode des Pakets) in der Steuerwarteschlange 118 gespeichert, wobei die FDB 110 geändert werden kann (z. B. ein neuer Fluss eingegeben werden kann oder ein vorhandener aktualisiert oder abgebaut werden kann).
  • Nunmehr anhand der 6A–6E ist der Zustand 600 ein Startzustand, in dem der FDBM 108 auf Informationen wartet, die einem durch die NIC 100 vom Netz 102 empfangenen Paket entnommen werden. Im Zustand 602 benachrichtigt der Kopfanalysealgorithmus 106 oder ein anderes Modul der NIC 100 den FDBM 108 über ein neues Paket, indem er den Flussschlüssel des Pakets und einige Steuerinformationen liefert. Der Empfang dieser Daten kann als eine Anforderung interpretiert werden, die FDB 110 zu durchsuchen, um zu bestimmen, ob bereits ein Fluss mit diesem Flussschlüssel vorhanden ist.
  • In einer Ausführungsform der Erfindung enthalten die an den FDBM 108 übergebenen Steuerinformationen eine Folgenummer (z. B. eine TCP-Folgenummer), die einem Paketkopf entnommen wird. Außerdem können die Steuerinformationen den Status bestimmter Merker im Kopf des Pakets, ob das Paket Daten enthält und, wenn das der Fall ist, ob die Datenmenge eine bestimmte Größe überschreitet, anzeigen. In dieser Ausführungsform empfängt der FDBM 108 außerdem ein No_Assist-Signal für ein Paket, falls der Kopfanalysealgorithmus wie in einem früheren Abschnitt bestimmt, dass das Paket nicht in Übereinstimmung mit einem der im Voraus gewählten Protokollstapel formatiert ist (d. h., dass das Paket nicht "kompatibel" ist). Beispielhaft zeigt das No_Assist-Signal an, dass eine oder mehrere Funktionen der NIC 100 (z. B. Datenwiederzusammensetzung, Stapelverarbeitung, Lastausgleich) für das Paket nicht bereitgestellt werden können.
  • Im Zustand 604 bestimmt der FDBM 108, ob für das Paket ein No_Assist-Signal aktiviert worden ist. Wenn das der Fall ist, geht die Prozedur zum Zustand 668 (6E) über. Andernfalls durchsucht der FDBM 108 die FDB 110 im Zustand 606 nach dem Flussschlüssel des Pakets. In einer Ausführungsform der Erfindung werden nur gültige Flusseinträge in der Flussdatenbank durchsucht. Wie oben diskutiert wurde, kann die Gültigkeit eines Flusses durch einen Gültigkeitsanzeiger wie etwa den (in 5 gezeigten) Flussgültigkeitsanzeiger 520 widerspiegelt werden. Falls im Zustand 608 bestimmt wird, dass der Flussschlüssel des Pakets in der Datenbank nicht ermittelt wurde oder dass eine Übereinstimmung gefunden wurde, der zugeordnete Fluss aber nicht gültig ist, rückt die Prozedur zum Zustand 646 (6D) vor.
  • Falls in der Flussdatenbank eine gültige Übereinstimmung ermittelt wird, wird im Zustand 610 die Flussnummer (z. B. der Flussdatenbankindex für den übereinstimmenden Eintrag) des übereinstimmenden Flusses notiert, wobei die in der FDB 110 gespeicherten Informationen gelesen werden. Beispielhaft enthalten diese Informationen den Flussgültigkeitsanzeiger 520, die Flussfolgenummer 522 und den Flussaktivitätsanzeiger 524 (die in 5 gezeigt sind).
  • Im Zustand 612 bestimmt der FDBM 108 aus den vom Kopfanalysealgorithmus 106 empfangenen Informationen, ob das Paket TCP-Nutzdaten enthält. Wenn das nicht der Fall ist, geht die veranschaulichte Prozedur zum Zustand 638 (6C) über; andernfalls wird die Prozedur mit dem Zustand 614 fortgesetzt.
  • Im Zustand 614 bestimmt der Flussdatenbankmanager, ob das Paket einen Versuch zum Zurücksetzen einer Kommunikationsverbindung oder eines Kommunikationsflusses bildet. Beispielhaft kann dies dadurch bestimmt werden, dass der Zustand eines SYN-Bits in einem der Protokollköpfe (z. B. in einem TCP-Kopf) des Pakets untersucht wird. In einer Ausführungsform der Erfindung wird der Wert eines oder mehrerer Steuer- oder Merkerbits (wie etwa des SYN-Bits) durch den Kopfanalysealgorithmus an den FDBM geliefert. Eine TCP-Entität kann versuchen, einen Kommunikationsfluss oder eine Kommunikationsverbindung mit einer anderen Entität (z. B. wegen eines Problems in einem der Host-Computer der Entität) zurückzusetzen und zusammen mit der Wiederverbindungsanforderung einen ersten Datenabschnitt senden. Dies ist die Situation, die der Flussdatenbankmanager im Zustand 614 zu erkennen versucht. Falls das Paket Teil eines Versuchs zum Wiederverbinden oder Zurücksetzen eines Flusses oder einer Verbindung ist, wird die Prozedur im Zustand 630 (6C) fortgesetzt.
  • Im Zustand 616 vergleicht der Flussdatenbankmanager 108 eine aus einem Paketkopf extrahierte Folgenummer (z. B. eine TCP-Folgenummer) mit einer Folgenummer (z. B. der Flussfolgenummer 522 aus 5) des nächsten erwarteten Datenabschnitts für diesen Fluss. Beispielhaft sollten diese Folgenummern korrelieren, falls das Paket den nächsten Datenabschnitt des Flusses enthält. Falls die Folgenummern nicht übereinstimmen, wird die Prozedur im Zustand 628 fortgesetzt.
  • Im Zustand 618 bestimmt der FDBM 108, ob bestimmte aus einem oder aus mehreren Protokollköpfen des Pakets extrahierte Merker mit erwarteten Werten übereinstimmen. Zum Beispiel wird in einer Ausführungsform der Erfindung erwartet, dass der URG-, der PSH-, der RST- und der FIN-Merker aus dem TCP-Kopf des Pakets gelöscht sind (d. h. gleich null sind). Falls irgendeiner dieser Merker gesetzt (z. B. gleich eins) ist, kann eine Ausnahmebedingung vorliegen, die somit ermöglicht, dass eine oder mehrere der von der NIC 100 angebotenen Funktionen (z. B. Datenwiederzusammensetzung, Stapelverarbeitung, Lastverteilung) für dieses Paket nicht ausgeführt werden sollten. Solange die Merker gelöscht sind, wird die Prozedur im Zustand 620 fortgesetzt; andernfalls wird die Prozedur im Zustand 626 fortgesetzt.
  • Im Zustand 620 bestimmt der Flussdatenbankmanager, ob während dieses Flusses weitere Daten erwartet werden. Wie oben erläutert wurde, kann die Dauer eines Flusses auf ein einzelnes Datagramm beschränkt sein. Somit bestimmt der FDBM im Zustand 620, ob dieses Paket der letzte Datenabschnitt für das Datagramm dieses Flusses zu sein scheint. Beispielhaft erfolgt diese Bestimmung anhand der bei dem vorliegenden Paket enthaltenen Datenmenge. Ein Datagramm, das mehr Daten enthält, als in einem Paket übermittelt werden können, wird über mehrere Pakete gesendet. Die typische Art und Weise, ein Datagramm auf mehrere Pakete zu verteilen, ist es, soviel Daten wie möglich in jedes Paket zu legen. Somit hat jedes Paket bis auf das letzte üblicherweise die gleiche oder nahezu gleiche Größe wie die größte Übertragungseinheit (MTU), die für das Netz, über das die Pakete gesendet werden, zulässig ist. Das letzte Paket hält den Rest, was üblicherweise veranlasst, dass es kleiner als die MTU ist.
  • Somit ist eine Art und Weise des Identifizierens des letzten Datenabschnitts im Datagramm eines Flusses, die Größe jedes Pakets zu untersuchen und mit einer Zahl (z. B. der MTU) zu vergleichen, von der erwartet wird, dass sie ein Paket, außer wenn es den letzten Datenabschnitt übermittelt, überschreitet. Zuvor wurde beschrieben, dass durch den FDBM 108 Steuerinformationen vom Kopfanalysealgorithmus 106 empfangen werden. In diesen Informationen kann eine Angabe der Größe der durch ein Paket übermittelten Daten enthalten sein. Insbesondere ist der Kopfanalysealgorithmus 106 in einer Ausführungsform der Erfindung so konfiguriert, dass er die Größe des Datenabschnitts jedes Pakets mit einem im Voraus gewählten Wert vergleicht. In einer Ausführungsform der Erfindung ist dieser Wert programmierbar. In der veranschaulichten Ausführungsform der Erfindung wird dieser Wert auf die maximale Datenmenge gesetzt, die ein Paket übermitteln kann, ohne die MTU zu überschreiten. In einer alternativen Ausführungsform wird der Wert auf eine Menge gesetzt, die etwas kleiner als die maximale Datenmenge ist, die übermittelt werden kann.
  • Somit bestimmt der Flussdatenbankmanager 108 im Zustand 620, ob das empfangene Paket den letzten Datenabschnitt für das Datagramm des Flusses zu übermitteln scheint. Wenn das nicht der Fall ist, wird die Prozedur im Zustand 626 fortgesetzt.
  • Im Zustand 622 ist sichergestellt worden, dass das Paket mit den im Voraus gewählten Protokollen kompatibel und für eine oder mehrere von der NIC 100 gebotene Funktionen geeignet ist. Insbesondere ist das Paket geeignet für eine oder mehrere der oben diskutierten Funktionen formatiert worden. Der FDBM 108 hat bestimmt, dass das empfangene Paket Teil eines vorhandenen Flusses ist, mit den im Voraus gewählten Protokollen kompatibel ist und den nächsten Datenabschnitt für den Fluss (jedoch nicht den letzten Abschnitt) enthält. Ferner ist das Paket nicht Teil eines Versuchs zum Zurücksetzen eines Flusses/einer Verbindung und haben wichtige Merker ihre erwarteten Werte. Somit kann die Flussdatenbank 110 wie folgt aktualisiert werden.
  • Der Aktivitätsanzeiger (z. B. der Flussaktivitätsanzeiger 524 aus 5) für diesen Fluss wird modifiziert, um die jüngste Flussaktivität zu widerspiegeln. In einer Ausführungsform der Erfindung ist der Flussaktivitätsanzeiger 524 als ein Zähler implementiert oder einem Zähler zugeordnet, der jedes Mal inkrementiert wird, wenn Daten für einen Fluss empfangen werden. In einer weiteren Ausführungsform der Erfindung wird ein Aktivitätsanzeiger oder -zähler jedes Mal aktualisiert, wenn ein Paket mit einem Flussschlüssel empfangen wird, der mit einem gültigen Fluss übereinstimmt (z. B. gleich, ob das Paket Daten enthält oder nicht).
  • Nachdem ein Flussaktivitätsanzeiger oder -zähler inkrementiert worden ist, wird er in der veranschaulichten Ausführungsform untersucht, um zu bestimmen, ob er auf null "übergelaufen" ist (d. h., ob er über seinen Maximalwert hinaus inkremen tiert worden ist). Wenn das der Fall ist, werden der Zähler und/oder die Flussaktivitätsanzeiger für jeden Eintrag in der Flussdatenbank 110 auf null gesetzt und wird der Aktivitätsanzeiger des momentanen Flusses noch einmal inkrementiert. Somit veranlasst in einer Ausführungsform der Erfindung der Überlauf eines Flussaktivitätszählers oder -anzeigers die Neuinitialisierung des Flussaktivitätsmechanismus für die Flussdatenbank 110. Anschließend wird der Zähler inkrementiert und werden die Flussaktivitätsanzeiger wie zuvor beschrieben noch einmal aktualisiert. Somit können in einer Ausführungsform der vorliegenden Erfindung viele weitere geeignete Verfahren angewendet werden, um anzuzeigen, dass ein Fluss in jüngerer Zeit als ein anderer aktiv war.
  • Außerdem wird im Zustand 622 die Flussfolgenummer 522 aktualisiert. Beispielhaft wird die neue Flussfolgenummer dadurch bestimmt, dass zu der vorhandenen Flussfolgenummer die Größe der neu empfangenen Daten addiert wird. Diese Summe muss möglicherweise je nach der Konfiguration des Pakets (z. B. den Werten in seinen Köpfen) angepasst werden. Zum Beispiel kann diese Summe einfach die Gesamtmenge der bisher für das Datagramm des Flusses empfangenen Daten anzeigen. Somit muss möglicherweise ein Wert (z. B. ein Byte) addiert werden, um eine Folgenummer des nächsten Datenbytes für das Datagramm anzuzeigen. Anstelle des hier beschriebenen Schemas können andere geeignete Verfahren verwendet werden, um sicherzustellen, dass die Daten in der richtigen Reihenfolge empfangen werden.
  • Schließlich wird der Flussgültigkeitsanzeiger 520 im Zustand 622 in einer Ausführungsform der Erfindung gesetzt oder zurückgesetzt, um die Gültigkeit des Flusses anzuzeigen.
  • Daraufhin wird dem Paket im Zustand 624 ein Operationscode zugeordnet. In der veranschaulichten Ausführungsform der Erfindung enthalten Operationscodes Codes, die durch den Flussdatenbankmanager 108 erzeugt und in der Steuerwarteschlange 118 gespeichert werden. In dieser Ausführungsform hat ein Operationscode eine Größe von drei Bytes, was acht Operationscodes ermöglicht. In alternativen Ausführungsformen können Operationscodes eine Vielzahl anderer Formen und Bereiche haben. Für die veranschaulichte Ausführungsform der Erfindung beschreibt TABELLE 1 jeden Operationscode hinsichtlich der Kriterien, die zur Auswahl jedes Codes führen, sowie der Verzweigungen dieser Auswahl. Für TABELLE 1 enthält das Aufbauen eines Flusses das Einsetzen eines Flusses in die Flussdatenbank 110. Das Abbauen eines Flusses enthält das Entfernen oder Annullieren eines Flusses in der Flussdatenbank 110. Durch die DMA-Maschine 120 kann ein Wiederzusammensetzen von Daten ausgeführt werden.
  • In der veranschaulichten Ausführungsform der Erfindung wird im Zustand 624 für Pakete im vorliegenden Kontext der Prozedur (z. B. kompatible Pakete, die den nächsten, aber nicht den letzten Datenabschnitt eines Flusses übermitteln) der Operationscode 4 ausgewählt. Somit wird der vorhandene Fluss nicht abgebaut und besteht keine Notwendigkeit, einen neuen Fluss aufzubauen. Wie oben beschrieben wurde, ist ein kompatibles Paket in dieser Ausführungsform ein Paket, das zu einem oder mehreren der im Voraus gewählten Protokolle konform ist. In einer alternativen Ausführungsform der Erfindung kann durch Ändern oder Ergänzen der im Voraus gewählten Protokolle praktisch irgendein Paket kompatibel sein.
  • Nunmehr zurückkehrend zu den 6A–6E endet die veranschaulichte Prozedur nach dem Zustand 624 im Zustand 670.
  • In dem (vom Zustand 618 oder vom Zustand 620 erreichten) Zustand 626 wird für das Paket der Operationscode 3 ausgewählt. Beispielhaft zeigt der Operationscode 3 an, dass das Paket kompatibel ist und mit einem gültigen Fluss übereinstimmt (wobei z. B. der Flussschlüssel des Pakets mit dem Flussschlüssel eines gültigen Flusses in der FDB 110 übereinstimmt). Außerdem kann der Operationscode 3 bedeuten, dass das Paket Daten enthält, keinen Versuch zum Neusynchronisieren oder Zurücksetzen eines Kommunikationsflusses/einer Kommunikationsverbindung bildet und dass die Folgenummer des Pakets mit der erwarteten Folgenummer (aus der Flussdatenbank 110) übereinstimmt. Allerdings ist entweder ein wichtiger Merker (z. B. einer der TCP-Merker URG, PSH, RST oder FIN) gesetzt (was im Zustand 618 bestimmt wird) oder sind die Daten des Pakets kleiner als der oben (im Zustand 620) beschriebene Schwellenwert, was somit anzeigt, dass auf dieses Paket in diesem Fluss wahrscheinlich keine weiteren Daten folgen. Somit wird der vorhandene Fluss abgebaut, aber kein neuer Fluss erzeugt. Beispielhaft kann der Fluss dadurch abgebaut werden, dass der Gültigkeitsanzeiger des Flusses gelöscht (z. B. auf null gesetzt) wird. Nach dem Zustand 626 endet die veranschaulichte Prozedur im Zustand 670.
  • Im Zustand 628 (der vom Zustand 616 erreicht wird) wird für das Paket der Operationscode 2 ausgewählt. Im vorliegenden Kontext kann der Operationscode 2 anzeigen, dass das Paket kompatibel ist, mit einem gültigen Fluss übereinstimmt (wobei z. B. der Flussschlüssel des Pakets mit dem Flussschlüssel eines gültigen Flusses in der FDB 110 übereinstimmt), Daten enthält und keinen Versuch zum Neusynchronisieren oder Zurücksetzen eines Kommunikationsflussesleiner Kommunikationsverbindung bildet. Allerdings stimmt die (im Zustand 616) aus dem Paket extrahierte Folgenummer nicht mit der erwarteten Folgenummer aus der Flussdatenbank 110 überein. Dies kann z. B. geschehen, wenn das Paket außer der Reihe empfangen wird. Somit wird der vorhandene Fluss abgebaut, jedoch kein neuer Fluss aufgebaut. Beispielhaft kann der Fluss dadurch abgebaut werden, dass der Gültigkeitsanzeiger des Flusses gelöscht (z. B. auf null gesetzt) wird. Nach dem Zustand 628 endet die veranschaulichte Prozedur im Zustand 670.
  • In den Zustand 630 wird vom Zustand 614 eingetreten, wenn bestimmt wird, dass das empfangene Paket einen Versuch zum Zurücksetzen eines Kommunikationsflusses oder einer Kommunikationsverbindung bildet (wobei z. B. das TCP-SYN-Bit gesetzt ist). Im Zustand 630 bestimmt der Flussdatenbankmanager 108, ob erwartet wird, dass weitere Daten folgen. Wie in Verbindung mit dem Zustand 620 erläutert wurde, kann diese Bestimmung anhand von Steuerinformationen erfolgen, die durch den Flussdatenbankmanager vom Kopfanalysealgorithmus empfangen werden. Falls weitere Daten erwartet werden (falls z. B die Datenmenge in dem Paket gleich oder größer als ein Schwellenwert ist), wird die Prozedur im Zustand 634 fortgesetzt.
  • Im Zustand 632 wird für das Paket der Operationscode 2 ausgewählt. Der Operationscode 2 wurde außerdem im Zustand 628 in einem anderen Kontext ausgewählt. Im vorliegenden Kontext kann der Operationscode 2 anzeigen, dass das Paket kompatibel ist, mit einem gültigen Fluss übereinstimmt und Daten enthält. Außerdem kann der Operationscode 2 in diesem Kontext bedeuten, dass das Paket einen Versuch zum Neusynchronisieren oder Zurücksetzen eines Kommunikationsflusses oder einer Kommunikationsverbindung bildet, dass aber keine weiteren Daten erwartet werden, wenn der Fluss/die Verbindung zurückgesetzt wird. Somit wird der vorhandene Fluss abgebaut und kein neuer Fluss aufgebaut. Beispielhaft kann der Fluss durch Löschen des Gültigkeitsanzeigers des Flusses (z. B. dadurch, dass er auf null gesetzt wird) abgebaut werden. Nach dem Zustand 632 endet die veranschaulichte Prozedur im Zustand 670.
  • Im Zustand 634 reagiert der Flussdatenbankmanager 108 auf einen Versuch, einen Kommunikationsfluss/eine Kommunikationsverbindung zurückzusetzen oder neu zu synchronisieren, wodurch zusätzliche Daten erwartet werden. Somit wird der vorhandene Fluss abgebaut und wie folgt ersetzt. Der vorhandene Fluss kann durch die im Zustand 610 wiedergewonnene Flussnummer oder durch den Flussschlüssel des Pakets identifiziert werden. Die Folgenummer des Flusses (z. B. die Flussfolgenummer 522 in 5) wird auf den nächsten erwarteten Wert gesetzt. Beispielhaft hängt dieser Wert von der aus dem Paket (z. B. durch den Kopfanalysealgorithmus 106) wiedergewonnenen Folgenummer (z. B. von der TCP-Folgenummer) und von der in dem Paket enthaltenen Datenmenge ab. In einer Ausführungsform der Erfindung werden diese zwei Werte addiert, um eine neue Flussfolgenummer zu bestimmen. Wie zuvor diskutiert worden ist, muss diese Summe möglicherweise (z. B. durch Addieren von eins) angepasst werden. Außerdem wird im Zustand 634 der Flussaktivitätsanzeiger aktualisiert (z. B. inkrementiert). Wie in Verbindung mit dem Zustand 622 erläutert worden ist, werden die Aktivitätsanzeiger für alle Flüsse in der Datenbank auf null gesetzt und wird der vorhandene Fluss erneut inkrementiert, falls der Flussaktivitätsanzeiger überläuft. Schließlich wird der Flussgültigkeitsanzeiger gesetzt, um anzugeben, dass der Fluss gültig ist.
  • Im Zustand 636 wird für das Paket der Operationscode 7 ausgewählt. Im vorliegenden Kontext zeigt der Operationscode 7 an, dass das Paket kompatibel ist, mit einem gültigen Fluss übereinstimmt und Daten enthält. Ferner kann der Operationscode 7 in diesem Kontext bedeuten, dass das Paket einen Versuch zum Neusynchronisieren oder Zurücksetzen eines Kommunikationsflussesleiner Kommunikationsverbindung bildet und dass zusätzliche Daten erwartet werden, wenn der Fluss/die Verbindung zurückgesetzt wird. Somit wird der vorhandene Fluss tatsächlich abgebaut und an seiner Stelle ein neuer (mit dem gleichen Flussschlüssel) gespeichert. Nach dem Zustand 636 endet die veranschaulichte Prozedur im Endzustand 670.
  • Wenn nach dem Zustand 612 bestimmt worden ist, dass das empfangene Paket keine Daten enthält, wird in den Zustand 638 eingetreten. Dies zeigt häufig an, dass das Paket ein Steuerpaket ist. Im Zustand 638 bestimmt der Flussdatenbankmanager 108, ob einer oder mehrere durch den Kopfanalysealgorithmus aus dem Paket extrahierte Merker mit den erwarteten oder gewünschten Werten übereinstimmen. Zum Beispiel müssen in einer Ausführungsform der Erfindung die TCP-Merker URG, PSH, RST und FIN gelöscht sein, damit die DMA-Maschine 120 Daten aus mehreren verwandten Paketen (z. B. aus Paketen mit einem gleichen Flussschlüssel) wieder zusammensetzt. Wie oben diskutiert wurde, kann außerdem das TCP-SYN-Bit untersucht werden. Im vorliegenden Kontext (z. B. ein Paket ohne Daten) wird ebenfalls erwartet, dass das SYN-Bit gelöscht ist (z. B. einen Wert null speichert). Falls die Merker (und das SYN-Bit) ihre erwarteten Werte haben, wird die Prozedur im Zustand 642 fortgesetzt. Falls dagegen irgendwelche dieser Merker gesetzt sind, kann eine Ausnahmebedingung vorliegen, was somit ermöglicht, dass eine oder mehrere von der NIC 100 gebotene Funktionen (z. B. Datenwiederzusammensetzung, Stapelverarbeitung, Lastverteilung) für dieses Paket ungeeignet sind, wobei die Prozedur in diesem Fall zum Zustand 640 übergeht.
  • Im Zustand 640 wird für das Paket der Operationscode 1 ausgewählt. Beispielhaft zeigt der Operationscode 1 an, dass das Paket kompatibel ist und mit einem gültigen Fluss übereinstimmt, jedoch keine Daten enthält und einer oder mehrere wichtige Merker oder Bits im Kopf bzw. in den Köpfen des Pakets gesetzt sind. Somit wird der vorhandene Fluss abgebaut und kein neuer Fluss aufgebaut. Beispielhaft kann der Fluss durch Löschen des Gültigkeitsanzeigers des Flusses (z. B. dadurch, dass er auf null gesetzt wird) abgebaut werden. Nach dem Zustand 640 endet die veranschaulichte Prozedur im Endzustand 670.
  • Im Zustand 642 wird der Aktivitätsanzeiger des Flusses aktualisiert (z. B. inkrementiert), obgleich das Paket keine Daten enthält. Wie oben in Verbindung mit dem Zustand 622 beschrieben worden ist, werden in der vorliegenden Ausführungsform der Erfindung alle Flussaktivitätsanzeiger in der Datenbank auf null gesetzt und wird der momentane Fluss erneut inkrementiert, falls der Aktivitätsanzeiger überläuft. Der Gültigkeitsanzeiger des Flusses sowie die Folgenummer des Flusses können ebenfalls zurückgesetzt werden.
  • Im Zustand 644 wird für das Paket der Operationscode 0 ausgewählt. Beispielhaft zeigt der Operationscode 0 an, dass das Paket kompatibel ist, mit einem gültigen Fluss übereinstimmt und keine Daten enthält. Das Paket kann z. B. ein Steuerpaket sein. Ferner zeigt der Operationscode 0 an, dass keiner der durch den Kopfanalysealgorithmus 106 geprüften und oben beschriebenen Merker (z. B. URG, PSH, RST und FIN) gesetzt ist. Somit wird der vorhandene Fluss nicht abgebaut und kein neuer Fluss aufgebaut. Nach dem Zustand 644 endet die veranschaulichte Prozedur im Endzustand 670.
  • In den Zustand 646 wird vom Zustand 608 eingetreten, falls der Flussschlüssel des Pakets mit keinem der Flussschlüssel gültiger Flüsse in der Flussdatenbank übereinstimmt. Im Zustand 646 bestimmt der FDBM 108, ob die Flussdatenbank 110 voll ist, wobei er eine Anzeige dessen sichern kann, ob die Datenbank voll ist. In einer Ausführungsform der Erfindung wird die Flussdatenbank als voll betrachtet, wenn der Gültigkeitsanzeiger (z. B. der Flussgültigkeitsanzeiger 520 aus 5) für jede Flussnummer (z. B. für jeden Fluss in der Datenbank) gesetzt ist. Falls die Datenbank voll ist, wird die Prozedur im Zustand 650 fortgesetzt, während sie andernfalls im Zustand 648 fortgesetzt wird.
  • Im Zustand 648 wird die niedrigste Flussnummer eines ungültigen Flusses (z. B. eines Flusses, für den der zugeordnete Flussgültigkeitsanzeiger gleich null ist) bestimmt. Beispielhaft gibt es diese Flussnummer dort, wo ein neuer Fluss gespeichert wird, falls das empfangene Paket die Erzeugung eines neuen Flusses gewährleistet. Nach dem Zustand 648 wird die Prozedur im Zustand 652 fortgesetzt.
  • Im Zustand 650 wird die Flussnummer des am wenigsten kurz zuvor aktiven Flusses bestimmt. Wie oben diskutiert wurde, wird in der veranschaulichten Ausführungsform der Erfindung jedes Mal, wenn Daten für einen Fluss empfangen werden, ein Aktivitätsanzeiger des Flusses (z. B. der Flussaktivitätsanzeiger 524 aus 5) aktualisiert (z. B. inkrementiert). Somit kann der am wenigsten kurz zuvor aktive Fluss in dieser Ausführungsform als der Fluss mit dem am wenigsten kurz zuvor aktualisierten (z. B. niedrigsten) Flussaktivitätsanzeiger identifiziert werden. Falls die Flussaktivitätsanzeiger mehrerer Flüsse auf einen gemeinsamen Wert (z. B. null) gesetzt sind, kann beispielhaft eine Flussnummer von ihnen willkürlich oder durch gewisse andere Kriterien gewählt werden. Nach dem Zustand 650 wird die Prozedur im Zustand 652 fortgesetzt.
  • Im Zustand 652 bestimmt der Flussdatenbankmanager 108, ob das Paket Daten enthält. Beispielhaft zeigen die durch den Kopfanalysealgorithmus an den FDBM 108 gelieferten Steuerinformationen an, ob das Paket Daten besitzt. Falls das Paket keine Daten enthält (falls das Paket z. B. ein Steuerpaket ist), wird die veranschaulichte Prozedur im Zustand 668 fortgesetzt.
  • Im Zustand 654 bestimmt der Flussdatenbankmanager 108, ob die mit dem vorliegenden Paket empfangenen Daten den letzten Datenabschnitt für das zugeordnete Datagramm/den zugeordneten Fluss zu enthalten scheinen. Wie in Verbindung mit dem Zustand 620 beschrieben wurde, kann diese Bestimmung anhand der bei dem Paket enthaltenen Datenmenge erfolgen. Falls die Datenmenge kleiner als ein Schwellenwert (in der veranschaulichten Ausführungsform ein programmierbarer Wert) ist, werden keine weiteren Daten erwartet, wobei dies wahrscheinlich die einzigen Daten für diesen Fluss sind. In diesem Fall wird die Prozedur im Zustand 668 fortgesetzt. Falls die Daten dagegen den Schwellenwert erfüllen oder überschreiten, in welchem Fall weitere Daten erwartet werden, geht die Prozedur zum Zustand 656 über.
  • Im Zustand 656 werden die Werte gewisser Merker untersucht. Diese Merker können z. B. das URG-, das PSH-, das RST- und das FIN-Bit eines TCP-Kopfs enthalten. Falls irgendeiner der untersuchten Merker nicht seinen erwarteten oder erwünschten Wert hat (falls z. B. irgendeiner der Merker gesetzt ist), kann eine Ausnahmebedingung vorliegen, die eine oder mehrere der Funktionen der NIC 100 (z. B. Datenwiederzusammensetzung, Stapelverarbeitung, Lastverteilung) ungeeignet für dieses Paket macht. In diesem Fall wird die Prozedur im Zustand 668 fortgesetzt; andernfalls geht die Prozedur zum Zustand 658 über.
  • Im Zustand 658 gewinnt der Flussdatenbankmanager die im Zustand 646 gespeicherten Informationen wieder, die die Frage betreffen, ob die Flussdatenbank 110 voll ist. Falls die Datenbank voll ist, wird die Prozedur im Zustand 664 fortgesetzt; andernfalls wird die Prozedur im Zustand 660 fortgesetzt.
  • Im Zustand 660 wird für das vorliegende Paket ein neuer Fluss zur Flussdatenbank 110 hinzugefügt. Beispielhaft wird der neue Fluss bei der im Zustand 648 identifizierten oder wiedergewonnenen Flussnummer gespeichert. Das Hinzufügen eines neuen Flusses kann das Setzen einer Folgenummer (z. B. der Flussfolgenummer 522 aus 5) enthalten. Die Flussfolgenummer 522 kann durch Addieren einer aus dem Paket wiedergewonnenen Folgenummer (z. B. TCP-Folgenummer) und der Menge der in dem Paket enthaltenen Daten erzeugt werden. Wie oben diskutiert wurde, muss diese Summe möglicherweise (z. B. durch Addieren von eins) angepasst werden.
  • Außerdem kann das Speichern eines neuen Flusses das Initialisieren eines Aktivitätsanzeigers (z. B. des Flussaktivitätsanzeigers 524 aus 5) enthalten. In einer Ausführungsform der Erfindung umfasst diese Initialisierung das Speichern eines Werts, der aus einem Zähler wiedergewonnen wird, der jedes Mal inkrementiert wird, wenn Daten für einen Fluss empfangen werden. Beispielhaft werden der Zähler und alle Flussaktivitätsanzeiger gelöscht oder zurückgesetzt, falls der Zähler oder ein Flussaktivitätsanzeiger über seinen maximal speicherbaren Wert hinaus inkrementiert wird. Außerdem wird im Zustand 660 ein Gültigkeitsanzeiger (z. B. der Flussgültigkeitsanzeiger 520 aus 5) gesetzt, um anzuzeigen, dass der Fluss gültig ist. Schließlich wird der Flussschlüssel des Pakets ebenfalls in dem Eintrag, der der zugewiesenen Flussnummer entspricht, in der Flussdatenbank gespeichert.
  • Im Zustand 662 wird für das Paket der Operationscode 6 ausgewählt. Beispielhaft zeigt der Operationscode 6 an, dass das Paket kompatibel ist, mit keinen gültigen Flüssen übereinstimmt und den ersten Datenabschnitt für einen neuen Fluss enthält. Ferner haben die Merker des Pakets ihre erwarteten oder erforderlichen Werte, werden in dem Fluss zusätzliche Daten erwartet und ist die Flussdatenbank nicht voll. Somit zeigt der Operationscode 6 an, dass kein vorhandener Fluss abzubauen ist und dass ein neuer Fluss in der Flussdatenbank gespeichert worden ist. Nach dem Zustand 662 endet die veranschaulichte Prozedur im Zustand 670.
  • Im Zustand 664 wird ein vorhandener Eintrag in der Flussdatenbank ersetzt, so dass ein neuer, durch das vorliegende Paket begonnener Fluss gespeichert werden kann. Somit wird die Flussnummer des im Zustand 650 identifizierten am wenigsten kurz zuvor aktiven Flusses wiedergewonnen. Dieser Fluss kann wie folgt ersetzt werden. Die Folgenummer des vorhandenen Flusses (z. B. die Flussfolgenummer 522 aus 5) wird durch einen Wert ersetzt, der durch Kombination einer aus dem Paket extrahierten Folgenummer (z. B. der TCP-Folgenummer) mit der Größe des Datenabschnitts des Pakets abgeleitet wird. Diese Summe muss möglicherweise (z. B. durch Addieren von eins) angepasst werden. Daraufhin wird der Aktivitätsanzeiger des vorhandenen Flusses (z. B. der Flussaktivitätsanzeiger 524) ersetzt. Zum Beispiel kann der Wert eines Flussaktivitätszählers wie oben diskutiert in den Flussaktivitätsanzeiger kopiert werden. Daraufhin wird der Gültigkeitsanzeiger des Flusses (z. B. der Flussgültigkeitsanzeiger 520 aus 5) gesetzt, um anzuzeigen, dass der Fluss gültig ist. Schließ lich wird der Flussschlüssel des neuen Flusses gespeichert.
  • Im Zustand 666 wird für das Paket der Operationscode 7 ausgewählt. Der Operationscode 7 wurde ebenfalls im Zustand 636 ausgewählt. Im vorliegenden Kontext kann der Operationscode 7 anzeigen, dass das Paket kompatibel ist, nicht mit dem Flussschlüssel irgendwelcher gültigen Flüsse übereinstimmt und den ersten Datenabschnitt für einen neuen Fluss enthält. Ferner haben die Merker des Pakets kompatible Werte und werden zusätzliche Daten in dem Fluss erwartet. Schließlich zeigt der Operationscode 7 in diesem Kontext aber an, dass die Flussdatenbank voll ist, so dass ein vorhandener Eintrag abgebaut und der neue an seiner Stelle gespeichert wurde. Nach dem Zustand 666 endet die veranschaulichte Prozedur im Endzustand 670.
  • Im Zustand 668 wird für das Paket der Operationscode 5 ausgewählt. In den Zustand 668 wird von verschiedenen Zuständen eingetreten, so dass der Operationscode 5 eine Vielzahl möglicher Bedingungen oder Situationen repräsentiert. Zum Beispiel kann der Operationscode 5 ausgewählt werden, wenn für ein Paket (im Zustand 604) ein No_Assist-Signal erfasst wird. Wie oben diskutiert wurde, kann das No_Assist-Signal anzeigen, dass das entsprechende Paket mit einer Menge im Voraus gewählter Protokolle nicht kompatibel ist. In dieser Ausführungsform der Erfindung sind inkompatible Pakete für eine oder mehrere der verschiedenen Funktionen der NIC 100 (z. B. Datenwiederzusammensetzung, Stapelverarbeitung, Lastverteilung) ungeeignet.
  • Außerdem kann vom Zustand 652 in den Zustand 668 eingetreten und der Operationscode 5 ausgewählt werden, wobei der Code in diesem Fall anzeigen kann, dass das empfangene Paket mit keinen gültigen Flussschlüsseln übereinstimmt und ferner keine Daten enthält (z. B. ein Steuerpaket sein kann).
  • Außerdem kann vom Zustand 654 in den Zustand 668 eingetreten werden. In diesem Kontext kann der Operationscode 5 anzeigen, dass das Paket mit keinen gültigen Flussschlüsseln übereinstimmt. Ferner kann er anzeigen, dass das Paket Daten enthält, dass aber die Größe des Datenabschnitts kleiner als der in Verbindung mit dem Zustand 654 diskutierte Schwellenwert ist. In diesem Kontext scheinen die Daten des Pakets vollständig zu sein (z. B. alle Daten für ein Datagramm zu enthalten), d. h., mit den Daten dieses Pakets sind keine weiteren Daten wieder zusammenzusetzen, so dass kein Grund besteht, für diesen Ein- Paket-Fluss einen neuen Eintrag in der Datenbank vorzunehmen.
  • Schließlich kann in den Zustand 668 ebenfalls vom Zustand 656 eingetreten werden. In diesem Kontext kann der Operationscode 5 anzeigen, dass das Paket mit keinen gültigen Flussschlüsseln übereinstimmt, Daten enthält und weitere Daten erwartet werden, wobei aber wenigstens ein Merker in einem oder in mehreren Protokollköpfen des Pakets nicht seinen erwarteten Wert besitzt. Zum Beispiel wird in einer Ausführungsform der Erfindung erwartet, dass die TCP-Merker URG, PSH, RST und FIN gelöscht sind. Falls irgendeiner dieser Merker gesetzt ist, kann eine Ausnahmebedingung vorliegen, die somit ermöglicht, dass eine der durch die NIC 100 gebotenen Funktionen für dieses Paket ungeeignet ist.
  • Wie die TABELLE 1 widerspiegelt, gibt es keinen abzubauenden Fluss und wird kein neuer Fluss aufgebaut, wenn der Operationscode 5 ausgewählt ist. Nach dem Zustand 668 endet die veranschaulichte Prozedur im Zustand 670.
  • Die in den 6A–6E veranschaulichte und oben diskutierte Prozedur ist nur eine geeignete Prozedur zum Aufrechterhalten und Aktualisieren einer Flussdatenbank und zum Bestimmen der Eignung eines Pakets für bestimmte Verarbeitungsfunktionen. Insbesondere können verschiedene Operationscodes genutzt werden oder auf andere Art und Weise implementiert werden, wobei ein Ziel die Erzeugung von Informationen zur späteren Verarbeitung des Pakets durch die NIC 100 ist.
  • Obgleich die Operationscodes in der veranschaulichten Prozedur für alle Pakete durch einen Flussdatenbankmanager zugewiesen werden, kann in einer alternativen Prozedur ein durch den FDBM zugewiesener Operationscode durch ein anderes Modul der NIC 100 ersetzt oder geändert werden. Dies kann erfolgen, um ein besonderes Verfahren der Behandlung bestimmter Pakettypen sicherzustellen. Zum Beispiel weist in einer Ausführungsform der Erfindung das IPP-Modul 104 Jumbo-Paketen (z. B. Paketen mit einer höheren Größe als die MTU) einen vorgegebenen Operationscode (z. B. den Operationscode 2 aus TABELLE 1) zu, so dass sie die DMA-Maschine 120 nicht wieder zusammensetzt. Insbesondere kann das IPP-Modul (z. B. aus den durch ein MAC-Modul gelieferten Informationen) unabhängig bestimmen, dass das Paket ein Jumbo-Paket ist, und somit den vorgegebenen Code zuweisen. Beispielhaft führen der Kopfanalysealgorithmus 106 und der FDBM 108 für ein Jumbo-Paket ihre normalen Funktionen aus, wobei das IPP-Modul 104 einen ersten, durch den FDBM zugewiesenen Operationscode empfängt. Allerdings ersetzt das IPP-Modul diesen Code, bevor es das Jumbo-Paket und das Paket betreffende Informationen speichert. In einer alternativen Ausführungsform können der Kopfanalysealgorithmus 106 und/oder der Flussdatenbankmanager 108 so konfiguriert sein, dass sie einen besonderen Pakettyp (z. B. Jumbo) erkennen und einen vorgegebenen Operationscode zuweisen.
  • Die Operationscodes, die in der in den 6A–6E veranschaulichten Ausführungsform der Erfindung angewendet werden, sind in der folgenden TABELLE 1 dargestellt und erläutert. TABELLE 1 enthält beispielhafte Kriterien, die zur Auswahl jedes Operationscodes verwendet werden, sowie beispielhafte Wirkungen oder Effekte jedes Codes.
  • Figure 00850001
  • Figure 00860001
    TABELLE 1
  • Eine Ausführungsform eines Lastverteilers
  • In einer Ausführungsform der Erfindung ermöglicht der Lastverteiler 112, die Verarbeitung der Pakete durch ihre Protokollstapel auf eine Anzahl von Prozessoren zu verteilen. Beispielhaft erzeugt der Lastverteiler 112 einen Identifizierer (z. B. eine Prozessornummer) eines Prozessors, an den ein Paket eingereicht werden soll. Die mehreren Prozessoren können sich in einem Host-Computersystem befinden, das durch die NIC 100 bedient wird. In einer alternativen Ausführungsform befinden sich einer oder mehrere Prozessoren zum Manipulieren von Paketen durch einen Protokollstapel in der NIC 100.
  • Ohne ein effektives Verfahren zum Teilen oder Verteilen der Verarbeitungsbelastung könnte ein Prozessor insbesondere in der Umgebung eines Hochgeschwin digkeitsnetzes überlastet werden, wenn er den gesamten oder meisten in der NIC 100 empfangenen Netzverkehr verarbeiten müsste. Die resultierende Verzögerung in der Verarbeitung des Netzverkehrs könnte die Operationen in dem Host-Computersystem sowie in anderen Computersystemen, die über das Netz mit dem Host-System kommunizieren, verschlechtern.
  • Die einfache Verteilung der Pakete auf Prozessoren in einer Menge von Prozessoren (z. B. wie etwa in einem Round-Robin-Schema) ist möglicherweise kein effizienter Plan. Ein solcher Plan könnte leicht dazu führen, dass Pakete außer der Reihe verarbeitet werden. Falls z. B. zwei Pakete aus einem Kommunikationsfluss oder einer Kommunikationsverbindung, die in der richtigen Reihenfolge in einer Netzschnittstelle empfangen wurden, an zwei verschiedene Prozessoren eingereicht wurden, kann das zweite Paket vor dem ersten verarbeitet werden. Dies könnte z. B. geschehen, falls der Prozessor, der das erste Paket empfangen hat, das Paket nicht sofort verarbeiten konnte, da er mit einer anderen Aufgabe beschäftigt war. Wenn Pakete außer der Reihe verarbeitet werden, muss allgemein ein Korrekturschema begonnen werden, was somit noch mehr Ineffizienz und weitere Verzögerung einführt.
  • Somit werden die Pakete in einer vorliegenden Ausführungsform der Erfindung anhand ihrer Flussidentitäten auf mehrere Prozessoren verteilt. Wie oben beschrieben wurde, kann ein Kopfanalysealgorithmus aus Schicht-Drei- (z. B. IP-) und Schicht-Vier- (z. B. TCP-) Quell- und Zielidentifizierern, die aus den Köpfen eines Pakets wiedergewonnen werden, einen Flussschlüssel erzeugen. Der Flussschlüssel kann verwendet werden, um den Kommunikationsfluss zu identifizieren, zu dem das Paket gehört. Somit werden in dieser Ausführungsform der Erfindung alle Pakete mit einem gleichen Flussschlüssel an einen einzelnen Prozessor eingereicht. Solange die Pakete durch die NIC 100 in der richtigen Reihenfolge empfangen werden, sollten sie durch ihren zugewiesenen Prozessor in der richtigen Reihenfolge an den Host-Computer geliefert und verarbeitet werden.
  • Beispielhaft haben mehrere von einer Quell-Entität an eine Ziel-Entität gesendete Pakete den gleichen Flussschlüssel, selbst wenn die Pakete Teil getrennter Datagramme sind, solange ihre Schicht-Drei- und Schicht-Vier-Identifizierer die gleichen bleiben. Wie oben diskutiert wurde, werden für jedes Datagramm innerhalb einer TCP-Ende-Ende-Verbindung getrennte Flüsse aufgebaut und abgebaut. So, wie alle Pakete innerhalb eines Flusses an einen Prozessor gesendet werden, werden somit alle Pakete innerhalb einer TCP-Ende-Ende-Verbindung ebenfalls an den gleichen Prozessor gesendet. Dies hilft, selbst zwischen Datagrammen die richtige Reihenfolge der Pakete für die gesamte Verbindung sicherzustellen.
  • Je nach der Netzumgebung, in der die NIC 100 arbeitet (z. B. je nach den durch das Netz 102 unterstützten Protokollen) kann der Flussschlüssel zu groß sein, um ihn als einen Identifizierer eines Prozessors zu verwenden. Zum Beispiel hat ein Flussschlüssel in einer oben beschriebenen Ausführungsform der Erfindung einen Umfang von 288 Bits. Währenddessen kann die Anzahl der Prozessoren, die an dem Lastausgleichsschema teilnehmen, viel kleiner sein. Zum Beispiel werden in der oben in Verbindung mit 7 beschriebenen Ausführungsform der Erfindung maximal vierundsechzig Prozessoren unterstützt. Somit ist in dieser Ausführungsform lediglich eine Sechs-Bit-Zahl erforderlich, um den ausgewählten Prozessor zu identifizieren. Somit kann der größere Flussschlüssel in einen kleineren Bereich von Werten abgebildet oder Hash-codiert werden.
  • 7 zeigt ein Verfahren zum Erzeugen eines Identifizierers (z. B. einer Prozessornummer), um anhand des Flussschlüssels des Pakets einen Prozessor anzugeben, um ein durch die NIC 100 empfangenes Paket zu verarbeiten. In dieser Ausführungsform der Erfindung ist das Netz 102 das Internet und ein empfangenes Paket in Übereinstimmung mit einem kompatiblen Protokollstapel (z. B. Ethernet in der Schicht zwei, IP in der Schicht drei und TCP in der Schicht vier) formatiert.
  • Der Zustand 700 ist ein Startzustand. Im Zustand 702 wird ein Paket durch die NIC 100 empfangen und ein Kopfabschnitt des Pakets durch den Kopfanalysealgorithmus 106 syntaktisch analysiert (wobei ein Verfahren zum syntaktischen Analysieren eines Pakets in einem früheren Abschnitt beschrieben ist). Im Zustand 704 empfängt der Lastverteiler 112 den Flussschlüssel des Pakets, der durch den Kopfanalysealgorithmus 106 erzeugt worden ist.
  • Da der Flussschlüssel eines Pakets in dieser Ausführungsform 288 Bits breit ist, wird im Zustand 706 eine Hash-Funktion ausgeführt, um einen Wert zu erzeugen, der eine geringere Größe hat. Die Hash-Operation kann z. B. eine Zweiunddreißig-Bit-CRC-Funktion (Funktion der zyklischen Redundanzprüfung) wie etwa ATM (asynchrone Übermittlung), Anpassungsschicht 5 (AAL 5), enthalten. Die AAL 5 erzeugt Zweiunddreißig-Bit-Zahlen, die recht gleichmäßig auf die 232 möglichen Werte verteilt sind. Ein weiteres geeignetes Verfahren für die Hash-Codierung ist die Standard-Ethernet-CRC-32-Funktion. Andere Hash-Funktionen, die aus verhältnismäßig großen Flussschlüsseln verhältnismäßig kleine Zahlen erzeugen können, wobei die erzeugten Zahlen gut auf einen Bereich von Werten verteilt sind, sind ebenfalls geeignet.
  • Mit dem resultierenden Hash-Wert wird im Zustand 708 eine Moduloperation über die Anzahl der zur Verteilung oder Teilung der Verarbeitung verfügbaren Prozessoren ausgeführt. Beispielhaft programmiert oder speichert Software, die in dem Host-Computer ausgeführt wird, (z. B. ein Gerätetreiber für die NIC 100) die Anzahl der Prozessoren, so dass sie durch den Lastverteiler 112 (z. B. in einem Register) gelesen oder wiedergewonnen werden kann. Die Anzahl der Prozessoren, die für den Lastausgleich verfügbar sind, können alle oder eine Teilmenge der Anzahl der in dem Host-Computersystem installierten Prozessoren sein. In der veranschaulichten Ausführungsform ist die Anzahl der in einem Host-Computersystem verfügbaren Prozessoren mit einem Maximalwert von vierundsechzig programmierbar. Das Ergebnis der Moduloperation ist in dieser Ausführungsform somit die Nummer des Prozessors (z. B. von null bis dreiundsechzig), an den das Paket zur Verarbeitung einzureichen ist. In dieser Ausführungsform der Erfindung ist der Lastverteiler 112 in Hardware implementiert, was somit eine schnelle Ausführung der Hash- und Modulfunktion ermöglicht. In einer alternativen Ausführungsform der Erfindung kann praktisch irgendeine Anzahl von Prozessoren versorgt werden.
  • Im Zustand 710 wird die Nummer des Prozessors, der das Paket durch seinen Protokollstapel verarbeiten wird, im Speicher des Host-Computers gespeichert. Beispielhaft wird der Zustand 710 parallel zur Speicherung des Pakets in einem Host-Speicherpuffer ausgeführt. In einer Ausführungsform der Erfindung ist im Speicher des Host-Computers ein Deskriptor-Ring konstruiert, um die Prozessornummer und möglicherweise weitere das Paket betreffende Informationen (z. B. einen Zeiger auf das Paket, seine Größe, seine TCP-Prüfsumme) zu halten.
  • Ein Deskriptor-Ring ist in dieser Ausführungsform eine Datenstruktur, die eine Anzahl von Einträgen oder "Deskriptoren" zum Speichern von Informationen enthält, die vom Host-Computersystem einer Netzschnittstellenschaltung zu verwenden sind. In der veranschaulichten Ausführungsform speichert ein Deskriptor vorübergehend Paketinformationen, nachdem das Paket durch die NIC 100 emp fangen worden ist, jedoch bevor das Paket durch das Host-Computersystem verarbeitet wird. Die in einem Deskriptor gespeicherten Informationen können z. B. von dem Gerätetreiber für die NIC 100 oder zur Verarbeitung des Pakets durch seinen Protokollstapel verwendet werden.
  • Im Zustand 712 wird an den Host-Computer eine Unterbrechung oder eine andere Warnung ausgegeben, um ihn zu informieren, dass ein neues Paket von der NIC 100 geliefert worden ist. In einer Ausführungsform der Erfindung, in der die NIC 100 durch einen PCI-Bus (Peripheral-Component-Interconnect-Bus) mit dem Host-Computer gekoppelt ist, kann das INTA-Signal über den Bus aktiviert werden. Ein PCI-Controller in dem Host empfängt das Signal und das Host-Betriebssystem wird (z. B. über eine Unterbrechung) gewarnt.
  • Im Zustand 714 wird in dem Host-Computer arbeitende Software (z. B ein Gerätetreiber für die NIC 100) (z. B. durch das Unterbrechungsprogramm des Betriebssystems des Host-Computers) aufgerufen, um auf ein neu empfangenes Paket einzuwirken. Die Software sammelt Informationen von einem oder von mehreren Deskriptoren in dem Deskriptor-Ring und ordnet Informationen, die für den Abschluss der Verarbeitung jedes neuen Pakets erforderlich sind, in einer Warteschlange für den angegebenen Prozessor (d. h. gemäß der in dem Deskriptor des Pakets gespeicherten Prozessornummer) an. Beispielhaft entspricht jeder Deskriptor einem getrennten Paket. Die für jedes Paket in der Prozessorwarteschlange gespeicherten Informationen können einen Zeiger auf einen Puffer, der das Paket enthält, die TCP-Prüfsumme des Pakets, Versätze eines oder mehrerer Protokollköpfe usw. enthalten. Außerdem kann jeder an dem Lastverteilungsschema beteiligte Prozessor eine zugeordnete Warteschlange zur Verarbeitung von Netzpaketen besitzen. In einer alternativen Ausführungsform der Erfindung können mehrere Warteschlangen (z. B. für mehrere Prioritätsebenen oder für verschiedene Protokollstapel) verwendet werden.
  • Beispielhaft ist ein Prozessor in dem Host-Computersystem so konfiguriert, dass er alle Warnungen und/oder Unterbrechungen im Zusammenhang mit dem Empfang von Netzpaketen von der NIC 100 empfängt und die richtige Softwareroutine oder den richtigen Gerätetreiber warnt. Alternativ kann diese Anfangsverarbeitung auf mehrere Prozessoren verteilt sein. Außerdem wird in einer Ausführungsform der Erfindung ein Abschnitt der Wiedergewinnung und Manipulation des Deskriptorinhalts als Teil der Behandlung der Unterbrechung ausgeführt, die er zeugt wird, wenn ein neues Paket in dem Deskriptor-Ring gespeichert wird. Der zur Verarbeitung des Pakets ausgewählte Prozessor führt den Rest der Wiedergewinnungs/Manipulations-Prozedur aus.
  • Im Zustand 716 wird der zur Verarbeitung eines neuen Pakets bestimmte Prozessor gewarnt oder geweckt. In einer Ausführungsform der Erfindung, die in einer SolarisTM-Arbeitsstation arbeitet, sind einzelne durch den Prozessor ausgeführte Prozesse als "Prozessstränge" konfiguriert. Ein Prozessstrang ist ein Prozess, der in einer Normalbetriebsart (z. B. nicht auf einer Unterbrechungsebene) ausgeführt wird, so dass er minimale Auswirkungen auf andere in der Arbeitsstation ausgeführte Prozesse hat. Allerdings kann ein Prozess der Normalbetriebsart mit hoher Priorität ausgeführt werden. Alternativ kann ein Prozessstrang auf einer verhältnismäßig niedrigen Unterbrechungsebene ausgeführt werden.
  • Ein Prozessstrang, der für die Verarbeitung eines ankommenden Pakets verantwortlich ist, kann sich selbst sperren, wenn er keine Pakete zu verarbeiten hat, und erwachen, wenn er Arbeit zu verrichten hat. Um anzuzeigen, ob der Prozessstrang ein Paket zu verarbeiten hat, kann eine "Bedingungsvariable" verwendet werden. Beispielhaft wird die Bedingungsvariable auf einen ersten Wert gesetzt, wenn der Prozessstrang ein Paket verarbeiten soll (z. B., wenn ein Paket zur Verarbeitung durch den Prozessor empfangen wird), und auf einen zweiten Wert gesetzt, wenn keine weiteren Pakete zu verarbeiten sind. In der veranschaulichten Ausführungsform der Erfindung kann der Warteschlange jedes Prozessors eine Bedingungsvariable zugeordnet sein.
  • In einer alternativen Ausführungsform wird ein angegebener Prozessor im Zustand 716 durch einen "Prozessor-Queraufruf" gewarnt. Ein Prozessor-Queraufruf ist eine Art der Kommunikation unter Prozessoren, durch die ein Prozessor fern durch einen anderen Prozessor unterbrochen wird. Anstelle von Prozesssträngen und Prozessor-Queraufrufen können andere Verfahren verwendet werden, durch die ein Prozessor einen anderen Prozessor warnt oder einen Prozess an einen anderen Prozessor schickt.
  • Im Zustand 718 beginnt ein Prozessstrang oder ein anderer Prozess in dem ausgewählten Prozessor, das Paket, das in der Warteschlange des Prozessors gespeichert worden ist, zu verarbeiten. Verfahren zur Verarbeitung eines Pakets durch seinen Protokollstapel brauchen hier nicht ausführlich beschrieben zu werden. Daraufhin endet die veranschaulichte Prozedur mit dem Endzustand 720.
  • In einer alternativen Ausführungsform der Erfindung ist eine Hochgeschwindigkeitsnetz-Schnittstelle so konfiguriert, dass sie ATM-Verkehr (Asynchronübermittlungsverkehr) empfängt und verarbeitet. In dieser Ausführungsform ist ein Lastverteiler eher als ein Befehlssatz (z. B. als Software) als als ein Hardware-Modul implementiert. ATM-Verkehr ist verbindungsorientiert und kann durch einen virtuellen Verbindungsidentifizierer (VCI) identifiziert werden, der einer virtuellen Verbindung entspricht, die zwischen der Quell-Entität und der Ziel-Entität des Pakets aufgebaut wird. Jedes Paket, das Teil einer virtuellen Verbindung ist, enthält in seinem Kopf den VCI.
  • Vorteilhaft besitzt ein VCI eine verhältnismäßig kleine Größe (z. B. sechzehn Bits). Somit kann in dieser alternativen Ausführungsform anstelle eines Flussschlüssels der VCI eines Pakets zur Verteilung oder Teilung der Last der Verarbeitungspakete auf ihre Protokollstapel verwendet werden. Beispielhaft wird Verkehr von verschiedenen VCIs an verschiedene Prozessoren gesendet, wobei aber alle Pakete mit dem gleichen VCI an den gleichen Prozessor gesendet werden, um die richtige Reihenfolge der Pakete sicherzustellen. Wenn in einer Netzschnittstelle ein ATM-Paket empfangen wird, wird der VCI aus seinem Kopf wiedergewonnen und an den Lastverteiler geliefert. Daraufhin wird der Modul des VCI über die Anzahl der für die Lastverteilung verfügbaren Prozessoren berechnet. Ähnlich der veranschaulichten Ausführungsform werden daraufhin das Paket und seine zugeordnete Prozessornummer an den Host-Computer geliefert.
  • Wie oben beschrieben wurde, wird die Lastverteilung in einer vorliegenden Ausführungsform der Erfindung anhand der Quell- und Ziel-Entitätsidentifizierer der Schicht drei und/oder der Schicht vier eines Pakets ausgeführt. In einer alternativen Ausführungsform der Erfindung kann die Lastverteilung dagegen anhand von Schicht-Zwei-Adressen ausgeführt werden. In dieser alternativen Ausführungsform werden z. B. Pakete mit der gleichen Ethernet-Quelladresse und -Zieladresse an einen einzelnen Prozessor gesendet.
  • Allerdings kann dies dazu führen, dass ein Prozessor viel mehr Pakete empfängt, als er empfangen würde, falls Schicht-Drei- und/oder Schicht-Vier-Identifizierer verwendet würden. Falls z. B. eine große Menge Verkehr über einen Router empfangen wird, der sich (in einem logischen Sinn) in der Nähe des Host-Com puters befindet, kann die Quell-Ethernet-Adresse für den gesamten Verkehr die Adresse des Routers sein, obgleich der Verkehr von einer Vielzahl verschiedener Endanwender und/oder Computer stammt. Falls der Host-Computer demgegenüber in dem gleichen Ethernet-Segment wie alle Endanwender/Computer ist, zeigt die Schicht-Zwei-Quelladresse eine größere Vielfalt und ermöglicht einen effektiveren Lastverbund.
  • Andere Verfahren der Verteilung der Verarbeitung der von einem Netz empfangen Pakete können sich von der in 7 veranschaulichten Ausführungsform unterscheiden, ohne den Umfang der Erfindung zu überschreiten. Insbesondere können zum Zuweisen der Pakete eines Flusses zu einem Prozessor und zum Liefern dieser Pakete an den Prozessor viele alternative Prozeduren verwendet werden.
  • Eine Ausführungsform einer Paketwarteschlange
  • Wie oben beschrieben wurde, speichert die Paketwarteschlange 116 vom IPP-Modul 104 empfangene Pakete vor ihrem Wiederzusammensetzen durch die DMA-Maschine 120 und vor ihrer Übertragung an das Host-Computersystem. 8 zeigt die Paketwarteschlange 116 in Übereinstimmung mit einer Ausführungsform der Erfindung.
  • In der veranschaulichten Ausführungsform ist die Paketwarteschlange 116 als eine FIFO-Warteschlange (Zuerst-Eingeben/Zuerst-Ausgeben-Warteschlange) implementiert, die bis zu 256 Einträge enthält. In dieser Ausführungsform speichert jeder Eintrag der Paketwarteschlange ein Paket zuzüglich verschiedener das Paket betreffender Informationen. Zum Beispiel enthält der Eintrag 800 einen Paketabschnitt 802 zuzüglich eines Paketstatusabschnitts. Da in der Paketwarteschlange 116 Pakete verschiedener Größen gespeichert werden, kann der Paketabschnitt 802 ein Füllfeld 802a enthalten, das das Paket ergänzt, so dass der Paketabschnitt an einer geeigneten Grenze (z. B. Byte, Wort, Doppelwort) endet.
  • Das Füllfeld 802a kann willkürlich angenommene Daten oder Daten mit einem angegebenen Muster enthalten. Das Füllfeld 802a kann durch das Muster der Füllfelddaten oder durch ein Etikettfeld von dem gespeicherten Paket unterschieden werden.
  • Die Paketstatusinformationen enthalten beispielhaft einen TCP-Prüfsummenwert 804 und eine Paketlänge 806 (z. B. die Länge des im Paketabschnitt 802 gespeicherten Pakets). Das Speichern der Paketlänge kann ermöglichen, dass das Paket leicht identifiziert und aus dem Paketabschnitt 802 wiedergewonnen wird. Außerdem können die Paketstatusinformationen Diagnose/Status-Informationen 808 enthalten. Die Diagnose/Status-Informationen 808 können einen Merker, der anzeigt, dass das Paket unbrauchbar (z. B. unvollständig, mit einem Fehler empfangen ist) ist, einen Anzeiger, dass für das Paket eine Prüfsumme berechnet oder nicht berechnet wurde, einen Anzeiger, dass die Prüfsumme einen bestimmten Wert hat, einen Versatz zu dem Abschnitt des Pakets, an dem die Prüfsumme berechnet wurde, usw. enthalten. Weitere Merker oder Anzeiger können für Diagnose-, Filter- oder andere Zwecke ebenfalls enthalten sein. In einer Ausführungsform der Erfindung sind in den Diagnose/Status-Informationen 808 die (oben beschriebenen und zum Identifizieren des Flusses, der das Paket enthält, verwendeten) Flussschlüssel des Pakets und/oder die Flussnummer (z. B. der entsprechende Index des Flusses des Pakets in der Flussdatenbank 110) enthalten. In einer weiteren Ausführungsform ist in den Diagnose/Status-Informationen 808 ein Etikettfeld zum Identifizieren oder Begrenzen des Füllfelds 802a enthalten.
  • In einer alternativen Ausführungsform der Erfindung werden irgendwelche oder alle der oben beschriebenen Paketstatusinformationen eher in der Steuerwarteschlange 118 als in der Paketwarteschlange 116 gespeichert.
  • In der veranschaulichten Ausführungsform der Erfindung ist die Paketwarteschlange 116 in Hardware (z. B. als Schreib-Lese-Speicher) implementiert. In dieser Ausführungsform hat der Prüfsummenwert 804 eine Größe von sechzehn Bits und kann durch den Prüfsummengenerator 114 gespeichert werden. Die Paketlänge 806 ist vierzehn Bits groß und kann durch den Kopfanalysealgorithmus 106 gespeichert werden. Schließlich können Abschnitte der Diagnose/Status-Informationen 808 durch eines oder mehrere des IPP-Moduls 104, des Kopfanalysealgorithmus 106, des Flussdatenbankmanagers 108, des Lastverteilers 112 und des Prüfsummengenerators 114 gespeichert werden.
  • Die Paketwarteschlange 116 in 8 wird mit zwei Zeigern indiziert. Der Lesezeiger 810 identifiziert den nächsten aus der Warteschlange zu lesenden Eintrag, während der Schreibzeiger 812 den Eintrag identifiziert, in dem das nächste empfangene Paket und verwandte Informationen zu speichern sind. In einer vorliegenden Ausführungsform der Erfindung wird das im Paketabschnitt 802 eines Eintrags gespeicherte Paket aus der Paketwarteschlange 116 extrahiert, wenn seine Daten durch die DMA-Maschine 120 wieder zusammengesetzt und/oder an das Host-Computersystem übertragen werden sollen.
  • Eine Ausführungsform einer Steuerwarteschlange
  • In einer Ausführungsform der Erfindung speichert die Steuerwarteschlange 118 Steuer- und Statusinformationen, die ein durch die NIC 100 empfangenes Paket betreffen. In dieser Ausführungsform hält die Steuerwarteschlange 118 Informationen, die verwendet werden, um die Stapelverarbeitung der Protokollköpfe und/oder das Wiederzusammensetzen der Daten von mehreren verwandten Paketen zu ermöglichen. Außerdem kann die Steuerwarteschlange durch den Host-Computer zu verwendende Informationen oder eine Reihe von Befehlen, die in einem Host-Computer arbeiten (z. B. einen Gerätetreiber für die NIC 100) speichern. Die in der Steuerwarteschlange 118 gespeicherten Informationen können die in der Paketwarteschlange 116 gespeicherten Informationen ergänzen oder kopieren.
  • 9 zeigt die Steuerwarteschlange 118 in einer Ausführungsform der Erfindung. Die veranschaulichte Steuerwarteschlange enthält für jedes in der Paketwarteschlange 116 gespeicherte Paket einen Eintrag (z. B. bis zu 256 Einträge). In einer Ausführungsform der Erfindung entspricht jeder Eintrag in der Steuerwarteschlange 118 dem Eintrag (z. B. dem Paket) in der Paketwarteschlange 116 mit der gleichen Nummer. 9 zeigt den Eintrag 900 mit verschiedenen Feldern wie etwa einer CPU-Nummer 902, einem No_Assist-Signal 904, einem Operationscode 906, einem Nutzinformationsversatz 908, einer Nutzinformationsgröße 910 sowie weiteren Statusinformationen 912. Außerdem kann ein Eintrag weitere (in 9 nicht gezeigte) Status- oder Steuerinformationen enthalten. In alternativen Ausführungsformen der Erfindung können die Einträge in der Steuerwarteschlange 118 andere Informationen enthalten.
  • Die in einem vorangehenden Abschnitt diskutierte CPU-Nummer (oder Prozessornummer) 902 zeigt an, welcher der mehreren Prozessoren in dem Host-Computersystem die Protokollköpfe des Pakets verarbeiten sollte. Beispielhaft hat die CPU-Nummer 902 eine Größe von sechs Bits. Das ebenfalls in einem vorange henden Abschnitt beschriebene No_Assist-Signal 904 zeigt an, ob das Paket mit irgendeinem Protokoll aus einer Menge im Voraus gewählter Protokolle, die durch den Kopfanalysealgorithmus 106 syntaktisch analysiert werden können, kompatibel ist (z. B. in Übereinstimmung mit ihm formatiert ist). Das No_Assist-Signal 904 kann einen einzelnen Merker (z. B. ein Bit) enthalten. In einer Ausführungsform der Erfindung kann der Zustand oder Wert des No_Assist-Signals 904 durch den Flussdatenbankmanager 108 verwendet werden, um zu bestimmen, ob die Daten eines Pakets wieder zusammensetzbar sind und/oder ob seine Köpfe mit jenen verwandter Pakete verarbeitet werden können. Insbesondere kann der FDBM das No_Assist-Signal bei der Bestimmung verwenden, welcher Operationscode dem Paket zuzuweisen ist.
  • Der Operationscode 906 liefert an die DMA-Maschine 120 Informationen, die beim Wiederzusammensetzen der Daten des Pakets helfen. Ein Operationscode kann anzeigen, ob ein Paket Daten enthält oder ob die Daten eines Pakets für das Wiederzusammensetzen geeignet sind. Beispielhaft hat der Operationscode 906 eine Größe von drei Bits. Der Nutzinformationsversatz 908 und die Nutzinformationsgröße 910 entsprechen dem Versatz bzw. der Größe der TCP-Nutzinformationen (z. B. TCP-Daten) des Pakets. Diese Felder können sieben bzw. vierzehn Bits groß sein.
  • In der veranschaulichten Ausführungsform enthalten die weiteren Statusinformationen 912 Diagnose- und/oder Statusinformationen, die das Paket betreffen. Die Statusinformationen 912 können eine Startstelle für eine Prüfsummenberechnung (die eine Größe von sieben Bits haben kann), einen Versatz des Schicht-Drei-Protokollkopfs (z. B. IP-Protokollkopfs) (der ebenfalls eine Größe von sieben Bits haben kann) usw. enthalten. Außerdem können die Statusinformationen 912 einen Anzeiger enthalten, ob die Größe des Pakets einen ersten Schwellenwert übersteigt (z. B., ob das Paket größer als 1522 Bytes ist) oder unter einen zweiten Schwellenwert fällt (z. B., ob das Paket 256 Bytes oder kleiner ist). Diese Informationen können beim Wiederzusammensetzen der Paketdaten nützlich sein. Beispielhaft enthalten diese Anzeiger Ein-Bit-Merker.
  • In einer alternativen Ausführungsform der Erfindung enthalten die Statusinformationen 912 einen Flussschlüssel und/oder eine Flussnummer des Pakets (z. B. den Index des Flusses des Pakets in der Flussdatenbank 110). Der Flussschlüssel oder die Flussnummer kann z. B. zum Austesten oder für andere Diagnosezwecke verwendet werden. In einer Ausführungsform der Erfindung kann die Flussnummer des Pakets in den Statusinformationen 912 gespeichert werden, so dass mehrere Pakete in einem einzelnen Fluss identifiziert werden können. Dieses verwandte Paket kann daraufhin kollektiv zu einem Host-Computer übertragen und/oder durch ihn verarbeitet werden.
  • 9 zeigt einen Lesezeiger und einen Schreibzeiger zum Indizieren der Steuerwarteschlange 118. Der Lesezeiger 914 zeigt einen durch die DMA-Maschine 120 zu lesenden Eintrag an. Der Schreibzeiger 916 zeigt den Eintrag an, in dem Informationen zu speichern sind, die das nächste in der Paketwarteschlange 116 gespeicherte Paket betreffen.
  • In einer alternativen Ausführungsform der Erfindung kann ein (in 9 nicht gezeigter) zweiter Lesezeiger zum Indizieren der Steuerwarteschlange 118 verwendet werden. Wenn in dieser Ausführungsform ein Paket an den Host-Computer übertragen werden soll, werden den Einträgen in der Steuerwarteschlange entnommene Informationen durchsucht, um zu bestimmen, ob ein verwandtes Paket (z. B. ein Paket in dem gleichen Fluss wie das zu übertragende Paket) ebenfalls im Begriff ist, übertragen zu werden. Wenn das der Fall ist, wird der Host-Computer gewarnt, so dass die Protokollköpfe von den verwandten Paketen kollektiv verarbeitet werden können. In dieser alternativen Ausführungsform der Erfindung werden verwandte Pakete identifiziert, indem ihre Flussnummern (oder Flussschlüssel) in den Statusinformationen 912 verglichen werden. Der zweite Lesezeiger kann verwendet werden, um in der Steuerwarteschlange nach Paketen mit passenden Flussnummern vorauszuschauen.
  • In einer Ausführungsform der Erfindung kann die CPU-Nummer 902 durch den Lastverteiler 112 in der Steuerwarteschlange gespeichert werden und kann das No_Assist-Signal 904 durch den Kopfanalysealgorithmus 106 gespeichert werden. Der Operationscode 906 kann durch den Flussdatenbankmanager 108 gespeichert werden und der Nutzinformationsversatz 908 und die Nutzinformationsgröße 910 können durch den Kopfanalysealgorithmus 106 gespeichert werden. Abschnitte weiterer Statusinformationen können durch die vorstehenden Module und/oder andere wie etwa das IPP-Modul 104 und den Prüfsummengenerator 114 geschrieben werden. In einer besonderen Ausführungsform der Erfindung werden aber viele dieser Informationselemente durch das IPP-Modul 104 oder durch ein anderes Modul, das etwas in einer Koordinatorrolle wirkt, gespeichert.
  • Eine Ausführungsform einer DMA-Maschine
  • 10 ist ein Blockschaltplan einer DMA-Maschine (Direktspeicherzugriffsmaschine) 120 in einer Ausführungsform der Erfindung. Ein Zweck der DMA-Maschine 120 in dieser Ausführungsform ist es, Pakete aus der Paketwarteschlange 116 in die Puffer im Host-Computerspeicher zu übertragen. Da verwandte Pakete (z. B. Pakete, die Teil eines Flusses sind) durch ihre Flussnummern oder Flussschlüssel identifiziert werden können, können Daten von den verwandten Paketen kollektiv (z. B. in dem gleichen Puffer) übertragen werden. Unter Verwendung eines Puffers für Daten aus einem Fluss können die Daten auf hocheffiziente Weise an ein Anwendungsprogramm oder an ein anderes Ziel geliefert werden. Nachdem der Host-Computer die Daten empfangen hat, kann z. B. eher eine Seitenwechseloperation ausgeführt werden, um die Daten in den Speicherraum einer Anwendung zu übertragen, als zahlreiche Kopieroperationen auszuführen.
  • Mit Rückbezug auf die 1A–B wird ein Paket, das durch die DMA-Maschine 120 in den Host-Speicher übertragen werden soll, in der Paketwarteschlange 116 gespeichert, nachdem es vom Netz 102 empfangen worden ist. Der Kopfanalysealgorithmus 106 analysiert syntaktisch einen Kopfabschnitt des Pakets und erzeugt einen Flussschlüssel, während der Flussdatenbankmanager 108 dem Paket einen Operationscode zuweist. Außerdem wird der Kommunikationsfluss, der das Paket enthält, in der Flussdatenbank 110 registriert. Der Fluss des Pakets kann durch seinen Flussschlüssel oder durch seine Flussnummer (z. B. durch den Index des Flusses in der Flussdatenbank 110) identifiziert werden. Schließlich werden die das Paket betreffenden Informationen (z. B. der Operationscode, ein Paketgrößeanzeiger, die Flussnummer) in der Steuerwarteschlange 118 und möglicherweise in weiteren Abschnitten oder Modulen der NIC 100 gespeichert und wird das Paket durch die DMA-Maschine 120 an den Host-Computer übertragen. Während des Übertragungsprozesses kann sich die DMA-Maschine auf in der Steuerwarteschlange gespeicherte Informationen stützen, um das Paket wie im Folgenden beschrieben in einen geeigneten Puffer zu kopieren. Wie in einem folgenden Abschnitt ausführlich diskutiert wird, kann das dynamische Paketstapel-Modul 122 ebenfalls in der Steuerwarteschlange gespeicherte Informationen verwenden.
  • In 10 ist nunmehr eine Ausführungsform einer DMA-Maschine dargestellt. In dieser Ausführungsform administriert der DMA-Manager 1002 die Übertragung eines Pakets aus der Paketwarteschlange 116 in einen oder mehrere Puffer im Host-Computerspeicher. Wie im Folgenden beschrieben wird, identifiziert oder empfängt der Frei-Ring-Manager 1012 leere Puffer vom Host-Speicher, während der Abschluss-Ring-Manager 1014 die Puffer an den Host-Computer freigibt. Der Frei-Ring-Manager und der Abschluss-Ring-Manager können mit Logik gesteuert werden, die im DMA-Manager 1002 enthalten ist. In der veranschaulichten Ausführungsform speichern eine Flusswiederzusammensetzungstabelle 1004, eine Kopftabelle 1006, eine MTU-Tabelle 1008 und eine Jumbo-Tabelle 1010 Informationen, die Puffer betreffen, die (wie im Folgenden beschrieben) zum Speichern verschiedener Pakettypen verwendet werden. Die in einer dieser Tabelle gespeicherten Informationen können eine Bezugnahme auf einen Puffer oder eine andere Einrichtung zum Identifizieren eines Puffers enthalten. Die DMA-Maschine 120 in 10 ist teilweise oder vollständig in Hardware implementiert.
  • Über einen Frei-Deskriptor-Ring, der im Host-Speicher aufrechterhalten wird, werden leere Puffer identifiziert, in denen Pakete gespeichert werden können. In dieser Ausführungsform ist ein Deskriptor-Ring eine Datenstruktur, die logisch als eine ringförmige Warteschlange angeordnet ist. Ein Deskriptor-Ring enthält Deskriptoren zum Speichern von Informationen (z. B. Daten, Merker, Zeiger, Adresse). In einer Ausführungsform der Erfindung speichert jeder Deskriptor in dem Frei-Deskriptor-Ring seinen Index und einen Identifizierer (z. B. Speicheradresse, Zeiger) eines freien Puffers, der zum Speichern von Paketen verwendet werden kann. In dieser Ausführungsform wird ein Puffer in einem Deskriptor durch seine Adresse im Speicher identifiziert, obgleich andere Einrichtungen zum Identifizieren eines Speicherpuffers ebenfalls geeignet sind. In einer Ausführungsform der Erfindung ist ein Deskriptor-Ring dreizehn Bits groß, was maximal 8192 Deskriptoren in dem Ring ermöglicht, während eine Pufferadresse eine Größe von vierundsechzig Bits hat.
  • In der Ausführungsform aus 10 erhält Software, die in einem Host-Computer ausgeführt wird, wie etwa ein Gerätetreiber für die NIC 100 ein Datenfeld freier Puffer oder eine andere Datenstruktur (z. B. Liste, Tabelle) zum Speichern von Bezugnahmen auf die in den Frei-Deskriptoren identifizierten Puffer (z. B. deren Adressen) aufrecht. Während Deskriptoren aus dem Ring wiedergewonnen werden, werden ihre Pufferidentifizierer in dem Datenfeld angeordnet. Somit kann ein Puffer durch seinen Index (z. B. Zelle, Element) in dem Datenfeld freier Puffer identifiziert werden, wenn er für die Speicherung eines Pakets benötigt wird. Wenn der Puffer daraufhin nicht mehr benötigt wird, kann er an den Host-Computer freigegeben werden, indem sein Datenfeldindex oder seine Bezugnahme in einem Abschluss-Deskriptor angeordnet wird. Daraufhin kann ein in dem Puffer gespeichertes Paket dadurch wiedergewonnen werden, dass auf den in dem angegebenen Element des Datenfelds identifizierten Puffer zugegriffen wird. Somit braucht die Größe des Deskriptorindex (z. B. dreizehn Bits) in dieser Ausführungsform der Erfindung die Puffer, die durch den Frei-Ring-Manager 1012 zugewiesen werden können, nicht zu begrenzen. Insbesondere könnte praktisch irgendeine Anzahl von Puffern oder Deskriptoren durch die Software administriert werden. Zum Beispiel können die Pufferidentifizierer in einer alternativen Ausführungsform der Erfindung in einer oder in mehreren verketteten Listen gespeichert werden, nachdem sie von Deskriptoren in einem Frei-Deskriptor-Ring wiedergewonnen worden sind. Wenn der Puffer an den Host-Computer freigegeben wird, kann eine Bezugnahme auf den Kopf der verketteten Liste des Puffers geliefert werden. Daraufhin könnte durch die Liste navigiert werden, um den besonderen Puffer (z. B. durch seine Adresse) aufzufinden.
  • Die Aufnahme einer begrenzten Anzahl von Deskriptoren in den Frei-Deskriptor-Ring (z. B. in dieser Ausführungsform 8192) bedeutet, dass sie auf Round-Robin-Weise wieder verwendet werden können. In der derzeit beschriebenen Ausführungsform wird ein Deskriptor gerade lange genug benötigt, um seinen Pufferidentifizierer (z. B. die Adresse) wiederzugewinnen und in dem Datenfeld freier Puffer anzuordnen, wonach er verhältnismäßig schnell wiederverwendet werden kann. In weiteren Ausführungsformen der Erfindung können Frei-Deskriptor-Ringe mit anderen Anzahlen von Frei-Deskriptoren verwendet werden, die somit eine gewisse Steuerung der Rate ermöglichen, mit der die Frei-Deskriptoren wiederverwendet werden müssen.
  • Anstatt eine getrennte Datenstruktur zum Identifizieren eines Puffers zum Speichern eines Pakets zu verwenden, kann in einer alternativen Ausführungsform der Erfindung ein Puffer in der DMA-Maschine 120 durch den Index des Frei-Deskriptors in dem Frei-Deskriptor-Ring identifiziert werden, der auf den Puffer Bezug genommen hat. Wenn der Ring eine begrenzte Anzahl von Deskriptoren enthält, ist es aber ein Nachteil dieses Schemas, dass der Deskriptor eines besonderen Puffers möglicherweise wiederverwendet werden muss, bevor sein Puffer an den Host-Computer freigegeben worden ist. Somit muss entweder ein Verfahren implementiert werden, um die Wiederverwendung eines solchen Deskriptors zu vermeiden oder zu überspringen, oder muss der Puffer, auf den der Deskriptor Bezug nimmt, freigegeben werden, bevor der Deskriptor wieder benötigt wird. Andererseits kann ein Frei-Deskriptor-Ring in einer weiteren Alternative eine so hohe Größe haben, dass von der Zeit, zu der ein Frei-Deskriptor erstmals verwendet wird, bis er wiederverwendet werden muss, eine sehr lange oder sogar praktisch unendliche Zeitdauer vergehen kann.
  • Somit gewinnt der Frei-Ring-Manager 1012 in der veranschaulichten Ausführungsform der Erfindung einen Deskriptor aus dem Frei-Deskriptor-Ring wieder, speichert seinen Pufferidentifizierer (z. B. die Speicheradresse) in einem Datenfeld freier Puffer und liefert den Datenfeldindex und/oder den Pufferidentifizierer an die Flusswiederzusammensetzungstabelle 1004, an die Kopftabelle 1006, an die MTU-Tabelle 1008 oder an die Jumbo-Tabelle 1010.
  • Der Frei-Ring-Manager 1012 versucht sicherzustellen, dass immer ein Puffer für ein Paket verfügbar ist. Somit enthält der Frei-Ring-Manager 1012 in einer Ausführungsform der Erfindung einen Deskriptor-Cache 1012a, der zum Speichern einer Anzahl von Deskriptoren (z. B. bis zu acht) gleichzeitig konfiguriert ist. Immer dann, wenn es weniger als eine Schwellenzahl Einträge in dem Cache (z. B. fünf) gibt, können zusätzliche Deskriptoren aus dem Frei-Deskriptor-Ring wiedergewonnen werden. Vorteilhaft besitzen die Deskriptoren eine solche Größe (z. B. sechzehn Bytes), dass einige mehrere (z. B. vier) von ihnen in einer Vierundsechzig-Byte-Cache-Linienübertragung von dem Host-Computer effizient wiedergewonnen werden können.
  • Nunmehr zurückkehrend zu der veranschaulichten Ausführungsform der Erfindung besitzt jeder Puffer im Host-Speicher eine Größe einer Speicherseite. Allerdings können die Puffer und die in den Puffern gespeicherten Pakete anhand der Paketgröße und anhand dessen, ob die Daten eines Pakets wieder zusammengesetzt werden, in mehrere Kategorien unterteilt werden. Das Wiederzusammensetzen bezieht sich auf die Akkumulation der Daten aus mehreren Paketen eines einzigen Flusses in einem Puffer zur effizienten Übertragung aus dem Kernel-Raum in den Anwender- oder Anwendungsraum im Host-Speicher. Insbesondere können wieder zusammensetzbare Pakete als Pakete definiert werden, die zu einem im Voraus gewählten Protokoll (z. B. zu einem Protokoll, das durch den Kopfanalysealgorithmus 106 syntaktisch analysiert werden kann) konform sind.
  • Dadurch, dass eine Speicherseite mit Daten für ein Ziel gefüllt wird, kann ein Seitenwechsel ausgeführt werden, um eine Seite im Kernel-Raum an den Anwendungs- oder Anwenderraum zu liefern. Die Kategorie eines Pakets (z. B., ob wieder zusammensetzbar oder nicht wieder zusammensetzbar) kann aus Informationen bestimmt werden, die von der Steuerwarteschlange oder von dem Flussdatenbankmanager wiedergewonnen werden. Wie schon zuvor beschrieben wurde, kann insbesondere ein Operationscode verwendet werden, um zu bestimmen, ob ein Paket einen wieder zusammensetzbaren Datenabschnitt enthält.
  • In der veranschaulichten Ausführungsform der Erfindung werden Datenabschnitte verwandter, wieder zusammensetzbarer Pakete in einer ersten Kategorie von Puffern angeordnet – die als Wiederzusammensetzungspuffer bezeichnet werden können. Eine zweite Kategorie von Puffern, die Kopfpuffer genannt werden können, speichert die Köpfe jener Pakete, deren Datenabschnitte gerade wieder zusammengesetzt werden, und kann ebenfalls kleine Pakete (z. B. jene mit einer Größe kleiner oder gleich 256 Bytes) speichern. Eine dritte Kategorie von Puffern, die MTU-Puffer, speichert nicht wieder zusammensetzbare Pakete, die größer als 256 Bytes, aber kleiner als die MTU-Größe (z. B. 1522 Bytes), sind. Schließlich speichert eine vierte Kategorie von Puffern, die Jumbo-Puffer, Jumbo-Pakete (z. B. große Pakete, deren Größe größer als 1522 Bytes ist), die nicht wieder zusammengesetzt werden. Beispielhaft kann ein Jumbo-Paket unversehrt gespeichert werden (wobei z. B. seine Köpfe und seine Datenabschnitte in einem Puffer zusammengehalten werden) oder können seine Köpfe in einem Kopfpuffer gespeichert werden, während sein Datenabschnitt in einem geeigneten (z. B. Jumbo-)Nichtwiederzusammensetzungspuffer gespeichert wird.
  • In einer alternativen Ausführungsform der Erfindung wird zwischen MTU- und Jumbo-Paketen kein Unterschied gemacht. Somit werden in dieser alternativen Ausführungsform nur drei Puffertypen verwendet: Wiederzusammensetzungspuffer und Kopfpuffer wie oben beschrieben zuzüglich Nichtwiederzusammensetzungspuffern. Beispielhaft werden alle nicht kleinen Pakete (z. B. größer als 256 Bytes), die nicht wieder zusammengesetzt werden, in einem Nichtwiederzusammensetzungspuffer angeordnet.
  • In einer weiteren alternativen Ausführungsform können Jumbo-Pakete in Jumbo-Puffern wieder zusammengesetzt werden. Insbesondere werden in dieser Ausführungsform Datenabschnitte von Paketen, die kleiner als eine vorgegebene Größe (z. B. MTU) sind, in normalen Wiederzusammensetzungspuffern wieder zusammengesetzt, während Datenabschnitte von Jumbo-Paketen (z. B. Paketen mit einer größeren Größe als der MTU) in Jumbo-Puffern wieder zusammengesetzt werden. Für einen Kommunikationsfluss, der Jumbo-Rahmen mit einer Größe enthält, so dass mehrere Rahmen in einen Puffer passen können, kann das Wiederzusammensetzen von Jumbo-Paketen besonders effektiv sein. Die Kopfabschnitte beider Pakettypen können in einem Kopfpuffertyp gespeichert werden oder alternativ können für die Köpfe der verschiedenen Typen wieder zusammensetzbarer Pakete verschiedene Kopfpuffer verwendet werden.
  • In einer abermals weiteren alternativen Ausführungsform der Erfindung können die Puffer veränderliche Größen haben und in verschiedenen Deskriptor-Ringen oder anderen Datenstrukturen identifiziert werden. Zum Beispiel kann ein erster Deskriptor-Ring oder anderer Mechanismus verwendet werden, um die Puffer einer ersten Größe zum Speichern großer Pakete oder Jumbo-Pakete zu identifizieren. Ein zweiter Ring kann Deskriptoren speichern, die auf Puffer für Pakete mit MTU-Größe Bezug nehmen, und ein weiterer Ring kann Deskriptoren zum Identifizieren von Puffern mit Seitengröße (z. B. für die Datenwiederzusammensetzung) enthalten.
  • Ein Puffer, der zum Speichern von Abschnitten mehr als eines Pakettyps verwendet wird – wie etwa ein zum Speichern von Köpfen und kleinen Paketen verwendeter Kopfpuffer oder ein zum Speichern von MTU- und Jumbo-Paketen verwendeter Nichtwiederzusammensetzungspuffer – kann ein "Hybrid"-Puffer genannt werden.
  • Beispielhaft bevölkert ein Abschluss-Ring-Manager 1014 jedes Mal, wenn ein Paket oder ein Abschnitt eines Pakets in einem Puffer gespeichert wird, einen Deskriptor in einem Abschluss-Deskriptor-Ring mit Informationen, die das Paket betreffen. In den in einem Abschluss-Deskriptor gespeicherten Informationen ist in dieser Ausführungsform eine Zahl oder Bezugnahme enthalten, die die Datenfeldzelle oder das Datenfeldelement freier Puffer identifiziert, in der bzw. in dem sich ein Identifizierer (z. B. eine Speicheradresse) eines Puffers befindet, in dem ein Abschnitt des Pakets gespeichert ist. Außerdem können die Informationen einen Versatz in den Puffer (z. B. zum Beginn des Paketabschnitts), die Identität eines weiteren Eintrags im Datenfeld freier Puffer, der einen Pufferidentifizierer für einen Puffer speichert, der einen weiteren Abschnitt des Pakets enthält, eine Größe des Pakets usw. enthalten sein. Ein Paket kann z. B. in mehreren Puffern gespeichert werden, falls die Paketdaten und der Paketkopf getrennt gespeichert werden (wobei z. B. die Daten des Pakets in einem Wiederzusammensetzungspuffer wieder zusammengesetzt werden, während der Kopf des Pakets in einem Kopfpuffer angeordnet wird). Außerdem können sich die Datenabschnitte eines Jumbo-Pakets oder eines Wiederzusammensetzungspakets je nach Größe des Datenabschnitts über zwei oder mehr Puffer erstrecken.
  • Ein Unterschied zwischen einem Pufferidentifizierer (z. B. der Speicheradresse eines Puffers) und dem Eintrag in dem Datenfeld freier Puffer, in dem der Pufferidentifizierer gespeichert wird, sollte beachtet werden. Insbesondere ist oben beschrieben worden, dass ein Speicherpuffer, wenn er an einen Host-Computer freigegeben wird, für den Host-Computer eher durch seine Stellung innerhalb eines Datenfelds freier Puffer (oder einer anderen geeigneten Datenstruktur) als durch seinen Pufferidentifizierer identifiziert wird. Der Host-Computer gewinnt den Pufferidentifizierer aus dem angegebenen Datenfeldelement wieder und greift auf den angegebenen Puffer zu, um ein in dem Puffer gespeichertes Paket aufzufinden. Das Identifizieren von Speicherpuffern in Abschluss-Deskriptoren durch die Stellungen der Puffer in einem Datenfeld freier Puffer kann effizienter sein, als sie durch ihre Speicheradressen zu identifizieren. Insbesondere haben die Pufferidentifizierer in 10 eine Größe von vierundsechzig Bits, während ein Index in einem Datenfeld freier Puffer oder in einer ähnlichen Datenstruktur wahrscheinlich viel kleiner ist. Somit spart die Verwendung von Datenfeldstellen im Vergleich zur Verwendung von Pufferidentifizierern Platz. Dennoch können in einer alternativen Ausführungsform der Erfindung eher Pufferidentifizierer zum direkten Identifizieren von Puffern verwendet werden, als den Zugriff auf sie durch ein Datenfeld freier Puffer zu filtern. Allerdings müssten die Abschluss-Deskriptoren dementsprechend größer sein, um sie unterzubringen.
  • Außerdem kann ein Abschluss-Deskriptor einen oder mehrere Merker enthalten, die den Typ oder die Größe eines Pakets, ob die Paketdaten wieder zusammengesetzt werden sollten, ob das Paket das letzte eines Datagramms ist, ob der Host-Computer die Verarbeitung des Pakets verzögern sollte, um auf ein verwandtes Paket zu warten, usw. anzeigen. Wie in einem folgenden Abschnitt beschrieben wird, bestimmt das dynamische Paketstapel-Modul 122 in einer Ausführungsform der Erfindung zu der Zeit, zu der ein Paket an den Host-Computer übertragen wird, ob in Kürze ein verwandtes Paket gesendet wird. Wenn das der Fall ist, kann der Host-Computer darauf hingewiesen werden, um die Verarbeitung des übertragenen Pakets zu verzögern und auf das verwandte Paket zu warten, um eine effizientere Verarbeitung zu ermöglichen.
  • Wenn der durch seinen Pufferidentifizierer identifizierte Puffer an den Host-Computer freigegeben werden soll, kann der Abschluss-Deskriptor eines Pakets geeignet gekennzeichnet werden. Zum Beispiel kann in dem Deskriptor ein Merker gesetzt werden, um für den Host-Computer oder für die in dem Host-Computer arbeitende Software (z. B. für einen der NIC 100 zugeordneten Treiber) anzuzeigen, dass der Puffer des Pakets von der DMA-Maschine 120 freigegeben wird. In einer Ausführungsform der Erfindung enthält der Abschluss-Ring-Manager 1014 einen Abschluss-Deskriptor-Cache 1014a. Der Abschluss-Deskriptor-Cache 1014a kann einen oder mehrere Abschluss-Deskriptoren für die kollektive Übertragung von der DMA-Maschine 120 zum Host-Computer speichern.
  • Somit werden leere Puffer aus einem Frei-Ring wiedergewonnen und verwendete Puffer über einen Abschluss-Ring an den Host-Computer freigegeben. Ein Grund, dass zum Freigeben verwendeter Puffer an den Host-Computer ein getrennter Ring verwendet wird, ist, dass die Puffer möglicherweise nicht in der Reihenfolge freigegeben werden, in der sie genommen wurden. In einer Ausführungsform der Erfindung braucht ein Puffer, insbesondere ein Flusswiederzusammensetzungspuffer, nicht freigegeben zu werden, bis er voll ist. Alternativ kann ein Puffer praktisch jederzeit, wie etwa wenn das Ende eines Kommunikationsflusses erfasst wird, freigegeben werden. Frei-Deskriptoren und Abschluss-Deskriptoren werden im Folgenden in Verbindung mit 12 weiter beschrieben.
  • Ein weiterer Grund dafür, dass für Frei- und Abschluss-Deskriptoren getrennte Ringe verwendet werden, ist, dass die Anzahl der Abschluss-Deskriptoren, die in einer Ausführungsform der Erfindung erforderlich sind, die Anzahl der Frei-Deskriptoren, die in einem Frei-Deskriptor-Ring vorgesehen sind, übersteigen kann. Zum Beispiel kann ein Puffer, der durch einen Frei-Deskriptor bereitgestellt wird, zum Speichern mehrerer Köpfe und/oder kleiner Pakete verwendet werden. Allerdings wird jedes Mal, wenn ein Kopf oder ein kleines Paket in dem Kopfpuffer gespeichert wird, ein getrennter Abschluss-Deskriptor erzeugt. In einer Ausführungsform der Erfindung, in der ein Kopfpuffer eine Größe von acht Kilobytes hat, kann ein Kopfpuffer bis zu zweiunddreißig kleine Pakete speichern. Für jedes in dem Kopfpuffer gespeicherte Paket wird ein weiterer Abschluss-Deskriptor er zeugt.
  • 11 enthält Diagramme veranschaulichender Ausführungsformen der Flusswiederzusammensetzungstabelle 1004, der Kopftabelle 1006, der MTU-Tabelle 1008 und der Jumbo-Tabelle 1010. Eine alternative Ausführungsform der Erfindung enthält anstelle der MTU-Tabelle 1008 und der Jumbo-Tabelle 1010 eine Nichtwiederzusammensetzungstabelle, die einem einzigen Typ eines Nichtwiederzusammensetzungspuffers sowohl für MTU- als auch für Jumbo-Pakete entspricht. In einer weiteren alternativen Ausführungsform der Erfindung, in der Jumbo-Puffer nur bei Bedarf wiedergewonnen oder identifiziert werden, kann die Jumbo-Tabelle 1010 ebenfalls weggelassen sein. Da ein Jumbo-Puffer in dieser alternativen Ausführungsform nur einmal verwendet wird, besteht keine Notwendigkeit, eine Tabelle aufrechtzuerhalten, um seine Verwendung zu verfolgen.
  • In der veranschaulichten Ausführungsform speichert die Flusswiederzusammensetzungstabelle 1004 Informationen, die das Wiederzusammensetzen von Paketen in einem oder in mehreren Kommunikationsflüssen betreffen. Für jeden aktiven Fluss durch die DMA-Maschine 120 können zum Speichern der Daten des Flusses getrennte Flusswiederzusammensetzungspuffer verwendet werden. Für einen besonderen Fluss kann mehr als ein Puffer verwendet werden, wobei aber jeder Fluss einen Eintrag in der Flusswiederzusammensetzungstabelle 1004 besitzt, mit dem die Verwendung eines Puffers zu verfolgen ist. Eine Ausführungsform der Erfindung unterstützt die Verschachtelung von bis zu vierundsechzig Flüssen. Somit erhält die Flusswiederzusammensetzungs-Puffertabelle 1004 in dieser Ausführungsform bis zu vierundsechzig Einträge aufrecht. Der Eintrag eines Flusses in der Flusswiederzusammensetzungstabelle kann mit seiner Flussnummer (z. B. mit dem Index des Flussschlüssels des Flusses in der Flussdatenbank 110) übereinstimmen, während in einer alternativen Ausführungsform für jeden Fluss ein Eintrag verwendet werden kann.
  • In 11 enthält ein Eintrag in der Flusswiederzusammensetzungstabelle 1004 einen Flusswiederzusammensetzungs-Pufferindex 1102, eine nächste Adresse 1104 und einen Gültigkeitsanzeiger 1106. Der Flusswiederzusammensetzungs-Pufferindex 1102 enthält den Index oder die Stelle in einem Datenfeld freier Puffer oder einer anderen Datenstruktur zum Speichern von in Frei-Deskriptoren identifizierten Pufferidentifizierern eines Puffers zum Speichern von Daten aus einem zugeordneten Fluss. Beispielhaft wird dieser Wert in jeden Abschluss-Deskriptor geschrieben, der einem Paket zugeordnet ist, dessen Datenabschnitt in dem Puffer gespeichert ist. Dieser Wert kann von Software, die in dem Host-Computer arbeitet, verwendet werden, um auf den Puffer zuzugreifen und die Daten zu verarbeiten. Die nächste Adresse 1104 identifiziert den Platz in dem Puffer (z. B. eine Speicheradresse), an dem der nächste Datenabschnitt zu speichern ist. Beispielhaft wird dieses Feld jedes Mal aktualisiert, wenn Daten zu dem Puffer hinzugefügt werden. Der Gültigkeitsanzeiger 1106 zeigt an, ob der Eintrag gültig ist. Beispielhaft wird jeder Eintrag auf einen gültigen Zustand gesetzt (wobei er z. B. einen ersten Wert speichert), wenn ein erster Datenabschnitt in dem Wiederzusammensetzungspuffer des Puffers gespeichert wird, während er annulliert wird (z. B. einen zweiten Wert speichert), wenn der Puffer voll ist. Wenn ein Eintrag annulliert wird, kann der Puffer freigegeben oder an den Host-Computer zurückgegeben werden (da er z. B. voll ist).
  • Die Kopftabelle 1006 speichert in der veranschaulichten Ausführungsform Informationen, die einen oder mehrere Kopfpuffer betreffen, in denen Paketköpfe und kleine Pakete gespeichert werden. In der veranschaulichten Ausführungsform der Erfindung ist jederzeit nur ein Kopfpuffer aktiv. Das heißt, in einem Puffer werden Köpfe und kleine Pakete gespeichert, bis er freigegeben wird, wobei zu dieser Zeit ein neuer Puffer verwendet wird. In dieser Ausführungsform enthält die Kopftabelle 1006 einen Kopfpufferindex 1112, eine nächste Adresse 1114 und einen Gültigkeitsanzeiger 1116. Ähnlich wie bei der Flusswiederzusammensetzungstabelle 1004 identifiziert der Kopfpufferindex 1112 diejenige Zelle oder dasjenige Element in dem Datenfeld freier Puffer, die bzw. das einen Pufferidentifizierer für einen Kopfpuffer enthält. Die nächste Adresse 1114 identifiziert denjenigen Platz in dem Kopfpuffer, an dem der nächste Kopf oder das nächste kleine Paket zu speichern ist. Dieser Identifizierer, der ein Zähler sein kann, kann jedes Mal aktualisiert werden, wenn ein Kopf oder ein kleines Paket in dem Kopfpuffer gespeichert wird. Der Gültigkeitsanzeiger 1116 zeigt an, ob die Kopfpuffertabelle und/oder der Kopfpuffer gültig sind. Dieser Anzeiger kann auf gültig gesetzt werden, wenn ein erstes Paket oder ein erster Kopf in einem Kopfpuffer gespeichert wird, während er annulliert werden kann, wenn es bzw. er an den Host-Computer freigegeben wird.
  • Die MTU-Tabelle 1008 speichert Informationen, die einen oder mehrere MTU-Puffer zum Speichern von MTU-Paketen (z. B. Paketen größer als 256 Bytes, aber kleiner als 1523 Bytes) betreffen, die nicht wieder zusammengesetzt werden. Der MTU-Pufferindex 1122 identifiziert das Datenfeldelement freier Puffer, das einen Pufferidentifizierer (z. B. eine Adresse) eines Puffers zum Speichern von MTU-Paketen enthält. Die nächste Adresse 1124 identifiziert den Platz in dem momentanen MTU-Puffer, an dem das nächste Paket zu speichern ist. Der Gültigkeitsanzeiger 1126 zeigt die Gültigkeit des Tabelleneintrags an. Der Gültigkeitsanzeiger kann auf einen gültigen Zustand gesetzt werden, wenn ein erstes Paket in dem MTU-Puffer gespeichert wird, während er auf einen ungültigen Zustand gesetzt werden kann, wenn der Puffer an den Host-Computer freigegeben wird.
  • Die Jumbo-Tabelle 1010 speichert Informationen, die einen oder mehrere Jumbo-Puffer zum Speichern von Jumbo-Paketen (z. B. Paketen größer als 1522 Bytes) betreffen, die nicht wieder zusammengesetzt werden. Der Jumbo-Pufferindex 1132 identifiziert das Element innerhalb des Datenfelds freier Puffer, das einen Pufferidentifizierer speichert, der einem Jumbo-Puffer entspricht. Die nächste Adresse 1134 identifiziert den Platz in dem Jumbo-Puffer, an dem das nächste Paket zu speichern ist. Der Gültigkeitsanzeiger 1136 zeigt die Gültigkeit des Tabelleneintrags ein. Beispielhaft wird der Gültigkeitsanzeiger auf einen gültigen Zustand gesetzt, wenn ein erstes Paket in dem Jumbo-Puffer gespeichert wird, während er auf einen ungültigen Zustand gesetzt wird, wenn der Puffer an den Host-Computer freigegeben wird.
  • In der in 11 gezeigten Ausführungsform der Erfindung wird ein Paket mit einer größeren als einer angegebenen Größe (z. B. 256 Bytes) nicht wieder zusammengesetzt, falls es mit den im Voraus gewählten Protokollen für die NIC 100 (z. B. TCP, IP, Ethernet) inkompatibel ist oder falls das Paket zu groß (z. B. größer als 1522 Bytes) ist. Obgleich in dieser Ausführungsform für nicht wieder zusammensetzbare Pakete zwei Typen von Puffern (z. B. MTU und Jumbo) verwendet werden, kann in einer alternativen Ausführungsform der Erfindung irgendeine Anzahl einschließlich einem verwendet werden. Pakete kleiner als die angegebene Größe werden allgemein nicht wieder zusammengesetzt. Stattdessen werden sie wie oben beschrieben unversehrt in einem Kopfpuffer gespeichert.
  • In der in 11 gezeigten Ausführungsform der Erfindung können die Felder der nächsten Adresse eine Speicheradresse, einen Versatz, einen Zeiger, einen Zähler oder eine andere Einrichtung zum Identifizieren einer Stelle in einem Puffer speichern. Vorteilhaft wird das Feld der nächsten Adresse einer Tabelle oder eines Tabelleneintrags anfangs auf die Adresse des Puffers gesetzt, der zum Speichern von Paketen des der Tabelle zugeordneten Typs (und für die Wiederzusammensetzungstabelle 1004 des besonderen Flusses) zugewiesen ist. Während der Puffer bevölkert wird, wird die Adresse aktualisiert, um den Platz in dem Puffer zu identifizieren, an dem das nächste Paket oder der nächste Abschnitt eines Pakets gespeichert werden soll.
  • Beispielhaft speichert jeder Gültigkeitsanzeiger einen ersten Wert (z. B. eins) zum Anzeigen der Gültigkeit und einen zweiten Wert (z. B. null) zum Anzeigen der Ungültigkeit. In der veranschaulichten Ausführungsform der Erfindung hat jedes Indexfeld dreizehn Bits, hat jedes Adressenfeld vierundsechzig Bits und haben die Gültigkeitsanzeiger jeweils eine Größe von einem Bit.
  • Die Tabellen 1004, 1006, 1008 und 1010 können andere Formen annehmen, wobei sie innerhalb des Umfangs der wie betrachteten Erfindung bleiben. Zum Beispiel können diese Datenstrukturen die Form von Datenfeldern, Listen, Datenbanken usw. annehmen und in Hardware oder Software implementiert werden. In der veranschaulichten Ausführungsform der Erfindung enthalten die Kopftabelle 1006, die MTU-Tabelle 1008 und die Jumbo-Tabelle 1010 jeweils jederzeit nur einen Eintrag. Somit sind in dieser Ausführungsform jederzeit nur ein Kopfpuffer, ein MTU-Puffer und ein Jumbo-Puffer aktiv (z. B. gültig). In einer alternativen Ausführungsform der Erfindung können mehrere Kopfpuffer, MTU-Puffer und/oder Jumbo-Puffer gleichzeitig verwendet werden (z. B. gültig sein).
  • In einer Ausführungsform der Erfindung können bestimmte Kategorien von Puffern (z. B. Kopfpuffer, Nichtwiederzusammensetzungspuffer) eine im Voraus bestimmte Anzahl von Paketen oder Paketabschnitten speichern. Zum Beispiel kann ein Kopfpuffer maximal zweiunddreißig Einträge, von denen jeder 256 Bytes beträgt, speichern, wo die Speicherseitengröße eines Host-Computerprozessors acht Kilobytes beträgt. Beispielhaft wird der nächste Eintrag in dem Puffer an der nächsten 256-Byte-Grenze gespeichert, selbst wenn ein Paket oder Kopf kleiner als 256 Bytes ist. Dem Puffer kann ein Zähler zugeordnet werden, der jedes Mal, wenn in dem Puffer ein neuer Eintrag gespeichert wird, dekrementiert (oder inkrementiert) wird. Nachdem zweiunddreißig Einträge vorgenommen worden sind, kann der Puffer freigegeben werden.
  • In einer Ausführungsform der Erfindung können andere Puffer als Kopfpuffer in Gebiete fester Größe unterteilt werden. Zum Beispiel können jedem MTU-Paket in einem Acht-Kilobyte-MTU-Puffer zwei Kilobytes zugeordnet werden. Irgendein Platz, der im Bereich eines Pakets verbleibt, nachdem das Paket gespeichert worden ist, kann ungenutzt gelassen oder aufgefüllt werden.
  • In einer alternativen Ausführungsform der Erfindung werden Einträge in einem Kopfpuffer und/oder in einem Nichtwiederzusammensetzungspuffer (z. B. MTU, Jumbo) zur effizienteren Übertragung ausgerichtet. Insbesondere werden zu Beginn jedes Eintrags in einem solchen Puffer zwei Bytes zum Auffüllen (z. B. willkürliche Bytes) gespeichert. Da der Schicht-Zwei-Ethernet-Kopf eines Pakets vierzehn Bytes lang ist, wird der Schicht-Drei-Protokollkopf (z. B. IP) jedes Pakets durch Addieren von zwei Auffüllbytes auf eine Sechzehn-Byte-Grenze ausgerichtet. Die Sechzehn-Byte-Ausrichtung ermöglicht das effiziente Kopieren von Paketinhalten (wie etwa des Schicht-Drei-Kopfs). Allerdings kann das Hinzufügen von zwei Bytes die Größe des maximalen Pakets, das in einem Kopfpuffer gespeichert werden kann, (z. B. auf 254 Bytes) verringern.
  • Wie oben erläutert wurde, können Zähler und/oder Auffüllen ebenfalls bei Nichtwiederzusammensetzungspuffern verwendet werden. Allerdings können einige nicht wieder zusammensetzbare Pakete (z. B. Jumbo-Pakete) in getrennte Kopf- und Datenabschnitte getrennt werden, wobei jeder Abschnitt – ähnlich dem Wiederzusammensetzen von Flusspaketen – in einem getrennten Puffer gespeichert wird. In einer Ausführungsform der Erfindung wird das Auffüllen lediglich bei Kopfabschnitten getrennter Pakete verwendet. Somit kann das Auffüllen, wenn ein nicht wiederzusammengesetztes (z. B. Jumbo-) Paket getrennt wird, auf den Kopfpuffer/kleinen Puffer, in dem der Kopfabschnitt des Pakets gespeichert ist, aber nicht auf den Nichtwiederzusammensetzungspuffer, in dem der Datenabschnitt des Pakets gespeichert ist, angewendet werden. Wenn dagegen ein Nichtwiederzusammensetzungspaket mit seinem Kopf und mit seinen Daten kollektiv in einem Nichtwiederzusammensetzungspuffer gespeichert wird, kann das Auffüllen auf diesen Puffer angewendet werden.
  • In einer weiteren alternativen Ausführungsform der Erfindung kann zu jedem Eintrag in einem Puffer, der nicht wiederzusammengesetzte Pakete speichert, die größer als 256 Bytes sind, (z. B. MTU-Pakete und Jumbo-Pakete, die nicht getrennt sind) eine zweite Ebene des Auffüllens hinzugefügt werden. In dieser alternativen Ausführungsform wird eine Cache-Speicherlinie (z. B. vierundsechzig Bytes für eine SolarisTM-Workstation) in dem Puffer übersprungen, bevor jedes Paket gespeichert wird. Der zusätzliche Auffüllbereich kann durch Software verwendet werden, die die Pakete und/oder ihre Abschluss-Deskriptoren verarbeitet. Die Software kann den zusätzlichen Auffüllbereich zum Leiten oder als eine temporäre Ablage für Informationen, die in einer sekundären oder späteren Verarbeitungsphase benötigt werden, verwenden.
  • Zum Beispiel kann die Software vor der tatsächlichen Verarbeitung des Pakets einige Daten speichern, die ein effizientes Multitasking in dem Auffüllbereich fördern. Die Informationen sind dann verfügbar, wenn das Paket schließlich aus dem Puffer extrahiert wird. Insbesondere kann eine Netzschnittstelle in einer Ausführungsform der Erfindung einen oder mehrere Datenwerte erzeugen, um Gruppenadressen oder alternative Adressen zu identifizieren, die einer Schicht-Zwei-Adresse eines von einem Netz empfangenen Pakets entsprechen. Die Gruppenadressen oder alternativen Adressen können in einem Netzschnittstellenspeicher durch Software, die in einem Host-Computer arbeitet (z. B. durch einen Gerätetreiber), gespeichert werden. Durch Speichern des Datenwerts bzw. der Datenwerte beim Auffüllen können verbesserte Leitungsfunktionen ausgeführt werden, wenn der Host-Computer das Paket verarbeitet.
  • Das Reservieren von vierundsechzig Bytes zu Beginn eines Puffers ermöglicht außerdem, dass bei Bedarf Kopfinformationen modifiziert oder vorangestellt werden. Zum Beispiel muss ein regulärer Ethernet-Kopf eines Pakets möglicherweise wegen Lenkungsanforderungen durch einen viel größeren FDDI-Kopf (Fiber-Distributed-Data-Interface-Kopf) ersetzt werden. Der Fachmann auf dem Gebiet erkennt die Größenungleichheit zwischen diesen Köpfen. Vorteilhaft kann für den FDDI-Kopf eher der reservierte Auffüllbereich verwendet werden, als einen weiteren Speicherblock zuzuordnen.
  • In einer vorliegenden Ausführungsform der Erfindung kann die DMA-Maschine 120 durch Untersuchen des Operationscodes eines Pakets bestimmen, zu welcher Kategorie ein Paket gehört und in welchem Puffertyp es zu speichern ist. Wie zuvor beschrieben wurde, kann für jedes in der Paketwarteschlange 116 gespeicherte Paket ein Operationscode in der Steuerwarteschlange 118 gespeichert werden. Somit kann die DMA-Maschine 120, wenn sie ein Paket in der Paketwarteschlange 116 erfasst, die entsprechenden Informationen in der Steuerwarteschlange holen und dementsprechend wirken.
  • Ein Operationscode kann anzeigen, ob ein Paket kompatibel mit den für die NIC 100 im Voraus gewählten Protokollen ist. In einer veranschaulichenden Ausführungsform der Erfindung sind lediglich kompatible Pakete für die Datenwiederzusammensetzung und/oder für andere durch die NIC 100 gebotene verbesserte Operationen (z. B. Paketstapelung oder Lastverfeilung) wählbar. Außerdem kann ein Operationscode die Größe eines Pakets (z. B. kleiner oder größer als eine vorgegebene Größe), ob ein Paket Daten enthält oder ein Steuerpaket ist und ob ein Paket einen Fluss beginnt, fortsetzt oder endet, widerspiegeln. In dieser Ausführungsform der Erfindung werden acht verschiedene Operationscodes verwendet. In alternativen Ausführungsformen der Erfindung können mehr oder weniger als acht Codes verwendet werden. TABELLE 1 führt Operationscodes auf, die in einer Ausführungsform der Erfindung verwendet werden können.
  • Die 12A–12B veranschaulichen Deskriptoren aus einem Frei-Deskriptor-Ring und aus einem Abschluss-Deskriptor-Ring in einer Ausführungsform der Erfindung. 12A zeigt außerdem ein Datenfeld freier Puffer zum Speichern von aus Frei-Deskriptoren wiedergewonnenen Pufferidentifizierern.
  • Der Frei-Deskriptor-Ring 1200 wird im Host-Speicher aufrechterhalten und mit Deskriptoren wie etwa einem Frei-Deskriptor 1202 bevölkert. Beispielhaft enthält der Frei-Deskriptor 1202 einen Ringindex 1204, den Index des Deskriptors 1202 im Frei-Ring 1200, und einen Pufferidentifizierer 1206. In dieser Ausführungsform ist ein Pufferidentifizierer eine Speicheradresse, wobei er aber alternativ einen Zeiger oder irgendeine andere geeignete Einrichtung zum Identifizieren eines Puffers im Host-Speicher enthalten kann.
  • In der veranschaulichten Ausführungsform ist das Datenfeld 1210 freier Puffer durch Software, die in einem Host-Computer arbeitet, (z. B. durch einen Gerätetreiber) konstruiert. Ein Eintrag im Datenfeld 1210 freier Puffer enthält in dieser Ausführungsform ein Datenfeld-Indexfeld 1212, das zum Identifizieren des Eintrags verwendet werden kann, und ein Pufferidentifiziererfeld 1214. Somit speichert das Pufferidentifiziererfeld jedes Eintrags einen Pufferidentiffzierer, der aus einem Frei-Deskriptor im Frei-Deskriptor-Ring 1200 wiedergewonnen wird.
  • In einer Ausführungsform der Erfindung gewinnt der Frei-Ring-Manager 1012 der DMA-Maschine 120 den Deskriptor 1202 aus dem Ring wieder und speichert den Pufferidentifizierer 1206 im Datenfeld 1210 freier Puffer. Außerdem übergibt der Frei-Ring-Manager den Pufferidentifizierer bei Bedarf an die Flusswiederzusammensetzungstabelle 1004, an die Kopftabelle 1006, an die MTU-Tabelle 1008 oder an die Jumbo-Tabelle 1010. In einer weiteren Ausführungsform extrahiert der Frei-Ring-Manager Deskriptoren aus dem Frei-Deskriptor-Ring und speichert sie in einem Deskriptor-Cache, bis ein Puffer benötigt wird, wobei zu dieser Zeit der Pufferidentifizierer des Puffers in dem Datenfeld freier Puffer gespeichert wird. In einer abermals weiteren Ausführungsform kann ein Deskriptor verwendet werden (kann z. B. der Puffer, auf den er Bezug nimmt, zum Speichern eines Pakets verwendet werden), während er weiter in dem Cache ist.
  • In einer Ausführungsform der Erfindung hat der Deskriptor 1202 eine Länge von sechzehn Bytes. In dieser Ausführungsform hat der Ringindex 1204 eine Größe von dreizehn Bits, ist der Pufferidentifizierer 1206 (und das Pufferidentifiziererfeld 12140 im Datenfeld 1210 freier Puffer) vierundsechzig Bits und kann der verbleibende Platz weitere Informationen speichern oder nicht verwendet werden. Die Größe des Datenfeld-Indexfelds 1212 hängt von den Abmessungen des Datenfelds 1210 ab; in einer Ausführungsform hat das Feld eine Größe von dreizehn Bits.
  • Außerdem wird im Host-Speicher ein Abschluss-Deskriptor-Ring 1220 aufrechterhalten. Die Deskriptoren im Abschluss-Ring 1220 werden geschrieben oder konfiguriert, wenn durch die DMA-Maschine 120 ein Paket an den Host-Computer übertragen wird. Die in einen Deskriptor wie etwa in den Deskriptor 1222 geschriebenen Informationen werden von Software, die in dem Host-Computer arbeitet, (z. B. von einem der NIC 100 zugeordneter Gerätetreiber) verwendet, um das Paket zu verarbeiten. Beispielhaft zeigt ein (im Folgenden beschriebener) Besitzanzeiger in dem Deskriptor an, ob die DMA-Maschine 120 unter Verwendung des Deskriptors abgeschlossen hat. Zum Beispiel kann dieses Feld auf einen besonderen Wert (z. B. null) gesetzt werden, wenn die DMA-Maschine unter Verwendung des Deskriptors abschließt, und auf einen anderen Wert (z. B. eins) gesetzt werden, wenn er zur Verwendung durch die DMA-Maschine verfügbar ist. Allerdings gibt die DMA-Maschine 120 in einer weiteren Ausführungsform der Erfindung eine Unterbrechung an den Host-Computer aus, wenn sie einen Abschluss-Deskriptor freigibt. In einer alternativen Ausführungsform kann eine nochmals weitere Einrichtung zum Warnen des Host-Computers verwendet werden. In einer Ausführungsform der Erfindung hat der Deskriptor 1222 eine Länge von zweiunddreißig Bytes.
  • In der veranschaulichten Ausführungsform der Erfindung betreffen die im Deskriptor 1222 gespeicherten Informationen ein übertragenes Paket und/oder den Puffer, in dem es gespeichert war, wobei sie die folgenden Felder enthalten. Eine Datengröße 1230 berichtet die Datenmenge in dem Paket (z. B. in Bytes). Das Datengrößefeld kann eine Null enthalten, falls es in dem Paket keinen Datenabschnitt gibt oder kein Datenpuffer verwendet wurde (z. B. Flusswiederzusammensetzungspuffer, Nichtwiederzusammensetzungspuffer, Jumbo-Puffer, MTU-Puffer). Der Datenpufferindex 1232 ist in dem Datenfeld 1210 freier Puffer der Index des Pufferidentifizierers für den Flusswiederzusammensetzungspuffer, für den Nichtwiederzusammensetzungspuffer, für den Jumbo-Puffer oder für den MTU-Puffer, in dem die Daten des Pakets gespeichert wurden. Wenn der Deskriptor einem kleinen Paket entspricht, das vollständig in einem Kopfpuffer gespeichert worden ist, kann dieses Feld eine Null speichern oder ungenutzt bleiben. Der Datenversatz 1234 ist der Versatz der Daten des Pakets in dem Flusswiederzusammensetzungspuffer, in dem Nichtwiederzusammensetzungspuffer, in dem Jumbo-Puffer oder in dem MTU-Puffer (z. B. der Platz des ersten Datenbytes in dem Datenpuffer).
  • In 12B enthält ein Merkerfeld 1236 einen oder mehrere Merker, die einen Puffer oder ein Paket betreffen. Zum Beispiel wird ein Kopffreigabemerker bzw. ein Datenfreigabemerker gesetzt, falls ein Kopfpuffer oder Daten freigegeben werden (da z. B. er voll ist bzw. sie voll sind). Ein Flussfreigabemerker kann verwendet werden, um anzuzeigen, ob ein Fluss wenigstens vorübergehend geendet hat. Mit anderen Worten, falls ein Flussfreigabemerker gesetzt ist (z. B. einen Wert eins speichert) zeigt dies an, dass in der Paketwarteschlange keine weiteren Pakete warten, die in dem gleichen Fluss wie das dem Deskriptor 1222 zugeordnete Paket sind. Falls dieser Merker andernfalls nicht gesetzt ist (z. B. einen Wert null speichert), kann Software, die in dem Host-Computer arbeitet, dieses Paket in die Warteschlange einreihen, so dass es auf eines oder mehrere zusätzliche Flusspakete wartet, so dass sie kollektiv verarbeitet werden können. In das Merkerfeld 1236 kann ein Getrennt-Merker aufgenommen werden, der identifiziert, ob sich der Inhalt eines Pakets (z. B. Daten) über mehrere Puffer erstreckt. Beispielhaft gibt es einen Eintrag in dem unten beschriebenen Index 1240 des Puffers der nächsten Daten, falls der Getrennt-Merker gesetzt ist.
  • In der derzeit beschriebenen Ausführungsform der Erfindung kann der Deskrip tortyp 1238 einen von drei Werten annehmen. Ein erster Wert (z. B. eins) zeigt an, dass die DMA-Maschine 120 einen Flusspuffer für einen Fluss freigibt, der verbraucht ist (z. B. ist in dem Fluss für eine gewisse Zeitdauer kein Paket empfangen worden). Ein zweiter Wert (z. B. zwei) kann anzeigen, dass in einem Puffer ein nicht wieder zusammensetzbares Paket gespeichert war. Ein dritter Wert (z. B. drei) kann verwendet werden, um anzuzeigen, dass in einem Puffer ein Flusspaket (z. B. ein Paket, das Teil eines Flusses durch die NIC 100 ist) gespeichert war.
  • Der Index 1240 des nächsten Puffers speichert im Datenfeld 1210 freier Puffer einen Index eines Eintrags, der einen Pufferidentifizierer enthält, der einem Puffer entspricht, der einen nachfolgenden Abschnitt eines Pakets speichert, falls das gesamte Paket oder seine Daten nicht in den ersten zugewiesenen Puffer eingepasst werden konnten. Es kann angenommen werden, dass der Versatz in dem nächsten Puffer null ist. Die Kopfgröße 1242 berichtet die Länge des Kopfs (z. B. in Bytes). Die Kopfgröße kann auf null gesetzt werden, falls der Kopfpuffer für dieses Paket nicht verwendet wurde (z. B., falls das Paket nicht wieder zusammengesetzt wird und kein kleines Paket ist). Der Kopfpufferindex 1244 ist im Datenfeld 1210 freier Puffer der Index des Pufferidentifizierers für den Kopfpuffer, der zum Speichern des Kopfs dieses Pakets verwendet wird. Der Kopfversatz 1246 ist der Versatz des Kopfs des Pakets in dem Puffer (z. B. Kopfpuffer), in dem der Kopf gespeichert wurde. Der Kopfversatz kann die Form einer Anzahl der Bytes in dem Puffer annehmen, in dem der Kopf ermittelt werden kann. Alternativ kann der Versatz ein Indexwert sein, der die Indexstellung des Kopfs berichtet. Zum Beispiel werden die Einträge in einem Kopfpuffer in einer oben erwähnten Ausführungsform der Erfindung in 256-Byte-Einheiten gespeichert. Somit beginnt jeder Eintrag unabhängig von der tatsächlichen Größe der Einträge bei einer 256-Byte-Grenze. Die 256-Byte-Einträge können innerhalb des Puffers nummeriert oder indiziert werden.
  • In der veranschaulichten Ausführungsform ist die Flussnummer 1250 die Flussnummer des Pakets (z. B. der Index in der Flussdatenbank 110 des Flussschlüssels des Pakets). Die Flussnummer 1250 kann zum Identifizieren von Paketen in dem gleichen Fluss verwendet werden. Der Operationscode 1252 ist ein Code, der durch den Flussdatenbankmanager 108 erzeugt und durch die DMA-Maschine 120 zum Verarbeiten des Pakets und zu dessen Übertragen in einen geeigneten Puffer verwendet wird. Das ebenfalls in einem früheren Abschnitt beschriebene No_Assist-Signal 1254 kann gesetzt oder angehoben werden, wenn das Paket nicht mit den im Voraus für die NIC 100 gewählten Protokollen kompatibel ist. Ein Ergebnis der Inkompatibilität ist, dass der Kopfanalysealgorithmus 106 das Paket nicht umfassend syntaktisch analysieren kann, wobei das Paket in diesem Fall nicht die nachfolgenden Nutzen empfängt. Der Prozessoridentifizierer 1256, der durch den Lastverteiler 112 erzeugt werden kann, identifiziert einen Prozessor des Host-Computersystems für die Verarbeitung des Pakets. Wie in einem früheren Abschnitt beschrieben wurde, versucht der Lastverteiler 112, die Last der Verarbeitung der Netzpakete auf mehrere Prozessoren zu teilen oder zu verteilen, indem er alle Pakete in einem Fluss durch den gleichen Prozessor verarbeiten lässt. Der Schicht-Drei-Kopfversatz 1258 berichtet einen Versatz in dem Paket des ersten Bytes des Schicht-Drei-Protokollkopfs (z. B. IP-Kopfs) des Pakets. Mit diesem Wert kann die in dem Host-Computer arbeitende Software leicht einen oder mehrere Köpfe oder Kopfabschnitte entfernen.
  • Der Prüfsummenwert 1260 ist eine Prüfsumme, die für dieses Paket durch den Prüfsummengenerator 114 berechnet wird. Die Paketlänge 1262 ist die Länge (z. B. in Bytes) des gesamten Pakets.
  • In der derzeit beschriebenen Ausführungsform der Erfindung wird der Besitzanzeiger 1264 verwendet, um anzuzeigen, ob die NIC 100 oder die Software, die in dem Host-Computer arbeitet, den Abschluss-Deskriptor 1222 "besitzt". Insbesondere wird in dem Besitzanzeigerfeld ein erster Wert (z. B. null) angeordnet, wenn die NIC 100 (z. B. die DMA-Maschine 120) das Konfigurieren des Deskriptors abgeschlossen hat. Beispielhaft zeigt dieser erste Wert selbstverständlich an, dass die Software den Deskriptor nun verarbeiten kann. Wenn die Software die Verarbeitung des Deskriptors abgeschlossen hat, kann sie in dem Besitzanzeiger einen zweiten Wert (z. B. eins) speichern, der anzeigt, dass die NIC 100 den Deskriptor nun für ein weiteres Paket verwenden kann.
  • Es gibt zahlreiche Verfahren, die verwendet werden können, um die Host-Software zu informieren, dass ein Deskriptor durch die DMA-Maschine 120 verwendet oder an sie zurückgegeben wurde. Zum Beispiel werden in einer Ausführungsform der Erfindung eines oder mehrere Register, Zeiger oder andere Datenstrukturen aufrechterhalten, um anzuzeigen, welche Abschluss-Deskriptoren in einem Abschluss-Deskriptor-Ring verwendet worden sind oder nicht verwendet worden sind. Insbesondere kann ein Kopfregister verwendet werden, um einen ersten einer Reihe von Deskriptoren zu identifizieren, die die Host-Software besitzt, während ein Endregister den letzten Deskriptor in der Reihe identifiziert. Die DMA-Maschine 120 kann diese Register aktualisieren, während sie Deskriptoren konfiguriert und freigibt. Somit können die Host-Software und die DMA-Maschine dadurch, dass sie diese Register untersuchen, bestimmen, wie viele Deskriptoren verwendet worden sind oder nicht verwendet worden sind.
  • Schließlich können in dem Weiteres-Feld 1266 weitere Informationen, Merker und Anzeiger gespeichert werden. Die weiteren Informationen, die in einer Ausführungsform der Erfindung gespeichert werden können, enthalten die Länge und/oder den Versatz von TCP-Nutzinformationen, einen Merker, der ein kleines Paket (z. B. kleiner als 257 Bytes) oder ein Jumbo-Paket (z. B. mehr als 1522 Bytes) anzeigt, einen Merker, der ein unbrauchbares Paket (z. B. CRC-Fehler) anzeigt, eine Prüfsummenstartstelle usw.
  • In alternativen Ausführungsformen der Erfindung sind im Deskriptor 1222 nur Informationen und Merker enthalten, die der Host-Computer (z. B. die Treibersoftware) benötigt. Somit können in einer alternativen Ausführungsform eines oder mehrere Felder mit Ausnahme der Folgenden weggelassen sein: Datengröße 1230, Datenpufferindex 1232, Datenversatz 1234, ein Getrennt-Merker, der Index 1240 des Puffers der nächsten Daten, die Kopfgröße 1242, der Kopfpufferindex 1244, der Kopfversatz 1246 und der Besitzanzeiger 1264.
  • Außerdem kann ein Abschluss-Deskriptor praktisch in irgendeiner Form organisiert sein; die Reihenfolge der Felder des Deskriptors 1222 in 12 ist nur eine mögliche Konfiguration. Allerdings ist es vorteilhaft, den Besitzanzeiger 1264 gegen das Ende eines Abschluss-Deskriptors anzuordnen, da der Anzeiger dazu verwendet werden kann, die Host-Software zu informieren, wenn die DMA-Maschine das Bevölkern des Deskriptors abgeschlossen hat. Falls der Besitzanzeiger zu Beginn des Deskriptors angeordnet würde, kann ihn die Software lesen und versuchen, den Deskriptor zu verwenden, bevor die DMA-Maschine das Schreiben in ihn abgeschlossen hat.
  • Zum Identifizieren von Speicherbereichen, in denen Pakete anzuordnen sind, die von einem Netz zu einem Host-Computer übertragen werden, können andere als die in diesem Abschnitt beschriebenen Systeme und Verfahren implementiert werden, ohne den Umfang der Erfindung zu überschreiten.
  • Eine Ausführung eines Paketstapel-Moduls
  • 13 ist ein Diagramm eines dynamischen Paketstapel-Moduls 122 in einer Ausführungsform der Erfindung. In dieser Ausführungsform warnt das Paketstapel-Modul 122 einen Host-Computer über die Übertragung oder bevorstehende Übertragung mehrerer Pakete aus einem Kommunikationsfluss. Die verwandten Pakete können dann eher durch einen geeigneten Protokollstapel kollektiv als immer nur eins verarbeitet werden. Dies erhöht vorteilhaft die Effizienz, mit der der Netzverkehr durch den Host-Computer behandelt werden kann.
  • In der veranschaulichten Ausführungsform wird ein Paket durch die DMA-Maschine 120 (z. B. durch Kopieren seiner Nutzinformationen in einen geeigneten Puffer) von der NIC 100 an den Host-Computer übertragen. Wenn ein Paket übertragen wird, bestimmt das Paketstapel-Modul 122, ob bald ein verwandtes Paket (z. B. ein Paket in dem gleichen Fluss) ebenfalls übertragen wird. Insbesondere untersucht das Paketstapel-Modul 122 Pakete, die nach dem vorliegenden Paket übertragen werden sollen. Je höher die Rate der Paketankunft an der NIC 100 ist, desto mehr Pakete warten zu einer gegebenen Zeit wahrscheinlich auf die Übertragung zu einem Host-Computer. Je mehr Pakete auf die Übertragung warten, desto mehr Pakete können durch das dynamische Paketstapel-Modul untersucht werden und desto größeren Nutzen kann es liefern. Insbesondere, während die Anzahl der auf die Übertragung wartenden Pakete zunimmt, kann das Paketstapel-Modul 122 eine größere Anzahl verwandter Pakete zur kollektiven Verarbeitung identifizieren. Während die Anzahl der kollektiv verarbeiteten Pakete zunimmt, nimmt die Dauer der Host-Prozessorzeit, die zum Verarbeiten jenes Pakets erforderlich ist, ab.
  • Somit warnt das Paketstapel-Modul den Host-Computer, falls ein verwandtes Paket ermittelt wird, so dass die Pakete als eine Gruppe verarbeitet werden können. In einer Ausführungsform der Erfindung warnt das dynamische Paketstapel-Modul 122 den Host-Computer über die Verfügbarkeit eines verwandten Pakets, indem es einen Flussfreigabemerker in einem Abschluss-Deskriptor löscht, der einem übertragenen Paket zugeordnet ist. Der Merker kann z. B. durch die DMA-Maschine 120 in Reaktion auf ein Signal oder eine Warnung vom dynamischen Paketstapel-Modul 122 gelöscht werden.
  • Im Gegensatz dazu kann das dynamische Paketstapel-Modul 122 oder die DMA- Maschine 120 den Host-Computer in einer alternativen Ausführungsform der Erfindung warnen, wenn keine verwandten Pakete ermittelt werden oder wenn der Host-Prozessor aus einem anderen Grund die Verarbeitung eines übertragenen Pakets nicht verzögern sollte. Insbesondere kann ein Flussfreigabemerker gesetzt werden, wenn nicht erwartet wird, dass der Host-Computer ein mit einem in nächster Zukunft übertragenen Paket verwandtes Paket empfängt (was somit z. B. anzeigt, dass der zugeordnete Fluss freigegeben oder abgebaut wird). Zum Beispiel kann bestimmt werden, dass das übertragene Paket das letzte Paket in seinem Fluss ist oder dass ein besonderes Paket nicht einmal zu einem Fluss gehört (was sich z. B. im zugeordneten Operationscode des Pakets widerspiegeln kann).
  • Nunmehr anhand von 13 enthält das Paketstapel-Modul 122 in einer Ausführungsform der Erfindung einen Speicher 1302 und einen Controller 1304. Beispielhaft enthält jeder Eintrag im Speicher 1302 wie etwa der Eintrag 1306 zwei Felder: die Flussnummer 1308 und den Gültigkeitsanzeiger 1310. In alternativen Ausführungsformen der Erfindung können andere Informationen im Speicher 1302 gespeichert werden. Ein Lesezeiger 1312 und ein Schreibzeiger 1314 dienen als Indizes in den Speicher 1302.
  • In der veranschaulichten Ausführungsform ist der Speicher 1302 ein Assoziativspeicher (z. B. ein CAM) der zum Speichern von bis zu 256 Einträgen konfiguriert ist. Jeder Eintrag entspricht einem in der Paketwarteschlange 116 gespeicherten Paket und stellt ein solches dar. Wie in einem früheren Abschnitt beschrieben wurde, kann die Paketwarteschlange 116 in einer Ausführungsform der Erfindung ebenfalls bis zu 256 Pakete enthalten. Wenn ein Paket durch die DMA-Maschine 120 von der Paketwarteschlange 116 an den Host-Computer übertragen wird oder im Begriff ist, übertragen zu werden, kann der Speicher 1302 nach einem Eintrag mit einer Flussnummer durchsucht werden, die mit der Flussnummer des übertragenen Pakets übereinstimmt. Da der Speicher 1302 in dieser Ausführungsform ein CAM ist, können alle Einträge in dem Speicher gleichzeitig oder nahezu gleichzeitig durchsucht werden. In dieser Ausführungsform ist der Speicher 1302 in Hardware implementiert, wobei die Einträge logisch als ein Ring angeordnet sind. In alternativen Ausführungsformen kann der Speicher 1302 praktisch irgendein Datenstrukturtyp (z. B. Datenfeld, Tabelle, Liste, Warteschlange) sein, der in Hardware oder Software implementiert ist. In einer besonderen alternativen Ausführungsform ist der Speicher 1302 als ein RAM implementiert, wobei die Einträge in diesem Fall auf serielle Weise untersucht werden können.
  • In der veranschaulichten Ausführungsform stimmt das Maximum von 256 Einträgen mit der maximalen Anzahl von Paketen überein, die in einer Paketwarteschlange gespeichert werden können. Da die Tiefe des Speichers 1302 mit der Tiefe der Paketwarteschlange übereinstimmt, kann die Flussnummer eines Pakets, wenn es in der Paketwarteschlange gespeichert wird, automatisch im Speicher 1302 gespeichert werden. Obgleich in dieser Ausführungsform die gleiche Anzahl von Einträgen bereitgestellt wird, kann der Speicher 1302 in einer alternativen Ausführungsform der Erfindung so konfiguriert sein, dass er eine kleinere oder größere Anzahl von Einträgen als die Paketwarteschlange hält. Wie zudem in einem früheren Abschnitt diskutiert wurde, können außerdem für jedes in der Paketwarteschlange gespeicherte Paketverwandte Informationen in der Steuerwarteschlange gespeichert werden.
  • In der veranschaulichten Ausführungsform der Erfindung ist die Flussnummer 1308 der Index in die Flussdatenbank 110 des Flusses, der das entsprechende Paket enthält. Wie oben beschrieben wurde, enthält ein Fluss in einer Ausführungsform der Erfindung Pakete, die Daten von einem von einer Quell-Entität zu einer Ziel-Entität gesendeten Datagramm übermitteln. Beispielhaft besitzt jedes verwandte Paket den gleichen Flussschlüssel und die gleiche Flussnummer. Die Flussnummer 1308 kann den Index des Flussschlüssels des Pakets in der Flussdatenbank 110 enthalten.
  • Der Gültigkeitsanzeiger 1310 zeigt an, ob die in dem Eintrag gespeicherten Informationen gültig oder aktuell sind. In dieser Ausführungsform kann der Gültigkeitsanzeiger 1310 einen ersten Wert (z. B. eins) speichern, wenn der Eintrag gültige Daten enthält, und einen zweiten Wert (z. B. null) speichern, wenn die Daten ungültig sind. Zum Beispiel kann der Gültigkeitsanzeiger 1310 im Eintrag 1306 auf einen gültigen Zustand gesetzt werden, wenn der entsprechende Eintrag in der Paketwarteschlange 116 ein Paket enthält, das auf die Übertragung zu dem Host-Computer wartet und zu einem Fluss gehört (was z. B. durch den Operationscode des Pakets angezeigt werden kann). Ähnlich kann der Gültigkeitsanzeiger 1310 auf einen ungültigen Zustand gesetzt werden, wenn der Eintrag nicht mehr benötigt wird (wenn das entsprechende Paket z. B. zu dem Host-Computer übertragen wird).
  • Außerdem kann der Flussgültigkeitsanzeiger 1310 auf einen ungültigen Zustand gesetzt werden, wenn der Operationscode eines entsprechenden Pakets anzeigt, dass das Paket nicht zu einem Fluss gehört. Außerdem kann er auf einen ungültigen Zustand gesetzt werden, wenn das entsprechende Paket ein Steuerpaket ist (z. B. keine Daten enthält) oder auf andere Weise nicht zusammensetzbar ist (da es z. B. außer der Reihe ist, mit einem im Voraus gewählten Protokoll inkompatibel ist, einen nicht erwarteten Steuermerker gesetzt hat). Der Gültigkeitsanzeiger 1310 kann während des Betriebs des Paketstapel-Moduls durch den Controller 1304 administriert werden.
  • In der veranschaulichten Ausführungsform der Erfindung wird die Flussnummer eines Eintrags aus einem Register empfangen, in dem sie zur vorübergehenden Speicherung angeordnet war. Die Flussnummer eines Pakets kann vorübergehend in einem Register oder in einer anderen Datenstruktur gespeichert werden, um ihre rechtzeitige Lieferung an das Paketstapel-Modul 122 zu erleichtern. Außerdem ermöglicht die vorübergehende Speicherung der Flussnummer, dass der Flussdatenbankmanager seine Aufmerksamkeit einem späteren Paket zuwendet. Eine Flussnummer kann z. B. nahezu zur gleichen Zeit an das dynamische Paketstapel-Modul 122 geliefert werden, zu der das zugeordnete Paket in der Paketwarteschlange 116 gespeichert wird. Beispielhaft kann die Flussnummer durch den Flussdatenbankmanager 108 oder durch das IPP-Modul 104 in dem Register gespeichert werden. In einer alternativen Ausführungsform wird die Flussnummer von der Steuerwarteschlange 118 oder von einem anderen Modul der NIC 100 empfangen.
  • In der veranschaulichten Ausführungsform der Erfindung enthält der Speicher 1302 entsprechend jedem Paket in der Paketwarteschlange 116 einen Eintrag. Wenn ein Paket in der Paketwarteschlange an einen Host-Computer übertragen wird (wenn es z. B. in einen Wiederzusammensetzungspuffer geschrieben wird), annulliert der Controller 1304 den Speichereintrag, der diesem Paket entspricht. Daraufhin wird der Speicher 1302 nach einem weiteren Eintrag durchsucht, der die gleiche Flussnummer wie das übertragene Paket hat. Wenn danach, eventuell anstelle des übertragenen Pakets, ein neues Paket in der Paketwarteschlange 116 gespeichert wird, wird ein neuer Eintrag im Speicher 1302 gespeichert.
  • In einer alternativen Ausführungsform der Erfindung kann der Speicher 1302 so konfiguriert sein, dass er nur Einträge für eine Teilmenge der maximalen Anzahl der in der Paketwarteschlange 116 gespeicherten Pakete (z. B. gerade für die wieder zusammensetzbaren Pakete) hält. Die Einträge im Speicher 1302 können weiter bevölkert werden, wenn ein Paket in der Paketwarteschlange gespeichert wird. Wenn der Speicher 1302 dagegen voll ist, wenn ein neues Paket empfangen wird, muss die Erzeugung eines Eintrags für das neue Paket warten, bis ein Paket übertragen worden ist und sein Eintrag im Speicher 1302 annulliert worden ist. Somit können die Einträge im Speicher 1302 in dieser alternativen Ausführungsform dadurch erzeugt werden, dass eher Informationen aus den Einträgen in der Steuerwarteschlange 118 als solche in der Paketwarteschlange 116 extrahiert werden. Der Controller 1304 würde somit ununterbrochen versuchen, Informationen aus den Einträgen in der Steuerwarteschlange 118 in den Speicher 1302 zu kopieren. Die Funktion des Bevölkerns des Speichers 1302 kann unabhängig oder halb unabhängig von der Funktion des tatsächlichen Vergleichens der Flussnummern der Speichereinträge mit der Flussnummer eines Pakets, das zum Host-Computer übertragen wird, ausgeführt werden.
  • In dieser alternativen Ausführungsform kann ein zweiter Lesezeiger verwendet werden, um die Steuerwarteschlange 118 zu indizieren, um bei der Bevölkerung des Speichers 1302 zu helfen. Insbesondere kann der zweite Lesezeiger durch das Paketstapel-Modul 122 verwendet werden, um Einträge für den Speicher 1302 zu ermitteln und zu holen. Beispielhaft könnte bestimmt werden, dass seit der letzten Prüfung durch den Controller 1304 keine neuen Einträge zur Steuerwarteschlange 118 hinzugefügt wurden, falls der zweite Lesezeiger oder "Vorgriffs"-Lesezeiger auf den gleichen Eintrag wie der Schreibzeiger der Steuerwarteschlange Bezug nimmt. Andernfalls können die notwendigen Informationen (z. B. die Flussnummer) in den Speicher 1302 für das Paket kopiert werden, das dem Eintrag entspricht, auf den der Vorgriff-Lesezeiger Bezug nimmt, solange es einen leeren (z. B. ungültigen) Eintrag im Speicher 1302 gibt. Daraufhin würde der Vorgriff-Lesezeiger inkrementiert.
  • Nunmehr wieder in 13 identifiziert der Lesezeiger 1312 des dynamischen Paketstapel-Moduls 122 den momentanen Eintrag im Speicher 1302 (z. B. den Eintrag, der dem Paket vorn in der Paketwarteschlange oder dem nächsten zu übertragenden Paket entspricht). Beispielhaft wird dieser Zeiger jedes Mal inkrementiert, wenn ein Paket an den Host-Computer übertragen wird. Der Schreibzeiger 1314 identifiziert die Stelle, an der der nächste Eintrag im Speicher 1302 gespeichert werden soll. Beispielhaft wird der Schreibzeiger jedes Mal inkremen tiert, wenn ein Eintrag zum Speicher 1302 hinzugefügt wird. Eine Art der kollektiven Verarbeitung von Köpfen von verwandten Paketen ist es, aus diesen einen "Super"-Kopf zu bilden. In diesem Verfahren werden die Datenabschnitte der Pakete getrennt (z. B. in einer getrennten Speicherseite oder in einem getrennten Puffer) von dem Super-Kopf gespeichert.
  • Beispielhaft enthält ein Super-Kopf für jede Schicht des zugeordneten Protokollstapels der Pakete (z. B. für einen TCP-Kopf und für einen IP-Kopf) einen kombinierten Kopf. Um den Abschnitt eines Superkopfs jeder Schicht zu bilden, können die einzelnen Köpfe des Pakets zusammengeführt werden, um einen Kopf regulärer Größe zu bilden, dessen Felder genau die zusammengesetzten Daten und kombinierten Köpfe widerspiegeln. Zum Beispiel würden die zusammengeführten Kopffelder, die sich auf Nutzinformationen oder auf die Kopflänge beziehen, die Größe der aggregierten Daten oder aggregierten Köpfe anzeigen, wäre die Folgenummer eines zusammengeführten TCP-Kopfs geeignet gesetzt usw. Daraufhin kann der Superkopfabschnitt auf ähnliche Weise durch seinen Protokollstapel verarbeitet werden wie der Kopf eines einzelnen Pakets verarbeitet wird.
  • Dieses Verfahren der kollektiven Verarbeitung der Köpfe verwandter Pakete (z. B. mit "Super"-Köpfen) kann eine Modifikation der Befehle zum Verarbeiten von Paketen (z. B. eines Gerätetreibers) erfordern. Zum Beispiel kann die Software eine Modifikation zum Erkennen und Behandeln der Superköpfe erfordern, da für jede Schicht des Protokollstapels mehrere Köpfe zusammengeführt sind. In einer Ausführungsform der Erfindung kann die Anzahl der Köpfe, die zu einem Superkopf zusammengelegt oder zusammengeführt werden, begrenzt sein. In einer alternativen Ausführungsform der Erfindung können die Köpfe aller aggregierten Pakete unabhängig von der Anzahl kombiniert werden.
  • In einem weiteren Verfahren der kollektiven Verarbeitung können die Kopfabschnitte, die Paketdaten und die Köpfe verwandter Pakete wieder getrennt (z. B. in getrennten Speicherseiten) gespeichert werden. Anstatt die Köpfe der Pakete für jede Schicht des geeigneten Protokollstapels zu kombinieren, um einen Superkopf zu bilden, können sie aber in rascher Folge zur Einzelverarbeitung eingereicht werden. Zum Beispiel können alle Schicht-Zwei-Köpfe der Pakete durch Köpfe der Pakete in rascher Folge – nacheinander –, anschließend alle Schicht-Drei-Köpfe usw. verarbeitet werden. Auf diese Weise brauchen die Paketverarbeitungsbefehle nicht modifiziert zu werden, während die Köpfe dennoch effizienter verar beitet werden. Insbesondere kann eher ein Befehlssatz (z. B. für jede Protokollschicht) für alle verwandten Pakete einmal geladen werden, anstatt ihn für jedes Paket getrennt zu laden und auszuführen.
  • Beispielhaft können die Datenabschnitte verwandter Pakete zur effizienten Übertragung aus dem Kernel-Raum des Host-Computers in den Anwendungs- oder Anwenderraum in Speicherbereiche vorgegebener Größe (z. B. Speicherseiten) übertragen werden. Wo die übertragenen Daten die Größe einer Speicherseite haben, können die Daten unter Verwendung des hocheffizienten "Seitenwechsels" übertragen werden, bei dem eine vollständige Datenseite an den Anwendungs- oder Anwenderspeicherraum geliefert wird.
  • Die 14A–14B zeigen ein Verfahren der dynamischen Paketstapelung mit dem Paketstapel-Modul 122. In dem veranschaulichten Verfahren wird der Speicher 1302 mit Flussnummern von in der Paketwarteschlange 116 gespeicherten Paketen bevölkert. Insbesondere werden aus der Paketwarteschlange 118, aus dem IPP-Modul 104, aus dem Flussdatenbankmanager 108 oder aus einem bzw. mehreren anderen Modulen der NIC 100 die Flussnummer und der Operationscode eines Pakets wiedergewonnen. Die Flussnummer des Pakets wird in dem Flussnummerabschnitt eines Eintrags im Speicher 1302 gespeichert und der Gültigkeitsanzeiger 1310 in Übereinstimmung mit dem Operationscode gesetzt. Zum Beispiel kann der Gültigkeitsanzeiger auf null gesetzt werden, falls das Paket nicht wieder zusammensetzbar ist (z. B. die Codes 2 und 5 in TABELLE 1); während er andernfalls auf eins gesetzt werden kann.
  • Das veranschaulichte Verfahren kann parallel zum Betrieb der DMA-Maschine 120 arbeiten. Mit anderen Worten, das dynamische Paketstapel-Modul 122 kann nach Paketen suchen, die mit einem Paket verwandet sind, das in dem Prozess ist, zu einem Host-Speicherpuffer übertragen zu werden. Alternativ kann eine Suche durchgeführt werden, kurz nachdem oder bevor das Paket übertragen wird. Da der Speicher 1302 dem Wesen nach assoziativ sein kann, kann die Suchoperation schnell durchgeführt werden, was somit, falls überhaupt, wenig Verzögerung in den Übertragungsprozess einführt.
  • 14A kann als ein Verfahren zum Suchen nach einem verwandten Paket betrachtet werden, während 14B als ein Verfahren zum Bevölkern des Speichers des dynamischen Paketstapel-Moduls betrachtet werden kann.
  • Die 14A–14B widerspiegeln jeweils einen "Zyklus" einer dynamischen Paketstapeloperation (z. B. einer Suche und Erzeugung eines neuen Speichereintrags). Beispielhaft wird die Operation des Paketstapel-Moduls 122 aber ununterbrochen ausgeführt. Das heißt, am Ende eines Operationszyklus beginnt sofort ein weiterer Zyklus. Auf diese Weise bemüht sich der Controller 1304 sicherzustellen, dass der Speicher 1302 mit Einträgen für Pakete bevölkert wird, während sie in der Paketwarteschlange 116 gespeichert werden. Falls der Speicher 1302 nicht groß genug ist, um für jedes Paket in der Warteschlange 116 einen Eintrag zu speichern, versucht der Controller 1304, den Speicher so voll wie möglich zu halten und einen annullierten Eintrag schnell durch einen neuen zu ersetzen.
  • Der Zustand 1400 ist ein Startzyklus für einen Speichersuchzyklus. Im Zustand 1402 wird bestimmt, ob ein Paket (z. B. das Paket vorn in der Paketwarteschlange) an den Host-Computer übertragen wird. Diese Bestimmung kann z. B. auf dem Betrieb der DMA-Maschine 120 oder auf dem Status eines Zeigers in der Paketwarteschlange 116 oder in der Steuerwarteschlange 118 beruhen. Beispielhaft wird der Zustand 1402 durch die DMA-Maschine 120 begonnen, während ein Paket in einen Puffer in dem Host-Computer kopiert wird. Ein Zweck des Zustands 1402 ist es einfach zu bestimmen, ob der Speicher 1302 nach einem Paket durchsucht werden sollte, das mit einem verwandt ist, das übertragen wurde, übertragen werden wird oder gerade übertragen wird. Bis ein Paket übertragen wird oder im Begriff ist, übertragen zu werden, wird die veranschaulichte Prozedur im Zustand 1402 fortgesetzt.
  • Wenn es dagegen Zeit ist, eine Suche durchzuführen (wenn z. B. gerade ein Paket übertragen wird), wird das Verfahren im Zustand 1404 fortgesetzt. Im Zustand 1404 entspricht der Eintrag im Speicher 1302 dem Annullieren des Pakets, das gerade übertragen wird. Beispielhaft besteht dies im Speichern eines vorgegebenen Werts (z. B. null) im Gültigkeitsanzeiger 1310 für den Eintrag des Pakets. In einer vorliegenden Ausführungsform der Erfindung identifiziert der Lesezeiger 1312 den Eintrag, der dem zu übertragenden Paket entspricht. Ein Grund dafür, dass der Eintrag eines übertragenen Pakets annulliert wird, ist der, dass der eigene Eintrag des übertragenen Pakets nicht identifiziert wird, wenn der Speicher 1302 nach einem Eintrag durchsucht wird, der einem mit dem übertragenen Paket verwandten Paket zugeordnet ist.
  • In einer Ausführungsform der Erfindung wird die Flussnummer des übertragenen Pakets in ein Register (z. B. in ein Hardwareregister) kopiert, wenn das dynamische Paketstapel-Modul 122 nach einem verwandten Paket suchen soll. Dies kann besonders hilfreich sein (z. B. als Hilfe beim Vergleich der Flussnummer mit den Flussnummern anderer Pakete), falls der Speicher 1302 als ein RAM anstatt als ein CAM implementiert ist.
  • Im Zustand 1406 wird der Lesezeiger 1312 inkrementiert, so dass er auf den nächsten Eintrag im Speicher 1302 zeigt. Falls der Lesezeiger auf den gleichen Eintrag inkrementiert wird, auf den der Schreibzeiger 1314 Bezug nimmt, und falls dieser Eintrag ebenfalls annulliert wird (was durch den Gültigkeitsanzeiger 1310 angezeigt wird), kann bestimmt werden, dass der Speicher 1302 jetzt leer ist.
  • Daraufhin wird der Speicher 1302 im Zustand 1408 nach einem Paket durchsucht, das mit dem gerade übertragenen Paket verwandt ist (wobei der Speicher z. B. nach einem Eintrag mit der gleichen Flussnummer durchsucht wird). Wie oben beschrieben wurde, werden die Einträge im Speicher 1302 in einer Ausführungsform der Erfindung assoziativ durchsucht. Somit kann das Ergebnis der Suchoperation ein einzelnes Signal sein, das anzeigt, ob eine Übereinstimmung gefunden wurde.
  • In der veranschaulichten Ausführungsform der Erfindung werden lediglich gültige Einträge (z. B. jene mit einem Wert eins in ihren Gültigkeitsanzeigern) durchsucht. Wie oben erläutert wurde, kann ein Eintrag als ungültig gekennzeichnet werden (falls sein Gültigkeitsanzeiger z. B. einen Wert null speichert), wenn das zugeordnete Paket als inkompatibel betrachtet wird. Einträge für inkompatible Pakete können ignoriert werden, da ihre Daten nicht ordentlich wieder zusammengesetzt worden sind und ihre Köpfe nicht normal gestapelt sind. In einer alternativen Ausführungsform der Erfindung können alle Einträge durchsucht werden, wobei aber nur dann eine Übereinstimmung berichtet wird, wenn ein übereinstimmender Eintrag gültig ist.
  • Im Zustand 2132 wird der Host-Computer über die Verfügbarkeit oder Nichtverfügbarkeit eines verwandten Pakets gewarnt. In dieser Ausführungsform der Erfindung wird der Host-Computer dadurch gewarnt, dass in einem spezifischen Feld des Abschluss-Deskriptors des übertragenen Pakets ein vorgegebener Wert gespeichert wird. Wenn ein Paket übertragen wird, wird ein Deskriptor in einem Deskriptor-Ring im Host-Speicher mit Informationen, die das Paket betreffen, (z. B. mit einem Identifizierer seines Platzes im Host-Speicher, mit seiner Größe, mit einem Identifizierer eines Prozessors zum Verarbeiten des Kopfs des Pakets) bevölkert. Insbesondere wird ein Flussfreigabemerker oder -anzeiger auf einen ersten Wert (z. B. null) gesetzt, falls ein verwandtes Paket ermittelt wird, und auf einem zweiten Wert gesetzt, falls kein verwandtes Paket ermittelt wird. Beispielhaft gibt die DMA-Maschine 120 die Warnung aus oder speichert sie die erforderlichen Informationen zur Angabe des Vorhandenseins eines verwandten Pakets in Reaktion auf eine Benachrichtigung vom dynamischen Paketstapel-Modul 122. Andere Verfahren zum Benachrichtigen des Host-Computers über das Vorhandensein eines verwandten Pakets (z. B. ein Anzeiger, Merker, Schlüssel) sind ebenfalls geeignet.
  • In 14B ist der Zustand 1420 ein Startzustand für einen Speicherbevölkerungszyklus.
  • Im Zustand 1422 wird bestimmt, ob ein neues Paket bei der Netzschnittstelle empfangen worden ist. Beispielhaft wird für jedes aus dem Netz empfangene Paket ein neuer Eintrag in dem Speicher des Paketstapel-Moduls vorgenommen. Der Empfang eines neuen Pakets kann durch das IPP-Modul 104 signalisiert werden. Zum Beispiel kann der Empfang eines neuen Pakets durch die Speicherung der Flussnummer des Pakets durch das IPP-Modul 104 an einem temporären Platz (z. B. in einem Register) angezeigt werden. Die veranschaulichte Prozedur wartet, bis ein neues Paket empfangen wird. Wenn ein Paket empfangen wird, wird die Prozedur im Zustand 1424 fortgesetzt.
  • Falls der Speicher 1302 im Zustand 1424 so konfiguriert wird, dass er weniger Einträge als die Paketwarteschlange 116 (und möglicherweise als die Steuerwarteschlange 118) speichert, wird der Speicher 1302 untersucht, um zu bestimmen, ob er voll ist.
  • In einer Ausführungsform der Erfindung kann der Speicher 1302 als voll betrachtet werden, falls der Gültigkeitsanzeiger für jeden Eintrag oder für den Eintrag, auf den der Schreibzeiger 1314 Bezug nimmt, gesetzt (z. B. gleich eins) ist. Falls der Speicher voll ist, wartet die veranschaulichte Prozedur, bis der Speicher nicht voll ist. Der Speicher 1302 und andere Datenstrukturen in der NIC 100 können durch Vergleich ihrer Lese- und Schreibzeiger auf Sättigung (z. B. darauf, ob sie gefüllt sind) getestet werden.
  • Im Zustand 1426 wird ein neues Paket dadurch im Speicher 1302 dargestellt, dass seine Flussnummer in dem durch den Schreibzeiger 1314 identifizierten Eintrag gespeichert wird und ein geeigneter Wert im Gültigkeitsanzeigerfeld des Eintrags gespeichert wird. Falls das Paket z. B. (wie z. B. durch seinen Operationscode angezeigt wird) nicht wieder zusammensetzbar ist, kann der Gültigkeitsanzeiger des Eintrags auf einen ungültigen Zustand gesetzt werden. Für den Betrieb des dynamischen Paketstapel-Moduls 122 kann ein TCP-Steuerpaket als wieder zusammensetzbar oder als nicht wieder zusammensetzbar betrachtet werden. Somit kann der Gültigkeitsanzeiger für ein Paket, das ein TCP-Steuerpaket ist, je nach Implementierung einer besonderen Ausführungsform auf einen gültigen oder ungültigen Zustand gesetzt werden.
  • In einer alternativen Ausführungsform der Erfindung wird ein Eintrag im Speicher 1302 mit Informationen aus dem durch den oben beschriebenen zweiten Lesezeiger identifizierten Steuerwarteschlangeneintrag bevölkert. Daraufhin kann dieser Zeiger auf den nächsten Eintrag in der Steuerwarteschlange 118 inkrementiert werden.
  • Im Zustand 1428 wird der Schreibzeiger 1314 auf den nächsten Eintrag des Speichers 1302 inkrementiert, wonach das veranschaulichte Verfahren im Endzustand 1430 endet. Falls der Schreibzeiger 1314 auf den gleichen Eintrag wie der Lesezeiger 1312 Bezug nimmt, kann bestimmt werden, dass der Speicher 1302 voll ist. Es können viele weitere geeignete Verfahren des Managements der Zeiger für den Speicher 1302 verwendet werden.
  • Wie oben erwähnt wurde, werden die Speichersuchoperation und/oder die Speicherbevölkerungsoperationen in einer Ausführungsform der Erfindung ununterbrochen ausgeführt. Somit kann der Endzustand 1430 aus der in 14B veranschaulichten Prozedur entfernt werden, wobei die Prozedur in diesem Fall nach dem Zustand 1428 zum Zustand 1422 zurückkehrt.
  • In der veranschaulichten Ausführungsform der Erfindung nehmen die durch das dynamische Paketstapel-Modul 122 für den Host-Computer geschaffenen Nutzen vorteilhaft zu, während der Host-Computer zunehmend belegt wird. Insbesondere ist die Verzögerung, die zugezogen wird, bis ein von der NIC 100 empfangenes Paket verarbeitet werden kann, umso größer, je größer die Last ist, die einem Host-Prozessor auferlegt wird. Im Ergebnis können Pakete in die Paketwarteschlange 116 eingereiht werden, wobei umso mehr Einträge im Speicher 1302 aufrechterhalten werden können, je mehr Pakete in der Paketwarteschlange sind.
  • Je mehr Einträge im Speicher 1302 gespeichert werden, desto weiter voraus kann das dynamische Paketstapel-Modul für ein verwandtes Paket vorgreifen. Je weiter voraus es abtastet, desto wahrscheinlicher ist es, dass ein verwandtes Paket ermittelt wird. Während mehr verwandte Pakete ermittelt werden und für den Host-Computer zur kollektiven Verarbeitung identifiziert werden, nimmt die Dauer der beim Netzverkehr verbrauchten Prozessorzeit ab und die Gesamtprozessornutzung zu.
  • Ohne den Umfang der vorliegenden Erfindung zu überschreiten, können zum Identifizieren mehrerer Pakete aus einem einzigen Kommunikationsfluss oder aus einer einzigen Kommunikationsverbindung andere Systeme und Verfahren verwendet werden. Ferner liefert die internationale Anmeldung Nr. PCT/US00/05307 (veröffentlicht am 8. September 2000 als Veröffentlichungsnummer WO 00/52904), die der US-Patentanmeldung Ifd. Nr. 09/259.765 mit dem Titel "A High Performance Network Interface" entspricht, zusätzliche Einzelheiten einer Netzschnittstelle, in der eine vorliegende Ausführungsform der Erfindung verwirklicht werden kann, wobei sie hiermit durch Literaturhinweis eingefügt ist.
  • Sun, Sun Microsystems, SPARC und Solaris sind Warenzeichen oder eingetragene Warenzeichen von Sun Microsystems, Incorporated, in den Vereinigten Staaten und in anderen Ländern.
  • Die vorstehenden Beschreibungen von Ausführungsformen der Erfindung wurden lediglich zur Veranschaulichung und Beschreibung gegeben. Sie sollen nicht erschöpfend sein oder die Erfindung auf die offenbarten Formen beschränken. Dementsprechend soll die obige Offenbarung die Erfindung nicht beschränken; wobei der Umfang der Erfindung durch die beigefügten Ansprüche definiert ist.

Claims (25)

  1. Verfahren zum Verarbeiten mehrerer Pakete in einem Kommunikationsfluss, wobei die Pakete zu einer vorgegebenen Menge von Kommunikationsprotokollen konform sind, wobei das Verfahren umfasst: Empfangen (132) eines ersten Pakets bei einer Kommunikationsvorrichtung (100), die mit einem Host-Computer gekoppelt ist; Identifizieren (134) eines ersten Kommunikationsflusses, der das erste Paket enthält; Identifizieren (144) eines zweiten Pakets, das bei der Kommunikationsvorrichtung empfangen wird, wobei der erste Kommunikationsfluss auch das zweite Paket enthält; Übertragen (146) des ersten Pakets an den Host-Computer; Übertragen (146) des zweiten Pakets an den Host-Computer; und kollektives Verarbeiten eines Kopfabschnitts des ersten Pakets und eines Kopfabschnitts des zweiten Pakets bei dem Host-Computer in Übereinstimmung mit einer gemeinsamen Menge von Kommunikationsprotokollen.
  2. Verfahren nach Anspruch 1, das ferner das Empfangen eines ersten Flussidentifizierers, der dem ersten Paket zugeordnet ist, umfasst, wobei der erste Flussidentifizierer so konfiguriert ist, dass er den ersten Kommunikationsfluss identifiziert.
  3. Verfahren nach Anspruch 2, bei dem das Empfangen eines ersten Flussidentifizierers umfasst: Empfangen eines Flussschlüssels, der aus einem Identifizierer einer Quelle des Pakets und aus einem Identifizierer eines Ziels des ersten Pakets erzeugt wird; wobei der erste Flussidentifizierer den Flussschlüssel umfasst.
  4. Verfahren nach Anspruch 2, bei dem das Empfangen eines ersten Flussidentifizierers umfasst: Empfangen eines Indexes des ersten Kommunikationsflusses in einer Fluss-Datenbank, die so konfiguriert ist, dass sie den jeweiligen Status mehrerer Kommunikationsflüsse aufrechterhält; wobei der erste Flussidentifizierer den Index umfasst.
  5. Verfahren nach Anspruch 2, bei dem das Identifizieren eines zweiten Pakets das Vergleichen (1408) des ersten Flussidentifizierers mit einem zweiten Flussidentifizierer, der einem bei der Kommunikationsvorrichtung empfangenen zweiten Paket zugeordnet ist, umfasst.
  6. Verfahren nach Anspruch 5, das ferner umfasst: Speichern (1426) des ersten Flussidentifizierers in einem Flussspeicher (1302); und Speichern (1426) des zweiten Flussidentifizierers in dem Flussspeicher.
  7. Verfahren nach Anspruch 6, bei dem der Flussspeicher ein Assoziativspeicher in der Kommunikationsvorrichtung ist.
  8. Verfahren nach Anspruch 1, das ferner das Speichern (140) des ersten Pakets in einem Paketspeicher (116) umfasst.
  9. Verfahren nach Anspruch 8, bei dem das Identifizieren eines zweiten Pakets das Vergleichen (1408) eines ersten Flussidentifizierers, der so konfiguriert ist, dass er den ersten Kommunikationsfluss identifiziert, mit einem zweiten Flussidentifizierer, der so konfiguriert ist, dass er einen zweiten Kommunikationsfluss, der ein in dem Paketspeicher gespeichertes zweites Paket enthält, identifiziert, umfasst.
  10. Verfahren nach Anspruch 1, das ferner das Informieren (148) des Host-Computers über die Übertragung des ersten Pakets umfasst.
  11. Verfahren nach Anspruch 10, bei dem das Informieren das Konfigurieren eines Anzeigers in einem Host-Computer-Speicher umfasst, wobei der Anzeiger so konfiguriert ist, dass er anzeigt, dass der Host-Computer die Verarbeitung des ersten Pakets verzögern sollte, bis das zweite Paket an den Host-Computer übertragen worden ist.
  12. Verfahren nach Anspruch 1, bei dem das kollektive Verarbeiten umfasst: Mischen eines ersten Kopfabschnitts des ersten Pakets mit einem ersten Kopfabschnitt des zweiten Pakets, um einen ersten gemischten Kopfabschnitt zu bilden, wobei die ersten Kopfabschnitte des ersten Pakets und des zweiten Pakets in Übereinstimmung mit einem ersten Protokoll konfiguriert sind; Mischen eines zweiten Kopfabschnitts des ersten Pakets mit einem zweiten Kopfabschnitt des zweiten Pakets, um einen zweiten gemischten Kopfabschnitt zu bilden, wobei die zweiten Kopfabschnitte des ersten Pakets und des zweiten Pakets in Übereinstimmung mit einem zweiten Protokoll konfiguriert sind; Verarbeiten des ersten gemischten Kopfabschnitts in Übereinstimmung mit dem ersten Protokoll; und Verarbeiten des zweiten gemischten Kopfabschnitts in Übereinstimmung mit dem zweiten Protokoll.
  13. Verfahren nach Anspruch 1, bei dem die kollektive Verarbeitung umfasst: Verarbeiten eines ersten Kopfes des ersten Pakets und eines ersten Kopfes des zweiten Pakets in Übereinstimmung mit einem ersten Protokoll; und Verarbeiten eines zweiten Kopfes des ersten Pakets und eines zweiten Kopfes eines zweiten Pakets in Übereinstimmung mit einem zweiten Protokoll.
  14. Verfahren nach Anspruch 1, bei dem das Übertragen des ersten Pakets umfasst: Kopieren eines Datenabschnitts eines ersten Pakets in den Host-Computer; und Konfigurieren eines Anzeigers für die Übertragung des ersten Pakets in dem Host-Computer, um anzuzeigen, dass ein weiteres Paket in dem ersten Kommunikationsfluss an den Host-Computer übertragen werden soll.
  15. Verfahren nach Anspruch 14, bei dem das Übertragen des zweiten Pakets umfasst: Kopieren eines Datenabschnitts des zweiten Pakets in den Host-Computer; und Konfigurieren eines Anzeigers für die Übertragung des zweiten Pakets in dem Host-Computer, um anzuzeigen, dass das zweite Paket ein letztes Paket in dem ersten Kommunikationsfluss ist.
  16. Computervorrichtung zum Verarbeiten mehrerer Pakete in einem Kommunikationsfluss, wobei die Pakete zu einer vorgegebenen Länge von Kommunikationsprotokollen konform sind, wobei die Computervorrichtung umfasst: eine Kommunikationsschnittstelle (100), die ihrerseits versehen ist mit: einem Analysealgorithmus-Modul (106), das so konfiguriert ist, dass es ein erstes Paket in einem Kommunikationsfluss syntaktisch analysiert, um den Kommunikationsfluss zu identifizieren; einem Paketstapel-Modul (122), das so konfiguriert ist, dass es ein zweites Paket in dem Kommunikationsfluss identifiziert; und einer Übertragungsmaschine (120), die so konfiguriert ist, dass sie das erste Paket und das zweite Paket von der Kommunikationsschnittstelle an die Computervorrichtung überträgt; und einen Prozessor, der so konfiguriert ist, dass er einen Kopfabschnitt des ersten Pakets und einen Kopfabschnitt des zweiten Pakets in Übereinstimmung mit einer gemeinsamen Menge von Kommunikationsprotokollen kollektiv verarbeitet.
  17. Computervorrichtung nach Anspruch 16, bei der das Paketstapel-Modul (122) so konfiguriert ist, dass es das zweite Paket dadurch identifiziert, dass es einen zweiten Flussidentifizierer, der dem zweiten Paket zugeordnet ist, mit einem ersten Flussidentifizierer, der dem ersten Paket zugeordnet ist, vergleicht.
  18. Computervorrichtung nach Anspruch 17, bei der die Kommunikationsschnittstelle (100) ferner umfasst: eine Fluss-Datenbank (110), die so konfiguriert ist, dass sie einen Status des Kommunikationsflusses speichert; und einen Fluss-Manager (108), der so konfiguriert ist, dass er das Management des Status ausführt.
  19. Computervorrichtung nach Anspruch 18, bei der der erste Flussidentifizierer und/oder der zweite Flussidentifizierer einen Index in der Fluss-Datenbank des Status des Kommunikationsflusses umfassen.
  20. Computervorrichtung nach Anspruch 17, bei der das Analysealgorithmus-Modul (106) so konfiguriert ist, dass es den Kommunikationsfluss mit einem Flussschlüssel identifiziert, der einen Identifizierer einer Quelle des Kommunikationsflusses und einen Identifizierer eines Ziels des Kommunikationsflusses enthält; und wobei der erste Flussidentifizierer und der zweite Flussidentifizierer den Flussschlüssel enthalten.
  21. Computervorrichtung nach Anspruch 16, bei der der Prozessor die Kopfab schnitte des ersten Pakets und des zweiten Pakets kollektiv verarbeitet durch: Mischen eines ersten Kopfabschnitts des ersten Pakets mit einem ersten Kopfabschnitt des zweiten Pakets, um einen ersten gemischten Kopfabschnitt zu bilden, wobei die ersten Kopfabschnitte des ersten Pakets bzw. des zweiten Pakets in Übereinstimmung mit einem ersten Protokoll konfiguriert sind; Mischen eines zweiten Kopfabschnitts des ersten Pakets mit einem zweiten Kopfabschnitt des zweiten Pakets, um einen zweiten gemischten Kopfabschnitt zu bilden, wobei die zweiten Kopfabschnitte des ersten Pakets bzw. des zweiten Pakets in Übereinstimmung mit einem zweiten Protokoll konfiguriert sind; Verarbeiten des ersten gemischten Kopfabschnitts in Übereinstimmung mit dem ersten Protokoll; und Verarbeiten des zweiten gemischten Kopfabschnitts in Übereinstimmung mit dem zweiten Protokoll.
  22. Computervorrichtung nach Anspruch 16, bei der der Prozessor die Kopfabschnitte des ersten Pakets und des zweiten Pakets kollektiv verarbeitet durch: Verarbeiten eines ersten Kopfes des ersten Pakets und eines ersten Kopfes des zweiten Pakets in Übereinstimmung mit einem ersten Protokoll; und Verarbeiten eines zweiten Kopfes des ersten Pakets und eines zweiten Kopfes des zweiten Pakets in Übereinstimmung mit einem zweiten Protokoll.
  23. Computervorrichtung nach Anspruch 16, bei der die Übertragungsmaschine (120) das erste Paket und das zweite Paket überträgt durch: Kopieren eines Datenabschnitts des ersten Pakets in die Computervorrichtung; Konfigurieren eines Anzeigers für die Übertragung des ersten Pakets, um anzugeben, dass ein weiteres Paket in dem ersten Kommunikationsfluss an die Computervorrichtung übertragen werden soll; und Kopieren eines Datenabschnitts des zweiten Pakets in die Computervorrichtung.
  24. Computerprogramm, das, wenn es auf einem Computer oder in einem Computernetz ausgeführt wird, das Verfahren nach einem der Ansprüche 1–15 ausführen kann.
  25. Computerprogramm nach Anspruch 24, das in einem computerlesbaren Speichermedium verkörpert ist.
DE60019401T 1999-03-01 2000-02-29 Verfahren und gerät für die dynamische und stapelweise verarbeitung von paketen mit einer netzwerkschnittstelle Expired - Fee Related DE60019401T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US260324 1999-03-01
US09/260,324 US6483804B1 (en) 1999-03-01 1999-03-01 Method and apparatus for dynamic packet batching with a high performance network interface
PCT/US2000/005344 WO2000052883A2 (en) 1999-03-01 2000-02-29 Method and apparatus for dynamic packet batching with a high perfromance network interface

Publications (2)

Publication Number Publication Date
DE60019401D1 DE60019401D1 (de) 2005-05-19
DE60019401T2 true DE60019401T2 (de) 2006-03-16

Family

ID=22988704

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60019401T Expired - Fee Related DE60019401T2 (de) 1999-03-01 2000-02-29 Verfahren und gerät für die dynamische und stapelweise verarbeitung von paketen mit einer netzwerkschnittstelle

Country Status (6)

Country Link
US (1) US6483804B1 (de)
EP (1) EP1159813B1 (de)
JP (1) JP2002538726A (de)
AU (1) AU3389400A (de)
DE (1) DE60019401T2 (de)
WO (1) WO2000052883A2 (de)

Families Citing this family (103)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8621101B1 (en) 2000-09-29 2013-12-31 Alacritech, Inc. Intelligent network storage interface device
US6434620B1 (en) * 1998-08-27 2002-08-13 Alacritech, Inc. TCP/IP offload network interface device
US8539112B2 (en) 1997-10-14 2013-09-17 Alacritech, Inc. TCP/IP offload device
US8782199B2 (en) 1997-10-14 2014-07-15 A-Tech Llc Parsing a packet header
US6226680B1 (en) 1997-10-14 2001-05-01 Alacritech, Inc. Intelligent network interface system method for protocol processing
US6757746B2 (en) 1997-10-14 2004-06-29 Alacritech, Inc. Obtaining a destination address so that a network interface device can write network data without headers directly into host memory
JP2000332817A (ja) * 1999-05-18 2000-11-30 Fujitsu Ltd パケット処理装置
CN100384180C (zh) * 1999-06-30 2008-04-23 倾向探测公司 用于监控网络流量的方法和设备
US6938097B1 (en) 1999-07-02 2005-08-30 Sonicwall, Inc. System for early packet steering and FIFO-based management with priority buffer support
JP4207323B2 (ja) * 1999-08-26 2009-01-14 富士通株式会社 データ転送装置及びデータ転送方法
US7076630B2 (en) * 2000-02-08 2006-07-11 Mips Tech Inc Method and apparatus for allocating and de-allocating consecutive blocks of memory in background memo management
US7139901B2 (en) * 2000-02-08 2006-11-21 Mips Technologies, Inc. Extended instruction set for packet processing applications
US7032226B1 (en) 2000-06-30 2006-04-18 Mips Technologies, Inc. Methods and apparatus for managing a buffer of events in the background
US7058065B2 (en) * 2000-02-08 2006-06-06 Mips Tech Inc Method and apparatus for preventing undesirable packet download with pending read/write operations in data packet processing
US7058064B2 (en) 2000-02-08 2006-06-06 Mips Technologies, Inc. Queueing system for processors in packet routing operations
US7165257B2 (en) * 2000-02-08 2007-01-16 Mips Technologies, Inc. Context selection and activation mechanism for activating one of a group of inactive contexts in a processor core for servicing interrupts
US7082552B2 (en) 2000-02-08 2006-07-25 Mips Tech Inc Functional validation of a packet management unit
US7649901B2 (en) 2000-02-08 2010-01-19 Mips Technologies, Inc. Method and apparatus for optimizing selection of available contexts for packet processing in multi-stream packet processing
US20010052053A1 (en) * 2000-02-08 2001-12-13 Mario Nemirovsky Stream processing unit for a multi-streaming processor
US7042887B2 (en) 2000-02-08 2006-05-09 Mips Technologies, Inc. Method and apparatus for non-speculative pre-fetch operation in data packet processing
US7065096B2 (en) 2000-06-23 2006-06-20 Mips Technologies, Inc. Method for allocating memory space for limited packet head and/or tail growth
US7502876B1 (en) 2000-06-23 2009-03-10 Mips Technologies, Inc. Background memory manager that determines if data structures fits in memory with memory state transactions map
US7155516B2 (en) 2000-02-08 2006-12-26 Mips Technologies, Inc. Method and apparatus for overflowing data packets to a software-controlled memory when they do not fit into a hardware-controlled memory
DE10011667C2 (de) * 2000-03-10 2002-11-21 Infineon Technologies Ag Hochgeschwindigkeits-Router
US6862267B1 (en) * 2000-05-08 2005-03-01 Nortel Networks Limited Determining network addresses and ports using table from a description file
US8300534B2 (en) * 2000-05-24 2012-10-30 Alcatel Lucent Programmable packet processor with flow resolution logic
US6741594B1 (en) * 2000-06-15 2004-05-25 Advanced Micro Devices, Inc. Arrangement for identifying data packet types from multiple protocol formats on a network switch port
US7032031B2 (en) * 2000-06-23 2006-04-18 Cloudshield Technologies, Inc. Edge adapter apparatus and method
US6928482B1 (en) * 2000-06-29 2005-08-09 Cisco Technology, Inc. Method and apparatus for scalable process flow load balancing of a multiplicity of parallel packet processors in a digital communication network
JP3348080B1 (ja) * 2000-07-07 2002-11-20 松下電器産業株式会社 データ送信装置とデータ受信装置及びデータ送受信方法
US6850491B1 (en) * 2000-08-21 2005-02-01 Nortel Networks Limited Modeling link throughput in IP networks
US6785751B1 (en) * 2000-09-19 2004-08-31 Intel Corporation Method and apparatus for minimizing bus contention for I/O controller write operations
US8019901B2 (en) 2000-09-29 2011-09-13 Alacritech, Inc. Intelligent network storage interface system
US6996833B1 (en) * 2001-03-27 2006-02-07 Microsoft Corporation Protocol agnostic request response pattern
US6862281B1 (en) * 2001-05-10 2005-03-01 Cisco Technology, Inc. L4 lookup implementation using efficient CAM organization
US8868659B2 (en) * 2001-05-15 2014-10-21 Avaya Inc. Method and apparatus for automatic notification and response
US20030115350A1 (en) * 2001-12-14 2003-06-19 Silverback Systems, Inc. System and method for efficient handling of network data
KR100437180B1 (ko) * 2001-12-26 2004-06-23 엘지전자 주식회사 에스아이피 메시지 파싱 장치, 파싱 방법 및 그 생성 방법
US20030149741A1 (en) * 2002-02-05 2003-08-07 Krooss Kevin William Methods for implementing remote operating system procedure calls
US7543087B2 (en) 2002-04-22 2009-06-02 Alacritech, Inc. Freeing transmit memory on a network interface device prior to receiving an acknowledgement that transmit data has been received by a remote device
US7149220B2 (en) 2002-04-25 2006-12-12 International Business Machines Corporation System, method, and product for managing data transfers in a network
US7436947B2 (en) * 2002-05-14 2008-10-14 Avaya Inc. Method and apparatus for automatic notification and response based on communication flow expressions
US20040051650A1 (en) * 2002-09-16 2004-03-18 Bryan Gonsoulin Two way data communication with a well logging tool using a TCP-IP system
US7400581B2 (en) * 2003-03-03 2008-07-15 Sun Microsystems, Inc. Load-balancing utilizing one or more threads of execution for implementing a protocol stack
US7913294B1 (en) 2003-06-24 2011-03-22 Nvidia Corporation Network protocol processing for filtering packets
US7620070B1 (en) * 2003-06-24 2009-11-17 Nvidia Corporation Packet processing with re-insertion into network interface circuitry
AU2003903480A0 (en) * 2003-07-07 2003-07-17 Canon Kabushiki Kaisha A Low Power Chip Architecture
US7571242B2 (en) * 2003-10-24 2009-08-04 Alcatel Lucent Method for accelerated packet processing
WO2005050925A1 (en) * 2003-11-21 2005-06-02 Canon Kabushiki Kaisha A MODULAR APPROACH TO THE TCP/IPv6 HARDWARE IMPLEMENTATION
US7433364B2 (en) * 2003-12-24 2008-10-07 Intel Corporation Method for optimizing queuing performance
US7443856B2 (en) * 2004-01-14 2008-10-28 Lucent Technologies Inc. Managing processing utilization in a network node
US7734731B2 (en) 2004-03-18 2010-06-08 Avaya Inc. Method and apparatus for a publish-subscribe system with third party subscription delivery
US20060075142A1 (en) * 2004-09-29 2006-04-06 Linden Cornett Storing packet headers
US7620046B2 (en) * 2004-09-30 2009-11-17 Intel Corporation Dynamically assigning packet flows
US7512684B2 (en) * 2004-09-30 2009-03-31 Intel Corporation Flow based packet processing
US8248939B1 (en) 2004-10-08 2012-08-21 Alacritech, Inc. Transferring control of TCP connections between hierarchy of processing mechanisms
US20060126640A1 (en) * 2004-12-14 2006-06-15 Sood Sanjeev H High performance Transmission Control Protocol (TCP) SYN queue implementation
US20060206706A1 (en) * 2005-03-14 2006-09-14 Bryan Dietz Method and apparatus for dynamically distributing data flow in a communication network
US7561573B2 (en) * 2005-03-23 2009-07-14 Fujitsu Limited Network adaptor, communication system and communication method
JP4526458B2 (ja) * 2005-07-29 2010-08-18 富士通株式会社 パケット処理装置及びパケット処理プログラム
US7957272B2 (en) * 2006-03-10 2011-06-07 Alcatel-Lucent Usa Inc. Method and apparatus for coincidence counting for estimating flow statistics
US8661160B2 (en) * 2006-08-30 2014-02-25 Intel Corporation Bidirectional receive side scaling
KR100867875B1 (ko) * 2007-04-25 2008-11-10 포스데이타 주식회사 휴대 인터넷 시스템의 서비스 품질 보장 장치 및 방법
US8090789B1 (en) * 2007-06-28 2012-01-03 Emc Corporation Method of operating a data storage system having plural data pipes
US9172595B2 (en) * 2008-01-07 2015-10-27 Masergy Communications, Inc. Systems and methods of packet object database management
JP5045472B2 (ja) * 2008-02-07 2012-10-10 富士通株式会社 メール管理装置、メール管理方法およびメール管理プログラム
US7962564B2 (en) * 2008-02-25 2011-06-14 International Business Machines Corporation Discovery of a virtual topology in a multi-tasking multi-processor environment
US8762125B2 (en) * 2008-02-25 2014-06-24 International Business Machines Corporation Emulated multi-tasking multi-processor channels implementing standard network protocols
US20090216893A1 (en) * 2008-02-25 2009-08-27 International Business Machines Corporation Buffer discovery in a parrallel multi-tasking multi-processor environment
US8009589B2 (en) * 2008-02-25 2011-08-30 International Business Machines Corporation Subnet management in virtual host channel adapter topologies
US8065279B2 (en) * 2008-02-25 2011-11-22 International Business Machines Corporation Performance neutral heartbeat for a multi-tasking multi-processor environment
US7949721B2 (en) * 2008-02-25 2011-05-24 International Business Machines Corporation Subnet management discovery of point-to-point network topologies
JP2009239435A (ja) * 2008-03-26 2009-10-15 Oki Semiconductor Co Ltd パケット中継装置
US8539513B1 (en) 2008-04-01 2013-09-17 Alacritech, Inc. Accelerating data transfer in a virtual computer system with tightly coupled TCP connections
US8014282B2 (en) * 2008-06-26 2011-09-06 Intel Corporation Hashing packet contents to determine a processor
US8341286B1 (en) 2008-07-31 2012-12-25 Alacritech, Inc. TCP offload send optimization
US9306793B1 (en) 2008-10-22 2016-04-05 Alacritech, Inc. TCP offload device that batches session layer headers to reduce interrupts as well as CPU copies
US8661314B2 (en) * 2009-03-23 2014-02-25 Broadcom Corporation Method and apparatus for calculating frame check sequence
US8683145B2 (en) 2009-11-09 2014-03-25 Microsoft Corporation Packed storage commands and storage command streams
KR101592039B1 (ko) * 2010-03-02 2016-02-05 삼성전자주식회사 통신 시스템에서 플로우 정보 관리 방법 및 장치
US9292329B2 (en) * 2011-02-10 2016-03-22 Microsoft Technology Licensing, Llc Virtual switch interceptor
US9094333B1 (en) * 2011-10-26 2015-07-28 Qlogic, Corporation Systems and methods for sending and receiving information via a network device
CN102413141B (zh) * 2011-11-30 2014-10-08 华为技术有限公司 网络消息解析方法及通信设备
US9047417B2 (en) 2012-10-29 2015-06-02 Intel Corporation NUMA aware network interface
US10684973B2 (en) 2013-08-30 2020-06-16 Intel Corporation NUMA node peripheral switch
CN104734993B (zh) * 2013-12-24 2018-05-18 杭州华为数字技术有限公司 数据分流方法及分流器
US10089339B2 (en) * 2016-07-18 2018-10-02 Arm Limited Datagram reassembly
US10681189B2 (en) * 2017-05-18 2020-06-09 At&T Intellectual Property I, L.P. Terabit-scale network packet processing via flow-level parallelization
US10152275B1 (en) 2017-08-30 2018-12-11 Red Hat, Inc. Reverse order submission for pointer rings
US10246835B1 (en) * 2017-11-02 2019-04-02 Roadtec, Inc. Method and apparatus for spreading chips on roadway using foamed asphalt cement
US10848420B2 (en) * 2018-02-12 2020-11-24 Cisco Technology, Inc. Dynamic forwarding features in network elements
CN110417707B (zh) * 2018-04-27 2021-11-09 中兴通讯股份有限公司 数据发送保护方法、装置、系统及计算机可读存储介质
US11277455B2 (en) 2018-06-07 2022-03-15 Mellanox Technologies, Ltd. Streaming system
US20200106828A1 (en) * 2018-10-02 2020-04-02 Mellanox Technologies, Ltd. Parallel Computation Network Device
US11082540B2 (en) * 2018-11-05 2021-08-03 Cisco Technology, Inc. Network operations including protocol processing of a packet updating an operations data field of a different protocol
US11625393B2 (en) 2019-02-19 2023-04-11 Mellanox Technologies, Ltd. High performance computing system
EP3699770A1 (de) 2019-02-25 2020-08-26 Mellanox Technologies TLV Ltd. System und verfahren zur kollektiven kommunikation
US11122464B2 (en) * 2019-08-27 2021-09-14 At&T Intellectual Property I, L.P. Real-time large volume data correlation
US11750699B2 (en) 2020-01-15 2023-09-05 Mellanox Technologies, Ltd. Small message aggregation
US11252027B2 (en) 2020-01-23 2022-02-15 Mellanox Technologies, Ltd. Network element supporting flexible data reduction operations
US11876885B2 (en) 2020-07-02 2024-01-16 Mellanox Technologies, Ltd. Clock queue with arming and/or self-arming features
US11556378B2 (en) 2020-12-14 2023-01-17 Mellanox Technologies, Ltd. Offloading execution of a multi-task parameter-dependent operation to a network device
US11922237B1 (en) 2022-09-12 2024-03-05 Mellanox Technologies, Ltd. Single-step collective operations

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5128926A (en) 1990-03-21 1992-07-07 Digital Equipment Corporation Updating link state information in networks
FR2686755A1 (fr) 1992-01-28 1993-07-30 Electricite De France Procede de chiffrement de messages transmis entre reseaux interconnectes, appareil de chiffrement et dispositif de communication de donnees chiffrees mettant en óoeuvre un tel procede.
GB2268372B (en) 1992-06-11 1995-11-01 Roke Manor Research Improvements in or relating to data transmission systems
DE69324204T2 (de) 1992-10-22 1999-12-23 Cabletron Systems Inc Aufsuchen von Adressen bei Paketübertragung mittels Hashing und eines inhaltsadressierten Speichers
ATE171325T1 (de) 1993-03-20 1998-10-15 Ibm Verfahren und vorrichtung zur herausarbeitung der vermittlungsinformation aus dem kopfteil eines protokolls
WO1995014269A1 (en) 1993-11-19 1995-05-26 The Trustees Of The University Of Pennsylvania A high-performance host interface for networks carrying connectionless traffic
US5758089A (en) 1995-11-02 1998-05-26 Sun Microsystems, Inc. Method and apparatus for burst transferring ATM packet header and data to a host computer system
US5778180A (en) 1995-11-06 1998-07-07 Sun Microsystems, Inc. Mechanism for reducing data copying overhead in protected memory operating systems
US5793954A (en) 1995-12-20 1998-08-11 Nb Networks System and method for general purpose network analysis
BR9707253A (pt) * 1996-01-31 1999-06-01 Ipsilon Networks Inc Processos de transmitir pacetes entre um nó a montante e um nó a jusante em uma rede e de comutar um fluxo em um primeiro nó produto de programa de computador unídade de comutação básica em um sistema para transmitir pacotes em uma rede unidade de porta de comutador e agente de comutação
US5787255A (en) 1996-04-12 1998-07-28 Cisco Systems, Inc. Internetworking device with enhanced protocol translation circuit
US5778414A (en) 1996-06-13 1998-07-07 Racal-Datacom, Inc. Performance enhancing memory interleaver for data frame processing
US5870394A (en) 1996-07-23 1999-02-09 Northern Telecom Limited Method and apparatus for reassembly of data packets into messages in an asynchronous transfer mode communications system
US5748905A (en) 1996-08-30 1998-05-05 Fujitsu Network Communications, Inc. Frame classification using classification keys
US6011803A (en) 1997-01-13 2000-01-04 Lucent Technologies Inc. Distributed-protocol server
US6470389B1 (en) 1997-03-14 2002-10-22 Lucent Technologies Inc. Hosting a network service on a cluster of servers using a single-address image
US6094435A (en) 1997-06-30 2000-07-25 Sun Microsystems, Inc. System and method for a quality of service in a multi-layer network element
US6115378A (en) 1997-06-30 2000-09-05 Sun Microsystems, Inc. Multi-layer distributed network element
US6128666A (en) 1997-06-30 2000-10-03 Sun Microsystems, Inc. Distributed VLAN mechanism for packet field replacement in a multi-layered switched network element using a control field/signal for indicating modification of a packet with a database search engine
US6088356A (en) 1997-06-30 2000-07-11 Sun Microsystems, Inc. System and method for a multi-layer network element
US6157955A (en) * 1998-06-15 2000-12-05 Intel Corporation Packet processing system including a policy engine having a classification unit

Also Published As

Publication number Publication date
EP1159813A2 (de) 2001-12-05
EP1159813B1 (de) 2005-04-13
WO2000052883A3 (en) 2001-01-04
WO2000052883A2 (en) 2000-09-08
US6483804B1 (en) 2002-11-19
JP2002538726A (ja) 2002-11-12
DE60019401D1 (de) 2005-05-19
AU3389400A (en) 2000-09-21

Similar Documents

Publication Publication Date Title
DE60019401T2 (de) Verfahren und gerät für die dynamische und stapelweise verarbeitung von paketen mit einer netzwerkschnittstelle
DE60021358T2 (de) Eine hoch-leistungs-netzschnittstelle
DE60031516T2 (de) Verfahren und gerät für die verwaltung eines netzflusses in einer hochleistungs-netzschnittstelle
DE60016574T2 (de) Verfahren und vorrichtung zur belastungsverteilung uphänging von datenflussen
DE112020002495T5 (de) System und verfahren zur erleichterung der betriebsverwaltung in einer netzwerkschnittstellensteuerung (nic) für beschleuniger
EP1159814B1 (de) Dynamisches parsing in einer hochleistungs netzwerkschnittstelle
EP1157518B1 (de) Verfahren und gerät für datenwiederversammlung mit einer hohe-leistung-netzschnittstelle
DE60203380T2 (de) Verfahren und vorrichtung zur mehrfachsendung
DE60009884T2 (de) Verfahren und vorrichtung zur identifizierung und klassifizierung von netzwerkverkehr in einer hochleistungs netzwerkschnittstelle
US6606301B1 (en) Method and apparatus for early random discard of packets
DE60211837T2 (de) Verfahren und Vorrichtung zur Paketkopfteilverarbeitung
DE112011103561T5 (de) Netzwerkprozessor und Verfahren zum Beschleunigen der Datenpaket-Syntaxanalyse
DE60015186T2 (de) Verfahren und system für rahmen- und protokollklassifikation
DE60112011T2 (de) Verfahren und Vorrichtung zum Filtern von Paketen basierend auf Datenströme unter Verwendung von Addressentabellen
DE102015112634A1 (de) Unterstützen von RMA-API über aktive Message
DE112004002544B4 (de) Verfahren, System und Programm zur Identifizierung von Datenüberlauf
EP2668763B1 (de) Schaltungsanordnung für verbindungsschnittstelle
DE102021203777A1 (de) Flexibles lenken
EP2663039B1 (de) Verfahren und vorrichtung zur zielgerichteten übertragung eines datenpakets

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee