DE60021358T2

DE60021358T2 - Eine hoch-leistungs-netzschnittstelle

Info

Publication number: DE60021358T2
Application number: DE60021358T
Authority: DE
Inventors: Shimon Muller; Denton Gentry; John Watkins; Linda Cheng
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1999-03-01
Filing date: 2000-02-29
Publication date: 2006-04-20
Anticipated expiration: 2020-03-01
Also published as: US6453360B1; AU3248500A; EP1159811B1; EP1159811A1; JP2002538733A; DE60021358D1; WO2000052904A1

Description

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 behan deln, 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 Verarbei tung 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, für 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. Gegenwärtig 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 Spei cherbusbandbreite 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 gegenwärtigen Netzschnittstellenschaltungen und Host-Computersystemen betrifft, ist, dass die Kombination häufig nicht die erhöhten Prozessorbetriebsmittel nutzt, die in Mehrprozessor-Computersystemen verfügbar sind. Mit anderen Worten, gegenwärtige 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 gegenwärtiger 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 beeinträchtigt 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 gegenwärtigen 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 684 954 offenbart ein Verfahren und eine Vorrichtung zum Verarbeiten von Feldern eines Protokollkopfs, der einem Datenstrom vorangeht, um einen Verbindungsidentifizierer zum Verarbeiten des Datenstroms zu erzeugen. Es werden Protokolltypinformationen eines ersten Protokolls extrahiert und daraufhin Informationen hinsichtlich der auf das erste Protokoll aufgebauten Protokolle gelesen. Die Protokoll- und die Protokolltypinformationen werden zum Erzeugen des Verbindungsidentifizierers verwendet.
US-A-5 748 905 offenbart eine Rahmenklassifizierung unter Verwendung von Klassifizierungsschlüsseln. Die Quell- und die Zieladresse werden von einem Rah men syntaktisch analysiert und zum Durchsuchen von Nachschlagetabellen verwendet. Erfolgreiche Durchsuchungen liefern Schlüsselwerte, die verkettet werden können, um neue Suchwerte zu bilden. Erfolgreiche Durchsuchungen mit den verketteten Schlüsselwerten liefern Klassifizierungsschlüssel zum Angeben der Verarbeitungsweise des Rahmens.
US-A-5 793 954 offenbart ein System und ein Verfahren zum syntaktischen Analysieren, Filtern, Erzeugen und Analysieren von über ein Datenkommunikationsnetz übertragenen Daten. Ein Logiksteuermodul führt anhand einer oder mehrerer programmierbarer konfigurierbarer Protokollbeschreibungen Datenmanipulationsfunktionen aus.
EP-A-0 853 411 offenbart ein verteiltes Protokollsystem, das einen Kommunikationsprotokoll-Server enthält, der die Verarbeitung verschiedener Protokollschichten auf die Server- und Client-Prozessoren verteilt.
ZUSAMMENFASSUNG
Es werden ein Verfahren gemäß Anspruch 1 und ein Computersystem gemäß Anspruch 29 geschaffen, um ein Paket von einem Netz zu empfangen und es an ein Host-Computersystem zu senden. In verschiedenen Ausführungsformen der Erfindung wird eine Hochleistungs-Netzschnittstelle so konfiguriert, dass sie eine oder mehrere verbesserte Optionen implementiert, um einen Bereich von Paketankunftsraten effizient zu behandeln, ohne das Host-Computersystem übermäßig zu belasten.
Eine solche Operation ist die Wiederzusammensetzung von Daten von mehreren Paketen in einem Kommunikationsfluss, in einer Kommunikationsschaltung oder in einer Kommunikationsverbindung. Insbesondere können Datenabschnitte solcher Pakete dadurch wieder zusammengesetzt werden, dass sie in einen einzigen Host-Speicherbereich oder -Puffer, der eine vorgegebene Größe (z. B. eine Speicherseite) hat, übertragen oder kopiert werden. Die wieder zusammengesetzten Daten können daraufhin auf effiziente Weise wie etwa als eine einzige Kopie oder Speicherübertragung an die Zielentität geliefert werden.
Eine weitere Operation zum Erhöhen der Effizienz der Behandlung von Netzverkehr ist in einer Ausführungsform der Erfindung die Blockbildungsverarbeitung von Paketköpfen durch einen geeigneten Protokollstapel. In dieser Operation wird ein Host-Computersystem vor der Übertragung zweier oder mehrerer Pakete aus dem gleichen Kommunikationsfluss in den Host-Speicher gewarnt. Wenn der Host-Computer derart gewarnt worden ist, kann er die Verarbeitung eines ersten Pakets in dem Fluss verzögern, um auf den Empfang eines zweiten zu warten. Daraufhin können die Köpfe der Pakete eher gemeinsam oder in schneller Folge verarbeitet werden, als die Verarbeitung der Pakete mit Paketen von anderen Flüssen zu durchsetzen.
In einer nochmals weiteren Operation kann die Verarbeitung von Paketen oder Paketköpfen durch ihre Protokollstapel in einem Mehrprozessor-Host-Computersystem auf zwei oder mehr Prozessoren verteilt werden. In einer Lastverteilungsoperation wird in einer Ausführungsform der Erfindung aus dem Flussschlüssel eines Pakets ein Identifizierer des Prozessors, der ein Paket verarbeiten soll, erzeugt. In dieser Ausführungsform wird ein Flussschlüssel aus Identifizierern der Quell- und der Zielentität des Pakets zusammengesetzt, die aus dem Kopfabschnitt des Pakets entnommen werden. Unter Verwendung des Flussschlüssels des Pakets, der einen besonderen Kommunikationsfluss eindeutig identifiziert, werden alle Pakete in demselben Fluss an denselben Prozessor gesendet. Ein Verfahren zum Erzeugen des Prozessoridentifizierers ist das Ausführen einer Hash-Funktion an dem Flussschlüssel und daraufhin das Bilden des Moduls dieses Ergebnisses über die Anzahl der Prozessoren in dem Host-Computersystem.
In einer Ausführungsform der Erfindung enthält eine Hochleistungs-Netzschnittstelle ein Modul zur syntaktischen Analyse von Köpfen. Wenn ein Paket von einem Netz empfangen wird, analysiert das Modul zur syntaktischen Analyse von Köpfen einen Kopfabschnitt des Pakets. Das Modul zur syntaktischen Analyse von Köpfen führt eine Reihe von Anweisungen zur syntaktischen Analyse aus, die in Übereinstimmung mit einer Menge von ausgewählten Kommunikationsprotokollen so konfiguriert werden, dass sie Pakete über das Netz zu befördern. Während der syntaktischen Analyse des Pakets vergleicht das Modul zur syntaktischen Analyse von Köpfen einen aus einem Kopffeld extrahierten Wert mit einem erwarteten Wert, um das empfangene Paket auf Kompatibilität mit den ausgewählten Protokollen zu testen. Die Befehle zum Betreiben des Moduls zur syntaktischen Analyse von Köpfen können in einem überschreibbaren Speicher gespeichert werden, so dass das Modul rekonfiguriert werden kann, um Pakete syntaktisch zu analysieren, die mit praktisch irgendeinem Kommunikationsprotokoll in Übereinstim mung stehen.
Außer der syntaktischen Analyse eines Pakets zur Feststellung seiner Kompatibilität mit einer Menge von Protokollen gewinnt ein Modul zur syntaktischen Analyse von Köpfen in einer Ausführungsform der Erfindung Werte aus einem oder aus mehreren Feldern im Kopf des Pakets wieder. Die extrahierten Werte können verwendet werden, um eine der verbesserten Operationen zu ermöglichen oder bei ihr zu helfen. Insbesondere extrahiert in dieser Ausführungsform ein Modul zur syntaktischen Analyse von Köpfen Identifizierer der Quell- und Zielidentität des Pakets. Diese Identifizierer können kombiniert werden, um einen Flussschlüssel zur Identifizierung des Kommunikationsflusses, der Kommunikationsschaltung oder der Kommunikationsverbindung, in der das Paket gesendet wurde, zu bilden. In dieser Ausführungsform kann jedes getrennte von einer Quellentität zu einer Zielentität gesendete Datagramm einen getrennten Fluss umfassen.
Nachdem ein Modul zur syntaktischen Analyse von Köpfen ein von einem Netz empfangenes Paket syntaktisch analysiert hat, übergibt das Modul zur syntaktischen Analyse von Köpfen den Flussschlüssel des Pakets und möglicherweise weitere aus dem Paket extrahierte Informationen an einen Flussdatenbankmanager. Der Flussdatenbankmanager hält eine Flussdatenbank für das Management der Kommunikationsflüsse, die bei der Netzschnittstelle empfangen werden. Innerhalb einer Flussdatenbank können eine Anzahl von Flussschlüsseln gespeichert und durch Flussnummern indiziert werden. Während Flüsse begonnen und abgeschlossen werden und während Flusspakete empfangen werden, wird die Datenbank dementsprechend aktualisiert.
Aus den in dieser Ausführungsform von einem Modul zur syntaktischen Analyse von Köpfen empfangenen Informationen weist der Flussdatenbankmanager dem Paket einen Operationscode zu. Andere Module der Netzschnittstelle können den Operationscode verwenden, um die Eignung des Pakets für eine oder mehrere der oben beschriebenen verbesserten Operationen oder zum Identifizieren eines Verfahrens zum Ausführen einer Operation festzustellen. Zum Beispiel kann der Operationscode des empfangenen Pakets offenbaren, ob das Paket mit der Menge von ausgewählten Protokollen kompatibel ist, ob das Paket Daten enthält, ob die Daten des Pakets mit anderen Flusspaketen wieder zusammengesetzt werden können, ob ein Fluss auf- oder abzubauen ist usw.
In einer Ausführungsform der Erfindung enthält die Hochleistungs-Netzschnittstelle eine Paketwarteschlange, in der ein von einem Netz empfangenes Paket vor seiner Übertragung an ein Host-Computersystem zu speichern ist. Außerdem kann die Netzschnittstelle eine Steuerwarteschlange oder andere Datenstrukturen (z. B. Register) enthalten, in der bzw. in denen aus einem Paket extrahierte Daten und/oder Informationen, die die extrahierten Daten betreffen, wie etwa ein Operationscode oder eine Flussnummer zu speichern sind. Die in der Paket- und/oder in der Steuerwarteschlange gespeicherten Informationen können außerdem eine durch ein Prüfsummenmodul erzeugte Prüfsumme, einen durch ein Lastverteilermodul erzeugten Prozessoridentifizierer, Versätze zu spezifischen Abschnitten des Pakets, Merker, die Status oder Bedingungen des Pakets betreffen, usw. enthalten.
In einer weiteren Ausführungsform der Erfindung ist eine DMA-Maschine zum Übertragen eines Pakets von einer Paketwarteschlange in einen Host-Speicherbereich wie etwa in einen Puffer in dem Host-Computersystem vorgesehen. Die DMA-Maschine kann sich auf Informationen in der Paketwarteschlange oder in einer Steuerwarteschlange wie etwa auf einen Operationscode stützen, um festzustellen, in welchem Puffer oder in welchen Puffern ein Paket zu speichern ist. Zum Beispiel kann der Kopf eines Pakets in einem Kopfpuffer gespeichert werden, während sein Datenabschnitt in einem Wiederzusammensetzungspuffer gespeichert wird. Pakete mit weniger als einer angegebenen Größe können ebenfalls in einem Kopfpuffer gespeichert werden. Ein Paket, das nicht mit den ausgewählten Protokollen kompatibel ist, kann intakt in einem Nichtwiederzusammensetzungspuffer gespeichert werden. In einer Ausführungsform haben die Puffer eine vorgegebene Größe, die die Effizienz von Speicherübertragungen oder -kopien erhöht, wie etwa eine Speicherseite.
In einer nochmals weiteren Ausführungsform der Erfindung enthält eine Hochleistungs-Netzschnittstelle ein dynamisches Paketblockbildungsmodul, um einen Host-Computer zu benachrichtigen, wenn mehrere Pakete in einer Kommunikation an den Computer übertragen werden. In dieser Ausführungsform enthält ein Paketblockbildungsmodul einen Speicher zum Speichern von Flussnummern oder Flussschlüsseln mehrerer an den Host-Computer zu übertragender Pakete. Wenn ein Paket übertragen wird oder kurz davor steht, übertragen zu werden, durchsucht das Paketblockbildungsmodul seinen Speicher nach weiteren Paketen mit der gleichen Flussnummer oder mit dem gleichen Flussschlüssel wie das übertra gene Paket. Der Host-Computer wird dementsprechend benachrichtigt und kann die Verarbeitung eines Pakets in einem Fluss verzögern, um es in Verbindung mit einem weiteren Paket in dem gleichen Fluss zu verarbeiten.
Die Netzschnittstelle kann das Host-Computersystem durch Konfigurieren und Freigeben eines Deskriptors, der identifiziert, wo das Paket gespeichert ist, über die Ankunft oder Übertragung eines Pakets benachrichtigen. In einer weiteren Ausführungsform gibt eine Hochleistungs-Netzschnittstelle eine Warnung wie etwa eine Unterbrechung an das Host-Computersystem aus. Von der Netzschnittstelle ausgegebene Unterbrechungen können insbesondere während die Rate, mit der Pakete von einem Netz ankommen, zunimmt, moduliert werden, um die Anzahl der Unterbrechungen oder die Häufigkeit, mit der sie ausgegeben werden, zu begrenzen. In einem Verfahren zum Modulieren von Unterbrechungen können weitere Unterbrechungen gesperrt werden, nachdem eine erste Unterbrechung ausgegeben worden ist, bis eine angegebene Anzahl von Paketen empfangen worden ist und/oder eine vorgegebene Zeitdauer verstrichen ist. In einem weiteren Verfahren zum Modulieren von Unterbrechungen können Unterbrechungen gesperrt werden, während Software, die in dem Host-Computer arbeitet, die Netzschnittstelle abfragt, um festzustellen, ob ein Paket empfangen oder gesendet worden ist. Außerdem können in diesem Verfahren Paket- und Zeitzähler verwendet werden, um zu ermöglichen, dass Unterbrechungen erzeugt werden, falls die Abfragesoftware gesperrt ist oder ausfällt.
Falls die Rate, mit der ein Host-Computer Pakete von einer Hochgeschwindigkeits-Netzschnittstelle annimmt, nicht mit der Rate Schritt hält, mit der Pakete bei der Netzschnittstelle empfangen werden, kann in einer Ausführungsform der Erfindung ein Paket fallen gelassen werden. In dieser Ausführungsform ist ein Verfahren vorgesehen, um zufällig ein Paket auszuwählen, das fallen zu lassen ist, bevor oder nachdem das Paket in einer Paketwarteschlange gespeichert wird bzw. gespeichert worden ist. In dieser Ausführungsform ist eine Paketwarteschlange logisch in mehrere Zonen oder Unterteilungen getrennt, die sich überschneiden können. Jeder Zone ist ein Wahrscheinlichkeitsindikator zugeordnet, der die Wahrscheinlichkeit angibt, dass ein Paket fallen gelassen wird, wenn das Niveau des in der Warteschleife gespeicherten Verkehrs innerhalb der Zone liegt. Wenn das Verkehrsniveau innerhalb einer besonderen Zone liegt, wird der Wahrscheinlichkeitsindikator für diese Zone jedes Mal angewendet, wenn in der Paketwarteschlange ein verwerfbares Paket zu speichern ist. Somit gibt der Wahrscheinlich keitsindikator der Zone an, ob das Paket zu verwerfen ist oder ob zu ermöglichen ist, dass es in der Warteschlange gespeichert wird. Es können alle Pakete als verwerfbar betrachtet werden oder einige Pakete (z. B. Steuerpakete, Pakete in einem bestimmten Fluss, Pakete, die ein besonderes Protokoll befolgen) als nicht verwerfbar betrachtet werden. In einer Ausführungsform der Erfindung enthält die Netzschnittstelle einen Zähler, der über einen begrenzten Bereich von Werten inkrementiert wird, während verwerfbare Pakete zur Speicherung in der Warteschlange empfangen werden. In dieser Ausführungsform besteht ein Wahrscheinlichkeitsindikator aus einer Anzahl von Zahlen (z. B. aus einer Maske), die für jeden Wert in dem Bereich von Zählerwerten angeben, ob ein Paket zu verwerfen ist.
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 eine Einrichtung zur syntaktischen Analyse von Köpfen einer Netzschnittstellenschaltung zum syntaktischen Analysieren eines Pakets in Übereinstimmung mit einer Ausführungsform der Erfindung zeigt.
4A–4B enthalten einen Ablaufplan, der ein Verfahren zur syntaktischen Analyse 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 Übereinstimmung 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–20 sind Ablaufpläne, die Verfahren zum Übertragen eines von einem Netz empfangenen Pakets an einen Puffer in einem Host-Computerspeicher in Übereinstimmung mit einer Ausführungsform der Erfindung demonstrieren.
21 ist ein Diagramm eines dynamischen Paketblockbildungsmoduls in Übereinstimmung mit einer Ausführungsform der Erfindung.
22A–22B umfassen einen Ablaufplan, der ein Verfahren zum dynamischen Durchsuchen eines Speichers, der Informationen hinsichtlich Paketen enthält, die auf die Übertragung zu einem Host-Computer warten, um ein Paket in demselben Kommunikationsfluss wie ein Paket, das übertragen wird, zu lokalisieren, in Übereinstimmung mit einer Ausführungsform der Erfindung demonstriert.
23 zeigt eine Menge dynamischer Befehle zur syntaktischen Analyse eines Pakets in Übereinstimmung mit einer Ausführungsform der Erfindung.
24 zeigt ein System zum zufälligen Verwerfen eines Pakets von einer Netzschnittstelle in Übereinstimmung mit einer Ausführungsform der Erfindung.
25A–25B umfassen einen Ablaufplan, der ein Verfahren zum Verwerfen eines Pakets von einer Netzschnittstelle in Übereinstimmung mit einer Ausführungsform der Erfindung demonstriert.
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 geboten 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 Spezial vorrichtung 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 gegenwärtig bekannt sind (z. B. AppleTalk, IPX (Internetwork Packet Exchange) usw.), als auch an solche, die gegenwärtig unbekannt sind, halten. Der Fachmann auf dem Gebiet erkennt, dass die durch diese Erfindung geschaffenen Verfahren leicht für neue Kommunikationsprotokolle anpassbar sind.
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 Kommunikationsvorrichtung 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, können 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 gemeinsam 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-Computersystems. 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 Modul zur syntaktischen Analyse in einer NIC des Host-Computers syntaktisch die Kopfabschnitte der Pakete. Beispielhaft enthält das Modul zur syntaktischen Analyse 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 gemeinsam 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 Da ten an die Ziel-Entität liefern kann.
Wo der Host-Computer mehrere Prozessoren enthält, kann eine Lastverteilungseinrichtung (die 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 zufällig 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 Ausfü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 wesentlich 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 Eingangsportverarbeitungsmodul (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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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.
Die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen mit dem Flussdatenbankmanager (FDBM) 108, der eine Flussdatenbank (FDB) 110 administriert. Insbesondere übergibt die Einrichtung 106 zur syntaktischen Analyse von Köpfen an den FDBM 108 eine Anfrage, um festzustellen, 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 Kommunikationsfluss 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen für das Flussmanagement den Flussschlüssel des Pakets an den Flussdatenbankmanager 108. Außerdem kann die Einrichtung zur syntaktischen Analyse von Köpfen 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 von der Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 der Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 wiedergegewonnene und durch die Einrichtung 106 zur syntaktischen Analyse von Köpfen gelieferte Informationen zur Auswahl eines geeigneten Operationscodes verwenden. Daraufhin wird der Operationscode des Pakets zusammen mit einem Index des Flusses des Pakets innerhalb der FDB 110 an die Einrichtung zur syntaktischen Analyse von Köpfen zurückgegeben.
In einer Ausführungsform der Erfindung kann die Kombination aus Einrichtung 106 zur syntaktischen Analyse von Köpfen, 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen den Flussschlüssel des Pakets außerdem an die Lastverteilungseinrichtung 112. In einem Host-Computersystem mit mehreren Prozessoren kann die Lastverteilungseinrichtung 112 feststellen, zu welchem Prozessor ein ankommendes Paket zur Verarbeitung durch den richtigen Protokollstapel zu leiten ist. Die Lastverteilungseinrichtung 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 die Lastverteilungseinrichtung 112 weggelassen sein. In einer alternativen Ausführungsform kann die Einrichtung 106 zur syntaktischen Analyse von Köpfen außerdem direkt mit anderen Modulen der NIC 100 neben der Lastverteilungseinrichtung und dem Flussdatenbankmanager kommunizieren.
Nachdem die Einrichtung 106 zur syntaktischen Analyse von Köpfen ein Paket syntaktisch analysiert hat, ändert oder aktualisiert somit der FDBM 108 die FDB 110, während die Lastverteilungseinrichtung 112 einen Prozessor in dem Host-Computersystem zum Verarbeiten des Pakets identifiziert. Nach diesen Aktionen gibt die Einrichtung zur syntaktischen Analyse von Köpfen 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 Paketblockbildungsmodul 122 übergeben werden können. Die Steuerwarteschlange 118 enthält für jedes Paket in der Paketwarteschlange 116 verwandte Steuerinformationen.
Das Paketblockbildungsmodul 122 stützt sich auf Informationen, die die Pakete in der Paketwarteschlange 116 betreffen, um die Blockbildungsverarbeitung (d. h. die gemeinsame Verarbeitung) der Köpfe von mehreren verwandten Paketen zu ermöglichen. In einer Ausführungsform der Erfindung warnt das Paketblockbildungsmodul 122 den Host-Computer vor der Verfügbarkeit der Köpfe von verwandten Paketen, so dass sie gemeinsam 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 die Lastverteilungseintichtung 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, Blockbildungsverarbeitung 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 wenn 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen übergeben. Die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 die Einrichtung zur syntaktischen Analyse von Köpfen so konfiguriert sein kann, dass sie Köpfe verschiedener Protokolle in verschiedenen Tiefen syntaktisch analysiert. Insbesondere kann die Einrichtung 106 zur syntaktischen Analyse von Köpfen für eine spezifische Menge von Protokollen oder Protokollstapeln optimiert sein (wobei z. B. ihre Operationsbefehle für sie konfiguriert sein können). Falls das Paket mit einem oder mit mehreren der angegebenen Protokolle in Übereinstimmung 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 die Lastverteilungseinrichtung 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 reflektiert. Ferner erzeugt der FDBM 108 einen Operationscode, um eine oder mehrere Kenndaten oder Bedingungen des Pakets zusammenzufassen. Wie in nachfolgenden Abschnitten beschrieben wird, kann der Operationscode 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 die Einrichtung zur syntaktischen Analyse von Köpfen zurückgegeben.
Falls der Host-Computer mehrere Prozessoren enthält, weist die Lastverteilungseinrichtung 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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, (z. B. die Flussnummer, der Flussschlüssel) an das dynamische Paketblockbildungsmodul 122 geliefert werden können.
Im Zustand 142 stellt die NIC 100 fest, 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 (wenn das z. B. Paket am Kopf der Paketwarteschlange ist oder wenn der Host-Computer das Paket vor diesem Paket in der Paketwarteschlange empfängt), stellt das dynamische Paketblockbildungsmodul 122 im Zustand 144 fest, ob bald ein verwandtes Paket übertragen wird. Wenn das 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.
Der Fachmann auf dem Gebiet der Computersysteme und -netze erkennt, dass die oben beschriebene Prozedur nur ein Verfahren ist, 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 Ursprungs-Entitä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.
Wie in anderen Abschnitten beschrieben ist, werden in einer Ausführungsform der Erfindung ein System und ein Verfahren zur syntaktischen Analyse 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 Empfangens 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 der syntaktischen Analyse abgekürzt oder abgebrochen werden, wenn festgestellt 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 der Einrichtung 106 zur syntaktischen Analyse von Köpfen 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.
Für den Fachmann auf dem Gebiet ist klar, dass die in dem folgenden Abschnitt beschriebenen Verfahren zur syntaktischen Analyse eines Pakets leicht für Pakete anpassbar sind, die in Übereinstimmung mit praktisch irgendeinem Kommunikationsprotokoll formatiert sind.
Eine Ausführungsform einer Einrichtung zur syntaktischen Analyse von Köpfen
3 zeigt die Einrichtung 106 zur syntaktischen Analyse von Köpfen aus 1A in Übereinstimmung mit einer vorliegenden Ausführungsform der Erfindung. Beispielhaft enthält die Einrichtung 106 zur syntaktischen Analyse von Köpfen einen Kopfspeicher 302 und eine Einrichtung 304 zur syntaktischen Analyse, wobei die Einrichtung 304 zur syntaktischen Analyse 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.
In der veranschaulichten Ausführungsform analysiert die Einrichtung 304 zur syntaktischen Analyse einen im Kopfspeicher 302 gespeicherten Kopf syntaktisch in Übereinstimmung mit Befehlen, die im Befehlsspeicher 306 gespeichert sind. Wie oben diskutiert wurde, sind die Befehle zur syntaktischen Analyse 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 zur syntaktischen Analyse heruntergeladen oder auf andere Weise installiert werden können. Die Befehle zur syntaktischen Analyse 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 die Einrichtung 304 zur syntaktischen Analyse den Kopfabschnitt syntaktisch in Übereinstimmung mit den im Befehlsspeicher 306 gespeicherten Befehlen. Die Befehle für den Betrieb der Einrichtung 304 zur syntaktischen Analyse wenden in der gegenwärtig 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 die Einrichtung zur syntaktischen Analyse in einer vorliegenden Ausführungsform der Erfindung dynamisch, wobei die aus einem Feld eines Kopfs wiedergewonnenen In formationen 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 der Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 der Einrichtung 304 zur syntaktischen Analyse "bekannt" sind, auf desto mehr Protokolle kann ein Paket getestet werden und desto komplizierter kann das syntaktische Analysieren des Kopfabschnitts eines Pakets werden. Für den Fachmann auf dem Gebiet ist klar, dass die Protokolle, die durch die Einrichtung 304 zur syntaktischen Analyse syntaktisch analysiert werden können, lediglich durch die Befehle beschränkt sind, in Übereinstimmungen mit denen sie arbeitet. Somit können durch Ergänzen oder Ersetzen der im Befehlsspeicher 306 gespeicherten Befehle zur syntaktischen Analyse durch die Einrichtung 106 zur syntaktischen Analyse von Köpfen praktisch alle bekannten Protokolle behandelt werden und praktisch irgendwelche Informationen aus den Köpfen eines Pakets wiedergewonnen werden.
Natürlich kann die Operation der syntaktischen Analyse abgeschlossen werden, wenn ein Paketkopf nicht mit einem erwarteten oder vermuteten Protokoll in Übereinstimmung ist. In diesem Fall ist das Paket möglicherweise nicht für eine weitere der durch die NIC 100 gebotenen Effizienzverbesserungen (z. B. Datenwiederzusammensetzung, Paketblockbildung, 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 die Einrichtung 304 zur syntaktischen Analyse 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 werden, 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.
Für den Fachmann auf dem Gebiet ist klar, dass die kommunizierenden Entitäten unter Verwendung von Merkmalen, die den höheren Schichten des einem Paket zugeordneten Protokollstapels entnommen werden, mit höherer Auflösung identifiziert werden können. 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 die Einrichtung 304 zur syntaktischen Analyse außerdem einen Steuer- oder Statusindikator, um zusätzliche Informationen in Bezug auf das Paket zusammenzufassen. In einer Ausführungsform der Erfindung enthält ein Steuerindikator 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 Steuerindikator 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 Steuerindikator ebenfalls geeignet, wobei er lediglich durch die Informationen begrenzt ist, die in dem durch die Einrichtung 304 zur syntaktischen Analyse syntaktisch analysierten Abschnitt des Pakets verfügbar sind.
In einer Ausführungsform der Erfindung liefert die Einrichtung 106 zur syntaktischen Analyse von Köpfen den Flussschlüssel und den gesamten Steuerindikator 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 die Einrichtung 304 zur syntaktischen Analyse zusätzliche aus dem Kopf eines Pakets abgeleitete Informationen zur Verwendung durch andere Module der NIC 100. Zum Beispiel kann die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen in einer Ausführungsform der Erfindung einen Nutzinformationsversatz und eine Nutzinformationsgröße an die Steuerwarteschlange 118.
Unter geeigneten Umständen kann die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 die Einrichtung 304 zur syntaktischen Analyse 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 Indikators annehmen. Das Signal kann jedes Mal angehoben oder ausgegeben werden, wenn festgestellt wird, dass das Paket ein anderes Protokoll als die im Voraus gewählten Protokolle, die mit den oben beschriebenen Verarbeitungsverbesserungen (z. B. Datenwiederzusammensetzung, Blockbildungsverarbeitung von Paketköpfen, Lastverteilung) kompatibel sind, reflektiert. Zum Beispiel kann die Einrichtung 304 zur syntaktischen Analyse in einer Ausführungsform der Erfindung so konfiguriert sein, dass sie 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 Blockbildungsverarbeitung gesammelt werden.
In einer Ausführungsform der Erfindung werden die verschiedenen oben beschriebenen Informationsstücke am Schluss der syntaktischen Analyse an die richtigen Module der NIC 100 verteilt. Danach stellt der Flussdatenbankmanager 108 (wie auch in einem folgenden Abschnitt beschrieben ist) fest, 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 analysieren ist, kopiert und daraufhin in einer Entwicklung syntaktisch analysiert, wonach die Einrichtung zur syntaktischen Analyse von Köpfen ihre Aufmerksamkeit auf ein weiteres Paket richtet. Allerdings können in einer alternativen Ausführungsform an einem einzelnen Paket mehrere Operationen des Kopierens und/oder der syntaktischen Analyse ausgeführt werden. Insbesondere kann in einer ersten Entwicklung ein Anfangskopfabschnitt des Pakets in die Einrichtung 106 zur syntaktischen Analyse von Köpfen kopiert und durch sie syntaktisch analysiert werden, wonach ein weiterer Kopfabschnitt in die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 umfangreiche Köpfe selbst dann 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 zur syntaktischen Analyse 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 eine Einrichtung zur syntaktischen Analyse von Köpfen einen Kopfabschnitt eines Pakets, das in einer Netzschnittstellenschaltung von einem Netz empfangen worden ist, syntaktisch analysieren kann. In dieser Implementierung ist die Einrichtung 106 zur syntaktischen Analyse von Köpfen für das syntaktische Analysieren von Paketen, die mit einer Menge im Voraus gewählter Protokolle (oder Protokollstapel) in Übereinstimmung 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 die Einrichtung zur syntaktischen Analyse von Köpfen 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 gemeinsam (z. B. eher als seriell) durch ihren Protokollstapel verarbeitet werden.
In einer weiteren Ausführungsform der Erfindung werden die von der Einrichtung zur syntaktischen Analyse von Köpfen 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 Einrichtungen zur syntaktischen Analyse von Köpfen 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 Verfahren der Einrichtung zur syntaktischen Analyse von Köpfen 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 Algorithmus zur syntaktischen Analyse für dieses Paket abgeschlossen werden. Da die Protokolle, gemäß denen ein Paket formatiert worden ist, in dem vorliegenden Verfahren nur dadurch festgestellt werden können, dass bestimmte Kopffeldwerte untersucht werden, kann die Feststellung, dass ein Paket nicht mit der gewählten Menge von Protokollen in Übereinstimmung 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 eine Einrichtung zur syntaktischen Analyse von Köpfen syntaktisch analysiert werden können), sind dem Fachmann auf dem Gebiet gut bekannt und sind mit großer 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 der syntaktischen Analyse 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 die Einrichtung zur syntaktischen Analyse von Köpfen 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, wobei ihre 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 Operationen zur syntaktischen Analyse 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. Wie der Fachmann auf dem Gebiet erkennt, können diese zwei Bytes je nachdem, welches Protokoll die Schicht zwei des Protokollstapels des Pakets bildet, 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 festzustellen, ob er einen VLAN-markierten Schicht-Zwei-Protokollkopf enthält. Beispielhaft hängt diese Feststellung 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 reflektieren. 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 festgestellt 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 die Einrichtung zur syntaktischen Analyse von Köpfen 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 festzustellen, ob es ein Jumbo-Ethernet-Rahmen ist. Diese Feststellung würde wahrscheinlich vor der Entscheidung vorgenommen, ob der Schicht-Zwei-Kopf mit dem Ethernet oder mit dem 802.3-Ethernet in Übereinstimmung ist. Beispielhaft kann die Feststellung 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-Typ-feld gelesen und die Prozedur im Zustand 412 fortgesetzt. Falls die Werte nicht übereinstimmen, ist das Paket nicht mit den angegebenen Protokollen in Übereinstimmung, 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 Zeigerstelle kann zur späteren Verwendung beim schnellen Identifizieren des Beginns des Kopfs gesichert werden. Nun ist bekannt, dass das Paket mit einem akzeptierten Schicht- Zwei-Protokoll (z. B. mit dem herkömmlichen Ethernet, mit dem Ethernet mit VLAN-Markierung oder mit dem 802.3-Ethernet mit LLC-SNAP) in Übereinstimmung 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 die Einrichtung zur syntaktischen Analyse von Köpfen verarbeitet, die mit dem IP-Protokoll in Übereinstimmung 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 Übereinstimmung 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 veranschau lichte Prozedur zum Zustand 422 vor.
Im Zustand 418 wird die Übereinstimmung 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 Feld des nächsten Kopfs 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 festgestellt, 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 Feld des nächsten Kopfs 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 festgestellt 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 Operation zur syntaktischen Analyse 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 mehreren 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. Wie in einem späteren Abschnitt zu sehen ist, signalisieren diese Merker in einer Ausführungsform der Erfindung 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 reflektieren. 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 (beispielhaft das Ende des Datenabschnitts des Pakets) ebenfalls gesichert werden kann. Durch Multiplizieren des Wertes 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 gegenwärtig 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 Raum des Flussschlüssels zu füllen.
Im Zustand 428 wird ein Steuerungs- oder Statusindikator zusammengesetzt, um verschiedene Informationen an eines oder an mehrere Module der NIC 100 zu liefern. In einer Ausführungsform der Erfindung enthält ein Steuerindikator die TCP-Folgenummer des Pakets, einen Merker oder Identifizierer (z. B. eines oder meh rere 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 überschreitet, 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 anderes 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 festgestellt wird, dass ein Kopfabschnitt, der durch eine Einrichtung zur syntaktischen Analyse von Köpfen syntaktisch analysiert wird, nicht mit den oben identifizierten im Voraus gewählten Protokollstapeln in Übereinstimmung 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 dass die oben und in den folgenden Abschnitten 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 Blockbildungsverarbeitung 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 gegenwärtig vom IPP-Modul 104 gehaltene Paket (z. B. das, das gerade durch die Einrichtung zur syntaktischen Analyse von Köpfen verarbeitet wird) mit keinem der im Voraus gewählten Protokollstapel in Übereinstimmung 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 festzustellen, von dem die Prüfsummenoperation beginnen soll. Nach dem Zustand 430 endet die Prozedur mit dem Endzustand 432.
Nach der syntaktischen Analyse eines Pakets kann die Einrichtung zur syntaktischen Analyse von Köpfen 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 die Lastverteilungseinrichtung 112 und an die Steuerwarteschlange 118 und/oder an die Paketwarteschlange 116 geliefert. Beispielhaft wird der Steuerindikator 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 Steuerwareschlange 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.
Wie in einem folgenden Abschnitt diskutiert wird, werden die Pakete in der veranschaulichten Ausführungsform der Erfindung in dem Host-Computersystem (z. B. durch ihre jeweiligen Protokollstapel) weiter verarbeitet, obgleich ein empfangenes Paket in der NIC 100 (z. B. durch die Einrichtung 106 zur syntaktischen Analyse von Köpfen) syntaktisch analysiert wird. 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 zur dynamischen syntaktischen Analyse von Köpfen in einer Ausführungsform der Erfindung
In einer Ausführungsform der vorliegenden Erfindung analysiert die Einrichtung 106 zur syntaktischen Analyse von Köpfen ein von einem Netz empfangenes Paket gemäß einer dynamischen Befehlsfolge. Die Befehle können im Befehlsspeicher (z. B. RAM, SRAM, DRAM, Flash) der Einrichtung zur syntaktischen Analyse von Köpfen 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 Befehlen zur syntaktischen Analyse zur Speicherung in dem Speicher der Einrichtung zur syntaktischen Analyse von Köpfen herunterladen.
Die Anzahl und das Format der in einem Befehlsspeicher der Einrichtung zur syntaktischen Analyse von Köpfen 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 festgestellt werden, werden verschiedene wie in den folgenden Abschnitten beschriebene 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 gemeinsam als seriell verarbeitet werden. Außerdem kann die Verarbeitung der Pakete aus verschiedenen Datagrammen durch einen Mehrprozessor-Host-Computer unter den Prozessoren gemeinsam ausgeführt oder verteilt werden. Somit ist es ein Ziel einer dynamischen Operation zur syntaktischen Analyse von Köpfen, ein Protokoll zu identifizieren, in Übereinstimmung mit dem ein empfangenes Paket formatiert worden ist, oder festzustellen, ob ein Paketkopf mit einem besonderen Protokoll in Übereinstimmung ist.
Die in Kürze ausführlich diskutierte 23 stellt eine beispielhafte Reihe von Befehlen zur syntaktischen Analyse der Schicht-Zwei-, Schicht-Drei- und Schicht-Vier-Köpfe eines Pakets dar, um festzustellen, ob sie Ethernet, IP oder TCP sind. Die veranschaulichten Befehle enthalten ein mögliches Programm oder einen möglichen Mikrocode zum Ausführen einer Operation zur syntaktischen Analyse. Wie der Fachmann auf dem Gebiet erkennt, können eine Anzahl verschiedener Programme zusammengesetzt werden, nachdem ein besonderer Satz von Befehlen zur syntaktischen Analyse in einen Speicher der Einrichtung zur syntaktischen Analyse geladen worden ist. Somit stellt 23 lediglich eines aus einer Anzahl von Programmen dar, die aus den gespeicherten Befehlen erzeugt werden können. Die in 23 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 zur syntaktischen Analyse 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 festzustellen, 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 Wertes mit dem für das Protokoll erwarteten Wert kann das Mikroprogrammwerk feststellen, ob das Paket mit dem Ethernet-Protokoll in Übereinstimmung zu sein scheint. Beispielhaft hängt der nächste in dem Programm zur syntaktischen Analyse 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 mit diesem Protokoll in Übereinstimmung ist. Wie für den Fachmann auf dem Gebiet klar ist, kann ein Kommunikationsprotokoll recht verschieden von einem anderen Protokoll sein und somit für verschiedene Protokolle die Untersuchung verschiedener Teile der Paketköpfe erfordern. Beispielhaft kann die syntaktische Analyse eines Pakets im Fall eines Fehlers oder da festgestellt wurde, dass das Paket, das syntaktisch analysiert wird, nicht mit dem Protokoll bzw. mit den Protokollen, für das/die die Befehle festgestellt worden ist/sind, in Übereinstimmung ist, enden.
Jeder Befehl in 23 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 die syntaktische Analyse 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 23 eine Ausgabeoperation identifizieren, die je nach dem Erfolg oder Misserfolg des Vergleichs eines aus dem Paket extrahierten Wertes 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 der syntaktischen Analyse 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 die syntaktische Analyse beginnt. Beispielhaft wird der Zeiger durch das Paket inkrementiert, während die Prozedur zur syntaktischen Analyse 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 23 gezeigten Programm zur syntaktischen Analyse 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 gemeinsam (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 23 veranschaulichten Ausführungsform der Erfindung enthält ein in den Befehlsspeicher der Einrichtung zur syntaktischen Analyse von Köpfen 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 2300 wird aus dem Befehlssatz erzeugt. Somit ist das Programm 2300 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 2300 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 Programm oder Mikrocode zur syntaktischen Analyse 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 2300 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 Wertes 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 in einem früheren Abschnitt diskutierten Steuerindikator enthalten, um zu identifizieren, ob ein Paket für die Datenwiederzusammensetzung, für die Paketblockbildung, für die Lastverteilung oder für andere verbesserte Funktionen der NIC 100 geeignet ist. Insbesondere kann ein Steuerindikator 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_AP-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. Wie der Fachmann auf dem Gebiet erkennt, kann der Schicht-Drei-Kopf eines Pakets sofort auf sein Schicht-Zwei-Ethertype-Feld folgen, falls das Paket mit dem Ethernet- und mit dem IP-Protokoll in Übereinstimmung ist.
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 Feststellung 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 der syntaktischen Analyse 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 Wertes 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 Stelle 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.
Der Fachmann auf dem Gebiet erkennt, dass die den oben und anderswo in diesem Abschnitt beschriebenen Operationen und Registern zugewiesenen Bezeichnungen dem Wesen nach lediglich beispielhaft sind und die Operationen und Befehle zur syntaktischen Analyse, die in anderen Ausführungsformen der Erfindung verwendet werden können, in keiner Weise beschränken.
Die Befehle im Programm 2300 enthalten ein Befehlsnummernfeld 2302, das eine Nummer eines Befehls innerhalb des Programms enthält, und ein Befehlsnamenfeld 2304, das einen Namen eines Befehls enthält. In einer alternativen Ausführungsform der Erftindung können das Befehlsnummernfeld und das Befehlsnamenfeld verschmolzen sein oder kann eines von ihnen weggelassen sein.
Das Befehlsinhaltsfeld 2306 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. von der momentanen Stelle 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 Wertes mit Nullen aufgeführt. Für den Fachmann auf dem Gebiet ist klar, dass das Format einer Extraktionsmaske (oder einer im Folgenden beschriebenen Ausgabemaske) bei Bedarf so angepasst werden kann, dass es die Little-Endian- oder die Big-Endian-Darstellung reflektiert.
Einer oder mehrere Befehle in einem Programm zur syntaktischen Analyse 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 Wertes aus maskiert ist, obgleich weiter ein Zwei-Byte-Wert von der Zeigerstelle 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 zu speichern ist. 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 2300, 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 2300 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 festgestellt worden ist, dass das Paket mit einem gewählten Protokoll in Übereinstimmung oder nicht in Übereinstimmung ist, kann die syntaktische Analyse aufhören oder ein Befehl zum Anhalten der Prozedur zur syntaktischen Analyse 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 die syntaktische Analyse für das vorliegende Paket abzuschließen ist. Andernfalls kann ein DONE-Befehl wie der Befehl achtzehn aus dem Programm 2300 eine gewisse Aktion ausführen, um (z. B. durch Initialisieren eines Registers) auf ein neues Paket zu warten.
Die verbleibenden Abschnitte des Befehlsinhaltsfelds 2306 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 2300 eine der sechzehn oben beschriebenen Operationen. Die im Programm 2300 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 2300 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 Stelle des Zeigers der syntaktischen Analyse angewendet, bevor der Zeiger wie durch den anwendbaren Erfolgsversatz oder Misserfolgsversatz angegeben vorgerückt wird. Die im Programm 2300 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 reflektieren. Da das Programm 2300 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) reflektieren 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 Wertes 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 23 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 23 nur ein Verfahren der syntaktischen Analyse eines Pakets, um festzustellen, ob es mit einem besonderen Kommunikationsprotokoll in Übereinstimmung 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. Wie für den Fachmann auf dem Gebiet klar ist, können die Befehle zur syntaktischen Analyse eines Pakets 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 23 die Befehle im Programm 2300 ausführlich beschrieben werden. Vor der Ausführung des in 23 gezeigten Programms befindet sich ein Zeiger der syntaktischen Analyse am Beginn des Schicht-Zwei-Kopfs eines Pakets. Die Stelle des Zeigers der syntaktischen Analyse kann zur leichten Bezugnahme und Aktualisierung während der Prozedur zur syntaktischen Analyse in einem Register gespeichert sein. Insbesondere kann die Stelle des Zeigers der syntaktischen Analyse als ein Versatz (z. B. vom Beginn des Schicht-Zwei-Kopfs) beim Berechnen der Stelle einer besonderen Stelle innerhalb eines Kopfs verwendet werden.
Das Programm 2300 beginnt mit einem WAIT-Befehl (z. B. mit 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 (wenn z. B. 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 Steuerindikatoren (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 2300 verwendet werden, um verschiedene Köpfe und Kopffelder zu verfolgen. Der Fachmann auf dem Gebiet erkennt die Anzahl möglicher Kombinationen von Kommunikationsprotokollen und die Wirkung dieser verschiedenen Kombinationen auf die Struktur und das Format der Köpfe eines Pakets. Von einem Paket, das mit einem Protokoll oder mit einer Menge von Protokollen in Übereinstimmung ist, können mehr Informationen zu untersuchen oder zu sammeln sein als von einem Paket, das mit einem anderen Protokoll oder mit einer anderen Menge von Protokollen in Übereinstimmung 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 gehalten 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 Stelle 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. Wie in dem vorigen Abschnitt beschrieben wurde, kann ein Steuerindikator 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 überschreitet. 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 in anderen Abschnitten beschriebenen Verarbeitungsverbesserungen geeignet, wobei die Prozedur zur syntaktischen Analyse 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 festzustellen, 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 mit dem 802.3-Ethernet-Protokoll in Übereinstimmung 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 Prozedur zur syntaktischen Analyse 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 festzustellen, 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 2300 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 gegenwärtig 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 gegenwärtig 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 Stelle 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 festzustellen, 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 in anderen Abschnitten beschriebenen 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. Der Fachmann auf dem Gebiet erkennt, dass dieser Binärwert (z. B. 111110) verwendet werden kann, 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 vorangegangenen 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 festzustellen, 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). Der Fachmann auf dem Gebiet erkennt, dass die Schicht-Drei- und Schicht-Vier-Köpfe des Pakets mit IP (Version vier) bzw. TCP in Übereinstimmung sein müssen, damit der Vergleich im IPV4_4-Befehl erfolgreich ist. 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 Zeigerstelle 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 Zeigerstelle 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. Wir für den Fachmann auf dem Gebiet klar ist, enthält das Gesamtlängenfeld (z. B. die IP-Segmentgröße) eines Kopfs des IP, Version vier, 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 Feld des nächsten Kopfs 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 Zeigerstelle 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 Feld des nächsten Kopfs untersucht, um festzustellen, 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 Feld des nächsten Kopfs 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 gegenwärtigen Stelle des Zeigers befindet. Somit wird der negative Versatz zu der gegenwärtigen Zeigerstelle 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 Stelle 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 der syntaktischen Analyse 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 die in anderen Abschnitten beschriebenen Verbesserungen 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 Zeigerstelle 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).
Wie der Fachmann auf dem Gebiet erkennen kann, muss der aus dem Kopflän genfeld extrahierte Wert in der veranschaulichten Ausführungsform möglicherweise angepasst werden, um die Verwendung von Zwei-Byte-Einheiten (z. B. Sechzehn-Bit-Wörtern) zu reflektieren. 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. Wie in einem späteren Abschnitt beschrieben wird, 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. dem Wert in dem ADDR-Register) minus zwei Bytes – was 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 vorangegangenen 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 der syntaktischen Analyse eines Pakets an, wenn festgestellt wird, dass das Paket nicht mit einem oder mit mehreren der Protokolle, die den veranschaulichten Befehlen zugeordnet sind, in Übereinstimmung 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.
Der Fachmann auf dem Gebiet erkennt, dass das veranschaulichte Programm oder der veranschaulichte Mikrocode nur ein Verfahren der syntaktischen Analyse eines Pakets zeigt. 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 in den folgenden Abschnitten beschriebenen verbesserten Verarbeitung realisiert werden können, gleichen die zu syntaktischen Analyse eines Pakets mit dem veranschaulichten Programm erforderliche Zeit mehr als aus. Auch wenn eine Einrichtung zur syntaktischen Analyse von Köpfen ein Paket in einer NIC in einer momentanen Ausführungsform der Erfindung syntaktisch 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 zu halten, die die Kommunikationsflüsse durch die NIC 100 betreffen. Wie der Fachmann auf dem Gebiet erkennt, ermöglicht die Struktur eines CAM 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 Blockbildungsverarbeitung von Paketköpfen und weitere Verbesserungen. Diese Funktionen sind in anderen Abschnitten ausführlich diskutiert, können aber 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 Blockbildungsverarbeitung von Paketköpfen hat eher die gemeinsame 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 gemeinsame 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 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 zwi schen 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 reflektieren, die durch die Protokolle, die durch die Einrichtung zur syntaktischen Analyse von Köpfen syntaktisch analysiert werden, und durch die Informationen, die zum Identifizieren von Kommunikationsflüssen verwendet werden, festgestellt werden können.
In der veranschaulichten Ausführungsform enthält der assoziierte Abschnitt 504 einen Flussgültigkeitsindikator 520, eine Flussfolgenummer 522 und einen Flussaktivitätsindikator 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ültigkeitsindikator 520 an, ob der assoziierte Fluss gültig oder ungültig ist. Beispielhaft wird der Flussgültigkeitsindikator 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ültigkeitsindikator 520 als ungültig gekennzeichnet werden. Außerdem kann der Flussgültigkeitsindikator 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ültigkeitsindikator 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. Wie der Fachmann auf dem Gebiet erkennt, identifiziert die TCP-Folgenummer eines Pakets die Stelle 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ätsindikator 524 reflektiert 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 dem Flussaktivitätsindikator 524 ein Zähler wie etwa ein (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ätsindikatorfeld 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 enthalten (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ätsindikatoren verschiedener Flüsse zu aktualisieren.
Da nicht immer festgestellt werden kann, wann ein Kommunikationsfluss geendet hat (z. B. kann das letzte Paket verloren gegangen sein), kann der Flussaktivitätsindikator 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ültigkeitsindikator 520 für jede Flussnummer gesetzt ist), wenn das erste Paket eines neuen Flusses empfangen wird, kann der Fluss mit dem niedrigsten Flussaktivitätsindikator 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ültigkeitsindikator 520, die Flussfolgenummer 522 und der Flussaktivitätsindikator 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ültigkeitsindikator 520 und der Flussaktivitätsindikator 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen syntaktisch einen Kopfabschnitt des Pakets. Wie in einem früheren Abschnitt beschrieben wurde, setzt die Einrichtung zur syntaktischen Analyse von Köpfen 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ültigkeitsindikator 520 so gesetzt, dass er einen gültigen Fluss anzeigt, wobei die Flussfolgenummer 522 aus der (beispielhaft von der Einrichtung zur syntaktischen Analyse von Köpfen gelieferten) TCP-Folgenummer abgeleitet wird und der Flussaktivitätsindikator 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 van 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ätsindikator 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ätsindikator 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ätsindikator 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ätsindikator haben.
Beim Empfang und bei der syntaktischen Analyse eines späteren bei 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ültigkeitsindikator 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ültigkeitsindikator einen gültigen Fluss anzeigt. Bei einem CAM wie etwa der FDB 110 in 5 können Flussschlüssel und Flussgültigkeitsindikator parallel durchsucht werden.
Falls ein späteres Paket den nächsten Datenabschnitt für einen früheren 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ätsindikator 524 inkrementiert wird, um diese jüngste Aktivität zu reflektieren. Der Flussgültigkeitsindikator 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 ungültig gemacht. In einer Ausführungsform der Erfindung wird der Flussgültigkeitsindikator 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 gehalten 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 in dieser Ausführungsform der Flussgültigkeitsindikator 520 ein Bit, sind der Flussfolgenummer 522 vier Bytes zugeordnet und sind dem Flussaktivitätsindikator 524 ebenfalls vier Bytes zugeordnet.
Wie der Fachmann auf dem Gebiet aus den oben beschriebenen Ausführungsformen erkennt, ist ein Fluss ähnlich, aber nicht gleich, einer Ende-Ende-TCP-Verbindung. Eine TCP-Verbindung kann für eine verhältnismäßig verlä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 Blockbildungsverarbeitung 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 gegenwärtig 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 für 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 (wenn der Eintrag des Flusses z. B. 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 Paketblockbildung (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 für ein durch die NIC 100 empfangenes Paket einen Operationscode erzeugt. Außerdem baut der FDBM 108 einen Fluss ab (ersetzt, entfernt oder macht er auf andere Weise z. B. einen Eintrag in der FDB 110 ungültig), wenn der Fluss abgeschlossen oder abgebrochen wird.
In einer Ausführungsform der Erfindung reflektiert 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, Blockbildungsverarbeitung von Paketköpfen, Lastverteilung). Mit anderen Worten, je nach dem Operationscode eines Pakets können andere Module der NIC 100 eine dieser Funktionen, wie sie in den folgenden Abschnitten beschrieben werden, 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 von der Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen oder ein anderes Modul der NIC 100 den FDBM 108 über ein neues Paket, indem sie 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 festzustellen, 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 die Einrichtung zur syntaktischen Analyse von Köpfen wie in einem früheren Abschnitt feststellt, 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, Blockbildungsverarbeitung, Lastausgleich) für das Paket nicht bereitgestellt werden können.
Im Zustand 604 stellt der FDBM 108 fest, 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ültigkeitsindikator wie etwa den (in 5 gezeigten) Flussgültigkeitsindikator 520 reflektiert werden. Falls im Zustand 608 festgestellt 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ültigkeitsindikator 520, die Flussfolgenummer 522 und den Flussaktivitätsindikator 524 (die in 5 gezeigt sind).
Im Zustand 612 stellt der FDBM 108 aus den von der Einrichtung 106 zur syntaktischen Analyse von Köpfen empfangenen Informationen fest, 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 stellt der Flussdatenbankmanager fest, ob das Paket einen Versuch zum Zurücksetzen einer Kommunikationsverbindung oder eines Kommunikationsflusses bildet. Beispielhaft kann dies dadurch festgestellt 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 durch die Einrichtung zur syntaktischen Analyse von Köpfen der Wert eines oder mehrerer Steuer- oder Merkerbits (wie etwa des SYN-Bits) an den FDBM geliefert. Wie der Fachmann auf dem Gebiet erkennt, kann eine TCP-Entität 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 zu 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. Wie in einem früheren Abschnitt diskutiert wurde, 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 stellt der FDBM 108 fest, 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 es somit möglich macht, dass eine oder mehrere der von der NIC 100 angebotenen Funktionen (z. B. Datenwiederzusammensetzung, Blockbildungsverarbeitung, 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 stellt der Flussdatenbankmanager fest, 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 stellt der FDBM im Zustand 620 fest, ob dieses Paket der letzte Datenabschnitt für das Datagramm dieses Flusses zu sein scheint. Beispielhaft erfolgt diese Feststellung anhand der bei dem vorliegenden Paket enthaltenen Datenmenge. Wie für den Fachmann auf dem Gebiet klar ist, wird ein Datagramm, das mehr Daten enthält, als in einem Paket übermittelt werden können, ü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 von der Einrichtung 106 zur syntaktischen Analyse von Köpfen empfangen werden. In diesen Informationen kann eine Angabe der Größe der durch ein Paket übermittelten Daten enthalten sein. Insbesondere ist die Einrichtung 106 zur syntaktischen Analyse von Köpfen in einer Ausführungsform der Erfindung so konfiguriert, dass sie 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 stellt der Flussdatenbankmanager 108 im Zustand 620 fest, 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 angebotene Funktionen geeignet ist. Insbesondere ist das Paket geeignet für eine oder mehrere der oben diskutierten Funktionen formatiert worden. Der FDBM 108 hat festgestellt, 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ätsindikator (z. B. der Flussaktivitätsindikator 524 aus 5) für diesen Fluss wird modifiziert, um die jüngste Flussaktivität zu reflektieren. In einer Ausführungsform der Erfindung ist der Flussaktivitätsindikator 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ätsindikator 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ätsindikator oder -zähler inkrementiert worden ist, wird er in der veranschaulichten Ausführungsform untersucht, um festzustellen, ob er auf null "übergelaufen" ist (d. h., ob er über seinen Maximalwert hinaus inkrementiert worden ist). Wenn das der Fall ist, werden der Zähler und/oder die Flussaktivitätsindikatoren für jeden Eintrag in der Flussdatenbank 110 auf null gesetzt und wird der Aktivitätsindikator des momentanen Flusses noch einmal inkrementiert. Somit veranlasst in einer Ausführungsform der Erfindung der Überlauf eines Flussaktivitätszählers oder -indikators die Neuinitialisierung des Flussaktivitätsmechanismus für die Flussdatenbank 110. Anschließend wird der Zähler inkrementiert und werden die Flussaktivitätsindikatoren wie zuvor beschrieben noch einmal aktualisiert. Der Fachmann auf dem Gebiet erkennt, dass es viele weitere geeignete Verfahren gibt, die in einer Ausführungsform der vorliegenden Erfindung angewendet werden können, 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 festgestellt, 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. Der Fachmann auf dem Gebiet erkennt, dass anstelle des hier beschriebenen Schemas andere geeignete Verfahren verwendet werden können, um sicherzustellen, dass die Daten in der richtigen Reihenfolge empfangen werden.
Schließlich wird der Flussgültigkeitsindikator 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 Ungültigmachen eines Flusses in der Flussdatenbank 110. Das Wiederzusammensetzen von Daten wird in einem folgenden Abschnitt diskutiert, der die DMA-Maschine 120 beschreibt.
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 mit einem oder mit mehreren der im Voraus gewählten Protokolle in Übereinstimmung 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 festgestellt 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ültigkeitsindikator 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 Kommunikationsflusses/einer 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ültigkeitsindikator 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 festgestellt 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 stellt der Flussdatenbankmanager 108 fest, ob erwartet wird, dass weitere Daten folgen. Wie in Verbindung mit dem Zustand 620 erläutert wurde, kann diese Feststellung anhand von Steuerinformationen erfolgen, die durch den Flussdatenbankmanager von der Einrichtung 106 zur syntaktischen Analyse von Köpfen empfangen werden. Falls weitere Daten erwartet werden (falls z. B die Datenmenge in dem Paket gleich einem 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ültigkeitsindikators 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen) 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ätsindikator aktualisiert (z. B. inkrementiert). Wie in Verbindung mit dem Zustand 622 erläutert worden ist, werden die Aktivitätsindikatoren für alle Flüsse in der Datenbank auf null gesetzt und wird der vorhandene Fluss erneut inkrementiert, falls der Flussaktivitätsindikator überläuft. Schließlich wird der Flussgültigkeitsindikator 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 Kommunikationsflusses/einer 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 festgestellt 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 stellt der Flussdatenbankmanager 108 fest, ob einer oder mehrere durch die Einrichtung zur syntaktischen Analyse von Köpfen 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, Blockbildungsverarbeitung, 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ültigkeitsindikators 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ätsindikator 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ätsindikatoren in der Datenbank auf null gesetzt und wird der momentane Fluss erneut inkrementiert, falls der Aktivitätsindikator überläuft. Der Gültigkeitsindikator 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 stellt der FDBM 108 fest, 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ültigkeitsindikator (z. B. der Flussgültigkeitsindikator 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ültigkeitsindikator gleich null ist) festgestellt. 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 festgestellt. Wie oben diskutiert wurde, wird in der veranschaulichten Ausführungsform der Erfindung jedes Mal, wenn Daten für einen Fluss empfangen werden, ein Aktivitätsindikator des Flusses (z. B. der Flussaktivitätsindikator 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ätsindikator identifiziert werden. Falls die Flussaktivitätsindikator mehrerer Flüsse auf einen gemeinsamen Wert (z. B. null) gesetzt sind, kann beispielhaft eine Flussnummer von ihnen zufällig oder durch gewisse andere Kriterien gewählt werden. Nach dem Zustand 650 wird die Prozedur im Zustand 652 fortgesetzt.
Im Zustand 652 stellt der Flussdatenbankmanager 108 fest, ob das Paket Daten enthält. Beispielhaft zeigen die durch die Einrichtung zur syntaktischen Analyse von Köpfen 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 stellt der Flussdatenbankmanager 108 fest, 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 Feststellung 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, Blockbildungsverarbeitung, 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ätsindikators (z. B. des Flussaktivitätsindikators 524 aus 5) enthalten. In einer Ausführungsform der Erfindung umfasst diese Initialisierung das Speichern eines Wertes, 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ätsindikatoren gelöscht oder zurückgesetzt, falls der Zähler oder ein Flussaktivitätsindikator über seinen maximal speicherbaren Wert hinaus inkrementiert wird. Außerdem wird im Zustand 660 ein Gültigkeitsindikator (z. B. der Flussgültigkeitsindikator 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ätsindikator des vorhandenen Flusses (z. B. der Flussaktivitätsindikator 524) ersetzt. Zum Beispiel kann der Wert eines Flussaktivitätszählers wie oben diskutiert in den Flussaktivitätsindikator kopiert werden. Daraufhin wird der Gültigkeitsindikator des Flusses (z. B. der Flussgültigkeitsindikator 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, Blockbildungsverarbeitung, 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 es somit möglich macht, dass eine der durch die NIC 100 gebotenen Funktionen für dieses Paket ungeeignet ist.
Wie 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.
Für den Fachmann auf dem Gebiet ist klar, dass die in den 6A–6E veranschaulichte und oben diskutierte Prozedur nur eine geeignete Prozedur zum Halten und Aktualisieren einer Flussdatenbank und zum Feststellen der Eignung eines Pakets für bestimmte Verarbeitungsfunktionen ist. 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 feststellen, dass das Paket ein Jumbo-Paket ist, und somit den vorgegebenen Code zuweisen. Beispielhaft führen die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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.
TABELLE 1
Eine Ausführungsform einer Lastverteilungseinrichtung
In einer Ausführungsform der Erfindung ermöglicht die Lastverteilungseinrichtung 112, die Verarbeitung der Pakete durch ihre Protokollstapel auf eine Anzahl von Prozessoren zu verteilen. Beispielhaft erzeugt die Lastverteilungseinrichtung 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 Hochgeschwindigkeitsnetzes ü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.
Wie für den Fachmann auf dem Gebiet klar ist, ist die einfache Verteilung der Pakete auf Prozessoren in einer Menge von Prozessoren (z. B. wie etwa in einem Round-Robin-Schema) 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 eine Einrichtung zur syntaktischen Analyse von Köpfen 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen syntaktisch analysiert (wobei ein Verfahren zur syntaktischen Analyse eines Pakets in einem früheren Abschnitt beschrieben ist). Im Zustand 704 empfängt die Lastverteilungseinrichtung 112 den Flussschlüssel des Pakets, der durch die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 die Anpassungsschicht 5 (AAL 5) der ATM (asynchrone Übermittlung) 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 die Lastverteilungseinrichtung 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 die Lastverteilungseinrichtung 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. Wie in einem folgenden Abschnitt beschrieben wird, ist in einer Ausführungsform der Erfindung 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 empfangen 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 erzeugt 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 Solaris^TM-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 (wenn z. B. 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 ge speichert worden ist, zu verarbeiten. Verfahren zur Verarbeitung eines Pakets durch seinen Protokollstapel sind dem Fachmann auf dem Gebiet gut bekannt und brauchen 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 eine Lastverteilungseinrichtung eher als ein Befehlssatz (z. B. als Software) als als ein Hardware-Modul implementiert. Wie dem Fachmann auf dem Gebiet bewusst ist, ist ATM-Verkehr 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 die Lastverteilungseinrichtung 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.
Wie der Fachmann auf dem Gebiet erkennt, kann dies allerdings 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-Computers 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 ist für den Fachmann auf dem Gebiet klar, dass zum Zuweisen der Pakete eines Flusses zu einem Prozessor und zum Liefern dieser Pakete an den Prozessor viele alternative Prozeduren verwendet werden können.
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 zufällig angenommene Daten oder Daten mit einem ange gebenen 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 Indikator, dass für das Paket eine Prüfsumme berechnet oder nicht berechnet wurde, einen Indikator, 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 Indikatoren 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen gespeichert werden. Schließlich können Abschnitte der Diagnose/Status-Informationen 808 durch eines oder mehrere des IPP-Moduls 104, der Einrichtung 106 zur syntaktischen Analyse von Köpfen, des Flussdatenbankmanagers 108, der Lastverteilungseinrichtung 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. Wie in einem nachfolgenden Abschnitt erläutert wird, 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 Blockbildungsverarbeitung 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 vorangegangenen 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 vorangegangenen Abschnitt beschriebene No_Assist-Signal 904 zeigt an, ob das Paket mit irgendeinem Protokoll aus einer Menge im Voraus gewählter Protokolle, die durch die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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 festzustellen, 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 Feststellung 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. Wie in einem früheren Abschnitt beschrieben wurde, kann ein Operationscode 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 Indikator enthalten, ob die Größe des Pakets einen ersten Schwellenwert überschreitet (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 Indikatoren 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 gemeinsam 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. Wie in einem späteren Abschnitt beschrieben wird, werden den Einträgen in der Steuerwarteschlange entnommene Informationen durchsucht, um fesizustellen, 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 ein Paket an den Host-Computer übertragen werden soll. Wenn das der Fall ist, wird der Host-Computer gewarnt, so dass die Protokollköpfe von den verwandten Paketen gemeinsam 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 die Lastverteilungseinrichtung 112 in der Steuerwarteschlange gespeichert werden und kann das No_Assist-Signal 904 durch die Einrichtung 106 zur syntaktischen Analyse von Köpfen gespeichert werden. Der Operationscode 906 kann durch den Flussdatenbankmanager 108 gespeichert werden und der Nutzinformationsversatz 908 und die Nutzinformationsgröße 910 können durch die Einrichtung 106 zur syntaktischen Analyse von Köpfen gespeichert werden. Abschnitte weiterer Sta tusinformationen können durch die vorstehenden Module und/oder durch andere wie etwa durch das IPP-Modul 104 und durch 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 gemeinsam (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. Die Einrichtung 106 zur syntaktischen Analyse von Köpfen 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ößeindikator, 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 Paketblockbildungsmodul 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 an 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 auf 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 gehalten wird, werden leere Puffer identifiziert, in denen Pakete gespeichert werden können. Wie dem Fachmann auf dem Gebiet bewusst ist, 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 hä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). 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.
Wie dem Fachmann auf dem Gebiet klar ist, bedeutet die Aufnahme einer begrenzten Anzahl von Deskriptoren in den Frei-Deskriptor-Ring (z. B. in dieser Ausführungsform 8192), dass sie auf Round-Robin-Weise wieder verwendet werden können. In der gegenwärtig 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-Deskrip tors 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 mit einem im Voraus gewählten Protokoll (z. B. mit einem Protokoll, das durch die Einrichtung 106 zur syntaktischen Analyse von Köpfen syntaktisch analysiert werden kann) in Übereinstimmung 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 festgestellt werden, die von der Steuerwarteschlange oder von dem Flussdatenbankmanager wiedergewonnen werden. Wie schon zuvor beschrieben wurde, kann insbesondere ein Operationscode verwendet werden, um festzustellen, 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-)Nichtwiederzusammensetzungspufter 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 Nichtwiederzusammensetzungspuftern. 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 Zelle oder das Element des Datenfelds 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 Stelle 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 Element des Datenfelds wieder und greift auf den angegebenen Puffer zu, um ein in dem Puffer gespeichertes Paket aufzufinden. Wie für den Fachmann auf dem Gebiet klar ist, kann das Identifizieren von Speicherpuffern in Abschluss-Deskriptoren durch die Stellen der Puffer in einem Datenfeld freier Puffer 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 Raum. 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, stellt das dynamische Paketblockbildungsmodul 122 in einer Ausführungsform der Erfindung zu der Zeit, zu der ein Paket an den Host-Computer übertragen wird, fest, 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 gemeinsame Ü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, erst freigegeben zu werden, wenn 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, überschreiten 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 erzeugt.
11 enthält Diagramme beispielhafter 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 zu halten, 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. Wie in einem früheren Abschnitt beschrieben wurde, unterstützt eine Ausführungsform der Erfindung die Verschachtelung von bis zu vierundsechzig Flüssen. Somit hält die Flusswiederzusammensetzungs-Puffer-Tabelle 1004 in dieser Ausführungsform bis zu vierundsechzig Einträge. 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-Puffer-Index 1102, eine nächste Adresse 1104 und einen Gültigkeitsindikator 1106. Der Flusswiederzusammensetzungs-Puffer-Index 1102 enthält den Index oder die Stelle in einem Datenfeld freier Puffer oder in 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ültigkeitsindikator 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 Wiederzusammensetzungspufter des Puffers gespeichert wird, während er ungültig gemacht wird (z. B. einen zweiten Wert speichert), wenn der Puffer voll ist. Wenn ein Eintrag ungültig gemacht 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ültigkeitsindikator 1116. Ähnlich wie bei der Flusswiederzusammensetzungstabelle 1004 identifiziert der Kopfpufferindex 1112 die Zelle oder das Element in dem Datenfeld freier Puffer, die bzw. das einen Pufferidentifizierer für einen Kopfpuffer enthält. Die nächste Adresse 1114 identifiziert den 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ültigkeitsindikator 1116 zeigt an, ob die Kopfpuffertabelle und/oder der Kopfpuffer gültig sind. Dieser Indikator kann auf gültig gesetzt werden, wenn ein erstes Paket oder ein erster Kopf in einem Kopfpuffer gespeichert wird, während er ungültig gemacht 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-Puffer-Index 1122 identifiziert das Element des Datenfelds 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ültigkeitsindikator 1126 zeigt die Gültigkeit des Tabelleneintrags an. Der Gültigkeitsindikator 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-Puffer-Index 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ültigkeitsindikator 1136 zeigt die Gültigkeit des Tabelleneintrags ein. Beispielhaft wird der Gültigkeitsindikator 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ültigkeitsindikator 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ültigkeitsindikatoren 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 Zonen 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. zufällige 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. Wie für den Fachmann auf dem Gebiet klar ist, ermöglicht die Sechzehn-Byte-Ausrichtung 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 Nicht-wiederzusammensetzungspuffern 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 gemeinsam 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 Solaris^TM-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 Leitungsanforderungen 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 feststellen, zu welcher Kategorie ein Paket gehört und in welchem Puffertyp es zu speichern ist. Wie in einem früheren Abschnitt 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 beispielhaften 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. Paketblockbildung oder Lastverteilung) 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 beendet, reflektieren. 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 gehalten 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 wird 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 Ein trags verwendet werden kann, und ein Pufferidentifiziererfeld 1214. Somit speichert das Pufteridentifiziererfeld jedes Eintrags einen Pufferidentifizierer, 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 (wobei z. B. der Puffer, auf den er Bezug nimmt, zum Speichern eines Pakets verwendet werden kann), 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 Raum 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 gehalten. 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) Besitzindikator 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, MTV-Puffer). Der Datenpuffer-Index 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 er z. B. 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 gemeinsam verarbeitet werden können. In das Merker feld 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 gegenwärtig beschriebenen Ausführungsform der Erfindung kann der Deskriptortyp 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 Indexstelle 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 Fluss nummer 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. Wie in einem früheren Abschnitt beschrieben wurde, ist der Operationscode 1252 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. Verfahren zum Übertragen eines Pakets je nach seinem Operationscode werden ausführlich in dem folgenden Abschnitt beschrieben. 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 die Einrichtung 106 zur syntaktischen Analyse von Köpfen das Paket nicht umfassend syntaktisch analysieren kann, wobei das Paket in diesem Fall nicht die nachfolgenden Nutzen empfängt. Der Prozessoridentifizierer 1256, der durch die Lastverteilungseinrichtung 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 die Lastverteilungseinrichtung 112, die Last der Verarbeitung der Netzpakete auf mehrere Prozessoren zu teilen oder zu verteilen, indem sie 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 gegenwärtig beschriebenen Ausführungsform der Erfindung wird der Besitzindikator 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 Besitzindikatorfeld 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 Besitzindikator einen zweiten Wert (z. B. eins) speichern, der anzeigt, dass die NIC 100 den Deskriptor nun für ein weiteres Paket verwenden kann.
Der Fachmann auf dem Gebiet erkennt, dass es zahlreiche Verfahren gibt, 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 gehalten, 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, feststellen, wie viele Deskriptoren verwendet worden sind oder nicht verwendet worden sind.
Schließlich können in dem Weiteres-Feld 1266 weitere Informationen, Merker und Indikator 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, Datenpuffer-Index 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 Besitzindikator 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 Besitzindikator 1264 gegen das Ende eines Abschluss-Deskriptors anzuordnen, da der Indikator dazu ver wendet werden kann, die Host-Software zu informieren, wenn die DMA-Maschine das Bevölkern des Deskriptors abgeschlossen hat. Falls der Besitzindikator zu Beginn des Deskriptors angeordnet würde, könnte ihn die Software lesen und versuchen, den Deskriptor zu verwenden, bevor die DMA-Maschine das Schreiben in ihn abgeschlossen hat.
Der Fachmann auf dem Gebiet erkennt, dass zum Identifizieren von Speicherbereichen, in denen Pakete anzuordnen sind, die von einem Netz zu einem Host-Computer übertragen werden, andere als die in diesem Abschnitt beschriebenen Systeme und Verfahren implementiert werden können, ohne den Umfang der Erfindung zu überschreiten.
Verfahren zum Übertragen eines Pakets in einen Speicherpuffer durch eine DMA-Maschine
Die 13–20 sind Ablaufpläne, die Prozeduren zum Übertragen eines Pakets in einen Host-Speicherpuffer beschreiben. In diesen Prozeduren hilft der Operationscode eines Pakets festzustellen, in welchem Puffer oder in welchen Puffern das Paket gespeichert wird. Eine beispielhafte Auswahl von Operationscodes, die in dieser Prozedur verwendet werden können, ist in TABELLE 1 aufgeführt und erläutert.
Die veranschaulichten Ausführungsformen der Erfindung verwenden vier Kategorien von Host-Speicherpuffern, deren Größen programmierbar sind. Die Puffergrößen sind programmierbar, um sie an verschiedene Host-Plattformen anzupassen, wobei sie in gegenwärtigen Ausführungsformen aber so programmiert werden, dass sie eine Größe von einer Speicherseite haben, um die Effizienz der Behandlung und Verarbeitung von Netzverkehr zu verbessern. Zum Beispiel sind die in diesem Abschnitt diskutierten Ausführungsformen auf die Verwendung eines Host-Computersystems gerichtet, das einen SPARC^TM-Prozessor verwendet, so dass jeder Puffer eine Größe von acht Kilobytes hat. Allerdings werden diese Ausführungsformen leicht für Host-Computersysteme angepasst, die Speicherseiten mit anderen Abmessungen verwenden.
Ein Puffertyp dient zum Wiederzusammensetzen von Daten aus einem Fluss, während ein weiterer Typ für Köpfe von Paketen, die wieder zusammengesetzt werden, und für kleine Pakete (z. B. jene mit einer Größe kleiner oder gleich 256 Bytes), die nicht wieder zusammengesetzt werden, ist. Ein dritter Puffertyp speichert Pakete bis zur MTU-Größe (z. B. 1522 Bytes), die nicht wieder zusammengesetzt werden, während ein vierter Typ Jumbo-Pakete speichert, die größer als die MTU-Größe sind und nicht wieder zusammengesetzt werden. Diese Puffer werden Flusswiederzusammensetzungspuffer, Kopfpuffer, MTU-Puffer und Jumbo-Puffer genannt.
Die in diesem Abschnitt beschriebenen Prozeduren nutzen Frei-Deskriptoren und Abschluss-Deskriptoren, wie sie in 12 gezeigt sind. Insbesondere speichern in diesen Prozeduren Frei-Deskriptoren, die aus einem Frei-Deskriptor-Ring wiedergewonnen werden, Pufferidentifizierer (z. B. Speicheradressen, Zeiger) zum Identifizieren von Puffern, in denen ein Abschnitt eines Pakets zu speichern ist. Ein verwendeter Puffer kann an einen Host-Computer zurückgegeben werden, indem der Platz in einem Datenfeld freier Puffer oder in einer anderen zum Speichern des Pufferidentifizierers des Puffers verwendeten Datenstruktur identifiziert wird. Der Fachmann auf dem Gebiet erkennt, dass diese Prozeduren leicht angepasst werden können, um mit alternativen Verfahren zum Erhalten und Zurückgeben von Puffern zum Speichern von Paketen zu arbeiten.
13 ist eine Ansicht auf höchster Ebene der Logiksteuerungs-DMA-Maschine 120 in dieser Ausführungsform der Erfindung. Der Zustand 1300 ist ein Startzustand.
Im Zustand 1302 wird in der Paketwarteschlange 116 ein Paket gespeichert und werden in der Steuerwarteschlange 118 zugeordnete Informationen gespeichert. In 8 ist eine Ausführungsform einer Paketwarteschlange gezeigt und in 9 ist eine Ausführungsform einer Steuerwarteschlange gezeigt. Die DMA-Maschine 120 kann durch Vergleichen des Lese- und des Schreibzeigers der Warteschlange das Vorhandensein eines Pakets in der Paketwarteschlange 116 erfassen. Selbstverständlich ist ein Paket in der Warteschlange gespeichert, solange sie nicht auf den gleichen Eintrag Bezug nehmen. Alternativ kann die DMA-Maschine 120 die Steuerwarteschlange 118 untersuchen, um festzustellen, ob dort ein Eintrag vorhanden ist, der angibt, dass in der Paketwarteschlange 116 ein Paket gespeichert ist. Solange der Lese- und der Schreibzeiger der Steuerwarteschlange nicht auf den gleichen Eintrag Bezug nehmen, wird ein Eintrag in der Steuerwarteschlange gespeichert und muss ein Paket in der Paketwarteschlange gespeichert werden.
Im Zustand 1304 wird der dem Paket zugeordnete Eintrag in der Steuerwarteschlange gelesen. Beispielhaft enthält der Steuerwarteschlangeneintrag den Operationscode des Pakets, den Status des No_Assist-Signals des Pakets (das z. B. angibt, ob das Paket mit einem im Voraus gewählten Protokoll kompatibel ist), einen oder mehrere Indikatoren, die die Größe des Pakets (und/oder seines Datenabschnitts) betreffen, usw.
Im Zustand 1306 gewinnt die DMA-Maschine 120 die Flussnummer des Pakets wieder. Wie zuvor beschrieben wurde, ist die Flussnummer eines Pakets der Index des Flusses des Pakets in der Flussdatenbank 110. Wie in einem folgenden Abschnitt beschrieben wird, kann die Flussnummer eines Pakets an das dynamische Paketblockbildungsmodul 122 geliefert und von ihm verwendet werden, um die gemeinsame Verarbeitung von Köpfen von verwandten Paketen zu ermöglichen. In einer Ausführungsform der Erfindung kann die Flussnummer eines Pakets an irgendeines einer Anzahl von NIC-Modulen (z. B. an das IPP-Modul 104, an das Paketblockbildungsmodul 122, an die DMA-Maschine 120, an die Steuerwarteschlange 118) geliefert werden, nachdem sie durch den Flussdatenbankmanager 108 erzeugt worden ist. Außerdem kann die Flussnummer in einer getrennten Datenstruktur (z. B. in einem Register) gespeichert werden, bis sie vom dynamischen Paketblockbildungsmodul 122 und/oder von der DMA-Maschine 120 benötigt wird. In einer Ausführungsform der Erfindung gewinnt die DMA-Maschine 120 die Flussnummer eines Pakets vom dynamischen Paketblockbildungsmodul 122 wieder. In einer alternativen Ausführungsform der Erfindung kann die Flussnummer von einem anderen Platz oder Modul wiedergewonnen werden.
Daraufhin stellt die DMA-Maschine 120 in den Zuständen 1308–1318 durch Untersuchung des Operationscodes des Pakets die richtige Weise der Verarbeitung des Pakets fest. Der Operationscode kann z. B. angeben, in welchen Puffer die Maschine das Paket übertragen sollte und ob ein Fluss in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 auf- oder abzubauen ist.
Die veranschaulichte Prozedur wird im Zustand 1400 (14), falls der Operationscode 0 ist, im Zustand 1500 (in 15) für den Operationscode 1, im Zustand 1600 (16) für den Operationscode 2, im Zustand 1700 (17) für den Operationscode 3, im Zustand 1800 (18) für den Operationscode 4, im Zustand 1900 (19) für den Operationscode 5 und im Zustand 2000 (20) für die Operationscodes 6 und 7 fortgesetzt.
EIN VERFAHREN ZUM ÜBERTRAGEN EINES PAKETS MIT DEM OPERATIONSCODE 0
14 zeigt eine beispielhafte Prozedur, in der die DMA-Maschine 120 ein Paket, dem der Operationscode 0 zugeordnet ist, an einen Host-Speicherpuffer überträgt. Wie TABELLE 1 widerspiegelt, gibt der Operationscode 0 in dieser Ausführungsform an, dass das Paket mit den Protokollen, die durch die NIC 100 syntaktisch analysiert werden können, kompatibel ist. Wie oben erläutert wurde, sind kompatible Pakete für die Wiederzusammensetzung berechtigt, so dass Daten von mehreren Paketen eines Flusses in einem Puffer gespeichert werden können, der daraufhin effizient (z. B. über einen Seitenwechsel) an einen Anwender- oder Programmspeicherraum geliefert werden können. Allerdings sind Pakete mit dem Operationscode 0 klein und enthalten keine Flussdaten für die Wiederzusammensetzung. Somit sind sie wahrscheinlich Steuerpakete. Somit wird kein neuer Fluss aufgebaut, kein vorhandener Fluss abgebaut und kann das gesamte Paket in einem Kopfpuffer angeordnet werden.
Im Zustand 1400 stellt die DMA-Maschine 120 (z. B. der DMA-Manager 1002) fest, ob es einen gültigen (z. B. aktiven) Kopfpuffer gibt. Beispielhaft wird diese Feststellung dadurch vorgenommen, dass der Gültigkeitsindikator 1116 der Kopfpuffertabelle 1006 untersucht wird, die das Management des aktiven Kopfpuffers ausführt. Falls der Gültigkeitsindikator gesetzt (z. B. gleich eins) ist, gibt es einen Kopfpuffer, der bereit ist, dieses Paket zu empfangen, wobei die Prozedur im Zustand 1404 fortgesetzt wird.
Andernfalls wird im Zustand 1402 ein Kopfpuffer zum Speichern kleiner Pakete (z. B. von Paketen mit einer Größe von weniger als 257 Bytes) und von Köpfen wieder zusammengesetzter Pakete (und möglicherweise von Köpfen anderer Pakete – wie etwa Jumbo-Pakete) vorbereitet oder initialisiert. In der veranschaulichten Ausführungsform umfasst dieser Initialisierungsprozess das Erhalten eines Frei-Ring-Deskriptors und das Wiedergewinnen seines Pufferidentifizierers (z. B. seiner Bezugnahme auf einen verfügbaren Host-Speicherpuffer). Der Pufferidentifizierer kann daraufhin in einer Datenstruktur wie etwa in einem Datenfeld 1210 freier Puffer (in 12A gezeigt) gespeichert werden. Wie oben beschrieben wurde, hält der Frei-Ring-Manager 1012 in einer Ausführungsform der Erfindung einen Cache von Deskriptoren, die auf leere Puffer Bezug nehmen. Somit kann aus diesem Cache ein Deskriptor wiedergewonnen werden und sein Puffer der Kopfpuffertabelle 1006 zugeordnet werden. Falls der Cache leer ist, können aus einem Frei-Deskriptor-Ring im Host-Speicher neue Deskriptoren wiedergewonnen werden, um den Cache aufzufüllen.
Wenn aus dem Cache oder aus dem Frei-Deskriptor-Ring ein neuer Pufteridentifizierer wiedergewonnen wird, wird die Stelle des Pufferidentifizierers in dem Datenfeld freier Puffer im Kopfpufferindex 1112 der Kopfpuffertabelle 1006 angeordnet. Ferner wird ein Anfangsspeicherplatz in dem Pufferidentifizierer (z. B. seine Startadresse) im Feld 1114 einer nächsten Adresse gespeichert und der Gültigkeitsindikator 1116 auf einen gültigen Zustand gesetzt.
Im Zustand 1404 wird das Paket an die Adresse oder an den Platz, der im Feld der nächsten Adresse der Kopfpuffertabelle 1006 angegeben ist, in den Kopfpuffer kopiert oder übertragen (z. B. über eine DMA-Operation). Wie oben beschrieben wurde, werden in einer Ausführungsform der Erfindung Auffüllbytes vor dem Paket eingefügt, um den Beginn des Schicht-Drei-Kopfs (z. B. des IP-Kopfs) des Pakets auf eine Sechzehn-Byte-Grenze auszurichten. Außerdem kann ein Paketpuffer logisch in Zellen vorgegebener Größe (z. B. 256 Bytes) unterteilt sein, wobei das Paket oder die Auffüllung in diesem Fall an einer Zellengrenze beginnen kann.
Im Zustand 1406 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um Informationen an den Host-Computer (z. B. an einen Software-Treiber) zur Verarbeitung des Pakets zu liefern. Insbesondere werden in den Deskriptor der Kopfpufferindex (z. B. der Index des Pufferidentifizierers, der auf den Kopfpuffer Bezug nimmt, in dem Datenfeld freier Puffer) und der Versatz des Pakets in dem Paketpuffer angeordnet. Beispielhaft kann der Versatz den Platz der Zelle, an dem der Kopf gespeichert ist, identifizieren oder das erste Byte des Pakets identifizieren. Die Größe des Pakets wird, beispielhaft in einem Kopfgrößefeld, ebenfalls in dem Deskriptor gespeichert. Ein Datengrößefeld in dem Deskriptor wird auf null gesetzt, um anzugeben, dass das gesamte Paket in dem Kopfpuffer angeordnet wurde (z. B. war kein Datenabschnitt in einem getrennten Datenpuffer zu speichern). Falls der Kopfpuffer voll ist, wird in dem Deskriptor ein Kopffreigabemerker gesetzt. Allerdings kann der Kopfpuffer erst in einem späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform der Erfindung kann der Kopffreigabemerker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden.
Wie in einem späteren Abschnitt beschrieben wird, kann in einer Ausführung der Erfindung in Abhängigkeit von dem dynamischen Paketblockbildungsmodul 122 auch ein Flussfreigabemerker gesetzt werden. Zum Beispiel wird der Flussfreigabemerker gelöscht (z. B. eine Null gespeichert), falls das Paketblockbildungsmodul feststellt, dass bald ein weiteres Paket in demselben Fluss an den Host-Computer übertragen wird. Dies gibt an, dass der Host-Computer auf das nächste Flusspaket warten sollte, bevor er dieses verarbeitet. Daraufhin können die Pakete durch gemeinsames Verarbeiten mehrerer Pakete aus einem einzigen Fluss effizienter verarbeitet werden, während sie weniger Prozessorzeit benötigen.
In dem Deskriptortypfeld wird ein Wert gespeichert, der angibt, dass ein Flusspaket an den Host-Speicher übertragen wurde. Außerdem wird in dem Besitzindikatorfeld ein vorgegebener Wert (z. B. null) gespeichert, um anzugeben, dass die DMA-Maschine 120 unter Verwendung des Deskriptors fertig ist und/oder ein Paket an den Host-Computer freigibt. Beispielhaft erfasst der Host-Computer die Änderung des Besitzindikators (z. B. von eins auf null) und verwendet die gespeicherten Informationen zum Verarbeiten des Pakets. In einer alternativen Ausführungsform der Erfindung gibt die DMA-Maschine 120 eine Unterbrechung oder ein anderes Signal aus, um den Host-Computer zu warnen, dass ein Deskriptor freigegeben wird. In einer weiteren alternativen Ausführungsform fragt der Host-Computer die NIC ab, um festzustellen, wann ein Paket empfangen und/oder übertragen worden ist. In einer nochmals weiteren alternativen Ausführungsform wird das Deskriptortypfeld verwendet, um den Host-Computer zu informieren, dass die DMA-Maschine einen Deskriptor freigibt. Wenn in dieser alternativen Ausführungsform ein von null verschiedener Wert in dem Deskriptortypfeld angeordnet wird, kann der Host-Computer verstehen, dass die DMA-Maschine den Deskriptor freigibt.
In einer vorliegenden Ausführungsform der Erfindung wird das Besitzindikatorfeld erst geändert, wenn die DMA-Maschine 120 mit irgendeiner weiteren dieses Paket betreffenden Verarbeitung fertig ist oder mit dem Erstellen aller Einträge in dem Deskriptor fertig ist. Wie im Folgenden beschrieben wird, kann z. B. zu einem Zeitpunkt nach dem Zustand 1406 festgestellt werden, dass ein Kopfpuffer oder ein anderer Puffer voll ist. Dadurch, dass das Setzen des Besitzindikators verzögert wird, kann ein Kopffreigabemerker gesetzt werden, bevor der Deskriptor von dem Host-Computer zurückverlangt wird, so dass die Verwendung eines weiteren Deskriptors vermieden wird.
Im Zustand 1408 wird festgestellt, ob der Kopfpuffer voll ist. In dieser Ausführungsform der Erfindung, in der jeder Puffer eine Größe von acht Kilobytes hat und Einträge in dem Kopfpuffer nicht größer als 256 Bytes sind, können in einem Kopfpuffer bis zu zweiunddreißig Einträge gespeichert werden. Somit kann ein Zähler verwendet werden, um in jedem neuen Kopfpuffer angeordnete Einträge zu verfolgen, wobei der Puffer als voll betrachtet werden kann, wenn zweiunddreißig Einträge gespeichert worden sind. Andere Verfahren der Feststellung, ob ein Puffer voll ist, sind ebenfalls geeignet. Zum Beispiel kann eines neues Feld der nächsten Adresse berechnet und die Differenz zwischen dem neuen Feld der nächsten Adresse und der Anfangsadresse des Puffers mit der Größe des Puffers (z. B. acht Kilobytes) verglichen werden, nachdem ein Paket in dem Kopfpuffer gespeichert worden ist. Falls weniger als eine vorgegebene Anzahl von Bytes (z. B. 256) ungenutzt sind, kann der Puffer als voll betrachtet werden.
Falls der Puffer voll ist, wird der Kopfpuffer im Zustand 1410 ungültig gemacht, um sicherzustellen, dass er nicht wieder verwendet wird. Beispielhaft umfasst dies das Setzen des Gültigkeitsindikators der Kopfpuffertabelle auf ungültig und das Übermitteln dieses Status über einen Deskriptor an den Host-Computer. In dieser Ausführungsform der Erfindung wird ein Kopffreigabemerker in dem Deskriptor gesetzt. Falls der Deskriptor, der im Zustand 1406 geschrieben wurde, bereits freigegeben wurde (z. B. sein Besitzindikatorfeld geändert wurde), kann in diesem Zustand ein weiterer Deskriptor verwendet werden. Falls einfach ein weiterer Deskriptor verwendet wird, um einen vollen Kopfpuffer zu berichten, können das Kopfgrößefeld und das Datengrößefeld des Deskriptors auf null gesetzt werden, um anzugeben, dass kein neues Paket mit diesem Deskriptor übertragen wurde.
Falls der Kopfpuffer nicht voll ist, wird im Zustand 1412 das Feld der nächsten Adresse der Kopfpuffertabelle 1006 aktualisiert, um die Adresse anzugeben, an der der nächste Kopf oder das nächste kleine Paket zu speichern ist. Daraufhin wird die einem Paket mit der Operationscode 0 zugeordnete Verarbeitung mit dem Endzustand 1499 abgeschlossen. In einer Ausführungsform der Erfindung wird bis zum Endzustand 1499 das Besitzindikatorfeld eines Deskriptors, der im Zustand 1406 geschrieben wird, nicht geändert und keine Unterbrechung ausgegeben. Eine Verzögerung der Benachrichtigung des Host-Computers ermöglicht, dass der Deskriptor solange wie möglich aktualisiert oder geändert wird, bevor er an den Host übergeben wird.
EIN VERFAHREN ZUM ÜBERTRAGEN EINES PAKETS MIT DEM OPERATIONSCODE 1
15 zeigt eine beispielhafte Prozedur, in der die DMA-Maschine 120 ein Paket, dem der Operationscode 1 zugeordnet ist, an einen Host-Speicherpuffer überträgt. Wie TABELLE 1 widerspiegelt, gibt der Operationscode 1 in dieser Ausführungsform an, dass das Paket mit den Protokollen, die durch die NIC 100 syntaktisch analysiert werden können, kompatibel ist. Allerdings kann ein Paket mit dem Operationscode 1 ein Steuerpaket mit einem besonderen gesetzten Merker sein. Es wird kein neuer Fluss aufgebaut, wobei aber bereits ein Fluss vorhanden sein sollte und abzubauen ist; es sind keine Daten wieder zusammenzusetzen und das gesamte Paket kann in einem Kopfpuffer gespeichert werden.
Im Zustand 1500 stellt die DMA-Maschine 120 (z. B. der DMA-Manager 1002) fest, ob es einen gültigen (z. B. aktiven) Kopfpuffer gibt. Beispielhaft wird diese Feststellung dadurch vorgenommen, dass der Gültigkeitsindikator 1116 der Kopfpuffertabelle 1006 untersucht wird, die das Management der aktiven Kopfpuffer ausführt. Falls der Gültigkeitsindikator gesetzt ist, ist ein Kopfpuffer zum Empfang dieses Pakets bereit, wobei die Prozedur im Zustand 1504 fortgesetzt wird.
Andernfalls wird im Zustand 1502 ein neuer Kopfpuffer vorbereitet oder initialisiert, um kleine Pakete und Köpfe von Wiederzusammensetzungspaketen zu speichern. Beispielhaft umfasst dieser Initialisierungsprozess das Erhalten eines Frei-Ring-Deskriptors aus einem durch den Frei-Ring-Manager 1012 gehaltenen Cache und das Wiedergewinnen seiner Bezugnahme auf einen leeren Puffer. Falls der Cache leer ist, können von dem Frei-Deskriptor-Ring im Host-Speicher neue Deskriptoren wiedergewonnen werden, um den Cache aufzufüllen.
Wenn aus dem Cache oder von dem Frei-Deskriptor-Ring ein neuer Deskriptor erhalten wird, wird sein Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in dem Datenfeld 1210 freier Puffer gespeichert und sein Anfangsspeicherplatz (z. B. Adressen- oder Zellenplatz) im Feld 1114 der nächsten Adresse der Kopfpuffertabelle 1006 gespeichert. Der Index oder die Stelle des Pufferidentifizierers in dem Datenfeld freier Puffer wird im Kopfpufferindex 1112 gespeichert. Schließlich wird der Gültigkeitsindikator 1116 auf einen gültigen Zustand gesetzt.
Im Zustand 1504 wird das Paket an die Adresse oder an den Platz, die/der in dem Feld der nächsten Adresse der Kopfpuffertabelle 1006 angegeben ist, kopiert. Wie oben beschrieben wurde, werden in einer Ausführungsform der Erfindung vor dem Paket Auffüllbytes eingefügt, um dem Beginn des Schicht-Drei-Kopfs (z. B. des IP-Kopfs) des Pakets auf eine Sechzehn-Byte-Grenze auszurichten. Außerdem kann das Paket (mit oder ohne Auffüllung) in einem vorgegebenen Bereich oder in einer vorgegebenen Zelle des Puffers angeordnet werden.
In der veranschaulichten Ausführungsform gibt der Operationscode 1 an, dass der vorhandene Fluss des Pakets abzubauen ist. Somit wird im Zustand 1506 durch Untersuchen des Gültigkeitsindikators des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 festgestellt, ob ein Flusswiederzusammensetzungspuffer für diesen Fluss gültig (z. B. aktiv) ist. Falls der Indikator z. B. gültig ist, gibt es einen aktiven Puffer, der Daten von einem oder von mehreren Paketen in diesem Fluss speichert. Beispielhaft wird der Fluss dadurch abgebaut, dass der Flusswiederzusammensetzungspuffer ungültig gemacht und an den Host-Computer freigegeben wird. Falls es keinen gültigen Flusswiederzusammensetzungspuffer für diesen Fluss gibt, wird die veranschaulichte Prozedur im Zustand 1512 fortgesetzt. Andernfalls geht die Prozedur zum Zustand 1508 über.
Im Zustand 1508 wird ein Abschluss-Deskriptor konfiguriert, um den Wiederzusammensetzungspufter des Flusses freizugeben und Informationen zur Verarbeitung des momentanen Pakets an den Host-Computer zu liefern. Insbesondere werden in dem Deskriptor der Kopfpufferindex und der Versatz des ersten Bytes des Pakets (oder der Platz der Zelle des Pakets) in dem Kopfpuffer angeordnet. Der Index des Eintrags, der den Pufferidentifizierer des Wiederzusammensetzungspuffers enthält, in dem Datenfeld freier Puffer wird in einem Datenindexfeld des Deskriptors gespeichert. Die Größe des Pakets wird in einem Kopfgrößefeld gespeichert und ein Datengrößefeld wird auf null gesetzt, um anzugeben, dass kein getrennter Puffer zum Speichern der Daten dieses Pakets verwendet wurde. Falls der Kopfpuffer voll ist, wird ein Kopffreigabemerker in dem Deskriptor gesetzt, und es wird ein Datenfreigabemerker gesetzt, um anzugeben, dass im vorliegenden Wiederzusammensetzungspuffer dieses Flusses keine weiteren Daten angeordnet werden (dass er z. B. freigegeben wird). Außerdem wird ein Flussfreigabemerker gesetzt, um anzugeben, dass die DMA-Maschine 120 den Fluss des Pakets abbaut. Der Kopfpuffer kann erst in einem späteren Zustand dieser Proze dur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform der Erfindung kann der Kopffreigabemerker zu dieser Zeit gesetzt werden.
Im Zustand 1510 wird der Eintrag des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 ungültig gemacht. Nach dem Zustand 1510 wird die Prozedur im Zustand 1514 fortgesetzt.
Im Zustand 1512 wird ein Abschluss-Deskriptor mit etwas anderen Informationen als denen des Zustands 1508 konfiguriert. Insbesondere werden in dem gleichen Deskriptorfeld wie oben der Kopfpufferindex, der Versatz zu diesem Paket in dem Kopfpuffer und die Paketgröße angeordnet. Die Datenfeldgröße wird wie oben auf null gesetzt, wobei aber kein Datenindex gespeichert zu werden braucht und kein Datenfreigabemerker gesetzt wird (da es z. B. keinen freizugebenden Flusswiederzusammensetzungspuffer gibt). Falls der Kopfpuffer voll ist, wird weiter ein Kopffreigabemerker in dem Deskriptor gesetzt, und es wird wieder ein Flussfreigabemerker gesetzt, um anzugeben, dass die DMA-Maschine 120 den Fluss des Pakets abbaut. Außerdem wird das Deskriptortypfeld auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein Flusspaket an den Host-Speicher übertragen hat.
Im Zustand 1514 wird festgestellt, ob der Kopfpuffer jetzt voll ist. In dieser Ausführungsform der Erfindung, in der jeder Puffer eine Größe von acht Kilobytes hat und Einträge in dem Kopfpuffer nicht größer als 256 Bytes sind, wird ein Zähler verwendet, um in jedem neuen Kopfpuffer angeordnete Einträge zu verfolgen. Wenn zweiunddreißig Einträge gespeichert worden sind, wird der Puffer als voll betrachtet.
Falls der Puffer voll ist, wird der Kopfpuffer im Zustand 1516 ungültig gemacht. Beispielhaft umfasst dies das Setzen des Gültigkeitsindikators der Kopfpuffertabelle auf ungültig und das Übermitteln dieses Status über den im Zustand 1508 oder im Zustand 1512 konfigurierten Deskriptor an den Host-Computer. In dieser Ausführungsform der Erfindung wird ein Kopffreigabemerker in dem Deskriptor gesetzt, um anzugeben, dass der Kopfpuffer voll ist.
Falls der Kopfpuffer nicht voll ist, wird im Zustand 1518 das Feld der nächsten Adresse der Kopfpuffertabelle 1006 aktualisiert, um die Adresse anzugeben, an der der nächste Kopf oder das nächste kleine Paket zu speichern ist.
Daraufhin wird die einem Paket mit dem Operationscode 1 zugeordnete Verarbeitung mit dem Endzustand 1599 abgeschlossen. In diesem Endzustand wird der für dieses Paket verwendete Deskriptor an den Host-Computer übergeben, indem sein Besitzindikatorfeld (z. B. von eins auf null) geändert wird, wobei eine Unterbrechung oder ein anderer Mechanismus ausgegeben wird.
Für den Fachmann auf dem Gebiet ist klar, dass eine Änderung des Deskriptortypfelds auf irgendeinen anderen Wert als den Wert (z. B. null), den es hatte, als die DMA-Maschine 120 es verwendet hat, in einer alternativen Ausführungsform der Erfindung eine Aushändigung des "Besitzes" des Deskriptors an den Host-Computer oder an die in dem Host-Computer arbeitende Software bilden kann. Der Host-Computer erfasst die Änderung in dem Deskriptortypfeld und verwendet nachfolgend die gespeicherten Informationen zur Verarbeitung des Pakets.
EIN VERFAHREN ZUM ÜBERTRAGEN EINES PAKETS MIT DEM OPERATIONSCODE 2
Die 16A–16F veranschaulichen eine Prozedur, in der die DMA-Maschine 120 ein Paket, dem der Operationscode 2 zugeordnet ist, an einen Host-Speicherpuffer überträgt. Wie TABELLE 1 widerspiegelt, kann der Operationscode 2 angeben, dass das Paket kompatibel mit den Protokollen ist, die durch die NIC 100 syntaktisch analysiert werden können, aber außer der Reihe mit einem anderen Paket in dem gleichen Fluss ist. Außerdem kann er einen Versuch zum Wiederaufbauen eines Flusses angeben, wobei nach diesem Paket aber wahrscheinlich keine weiteren Daten empfangen werden. Für den Operationscode 2 wird kein neuer Fluss aufgebaut und irgendein vorhandener Fluss mit der Flussnummer des Pakets ist abzubauen. Die Daten des Pakets sind nicht mit Daten aus anderen Paketen in demselben Fluss wieder zusammenzusetzen.
Da ein vorhandener Fluss abzubauen ist (z. B. der Wiederzusammensetzungspuffer des Flusses ungültig zu machen und an den Host-Computer freizugeben ist), wird im Zustand 1600 festgestellt, ob ein Flusswiederzusammensetzungspuffer für den Fluss mit der Flussnummer, die im Zustand 1306 gelesen wurde, gültig (z. B. aktiv) ist. Diese Feststellung kann dadurch vorgenommen werden, dass der Gültigkeitsindikator im Eintrag des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 untersucht wird. Beispielhaft gibt es einen aktiven Puffer, der Daten von einem oder von mehreren Paketen in dem Fluss speichert, falls der Indikator gültig ist. Falls es einen gültigen Flusswiederzusammensetzungspuffer für diesen Fluss gibt, wird die veranschaulichte Prozedur im Zustand 1602 fortgesetzt. Andernfalls geht die Prozedur zum Zustand 1606 über.
Im Zustand 1602 wird ein Abschluss-Deskriptor zum Freigeben des vorhandenen Flusswiederzusammensetzungspuffers geschrieben oder konfiguriert. Insbesondere wird der Index des Flusswiederzusammensetzungspuffers (z. B. der Platz, der den dem Flusswiederzusammensetzungspuffer entsprechenden Pufferidentifizierer enthält, in dem Datenfeld freier Puffer) in den Deskriptor geschrieben. In dieser Ausführungsform der Erfindung braucht kein Versatz im Datenversatzfeld des Deskriptors gespeichert zu werden und kann die Datenfeldgröße auf null gesetzt werden, da keine neuen Daten im Wiederzusammensetzungspuffer gespeichert wurden. Ähnlich ist der Kopfpuffer noch nicht freigegeben worden, so dass das Kopfindexfeld und das Kopfversatzfeld des Deskriptors nicht verwendet zu werden brauchen und in dem Kopfgrößefeld eine Null gespeichert werden kann.
Beispielhaft wird das Kopffreigabefeld des Deskriptors gelöscht (z. B. eine Null in dem Merker gespeichert), da der Kopfpuffer nicht freizugeben ist. Da keine weiteren Daten in dem freigegebenen Flusswiederzusammensetzungspuffer angeordnet werden, wird der Datenfreigabemerker dagegen gesetzt (z. B. eine Eins in dem Merker gespeichert). Ferner wird ein Flussfreigabemerker in dem Deskriptor ebenfalls gesetzt, um anzugeben, dass der dem freigegebenen Flusswiederzusammensetzungspuffer zugeordnete Fluss abzubauen ist.
Das Deskriptortypfeld kann auf einen Wert geändert werden, der angibt, dass die DMA-Maschine 120 einen verbrauchten Flusspuffer (z. B. einen Flusswiederzusammensetzungspuffer, der eine gewisse Zeit nicht verwendet worden ist) freigibt. Schließlich wird der Deskriptor an den Host-Computer übergeben, indem sein Besitzindikatorfeld geändert wird oder eine Unterbrechung ausgegeben oder ein anderer Mechanismus verwendet wird. In einer Ausführungsform der Erfindung wird der Deskriptor dagegen erst im Endzustand 1699 an den Host-Computer freigegeben.
Daraufhin wird der Flusswiederzusammensetzungspufter im Zustand 1604 durch geeignetes Ändern des Gültigkeitsindikators 1106 im Eintrag des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 ungültig gemacht.
Im Zustand 1606 wird festgestellt, ob das vorliegende Paket ein kleines Paket ist (z. B. eine Größe von weniger oder gleich 256 Bytes hat), das zur Speicherung in einem Kopfpuffer geeignet ist. Wenn das der Fall ist, geht die veranschaulichte Prozedur zum Zustand 1610 über. Um diese Feststellung vorzunehmen, können die in der Paketwarteschlange 116 und/oder in der Steuerwarteschlange 118 gespeicherten Informationen verwendet werden.
Im Zustand 1608 wird festgestellt, ob das vorliegende Paket ein Jumbo-Paket ist (z. B. eine Größe von mehr als 1522 Bytes hat), so dass es in einem Jumbo-Puffer gespeichert werden sollte. Wenn das der Fall ist, geht die veranschaulichte Prozedur zum Zustand 1650 über. Wenn das nicht der Fall ist, wird die Prozedur im Zustand 1630 fortgesetzt.
Im Zustand 1610 (der vom Zustand 1606 erreicht wird) ist festgestellt worden, dass das vorliegende Paket ein kleines Paket ist, das zur Speicherung in einem Kopfpuffer geeignet ist. Somit stellt die DMA-Maschine 120 (z. B. der DMA-Manager 1002) fest, ob es einen gültigen (z. B. aktiven) Kopfpuffer gibt. Beispielhaft wird diese Feststellung dadurch vorgenommen, dass der Gültigkeitsindikator 1116 der Kopfpuffertabelle 1006 festgestellt wird, die das Management des aktiven Kopfpuffers ausführt. Falls der Gültigkeitsindikator gesetzt ist, sollte es einen Kopfpuffer geben, der bereit ist, dieses Paket zu empfangen, wobei die Prozedur im Zustand 1614 fortgesetzt wird.
Andernfalls wird im Zustand 1612 ein neuer Kopfpuffer zum Speichern kleiner Pakete und Köpfe wieder zusammengesetzter Pakete vorbereitet oder initialisiert. Dieser Initialisierungsprozess kann das Erhalten eines Frei-Ring-Deskriptors von einem durch den Frei-Ring-Manager 1012 gehaltenen Cache und das Wiedergewinnen seiner Bezugnahme auf einen leeren Puffer umfassen. Falls der Cache leer ist, können neue Deskriptoren aus dem Frei-Deskriptor-Ring im Host-Speicher wiedergewonnen werden, um den Cache aufzufüllen.
Wenn von dem Cache oder von dem Frei-Deskriptor-Ring ein neuer Deskriptor erhalten wird, wird der in dem Deskriptor enthaltene Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in einem Datenfeld freier Puffer gespeichert. Die Anfangsadresse des Puffers oder ein anderer Indikator des ersten Speicherplatzes in dem Puffer wird im Feld 1114 der nächsten Adresse der Kopfpuffertabelle 1006 gespei chert. Die Stelle oder der Index des Pufferidentifizierers in dem Datenfeld freier Puffer wird im Kopfpufferindex 1112 gespeichert und der Gültigkeitsindikator 1116 auf einen gültigen Zustand gesetzt.
Im Zustand 1614 wird das Paket an die Adresse oder an den Platz, die/der in dem Feld der nächsten Adresse der Kopfpuffertabelle 1006 angegeben ist, in den Kopfpuffer kopiert oder übertragen (z. B. über eine DMA-Operation). Wie oben beschrieben wurde, werden in einer Ausführungsform der Erfindung Auffüllbytes vor dem Kopf eingefügt, um den Beginn des Schicht-Drei-Protokollkopfs (z. B. des IP-Kopfs) des Pakets auf eine Sechzehn-Byte-Grenze auszurichten. Außerdem kann das Paket in einer Zelle vorgegebener Größe (z. B. 256 Bytes) in dem Kopfpuffer positioniert werden.
Im Zustand 1616 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um notwendige Informationen für die Verarbeitung des Pakets an den Host-Computer (z. B. an einen Software-Treiber) zu liefern. Insbesondere werden in dem Deskriptor der Kopfpufferindex (z. B. die Stelle des Pufferidentifizierers des Kopfpuffers in dem Datenfeld freier Puffer) und der Versatz des Pakets in dem Kopfpuffer angeordnet. Beispielhaft kann dieser Versatz dazu dienen, das erste Byte des Pakets, das erste Auffüllbyte vor dem Paket oder den Beginn der Zelle des Pakets in dem Puffer zu identifizieren. Die Größe des Pakets wird ebenfalls in dem Deskriptor in einem Kopfgrößefeld gespeichert. Ein Datengrößefeld in dem Deskriptor kann auf null gesetzt werden, um anzugeben, dass das gesamte Paket in dem Kopfpuffer angeordnet wurde (dass z. B. kein getrennter Datenabschnitt gespeichert wurde). Falls der Kopfpuffer voll ist, wird ein Kopffreigabemerker in dem Deskriptor gesetzt. Allerdings kann der Kopfpuffer erst in einem späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform der Erfindung kann der Kopffreigabemerker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden. Ein Datenfreigabemerker wird gelöscht (z. B. auf einen Wert null gesetzt), da es keinen getrennten Datenabschnitt gibt, der zu dem Host-Computer befördert wird.
Außerdem wird das Deskriptortypfeld auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein nicht wieder zusammensetzbares Paket an den Host-Speicher übertragen hat. Außerdem wird in dem Besitzindikatorfeld des Deskriptors ein vorgegebener Wert (z. B. null) gespeichert, der angibt, dass die DMA-Maschine 120 ein Paket an den Host-Computer freigibt und den Besitz des Deskrip tors übergibt. In einer Ausführungsform der Erfindung wird das Besitzindikatorfeld erst im Endzustand 1699 unten geändert. In einer alternativen Ausführungsform der Erfindung gibt die DMA-Maschine 120 eine Unterbrechung oder ein anderes Signal aus, um den Host-Computer davor zu warnen, dass ein Deskriptor freigegeben wird.
Im Zustand 1618 wird festgestellt, ob der Kopfpuffer voll ist. In dieser Ausführungsform der Erfindung, in der jeder Puffer eine Größe von acht Kilobytes hat und Einträge in dem Kopfpuffer nicht größer als 256 Bytes sind, kann ein Zähler verwendet werden, um die in jedem neuen Kopfpuffer angeordneten Einträge zu verfolgen. Wenn zweiunddreißig Einträge gespeichert worden sind, wird der Puffer als voll betrachtet.
Falls der Puffer voll ist, wird der Kopfpuffer im Zustand 1620 ungültig gemacht, um sicherzustellen, dass er nicht wieder verwendet wird. Beispielhaft umfasst dies das Setzen des Gültigkeitsindikators der Kopfpuffertabelle auf einen ungültigen Zustand und das Übermitteln dieses Status an den Host-Computer. In dieser Ausführungsform der Erfindung wird ein Kopffreigabemerker in dem Deskriptor gesetzt. Daraufhin wird die veranschaulichte Prozedur mit dem Endzustand 1699 abgeschlossen.
Falls der Kopfpuffer nicht voll ist, wird im Zustand 1622 das Feld der nächsten Adresse der Kopfpuffertabelle 1006 aktualisiert, um die Adresse oder Zellengrenze anzugeben, an der das nächste Kopfpaket oder kleine Paket zu speichern ist. Daraufhin wird die veranschaulichte Prozedur mit dem Endzustand 1699 abgeschlossen.
Im Zustand 1630 (der vom Zustand 1608 erreicht wird) ist festgestellt worden, dass das Paket kein kleines Paket oder Jumbo-Paket ist. Somit kann das Paket in einem Nichtwiederzusammensetzungspuffer (z. B. in einem MTU-Puffer) gespeichert werden, der zum Speichern von Paketen mit einer Größe bis zur MTU (z. B. 1522 Bytes) verwendet wird. Somit stellt die DMA-Maschine 120 im Zustand 1630 fest, ob ein gültiger (z. B. aktiver) MTU-Puffer vorhanden ist. Beispielhaft wird diese Feststellung dadurch vorgenommen, dass der Gültigkeitsindikator 1126 der MTU-Puffer-Tabelle 1008 untersucht wird, die das Management eines aktiven MTU-Puffers ausführt. Wenn der Gültigkeitsindikator gesetzt ist, gibt es einen MTU-Puffer, der bereit ist, dieses Paket zu empfangen, wobei die Prozedur im Zustand 1634 fortgesetzt wird.
Andernfalls wird im Zustand 1632 ein neuer MTU-Puffer vorbereitet oder initialisiert, um nicht wieder zusammensetzbare Pakete mit einer Größe bis zu 1522 Bytes zu speichern. Beispielhaft umfasst dieser Initialisierungsprozess das Erhalten eines Frei-Ring-Deskriptors aus einem durch den Frei-Ring-Manager 1012 erhaltenen Cache und das Wiedergewinnen seiner Bezugnahme auf einen leeren Puffer (z. B. eines Pufferidentifizierers). Falls der Cache leer ist, können neue Deskriptoren aus dem Frei-Deskriptor-Ring im Host-Speicher wiedergewonnen werden, um den Cache aufzufüllen.
Wenn aus dem Cache oder aus dem Frei-Deskriptor-Ring ein neuer Deskriptor erhalten wird, wird der in dem Deskriptor enthaltene Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in dem Datenfeld freier Puffer gespeichert. Die Anfangsadresse des Puffers oder eine andere Angabe des ersten Speicherplatzes in dem Puffer wird in dem Feld 1124 der nächsten Adresse der MTU-Puffer-Tabelle 1008 gespeichert. Ferner wird die Stelle des Pufferidentifizierers in dem Datenfeld freier Puffer im MTU-Puffer-Index 1122 gespeichert und der Gültigkeitsindikator 1126 auf einen gültigen Zustand gesetzt.
Im Zustand 1634 wird das Paket an die Adresse oder an den Platz, die/der in dem Feld der nächsten Adresse angegeben ist, in den MTU-Puffer kopiert oder übertragen (z. B. über eine DMA-Operation). Wie oben beschrieben wurde, können in einer Ausführungsform der Erfindung Auffüllbytes vor dem Kopf eingefügt werden, um den Beginn des Schicht-Drei-Protokollkopfs (z. B. des IP-Kopfs) des Pakets auf eine Sechzehn-Byte-Grenze auszurichten. In einer weiteren Ausführungsform der Erfindung können die Pakete ähnlich den Einträgen in einem Kopfpuffer auf Zellen vorgegebener Größe (z. B. zwei Kilobytes) in einem MTU-Puffer ausgerichtet werden.
Im Zustand 1636 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um an den Host-Computer (z. B. an einen Software-Treiber) notwendige Informationen für die Verarbeitung des Pakets zu liefern. Insbesondere werden in dem Deskriptor im Datenindexfeld bzw. im Datenversatzfeld der MTU-Puffer-Index (z. B. das Element des Datenfelds freier Puffer, das den Pufferidentifizierer für den MTU-Puffer enthält) und der Versatz (z. B. der Versatz des ersten Bytes dieses Pakets in dem MTU-Puffer) angeordnet. Die Größe des Pakets wird ebenfalls in dem Deskriptor, beispielhaft in einem Datengrößefeld, gespeichert. Ein Kopfgrößefeld in dem Deskriptor wird auf null gesetzt, um anzugeben, dass das gesamte Paket in dem MTU-Puffer angeordnet wurde (wobei z. B. kein getrennter Kopfabschnitt in einem Kopfpuffer gespeichert wurde). Falls der MTU-Puffer voll ist, wird ein Datenfreigabemerker in dem Deskriptor gesetzt. Allerdings kann der MTU-Puffer erst in einem Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform der Erfindung kann der Datenfreigabemerker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden. Ein Freigabemerker wird gelöscht (z. B. auf null gesetzt), da es keinen getrennten Kopfabschnitt gibt, der zu dem Host-Computer befördert wird.
Ferner wird das Deskriptortypfeld auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein nicht wieder zusammensetzbares Paket an den Host-Speicher übertragen hat. Außerdem wird ein vorgegebener Wert (z. B. null) im Besitzindikatorfeld des Deskriptors gespeichert, um anzugeben, dass die DMA-Maschine 120 ein Paket an den Host-Computer freigibt und den Besitz des Deskriptors übergibt. In einer vorliegenden Ausführungsform der Erfindung wird das Besitzfeld erst im Endzustand 1699 unten gesetzt. In einer alternativen Ausführungsform der Erfindung gibt die DMA-Maschine 120 eine Unterbrechung oder ein anderes Signal aus, um den Host-Computer zu warnen, dass ein Deskriptor freigegeben wird, oder übermittelt dieses Ereignis über das Deskriptortypfeld an den Hostcomputer.
Im Zustand 1638 wird festgestellt, ob der MTU-Puffer voll ist. In dieser Ausführungsform der Erfindung, in der jeder Puffer eine Größe von acht Kilobytes hat und Einträgen in dem MTU-Puffer zwei Kilobytes zugewiesen sind, kann ein Zähler verwendet werden, um die in jedem neuen Kopfpuffer angeordneten Einträge zu verfolgen. Wenn eine vorgegebene Anzahl von Einträgen (z. B. vier) gespeichert worden sind, kann der Puffer als voll betrachtet werden. In einer alternativen Ausführungsform der Erfindung stellt die DMA-Maschine 120 fest, wie viel Speicherraum noch in dem Puffer zu verwenden ist. Falls kein Raum bleibt oder falls noch weniger als ein vorgegebener Betrag an Raum verfügbar ist, kann der Puffer als voll betrachtet werden.
Falls der MTU-Puffer voll ist, wird er im Zustand 1640 ungültig gemacht, um sicherzustellen, dass er nicht wieder verwendet wird. Beispielhaft umfasst dies das Setzen des Gültigkeitsindikators der MTU-Puffer-Tabelle auf ungültig und das Übermitteln dieses Status an den Host-Computer. In dieser Ausführungsform der Erfindung wird ein Datenfreigabemerker in dem Deskriptor gesetzt. Daraufhin wird die veranschaulichte Prozedur mit dem Endzustand 1699 abgeschlossen.
Falls der MTU-Puffer nicht voll ist, wird im Zustand 1642 das Feld der nächsten Adresse der MTU-Puffer-Tabelle 1008 aktualisiert, um die Adresse oder den Platz (z. B. die Zellengrenze) anzugeben, an der/dem das nächste Paket zu speichern ist. Daraufhin wird die veranschaulichte Prozedur mit dem Endzustand 1699 abgeschlossen.
Im Zustand 1650 (der vom Zustand 1608 erreicht wird) ist festgestellt worden, dass das Paket ein Jumbopaket ist (z. B., dass seine Größe größer als 1522 Bytes ist). In dieser Ausführungsform der Erfindung werden Jumbo-Pakete in Jumbo-Puffern gespeichert und, falls das Teilen von Jumbo-Paketen (wie z. B. im Zustand 1654 unten festgestellt wird) freigegeben ist, werden die Köpfe der Jumbo-Pakete in einem Kopfpuffer gespeichert. Die DMA-Maschine 120 stellt fest, ob ein gültiger (z. B. aktiver) Jumbo-Puffer vorhanden ist. Beispielhaft wird diese Feststellung vorgenommen, indem der Gültigkeitsindikator 1136 der Jumbo-Puffertabelle 1010 untersucht wird, die das Management des aktiven Jumbo-Puffers ausführt. Falls der Gültigkeitsindikator gesetzt ist, gibt es einen Jumbo-Puffer, der bereit ist, dieses Paket zu empfangen, wobei die Prozedur im Zustand 1654 fortgesetzt wird. Wie oben erläutert wurde, kann in einer Ausführungsform der Erfindung, in der ein Jumbo-Puffer nur einmal verwendet wird (z. B. um nur ein Jumbo-Paket oder nur einen Teil eines Jumbo-Paket zu speichern), keine Jumbo-Puffertabelle verwendet wird.
Andernfalls wird im Zustand 1652 ein neuer Jumbo-Puffer vorbereitet oder initialisiert, um ein nicht wiederzusammensetzbares Paket zu speichern, das größer als 1522 Bytes ist. Dieser Initialisierungsprozess kann das Erhalten eines Frei-Ring-Deskriptors aus einem von dem Frei-Ring-Manager 1012 gehaltenen Cache und das Wiedergewinnen seiner Bezugnahme auf einen leeren Puffer (z. B. einen Pufferidentifizierer) umfassen. Falls der Cache leer ist, können neue Deskriptoren aus dem Frei-Deskriptor-Ring im Host-Speicher wiedergewonnen werden, um den Cache aufzufüllen.
Wenn aus dem Cache oder aus dem Frei-Deskriptor-Ring ein neuer Deskriptor erhalten wird, wird sein Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in einem Datenfeld freier Puffer (oder in einer anderen Datenstruktur) gespeichert. Die Anfangsadresse des Puffers oder eine andere Angabe des ersten Speicherplatzes in dem Puffer wird im Feld 1134 der nächsten Adresse der Jumbo-Puffertabelle 1010 angeordnet. Außerdem wird der Platz des Pufferidentifizierers in dem Datenfeld freier Puffer im Jumbo-Puffer-Index 1132 gespeichert und der Gültigkeitsindikator 1136 auf einen gültigen Zustand gesetzt.
Daraufhin stellt die DMA-Maschine 120 im Zustand 1654 fest, ob ein Teilen von Jumbo-Puffern freigegeben ist. Falls es freigegeben ist, wird der Kopf eines Jumbo-Pakets in einem Kopfpuffer gespeichert, während die Daten des Pakets in einem oder in mehreren Jumbo-Puffern gespeichert werden. Falls es nicht freigegeben ist, wird das gesamte Paket in einem oder in mehreren Jumbo-Puffern gespeichert. Beispielhaft wird das Teilen von Jumbo-Paketen gemäß der Konfiguration eines programmierbaren Indikators (z. B. eines Merkers, eines Bits, eines Registers) freigegeben oder gesperrt, der durch Software, die in dem Host-Computer arbeitet, (z. B. durch einen Vorrichtungstreiber) gesetzt werden kann. Falls das Teilen freigegeben ist, wird die veranschaulichte Prozedur im Zustand 1670 fortgesetzt. Ansonsten wird die Prozedur mit dem Zustand 1656 fortgesetzt.
Im Zustand 1656 stellt die DMA-Maschine 120 fest, ob das Paket in einen Jumbo-Puffer passt. Zum Beispiel wird in einer Ausführungsform der Erfindung, die Acht-Kilobyte-Seiten verwendet, ein zweiter Jumbo-Puffer zum Speichern zusätzlicher Inhalte benötigt, falls das Paket größer als acht Kilobytes ist. Falls das Paket zu groß ist, wird die veranschaulichte Prozedur im Zustand 1662 fortgesetzt.
Im Zustand 1658 wird das Paket an den Platz, der in dem Feld 1134 der nächsten Adresse der Jumbo-Puffertabelle 1010 angegeben ist, in den momentanen Jumbo-Puffer kopiert oder übertragen (z. B. über eine DMA-Operation). Wenn das Paket intakt wie dieses übertragen wird, kann eine Auffüllung hinzugefügt werden, um einen Kopfabschnitt des Pakets auf eine Sechzehn-Byte-Grenze auszurichten. Für den Fachmann auf dem Gebiet ist klar, dass das Feld der nächsten Adresse nicht aktualisiert zu werden braucht, um dieses neue Paket zu berücksichtigen, da der Jumbo-Puffer freigegeben wird. Mit anderen Worten, in einer Ausführungsform der Erfindung kann ein Jumbo-Puffer nur einmal (z. B. zum Speichern eines Pakets oder eines Abschnitts eines Pakets) verwendet werden.
Im Zustand 1660 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um den Jumbo-Puffer freizugeben und Informationen an den Host-Computer zur Verarbeitung des Pakets zu liefern. Der Jumbo-Puffer-Index (z. B. die Stelle des Pufferidentifizierers für den Jumbo-Puffer in dem Datenfeld freier Puffer) und der Versatz des Pakets in dem Jumbo-Puffer werden in dem Deskriptor angeordnet. Beispielhaft werden diese Werte im Datenindexfeld bzw. im Datenversatzfeld gespeichert. Die Größe des Pakets (z. B. die Paketlänge) kann in einem Datengrößefeld gespeichert werden.
Ein Kopfgrößefeld wird gelöscht (z. B. eine Null gespeichert), um anzugeben, dass der Kopfpuffer nicht verwendet wurde (z. B., dass der Kopf nicht getrennt von den Daten des Pakets gespeichert wurde). Da es keinen getrennten Paketkopf gibt, werden das Kopfindexfeld und das Kopfversatzfeld nicht verwendet oder auf null gesetzt (wobei z. B. die in ihren Feldern gespeicherten Werte keine Rolle spielen). Ein Kopffreigabemerker wird gelöscht und ein Datenfreigabemerker gesetzt, um anzugeben, dass keine weiteren Daten in diesem Jumbo-Puffer angeordnet werden (z. B., da er freigegeben wird).
Außerdem wird das Deskriptortypfeld auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein nicht wieder zusammensetzbares Paket an den Host-Speicher übertragen hat. Außerdem wird ein vorgegebener Wert (z. B. null) in dem Besitzindikatorfeld des Deskriptors gespeichert, um anzugeben, dass die DMA-Maschine 120 ein Paket an den Host-Computer freigibt und den Besitz des Deskriptors übergibt. In einer alternativen Ausführungsform kann der Deskriptor dadurch freigegeben werden, dass eine Unterbrechung oder eine andere Warnung ausgegeben wird. In einer nochmals weiteren Ausführungsform kann das Ändern des Deskriptortypfelds (z. B. auf einen von null verschiedenen Wert) das Freigeben des Deskriptors signalisieren. In einer Ausführungsform der Erfindung wird der Besitzindikator erst im Endzustand 1699 unten gesetzt. Nach dem Zustand 1660 wird die veranschaulichte Prozedur im Zustand 1668 wieder aufgenommen.
Im Zustand 1662 wird ein erster Abschnitt des Pakets an dem in dem Feld 1134 der nächsten Adresse des Puffers identifizierten Platz in dem vorliegenden (z. B. gültigen) Jumbo-Puffer gespeichert. Daraufhin wird im Zustand 1664 ein neuer Jumbo-Puffer vorbereitet und der Rest des Pakets in diesem Puffer gespeichert, da das volle Paket nicht in diesen Puffer passt.
Im Zustand 1666 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert. Die Inhalte sind ähnlich wie die im Zustand 1660 beschriebenen, wobei dieser Deskriptor aber reflektieren muss, dass zum Speichern des Pakets zwei Jumbo-Puffer verwendet wurden.
Somit werden in dem Deskriptor der Jumbo-Puffer-Index (z. B. der Index des Pufferidentifizierers, der den Kopfpuffer identifiziert, in dem Datenfeld freier Puffer) und der Versatz des Pakets in dem ersten Jumbo-Puffer wie oben angeordnet. Die Größe des Pakets (z. B. die Paketlänge) wird in einem Datengrößefeld gespeichert.
Ein Kopfgrößefeld wird gelöscht (z. B. eine Null gespeichert), um anzugeben, dass der Kopfpuffer nicht verwendet wurde (z. B., dass der Kopf nicht getrennt von den Daten des Pakets gespeichert wurde). Da es keinen getrennten Paketkopf gibt, werden kein Kopfindexfeld und kein Kopfversatzfeld verwendet (wobei z. B. die in ihren Feldern gespeicherten Werte keine Rolle spielen).
Ein Kopffreigabemerker wird gelöscht und ein Datenfreigabemerker gesetzt, um anzugeben, dass keine weiteren Daten in diesen Jumbo-Puffern angeordnet werden (da sie z. B. freigegeben werden). Ferner wird ein Paketteilungsmerker gesetzt, um die Verwendung eines zweiten Jumbo-Puffers zu reflektieren, und der Index des Pufferidentifizierers (in dem Datenfeld freier Puffer) für den zweiten Puffer in einem Feld des nächsten Index gespeichert.
Ferner wird ein Deskriptortypfeld auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein nicht wieder zusammensetzbares Paket an den Host-Speicher übertragen hat. Schließlich wird ein vorgegebener Wert (z. B. null) im Besitzindikatorfeld des Deskriptors gespeichert oder ein anderer Mechanismus verwendet, um anzugeben, dass die DMA-Maschine 120 ein Paket an den Host-Computer freigibt und den Besitz des Deskriptors übergibt. In einer Ausführungsform der Erfindung wird der Deskriptor erst im Endzustand 1699 unten an den Host-Computer freigegeben.
Im Zustand 1668 werden der Jumbo-Puffer-Eintrag oder die Jumbo-Puffer-Einträge in der Jumbo-Puffertabelle 1010 ungültig gemacht (wobei z. B. der Gültigkeitsindikator 1136 auf ungültig gesetzt wird), um sicherzustellen, dass sie nicht wieder verwendet werden. In einer alternativen Ausführungsform der Erfindung kann ein Jumbo-Puffer über irgendeine Anzahl von Puffern gespeichert werden.
Wie für den Fachmann auf dem Gebiet klar, ist der Deskriptor so konfiguriert, dass er die Übertragung eines solchen Pakets berichtet bzw. sind die Deskriptoren so konfiguriert, dass sie die Übertragung eines solchen Pakets berichten.
Nach dem Zustand 1668 wird die veranschaulichte Prozedur mit dem Endzustand 1699 abgeschlossen.
Im Zustand 1670 (der vom Zustand 1654 erreicht wird) ist festgestellt worden, dass das vorliegende Jumbo-Paket geteilt wird, um den Paketkopf in einem Kopfpuffer und die Paketdaten in einem oder in mehreren Jumbo-Puffern zu speichern. Somit stellt die DMA-Maschine 120 (z. B. der DMA-Manager 1002) fest, ob es einen gültigen (z. B. aktiven) Kopfpuffer gibt. Beispielhaft wird diese Feststellung dadurch vorgenommen, dass der Gültigkeitsindikator 1116 der Kopfpuffertabelle 1006 untersucht wird, die das Management des aktiven Kopfpuffers ausführt. Falls der Gültigkeitsindikator gesetzt ist, ist ein Kopfpuffer bereit, dieses Paket zu empfangen, wobei die Prozedur im Zustand 1674 fortgesetzt wird.
Andernfalls wird im Zustand 1672 ein neuer Kopfpuffer vorbereitet oder initialisiert, um kleine Pakete und Köpfe anderer Pakete zu speichern. Beispielhaft umfasst dieser Initialisierungsprozess das Erhalten eines Frei-Ring-Deskriptors aus einem durch den Frei-Ring-Manager 1012 gehaltenen Cache und das Wiedergewinnen seiner Bezugnahme auf einen leeren Puffer. Falls der Cache leer ist, können neue Deskriptoren aus dem Frei-Deskriptor-Ring im Host-Speicher wiedergewonnen werden, um den Cache aufzufüllen.
Wenn aus dem Cache oder aus dem Frei-Deskriptor-Ring ein neuer Deskriptor erhalten wird, wird der in dem Deskriptor enthaltene Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in einem Datenfeld freier Puffer gespeichert. Die Anfangsadresse des Puffers oder eine andere Angabe des ersten Speicherplatzes oder der ersten Zelle in dem Puffer wird im Feld 1114 der nächsten Adresse der Kopfpuffertabelle 1006 angeordnet. Außerdem wird der Index des Pufferidentifizierers in dem Datenfeld freier Puffer im Kopfpufferindex 1112 gespeichert und der Gültigkeitsindikator 1116 auf einen gültigen Zustand gesetzt.
Im Zustand 1674 wird der Kopf des Pakets an die Adresse oder an den Platz, die/der in dem Feld der nächsten Adresse der Kopfpuffertabelle 1006 angegeben ist, in den Kopfpuffer kopiert oder übertragen (z. B. über eine DMA-Operation).
Wie oben beschrieben wurde, werden in einer Ausführungsform der Erfindung Auffüllbytes für den Kopf eingefügt, um dem Beginn des Schicht-Drei-Protokollkopfs (z. B. des IP-Kopfs) des Pakets auf eine Sechzehn-Byte-Grenze auszurichten. Außerdem kann der Kopf des Pakets in einer Zelle vorgegebener Größe (z. B. 256 Bytes) in dem Puffer positioniert werden.
Im Zustand 1676 stellt die DMA-Maschine 120 fest, ob die Daten des Pakets (z. B. die TCP-Nutzinformationen) in einen Jumbo-Puffer passen. Falls das Paket zu groß ist, wird die veranschaulichte Prozedur im Zustand 1682 fortgesetzt.
Im Zustand 1678 werden die Daten des Pakets an den in dem Feld 1134 der nächsten Adresse der Jumbo-Puffer-Tabelle 1010 angegebenen Platz in den momentanen Jumbo-Puffer kopiert oder übertragen (z. B. über eine DMA-Operation). Für den Fachmann auf dem Gebiet ist klar, dass das Feld der nächsten Adresse möglicherweise nicht aktualisiert zu werden braucht, um dieses neue Paket zu berücksichtigen, da der Jumbo-Puffer freigegeben wird. Mit anderen Worten, in einer Ausführungsform der Erfindung kann ein Jumbo-Puffer nur einmal verwendet werden (z. B., um ein Paket oder einen Abschnitt eines Pakets zu speichern).
Im Zustand 1680 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um den Jumbo-Puffer freizugeben und Informationen für die Verarbeitung des Pakets an den Host-Computer zu liefern. Der Kopfpufferindex (z. B. der Index des Pufferidentifizierers des Kopfpuffers in dem Datenfeld freier Puffer) und der Versatz des Kopfs des Pakets in dem Puffer werden im Kopfindexfeld bzw. im Kopfversatzfeld in dem Deskriptor angeordnet. Beispielhaft kann dieser Versatz zum Identifizieren des ersten Bytes des Kopfs, des ersten Auffüllbytes vor dem Kopf oder des Platzes der Zelle, in dem der Kopf gespeichert wird, dienen. Der Jumbo-Puffer-Index (z. B. der Platz oder Index des Pufferidentifizierers, der den Jumbo-Puffer identifiziert, in dem Datenfeld freier Puffer) und der Versatz des ersten Bytes der Daten des Pakets in dem Jumbo-Puffer werden im Datenindexfeld bzw. im Datenversatzfeld angeordnet. Das Kopfgrößefeld und das Datengrößefeld werden verwendet, um die Größe des Kopfs (z. B. den Versatz der Nutzinformationen in dem Paket) bzw. der Daten (z. B. die Nutzinformationsgröße) des Pakets zu speichern.
Falls der Kopfpuffer voll ist, wird in dem Deskriptor ein Kopffreigabemerker gesetzt. Allerdings kann der Kopfpuffer erst in einem späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform der Erfindung kann der Kopffreigabemerker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden. Ein Datenfreigabemerker wird ebenfalls gesetzt, da keine weiteren Daten in dem Jumbo-Puffer angeordnet werden (wobei er z. B. an den Host-Computer freigegeben wird).
Das Deskriptortypfeld wird auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein nicht wieder zusammensetzbares Paket an den Host-Speicher übertragen hat. Außerdem wird ein vorgegebener Wert (z. B. null) in dem Besitzindikatorfeld des Deskriptors gespeichert, um anzugeben, dass die DMA-Maschine 120 ein Paket an den Host-Computer freigibt und den Besitz des Deskriptors übergibt. In einer Ausführungsform der Erfindung wird der Besitzindikator erst im Endzustand 1699 unten geändert. In einer alternativen Ausführungsform kann der Deskriptor dadurch freigegeben werden, dass eine Unterbrechung oder eine andere Warnung ausgegeben wird. In einer nochmals weiteren alternativen Ausführungsform kann das Ändern des Deskriptortypwerts die Freigabe des Deskriptors signalisieren.
Nach dem Zustand 1680 wird die veranschaulichte Prozedur im Zustand 1688 fortgesetzt.
Im Zustand 1682 wird ein erster Abschnitt der Daten des Pakets an dem im Feld 1134 der nächsten Adresse des Puffers identifizierten Platz in dem vorliegenden (z. B. gültigen) Jumbo-Puffer gespeichert.
Da nicht alle Daten des Pakets in diesen Puffer passen, wird im Zustand 1684 ein neuer Jumbo-Puffer vorbereitet und der Rest des Pakets in diesem Puffer gespeichert.
Im Zustand 1686 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert. Die Inhalte sind ähnlich den in den Zuständen 1680 beschriebenen, wobei dieser Deskriptor aber reflektieren muss, dass zwei Jumbo-Puffer zum Speichern des Pakets verwendet wurden. Der Kopfpufferindex (z. B. der Index des Elements des Datenfelds freier Puffer, das den Pufferidentifizierer des Kopfpuffers enthält) und der Versatz (z. B. der Platz des Kopfs des Pakets in dem Kopfpuffer) werden im Kopfindexfeld bzw. im Kopfversatzfeld in dem Deskriptor angeordnet. Der Jumbo-Puffer-Index (z. B. der Index des Pufferidentifizierers, der auf den Jumbo-Puffer Bezug nimmt, in dem Datenfeld freier Puffer) und der Versatz des ersten Bytes der Daten des Pakets in dem Jumbo-Puffer werden im Datenindexfeld bzw. im Datenversatzfeld angeordnet. Das Kopfgrößefeld und das Datengrößefeld werden verwendet, um die Größe des Kopfs (z. B. wie durch den Versatz der Nutzinformationen des Pakets von dem Start des Pakets gemessen) bzw. der Daten (z. B. die Nutzinformationsgröße) des Pakets zu speichern.
Falls der Kopfpuffer voll ist, wird ein Kopffreigabemerker in dem Deskriptor gesetzt. Allerdings kann der Kopfpuffer erst in einem späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform der Erfindung kann der Kopffreigabemerker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden. Ein Datenfreigabemerker wird ebenfalls gesetzt, da keine weiteren Daten in dem Jumbo-Puffer angeordnet werden (wobei er z. B. an den Host-Computer freigegeben wird). Ferner wird ein Paketteilungsmerker gesetzt, um anzugeben, dass ein zweiter Jumbo-Puffer verwendet wurde, und der Platz (innerhalb des Datenfelds freier Puffer oder einer anderen Datenstruktur) des Pufferidentifizierers des zweiten Puffers in einem Feld des nächsten Index gespeichert.
Das Deskriptortypfeld wird auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein nicht wieder zusammensetzbares Paket an den Host-Speicher übertragen hat. Schließlich wird ein vorgegebener Wert (z. B. null) in dem Besitzindikatorteld des Deskriptors gespeichert, um anzugeben, dass die DMA-Maschine 120 ein Paket an den Host-Computer freigibt und den Besitz des Deskriptors übergibt. In einer Ausführungsform der Erfindung wird der Besitzindikator erst im Endzustand 1699 unten geändert.
Im Zustand 1688 wird der Eintrag des Jumbo-Puffers in der Jumbo-Puffertabelle 1010 ungültig gemacht (z. B. der Gültigkeitsindikator 1136 auf ungültig gesetzt), um sicherzustellen, dass er nicht wieder verwendet wird. In der oben beschriebenen Prozedur wurde ein Jumbo-Paket höchstens in zwei Jumbo-Puffern gespeichert. In einer alternativen Ausführungsform der Erfindung kann ein Jumbo-Paket über irgendeine Anzahl von Puffern gespeichert werden. Wie für den Fachmann auf dem Gebiet klar ist, ist der Deskriptor, der zum Berichten der Übertragung eines solchen Pakets konfiguriert ist, dementsprechend konstruiert.
Im Zustand 1690 wird festgestellt, ob der Kopfpuffer voll ist. In dieser Ausführungsform der Erfindung, in der jeder Puffer eine Größe von acht Kilobytes hat und die Einträge in dem Kopfpuffer nicht länger als 256 Bytes sind, kann ein Zähler verwendet werden, um die in jedem neuen Kopfpuffer angeordneten Einträge zu verfolgen. Wenn zweiunddreißig Einträge gespeichert worden sind, kann der Puffer als voll betrachtet werden.
Falls der Puffer voll ist, wird der Kopfpuffer im Zustand 1692 ungültig gemacht, um sicherzustellen, dass er nicht wieder verwendet wird. Beispielhaft umfasst dies das Setzen des Gültigkeitsindikators der Kopfpuffertabelle auf ungültig und das Übermitteln dieses Status an den Host-Computer. In dieser Ausführungsform der Erfindung wird ein Kopffreigabemerker in dem Deskriptor gesetzt. Daraufhin wird die veranschaulichte Prozedur mit dem Endzustand 1699 abgeschlossen.
Falls der Kopfpuffer nicht voll ist, wird im Zustand 1694 das Feld der nächsten Adresse der Kopfpuffertabelle 1006 aktualisiert, um die Adresse anzugeben, an der der nächste Kopf oder das nächste kleine Paket zu speichern ist. Daraufhin wird die veranschaulichte Prozedur mit dem Endzustand 1699 abgeschlossen.
Wie oben beschrieben wurde, kann im Endzustand 1699 ein Deskriptor an den Host-Computer übergeben werden, indem ein Wert in dem Deskriptortypfeld des Deskriptors (z. B. von eins auf null) geändert wird. Beispielhaft erfasst der Host-Computer (oder die in dem Host-Computer arbeitende Software) die Änderung und versteht, dass die DMA-Maschine 120 den Besitz des Deskriptors an den Host-Computer zurückgibt.
EIN VERFAHREN ZUM ÜBERTRAGEN EINES PAKETS MIT DEM OPERATIONSCODE 3
Die 17A–17C veranschaulichen eine Prozedur, in der die DMA-Maschine 120 ein Paket, dem der Operationscode 3 zugeordnet ist, an einen Host-Speicherpuffer überträgt. Wie TABELLE 1 widerspiegelt, kann der Operationscode 3 angeben, dass das Paket mit einem Protokoll, das durch die NIC 100 syntaktisch analysiert werden kann, kompatibel ist und einen letzten Datenabschnitt für seinen Fluss trägt. Es wird kein neuer Fluss aufgebaut, wobei aber bereits ein Fluss existieren sollte und abzubauen ist. Die Daten des Pakets sind mit Daten von früheren Flusspaketen wieder zusammenzusetzen. Da das Paket wieder zusammenzusetzen ist, sollte der Kopf des Pakets in einem Kopfpuffer gespeichert werden und sollten seine Daten in einem Wiederzusammensetzungspuffer des Flusses gespeichert werden. Der aktive Wiederzusammensetzungspuffer des Flusses kann durch den Eintrag des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 identifiziert werden.
Im Zustand 1007 stellt die DMA-Maschine 120 (z. B. der DMA-Manager 1002) fest, ob es einen gültigen (z. B. aktiven) Kopfpuffer gibt. Beispielhaft wird diese Feststellung vorgenommen, indem der Gültigkeitsindikator 1116 der Kopfpuffertabelle 1006 untersucht wird, der das Management des aktiven Kopfpuffers ausführt. Falls der Gültigkeitsindikator gesetzt ist (z. B. gleich eins ist), wird angenommen, dass ein Kopfpuffer bereit ist, dieses Paket zu empfangen, wobei die Prozedur im Zustand 1704 fortgesetzt wird.
Ansonsten wird im Zustand 1702 ein neuer Kopfpuffer zum Speichern kleiner Pakete und Köpfe wieder zusammengesetzter Pakete vorbereitet oder initialisiert. Dieser Initialisierungsprozess kann das Erhalten eines Frei-Ring-Deskriptors aus einem durch den Frei-Ring-Manager 1012 gehaltenen Cache und das Wiedergewinnen seines Pufferidentifizierers (z. B. einer Bezugnahme auf einen verfügbaren Speicherpuffer) umfassen. Falls der Cache leer ist, können aus dem Frei-Deskriptor-Ring im Host-Speicher neue Deskriptoren wiedergewonnen werden, um den Cache aufzufüllen.
Beispielhaft wird der in dem Deskriptor enthaltene Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in einem Datenfeld freier Puffer gespeichert, wenn ein neuer Deskriptor aus dem Cache oder aus dem Frei-Deskriptor-Ring erhalten wird. Die Anfangsadresse des Puffers oder eine andere Angabe des ersten Speicherplatzes oder der ersten Zelle in dem Puffer wird im Feld 1114 der nächsten Adresse der Kopfpuffertabelle 1006 angeordnet. Ferner wird der Index des Pufferidentifizierers in dem Datenfeld freier Puffer im Kopfpufferindex 1112 gespeichert und der Gültigkeitsindikator 1116 auf einen gültigen Zustand gesetzt.
Im Zustand 1704 wird der Kopf des Pakets an die Adresse oder an den Platz, die/der in dem Feld der nächsten Adresse der Kopfpuffertabelle 1006 angegeben ist, in den Kopfpuffer kopiert oder übertragen. Wie oben beschrieben wurde, können in einer Ausführungsform der Erfindung Auffüllbytes vor dem Kopf eingefügt werden, um den Beginn des Schicht-Drei-Protokollkopfs (z. B. des IP-Kopfs) des Pakets auf eine Sechzehn-Byte-Grenze auszurichten. Außerdem kann der Kopf in einer Zelle vorgegebener Größe (z. B. 256 Bytes) in dem Kopfpuffer positioniert werden.
In der veranschaulichten Ausführungsform gibt der Operationscode 3 an, dass ein vorhandener Fluss abzubauen ist (wobei z. B. der Flusswiederzusammensetzungspuffer ungültig zu machen und an den Host-Computer freizugeben ist). Somit wird im Zustand 1706 festgestellt, ob ein Flusswiederzusammensetzungspuffer für diesen Fluss gültig (z. B. aktiv) ist, indem der Gültigkeitsindikator in dem Eintrag des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 untersucht wird. Beispielhaft sollte es einen aktiven Puffer geben, der Daten von einem oder von mehreren Paketen in diesem Fluss speichert, falls der Indikator gültig ist. Falls es einen gültigen Flusswiederzusammensetzungspuffer für diesen Fluss gibt, wird die veranschaulichte Prozedur im Zustand 1712 fortgesetzt. Ansonsten geht die Prozedur zum Zustand 1708 über.
Im Zustand 1708 wird ein neuer Flusswiederzusammensetzungspuffer vorbereitet, um die Daten dieses Pakets zu speichern. Beispielhaft wird ein Frei-Ring-Deskriptor aus einem Cache erhalten, der durch den Frei-Ring-Manager 1012 gehalten wird, und seine Bezugnahme auf einen leeren Puffer wiedergewonnen. Falls der Cache leer ist, können neue Deskriptoren aus dem Frei-Deskriptor-Ring im Host-Computer wiedergewonnen werden, um den Cache aufzufüllen.
Wenn ein neuer Deskriptor aus dem Cache oder aus dem Frei-Deskriptor-Ring erhalten wird, wird der in dem Deskriptor enthaltene Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in einem Datenfeld freier Puffer gespeichert. Die Anfangsadresse des Puffers oder eine andere Angabe seines ersten Speicherplatzes wird in dem Feld 1104 der nächsten Adresse des Eintrags des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 angeordnet. Der Eintrag des Flusses in der Wiederzusammensetzungspuffertabelle kann durch seine Flussnummer erkannt werden. Der Platz des Pufferidentifizierers in dem Datenfeld freier Puffer wird im Wiederzusammensetzungspufferindex 1102 gespeichert und der Gültigkeitsindikator 1106 auf einen gültigen Zustand gesetzt.
Im Zustand 1710 werden die Daten des Pakets in die Adresse oder in die Stelle, die in dem Feld der nächsten Adresse des Eintrags des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 angegeben ist, kopiert oder übertragen (z. B. über eine DMA-Operation).
Im Zustand 1712 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um den Wiederzusammensetzungspuffer des Flusses freizugeben und Informationen zum Verarbeiten des Pakets an den Host-Computer zu liefern. Insbesondere werden in dem Deskriptor der Kopfpufferindex (z. B. der Index des Identifizierers des Kopfpuffers in dem Datenfeld freier Puffer) und der Versatz des Kopfs des Pakets in dem Kopfpuffer angeordnet. Beispielhaft dient dieser Versatz dazu, das erste Byte des Kopfs, das erste Auffüllbyte, das dem Kopf vorausgeht, oder die Zelle, in der der Kopf gespeichert ist, zu identifizieren. Der Flusswiederzusammensetzungs-Puffer-Index (z. B. der Index des Identifizierers des Flusswiederzusammensetzungspufters in dem Datenfeld freier Puffer) und der Versatz der Daten des Pakets in diesem Puffer werden ebenfalls in dem Deskriptor gespeichert.
Die Größe des Datenabschnitts (z. B. die Größe der TCP-Nutzinformationen des Pakets) und des Kopfabschnitts (z. B. der Versatz der TCP-Nutzinformationen in dem Paket) des Pakets werden im Datengrößefeld bzw. im Kopfgrößefeld gespeichert. Das Deskriptortypfeld erhält einen Wert, der angibt, dass ein Flusspaket an den Host-Speicher übertragen worden ist. Falls der Kopfpuffer voll ist, kann ein Kopffreigabemerker gesetzt werden, und zur Angabe, dass keine weiteren Daten in diesem Flusswiederzusammensetzungspuffer angeordnet werden (da er z. B. freigegeben wird), kann ein Datenfreigabemerker gesetzt werden. Außerdem wird ein Flussfreigabemerker gesetzt, um anzugeben, dass die DMA-Maschine 120 den Fluss des Pakets abbaut. Der Kopfpuffer kann erst in einen späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform kann der Kopffreigabemerker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden.
Daraufhin wird im Zustand 1714 der Flusswiederzusammensetzungspuffer ungültig gemacht, indem der Gültigkeitsindikator 1106 in dem Eintrag des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 geeignet geändert wird. Nach dem Zustand 1714 wird die Prozedur im Zustand 1730 fortgesetzt.
Im Zustand 1716 stellt die DMA-Maschine 120 fest, ob die TCP-Nutzinformationen des Pakets (z. B. der Datenabschnitt des Pakets) in den gültigen Flusswiederzusammensetzungspuffer passen. Wenn das nicht der Fall ist, wird die veranschaulichte Prozedur im Zustand 1722 fortgesetzt.
Im Zustand 1718 werden die Paketdaten an den in dem Feld 1104 der nächsten Adresse des Eintrags des Flusses in der Flusswiederzusammensetzungstabelle 1004 angegebenen Platz in den Wiederzusammensetzungspuffer des Flusses kopiert oder übertragen (z. B. über eine DMA-Operation). Für den Fachmann auf dem Gebiet ist klar, dass das Feld der nächsten Adresse aktualisiert oder nicht aktualisiert werden kann, um dieses neue Paket zu berücksichtigen, da der Wiederzusammensetzungspuffer freigegeben wird.
Im Zustand 1720 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um den Wiederzusammensetzungspuffer des Flusses freizugeben und Informationen zum Verarbeiten des Pakets an den Host-Computer zu liefern. Der Kopfpufferindex (z. B. der Platz oder Index des Identifizierers des Kopfpuffers in dem Datenfeld freier Puffer) und der Versatz des Kopfs des Pakets in dem Kopfpuffer werden in dem Deskriptor angeordnet. Der Flusswiederzusammensetzungs-Puffer-Index (z. B. der Platz oder Index des Identifizierers des Flusswiederzusammensetzungspuffers in dem Datenfeld freier Puffer) und der Versatz der Daten des Pakets in diesem Puffer werden ebenfalls in dem Deskriptor gespeichert.
Die Größe der Daten (z. B. die Größe der TCP-Nutzinformationen des Pakets) und des Kopfs (z. B. der Versatz der TCP-Nutzinformationen in dem Paket) des Pakets werden im Datengrößefeld bzw. im Kopfgrößefeld gespeichert. Das Deskriptortypfeld erhält einen Wert, der angibt, dass ein Flusspaket an den Host-Speicher übertragen worden ist. Falls der Kopfpuffer voll ist und ein Datenfreigabemerker gesetzt ist, um anzugeben, dass keine weitere Daten in diesem Flusswiederzusammensetzungspuffer angeordnet werden (da er z. B. freigegeben wird), wird ein Kopffreigabemerker gesetzt. Wie oben erläutert wurde, kann der Kopfpuffer erst in einem späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist, wobei zu diesem Zeitpunkt der Kopffreigabemerker gesetzt werden kann. Schließlich wird ein Flussfreigabemerker gesetzt, um anzugeben, dass die DMA-Maschine 120 den Fluss des Pakets abbaut. Nach dem Zustand 1720 wird die veranschaulichte Prozedur im Zustand 1728 wieder aufgenommen.
Im Zustand 1722 wird ein erster Abschnitt der Nutzinformationen des Pakets (z. B. Daten) an dem in dem Feld 1104 der nächsten Adresse des Puffers identifizierten Platz in dem vorliegenden (z. B. gültigen) Wiederzusammensetzungspuffer des Flusses gespeichert.
Da die vollen Nutzinformationen nicht in diesen Puffer passen, wird im Zustand 1724 ein neuer Flusswiederzusammensetzungspuffer vorbereitet und der Rest der Nutzinformationen in diesem Puffer gespeichert. In einer Ausführungsform der Erfindung werden Informationen, die den ersten Puffer betreffen, in einem Abschluss-Deskriptor gespeichert. Diese Informationen können die Stelle des Pufferidentifizierers des ersten Puffers in dem Datenfeld freier Puffer und den Versatz des ersten Datenabschnitts in dem Puffer enthalten. Daraufhin kann der Eintrag des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 für den zweiten Puffer aktualisiert werden (wobei z. B. eine erste Adresse im Feld 1104 der nächsten Adresse und der Platz des Identifizierers des Puffers in dem Datenfeld freier Puffer im Wiederzusammensetzungspufferindex 1102 gespeichert werden).
Im Zustand 1726 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert. Die Inhalte sind ähnlich den für die Zustände 1712 und 1720 beschriebenen, wobei dieser Deskriptor aber reflektieren muss, dass zwei Wiederzusammensetzungspuffer verwendet wurden.
Somit werden wie oben in dem Deskriptor der Kopfpufferindex (z. B. der Platz des Pufferidentifizierers, der dem Kopfpuffer entspricht, im Datenfeld freier Puffer) und der Versatz des Kopfs des Pakets in dem Kopfpuffer angeordnet. Der erste Flusswiederzusammensetzungs-Puffer-Index (z. B. die Stelle des Pufferidentifizierers, der dem ersten zum Speichern der Nutzinformationen dieses Pakets verwendeten Flusswiederzusammensetzungspuffer in dem Datenfeld freier Puffer entspricht) und der Versatz des ersten Datenabschnitts des Pakets in diesem Puffer werden ebenfalls in dem Deskriptor gespeichert.
Die Größe der Daten (z. B. die Größe der TCP-Nutzinformationen des Pakets) und des Kopfs (z. B. der Versatz der TCP-Nutzinformationen in dem Paket) des Pakets werden im Datengrößefeld bzw. im Kopfgrößefeld gespeichert. Das Deskriptortypfeld erhält einen Wert, der angibt, dass ein Flusspaket an den Host-Speicher übertragen worden ist. Falls der Kopfpuffer voll ist, wird ein Kopffreigabemerker gesetzt, während ein Datenfreigabemerker gesetzt wird, um anzugeben, dass keine weiteren Daten in diesem Flusswiederzusammensetzungspuffer angeordnet werden. Ein Flussfreigabemerker wird gesetzt, um anzugeben, dass die DMA-Maschine 120 den Fluss des Pakets abbaut.
Da zwei Wiederzusammensetzungspuffer verwendet wurden, wird ein Paketteilungsmerker gesetzt und der Index des Pufferidentifizierers des Wiederzusam mensetzungspuffers in dem Datenfeld freier Puffer in einem Feld des nächsten Index gespeichert. Da das Paket einen letzten Datenabschnitt für den Fluss enthält, kann außerdem ein Merker für die Freigabe des nächsten Datenpuffers gesetzt werden, um anzugeben, dass der zweite Flusswiederzusammensetzungspuffer freigegeben wird.
Im Zustand 1728 wird der Eintrag des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 ungültig gemacht, um sicherzustellen, dass er nicht wieder verwendet wird.
Im Zustand 1730 wird festgestellt, ob der Kopfpuffer voll ist. In dieser Ausführungsform der Erfindung, in der jeder Puffer eine Größe von acht Kilobytes hat und Einträge in dem Kopfpuffer nicht länger als 256 Bytes sind, wird ein Zähler verwendet, um die in jedem neuen Kopfpuffer angeordneten Einträge zu verfolgen. Wenn zweiunddreißig Einträge gespeichert worden sind, wird der Puffer als voll betrachtet.
Falls der Puffer voll ist, wird der Kopfpuffer im Zustand 1732 ungültig gemacht, um sicherzustellen, dass er nicht wieder verwendet wird. Beispielhaft umfasst dies das Setzen des Gültigkeitsindikators der Kopfpuffertabelle auf ungültig und das Übermitteln dieses Status an den Host-Computer. In dieser Ausführungsform der Erfindung wird ein Kopffreigabemerker in dem Deskriptor gesetzt.
Falls der Kopfpuffer nicht voll ist, wird im Zustand 1734 das Feld der nächsten Adresse der Kopfpuffertabelle 1006 aktualisiert, um die Adresse anzugeben, an der der nächste Kopf oder das nächste kleine Paket zu speichern ist.
Daraufhin wird die einem Paket mit dem Operationscode 3 zugeordnete Verarbeitung mit dem Endzustand 1799 abgeschlossen. In diesem Endzustand wird der für dieses Paket verwendete Deskriptor durch Ändern seines Besitzindikatorfelds (z. B. von eins auf null) an den Host-Computer übergeben. Alternativ kann ein anderer Mechanismus wie etwa das Ausgeben einer Unterbrechung oder das Ändern des Deskriptortypfelds des Deskriptors verwendet werden. Beispielhaft wird das Deskriptortypfeld auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein Flusspaket an den Host-Speicher übertragen hat.
In einer alternativen Ausführungsform der Erfindung kann bei der Verarbeitung eines Pakets mit dem Operationscode 3 eine Optimierung ausgeführt werden. Diese Optimierung nutzt die Kenntnis, dass das Paket den letzten Datenabschnitt für seinen Fluss enthält. Insbesondere kann der Deskriptor dort verwendet werden, wo er ist – in einem Deskriptor-Cache, der durch den Frei-Ring-Manager 1012 gehalten wird -, anstatt einen Deskriptor in die Flusswiederzusammensetzungs-Puffer-Tabelle 1004 zu laden.
Anstatt einen Pufferidentifizierer aus einem Deskriptor wiederzugewinnen und ihn im Zustand 1708 oben in einem Datenfeld zu speichern, kann es z. B. effizienter sein, den Deskriptor zu verwenden, ohne ihn aus dem Cache zu entfernen, um nur die Daten eines Pakets in dem identifizierten Puffer zu speichern, bevor er freigegeben wird. Wenn in dieser Ausführungsform ein Abschluss-Deskriptor geschrieben wird, werden die in seinem Datenindexfeld und in seinem Datenversatzfeld gespeicherten Werte aus einem Deskriptor in dem Deskriptor-Cache wiedergewonnen. Ähnlich kann ein Deskriptor in dem Deskriptor-Cache wieder verwendet werden, ohne ihn zuerst in ein Datenfeld freier Puffer und in die Flusswiederzusammensetzungs-Puffer-Tabelle zu laden, wenn der erste Abschnitt der Daten eines Code-3-Pakets in den aktiven Puffer des Flusses passt, während nur für die verbleibenden Daten ein neuer benötigt wird. In dieser Situation wird von dem Deskriptor in dem Deskriptor-Cache das nächste Indexfeld des Abschluss-Deskriptors wiedergewonnen.
EIN VERFAHREN ZUM ÜBERTRAGEN EINES PAKETS MIT DEM OPERATIONSCODE 4
Die 18A–18D zeigen eine beispielhafte Prozedur, in der die DMA-Maschine 120 ein Paket, dem der Operationscode 4 zugeordnet ist, an einen Host-Speicherpuffer überträgt. Wie TABELLE 1 widerspiegelt, gibt der Operationscode 4 in dieser Ausführungsform an, dass das Paket mit den Protokollen, die durch die NIC 100 syntaktisch analysiert werden können, kompatibel ist und einen Fluss fortsetzt, der bereits aufgebaut worden ist. Es wird kein neuer Fluss aufgebaut, der vorhandene Fluss ist nicht abzubauen und die Daten des Pakets sind mit Daten aus anderen Flusspaketen wieder zusammenzusetzen. Da das Paket wieder zusammenzusetzen ist, sollten der Kopf des Pakets in einem Kopfpuffer und seine Daten in dem Wiederzusammensetzungspuffer des Flusses gespeichert werden.
Im Zustand 1800 stellt die DMA-Maschine 120 fest, ob es einen gültigen (z. B. aktiven) Kopfpuffer gibt. Beispielhaft wird diese Feststellung durch Untersuchung des Gültigkeitsindikators 1116 der Kopfpuffertabelle 1006, die das Management des aktiven Kopfpuffers ausführt, vorgenommen. Falls der Gültigkeitsindikator gesetzt ist, sollte es einen Kopfpuffer geben, der bereit ist, dieses Paket zu empfangen, wobei die Prozedur im Zustand 1804 fortgesetzt wird.
Ansonsten wird im Zustand 1802 ein neuer Kopfpuffer zum Speichern kleiner Pakete und Köpfe wieder zusammengesetzter Pakete vorbereitet oder initialisiert. Beispielhaft umfasst dieser Initialisierungsprozess das Erhalten eines Frei-Ring-Deskriptors aus einem Cache, der durch den Frei-Ring-Manager 1012 gehalten wird, und das Wiedergewinnen seiner Bezugnahme auf einen leeren Puffer. Falls der Cache leer ist, können neue Deskriptoren aus dem Frei-Deskriptor-Ring im Host-Speicher wiedergewonnen werden, um den Cache aufzufüllen.
Wenn aus dem Cache oder aus dem Frei-Deskriptor-Ring ein neuer Deskriptor erhalten wird, wird der in dem Deskriptor enthaltene Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in einem Datenfeld freier Puffer gespeichert. Die Anfangsadresse des Puffers oder eine andere Angabe des ersten Speicherplatzes in dem Puffer wird im Feld 1114 der nächsten Adresse der Kopfpuffertabelle 1006 angeordnet. Außerdem wird die Stelle oder der Index des Pufferidentifizierers in dem Datenfeld freier Puffer im Kopfpufferindex 1112 gespeichert und der Gültigkeitsindikator 1116 auf einen gültigen Zustand gesetzt.
Im Zustand 1804 wird der Kopf des Pakets an die Adresse oder an den Platz, die/der in dem Feld der nächsten Adresse der Kopfpuffertabelle 1006 angegeben ist, in den Kopfpuffer kopiert oder übertragen. Wie oben beschrieben wurde, werden in einer Ausführungsform der Erfindung Auffüllbytes vor dem Kopf eingefügt, um den Beginn des Schicht-Drei-Protokollkopfs (z. B. des IP-Kopfs) des Pakets auf eine Sechzehn-Byte-Grenze auszurichten. Außerdem kann der Kopf des Pakets in einer Zelle vorgegebener Größe (z. B. 256 Bytes) in dem Puffer positioniert werden.
In der veranschaulichten Ausführungsform gibt der Operationscode 4 an, dass ein vorhandener Fluss fortzusetzen ist. Somit wird im Zustand 1806 festgestellt, ob ein Flusswiederzusammensetzungspuffer für diesen Fluss gültig (z. B. aktiv) ist, indem der Gültigkeitsindikator in dem Eintrag des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 untersucht wird. Beispielhaft gibt es einen aktiven Puffer, der Daten von einem oder von mehreren Paketen in diesem Fluss speichert, falls der Indikator gültig ist. Falls es einen gültigen Flusswiederzusammensetzungspuffer für diesen Fluss gibt, wird die veranschaulichte Prozedur im Zustand 1808 fortgesetzt. Ansonsten geht die Prozedur zum Zustand 1810 über.
Im Zustand 1808 wird festgestellt, ob der Datenabschnitt des Pakets (z. B. sein TCP-Nutzinformationsabschnitt) zu groß für den momentanen Flusswiederzusammensetzungspuffer ist. Falls der Datenabschnitt zu groß ist, werden zwei Flusswiederzusammensetzungspuffer verwendet, wobei die veranschaulichte Prozedur zum Zustand 1830 übergeht. Ansonsten wird die Prozedur im Zustand 1820 fortgesetzt.
Im Zustand 1810 wird ein neuer Flusswiederzusammensetzungspuffer vorbereitet, da (im Zustand 1806) ermittelt wurde, dass es keinen gültigen Flusswiederzusammensetzungspuffer für dieses Paket gibt. Beispielhaft wird aus einem durch den Frei-Ring-Manager 1012 gehaltenen Cache ein Frei-Ring-Deskriptor erhalten und seine Bezugnahme auf einen leeren Puffer wiedergewonnen. Falls der Cache leer ist, können neue Deskriptoren aus dem Frei-Deskriptor-Ring im Host-Speicher wiedergewonnen werden, um den Cache aufzufüllen.
Wenn aus dem Cache oder aus dem Frei-Deskriptor-Ring ein neuer Deskriptor erhalten wird, wird der in dem Deskriptor enthaltene Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in einem Datenfeld freier Puffer gespeichert. Die Anfangsadresse des Puffers oder ein anderer Indikator seines ersten Speicherplatzes wird im Feld 1104 der nächsten Adresse des Eintrags des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 angeordnet. Der Eintrag des Flusses in der Tabelle kann durch seine Flussnummer erkannt werden. Der Platz des Pufferidentifizierers in dem Datenfeld freier Puffer wird im Wiederzusammensetzungspufferindex 1102 gespeichert und der Gültigkeitsindikator 1106 auf einen gültigen Wert gesetzt.
Im Zustand 1812 werden die Daten des Pakets an die Adresse oder an den Platz, die/der in dem Feld der nächsten Adresse des Eintrags des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 angegeben ist, kopiert oder übertragen (z. B. über eine DMA-Operation).
Im Zustand 1814 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um an den Host-Computer Informationen für die Verarbeitung des Pakets zu liefern. Insbesondere werden in dem Deskriptor der Kopfpufferindex (z. B. der Index des Pufferidentifizierers, der den Kopfpuffer identifiziert, in dem Datenfeld freier Puffer) und der Versatz des Kopfs des Pakets in dem Kopfpuffer angeordnet. Beispielhaft kann dieser Versatz dazu dienen, das erste Byte des Kopfs, das erste Auffüllbyte, das dem Kopf vorangeht, oder die Zelle des Kopfs in dem Kopfpuffer zu identifizieren. Der Flusswiederzusammensetzungs-Puffer-Index (z. B. der Index des Pufferidentifizierers, der den Flusswiederzusammensetzungspufter identifiziert, in dem Datenfeld freier Puffer) und der Versatz der Daten des Pakets in diesem Puffer werden ebenfalls in dem Deskriptor gespeichert.
Die Größe der Daten (z. B. die Größe der TCP-Nutzinformationen des Pakets) und des Kopfs (z. B. der Versatz der TCP-Nutzinformationen in dem Paket) des Pakets werden im Datengrößefeld bzw. im Kopfgrößefeld gespeichert. Das Deskriptortypfeld erhält einen Wert, der angibt, dass ein Flusspaket an den Host-Speicher übertragen worden ist. Falls der Kopfpuffer voll ist, aber kein Datenfreigabemerker gesetzt ist, da weitere Daten in diesem Flusswiederzusammensetzungspuffer angeordnet werden, wird ein Kopffreigabemerker gesetzt. Der Kopfpuffer kann erst zu einem späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform kann der Kopffreigabemerker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden.
In einer Ausführungsform der Erfindung kann in Abhängigkeit von dem dynamischen Paketblockbildungsmodul 122 auch ein Flussfreigabemerker gesetzt werden. Zum Beispiel wird der Flussfreigabemerker gelöscht (z. B. eine Null gespeichert), falls das Paketblockbildungsmodul feststellt, dass bald ein weiteres Paket in dem gleichen Fluss an den Host-Computer übertragen wird. Dies gibt an, dass der Host-Computer auf das nächste Flusspaket warten sollte, bevor er dieses verarbeitet. Durch gemeinsames Verarbeiten mehrerer Pakete aus einem einzigen Fluss können die Pakete effizienter verarbeitet werden und ist weniger Prozessorzeit erforderlich. Falls allerdings keine weiteren Pakete in dem gleichen Fluss identifiziert werden, kann der Flussfreigabemerker gesetzt (z. B. eine Eins gespeichert) werden, um anzugeben, dass der Host-Computer die Flusspakete, die er bisher empfangen hat, verarbeiten sollte, ohne auf weitere zu warten.
Im Zustand 1816 wird der Eintrag des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 aktualisiert. Insbesondere wird das Feld 1104 der nächsten Adresse aktualisiert, um den Platz in dem Wiederzusammensetzungspuffer zu identifizieren, an dem die Daten des nächsten Flusspakets gespeichert werden sollten. Nach dem Zustand 1816 wird die veranschaulichte Prozedur im Zustand 1838 fortgesetzt.
Im Zustand 1820 (der vom Zustand 1808 erreicht wird) ist bekannt, dass die Daten des Pakets oder die TCP-Nutzinformationen in den momentanen Wiederzusammensetzungspuffer des Flusses passen. Somit werden die Paketdaten an den Platz, der in dem Feld 1104 der nächsten Adresse des Eintrags des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 identifiziert ist, in den Puffer kopiert oder übertragen.
Im Zustand 1822 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um Informationen zur Verarbeitung des Pakets an den Host-Computer zu liefern. Insbesondere werden in dem Deskriptor der Kopfpufferindex (z. B. der Index des Pufferidentifizierers, der den Kopfpuffer identifiziert, in dem Datenfeld freier Puffer) und der Versatz des Kopfs des Pakets in dem Kopfpuffer angeordnet. Der Flusswiederzusammensetzungs-Puffer-Index (z. B. der Index des Pufferidentifizierers, der den Flusswiederzusammensetzungspuffer identifiziert, in dem Datenfeld freier Puffer) und der Versatz der Daten des Pakets in diesem Puffer werden ebenfalls in dem Deskriptor gespeichert.
Die Größe der Daten (z. B. die Größe der TCP-Nutzinformationen des Pakets) und des Kopfs (z. B. der Versatz der TCP-Nutzinformationen in dem Paket) des Pakets werden im Datengrößefeld bzw. im Kopfgrößefeld gespeichert. Das Deskriptortypfeld erhält einen Wert, der angibt, dass ein Flusspaket an den Host-Speicher übertragen worden ist. Falls der Kopfpuffer voll ist, wird ein Kopffreigabemerker gesetzt, während ein Datenfreigabemerker nur dann gesetzt wird, wenn der Flusswiederzusammensetzungspuffer jetzt voll ist. Der Kopfpuffer und der Flusswiederzusammensetzungspuffer können erst in einem späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob sie voll sind. In einer solchen Ausführungsform können die Merker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden.
In einer Ausführungsform der Erfindung kann in Abhängigkeit von dem dynamischen Paketblockbildungsmodul 122 auch ein Flussfreigabemerker gesetzt werden. Zum Beispiel wird der Flussfreigabemerker gelöscht, falls das Paketblockbildungsmodul feststellt, dass bald ein weiteres Paket in dem gleichen Fluss an den Host-Computer übertragen wird. Dies gibt an, dass der Host-Computer auf das nächste Flusspaket warten sollte, bevor er dieses verarbeitet. Durch gemeinsames Verarbeiten mehrerer Pakete aus einem einzigen Fluss können die Pakete effizienter verarbeitet werden und ist weniger Prozessorzeit erforderlich. Falls aber keine weiteren Pakete in dem gleichen Fluss identifiziert werden, kann der Flussfreigabemerker gesetzt werden, um anzugeben, dass der Host-Computer die bisher empfangenen Flusspakete verarbeiten sollte, ohne auf weitere zu warten.
Im Zustand 1824 wird der Flusswiederzusammensetzungspuffer untersucht, um festzustellen, ob er voll ist. In der gegenwärtig beschriebenen Ausführungsform der Erfindung wird dieser Test dadurch durchgeführt, dass zunächst festgestellt wird, wie viel Daten (z. B. wie viel Bytes) in dem Puffer gespeichert worden sind. Beispielhaft werden das Feld der nächsten Adresse des Flusses und die Menge der von diesem Paket gespeicherten Daten summiert. Daraufhin wird die Anfangspufferadresse (z. B. bevor irgendwelche Daten darin gespeichert worden sind) von dieser Summe subtrahiert. Dieser Wert, der repräsentiert, wie viel Daten jetzt in dem Puffer gespeichert sind, wird daraufhin mit der Größe des Puffers (z. B. acht Kilobytes) verglichen.
Falls die Menge der Daten, die momentan in dem Puffer gespeichert sind, gleich der Größe des Puffers ist, ist er voll. In der gegenwärtig beschriebenen Ausführungsform der Erfindung ist es erwünscht, die Flusswiederzusammensetzungspuffer vollständig zu füllen. Somit wird ein Flusswiederzusammensetzungspuffer erst dann als voll betrachtet, wenn sein Speicherraum vollständig mit Flussdaten bevölkert ist. Dieses Schema ermöglicht die effiziente Verarbeitung von Netzpaketen.
Falls der Flusswiederzusammensetzungspuffer voll ist, wird der Puffer im Zustand 1826 ungültig gemacht, um sicherzustellen, dass er nicht wieder verwendet wird. Beispielhaft umfasst dies das Setzen des Gültigkeitsindikators der Kopfpuffertabelle auf ungültig und das Übermitteln dieses Status an den Host-Computer. In dieser Ausführungsform der Erfindung wird ein Datenfreigabemerker in dem Deskriptor gesetzt. Nach dem Zustand 1826 wird die Prozedur im Zustand 1838 fortgesetzt.
Falls der Flusswiederzusammensetzungspuffer nicht voll ist, wird im Zustand 1828 das Feld 1104 der nächsten Adresse im Eintrag des Flusses in der Flusswieder zusammensetzungs-Puffer-Tabelle 1004 aktualisiert, um die Adresse anzugeben, an der der nächste Flussdatenabschnitt zu speichern ist. Nach dem Zustand 1828 wird die Prozedur im Zustand 1838 fortgesetzt.
Im Zustand 1830 (der vom Zustand 1808 erreicht wird) ist bekannt, dass die Daten des Pakets nicht in den momentanen Wiederzusammensetzungspuffer des Flusses passen. Somit werden einige der Daten in dem momentanen Puffer gespeichert, während der Rest in einem neuen Puffer gespeichert wird. Insbesondere wird im Zustand 1830 ein erster Datenabschnitt (z. B. eine Menge, die ausreicht, den Puffer zu füllen) in den momentanen Flusswiederzusammensetzungspuffer kopiert oder übertragen.
Im Zustand 1832 wird ein neuer Deskriptor von einem durch den Frei-Ring-Manager 1012 gehaltenen Deskriptor-Cache geladen. Sein Identifizierer eines neuen Puffers wird wiedergewonnen und die verbleibenden Daten von dem Paket werden in dem neuen Puffer gespeichert. In einer Ausführungsform der Erfindung werden Informationen aus dem Eintrag des Flusses in der Flusswiederzusammensetzungstabelle 1004 in einem Abschluss-Deskriptor gespeichert, nachdem der erste Datenabschnitt gespeichert worden ist. Beispielhaft enthalten diese Informationen den Wiederzusammensetzungspufferindex 1102 und den Versatz des ersten Datenabschnitts in dem vollen Puffer. Daraufhin kann der neue Deskriptor geladen werden – wobei sein Index im Wiederzusammensetzungspufferindex 1102 und eine Anfangsadresse in der nächsten Adresse 1104 gespeichert werden.
Im Zustand 1834 wird ein Abschluss-Deskriptor beschrieben oder konfiguriert, um Informationen zur Verarbeitung des Pakets an den Host-Computer zu liefern. Insbesondere werden in dem Deskriptor der Kopfpufferindex (z. B. der Platz des Pufferidentifizierers des Kopfpuffers in dem Datenfeld freier Puffer) und der Versatz des Kopfs des Pakets in dem Kopfpuffer angeordnet. Der Flusswiederzusammensetzungs-Puffer-Index (z. B. der Platz des Pufferidentifizierers des Flusswiederzusammensetzungspuffers in dem Datenfeld freier Puffer) und der Versatz der Daten des Pakets in diesem Puffer werden ebenfalls in dem Deskriptor gespeichert.
Die Größe der Daten (z. B. die Größe der TCP-Nutzinformationen des Pakets) und des Kopfs (z. B. der Versatz der TCP-Nutzinformationen in dem Paket) des Pakets werden im Datengrößefeld bzw. im Kopfgrößefeld gespeichert. Das Deskriptortypfeld erhält einen Wert, der angibt, dass ein Flusspaket an den Host-Speicher übertragen worden ist. Falls der Kopfpuffer voll ist, wird ein Kopffreigabemerker gesetzt, wobei ein Datenfreigabemerker gesetzt wird, da der erste Flusswiederzusammensetzungspuffer freigegeben wird. Der Kopfpuffer kann erst in einem späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform kann der Kopffreigabemerker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden.
Da zwei Wiederzusammensetzungspuffer verwendet wurden, wird ein Paketteilungsmerker in dem Deskriptor gesetzt, wobei der Index des Deskriptors, der auf den zweiten Wiederzusammensetzungspuffer Bezug nimmt, in dem Frei-Deskriptor-Ring in einem Feld des nächsten Index gespeichert wird.
In einer Ausführungsform der Erfindung kann in Abhängigkeit von dem dynamischen Paketblockbildungsmodul 122 außerdem ein Flussfreigabemerker gesetzt werden. Zum Beispiel wird der Flussfreigabemerker gelöscht, falls das Paketblockbildungsmodul feststellt, dass bald ein weiteres Paket in dem gleichen Fluss an den Host-Computer übertragen wird. Dies gibt an, dass der Host-Computer auf das nächste Flusspaket warten sollte, bevor er dieses verarbeitet. Durch gemeinsames Verarbeiten mehrerer Pakete aus einem einzigen Fluss können die Pakete effizienter verarbeitet werden und ist weniger Prozessorzeit erforderlich. Falls dagegen keine weiteren Pakete in dem gleichen Fluss identifiziert werden, kann der Flussfreigabemerker gesetzt werden, um anzugeben, dass der Host-Computer die bisher empfangenen Flusspakete verarbeiten sollte, ohne auf weitere zu warten.
Im Zustand 1836 wird das Feld 1104 der nächsten Adresse im Eintrag des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 aktualisiert, um die Adresse in dem neuen Puffer anzugeben, an der der nächste Flussdatenabschnitt zu speichern ist.
Im Zustand 1838 wird festgestellt, ob der Kopfpuffer voll ist. In dieser Ausführungsform der Erfindung, in der jeder Puffer eine Größe von acht Kilobytes hat und Einträge in dem Kopfpuffer nicht größer als 256 Bytes sind, kann ein Zähler verwendet werden, um die in jedem neuen Kopfpuffer angeordneten Einträge zu verfolgen. Wenn zweiunddreißig Einträge gespeichert worden sind, wird der Puffer als voll betrachtet.
Falls der Puffer voll ist, wird der Kopfpuffer im Zustand 1840 ungültig gemacht, um sicherzustellen, dass er nicht wieder verwendet wird. Beispielhaft umfasst dies das Setzen des Gültigkeitsindikators der Kopfpuffertabelle auf ungültig und das Übermitteln dieses Status an den Host-Computer. In dieser Ausführungsform der Erfindung wird ein Kopffreigabemerker in dem Deskriptor gesetzt.
Falls der Kopfpuffer nicht voll ist, wird im Zustand 1842 das Feld der nächsten Adresse der Kopfpuffertabelle 1006 aktualisiert, um die Adresse anzugeben, an der der nächste Kopf oder das nächste kleine Paket zu speichern ist.
Daraufhin wird die einem Paket mit dem Operationscode 4 zugeordnete Verarbeitung mit dem Endzustand 1899 abgeschlossen. In diesem Endzustand wird der für dieses Paket verwendete Deskriptor durch Ändern seines Besitzindikatorfelds (z. B. von eins auf null) an den Host-Computer übergeben. In einer alternativen Ausführungsform der Erfindung gibt die DMA-Maschine 120 eine Unterbrechung aus oder verwendet eine andere Einrichtung, um den Host-Computer zu warnen, dass ein Deskriptor freigegeben wird.
In einer alternativen Ausführungsform der Erfindung kann die Optimierung, die oben für Pakete beschrieben wurde, denen der Operationscode 3 zugeordnet ist, ausgeführt werden, wenn ein Paket mit dem Operationscode 4 verarbeitet wird. Diese Optimierung ist z. B. nützlich, wenn die Daten eines Code-4-Pakets zu groß sind, um in den momentanen Flusswiederzusammensetzungspuffer zu passen. Anstatt einen neuen Deskriptor für den zweiten Datenabschnitt zu laden, kann der Deskriptor verwendet werden, wo er ist – in einem Deskriptor-Cache, der durch den Frei-Ring-Manager 1012 gehalten wird. Dies ermöglicht, dass die DMA-Maschine 120 die Übertragung des Pakets abschließt und den Abschluss-Deskriptor übergibt, bevor sie die Flusswiederzusammensetzungs-Puffer-Tabelle 1004 anpasst, um einen neuen Puffer zu reflektieren.
Insbesondere kann es effizienter sein, den Deskriptor zu verwenden, ohne ihn aus dem Cache zu entfernen, anstatt im Zustand 1832 oben Informationen aus einem neuen Deskriptor zu laden. In dieser Ausführungsform wird auf einen neuen Puffer zum Speichern eines Rests der Daten des Pakets zugegriffen, indem sein Pufferidentifizierer von einem Deskriptor in dem Deskriptor-Cache des Frei-Ring-Managers wiedergewonnen wird. Die Daten werden in dem Puffer gespeichert und nachdem der Abschluss-Deskriptor des Pakets konfiguriert und freigegeben worden ist, werden die notwendigen Informationen wie oben beschrieben in die Fluss wiederzusammensetzungstabelle geladen. Beispielhaft speichert der Wiederzusammensetzungspufferindex 1102 den Index des Pufferidentifizierers in dem Datenfeld freier Puffer, wobei in der nächsten Adresse 1104 eine Anfangsspeicheradresse des Puffers angeordnet wird, die die neu gespeicherten Daten berücksichtigt.
EIN VERFAHREN ZUM ÜBERTRAGEN EINES PAKETS MIT DEM OPERATIONSCODE 5
Die 19A–19E zeigen eine Prozedur, in der die DMA-Maschine 120 ein Paket, dem der Operationscode 5 zugeordnet ist, an einen Host-Speicherpuffer überträgt. Wie TABELLE 1 reflektiert, kann der Operationscode 5 in einer Ausführungsform der Erfindung angeben, dass ein Paket inkompatibel mit den Protokollen ist, die durch die NIC 100 syntaktisch analysiert werden können. Außerdem kann er angeben, dass ein Paket alle Daten für einen neuen Fluss enthält (wobei z. B. keine weitere Daten für den Fluss des Pakets empfangen werden). Somit wird für den Operationscode 5 kein neuer Fluss aufgebaut und sollte kein Fluss abzubauen sein. Die Daten des Pakets, wenn es überhaupt welche gibt, sind nicht wieder zusammenzusetzen.
Im Zustand 1900 wird festgestellt, ob das vorliegende Paket ein kleines Paket ist (z. B. eine Größe kleiner oder gleich 256 Bytes hat), das zur Speicherung in einem Kopfpuffer geeignet ist. Wenn das der Fall ist, geht die veranschaulichte Prozedur zum Zustand 1920 über.
Andernfalls wird im Zustand 1902 festgestellt, ob das vorliegende Paket ein Jumbo-Paket ist (z. B. eine Größe größer als 1522 Bytes hat), so dass es in einem Jumbo-Puffer gespeichert werden sollte. Wenn das der Fall ist, geht die veranschaulichte Prozedur zum Zustand 1940 über. Wenn das nicht der Fall ist, wird die Prozedur im Zustand 1904 fortgesetzt.
Im Zustand 1904 ist festgestellt worden, dass das Paket weder ein kleines Paket noch ein Jumbo-Paket ist. Das Paket kann somit in einem Nichtwiederzusammensetzungspuffer gespeichert werden, der zum Speichern von Paketen verwendet wird, deren Größe nicht größer als die der MTU (größte Übertragungseinheit) ist, die in einer vorliegenden Ausführungsform 1522 Bytes beträgt. Dieser Puffer kann ein MTU-Puffer genannt werden. Somit stellt die DMA-Maschine 120 fest, ob ein gültiger (z. B. aktiver) MTU-Puffer vorhanden ist. Beispielhaft wird diese Feststellung dadurch vorgenommen, dass der Gültigkeitsindikator 1126 der MTU-Puffer-Tabelle 1008 untersucht wird, die das Management des aktiven MTU-Puffers ausführt. Falls der Gültigkeitsindikator gesetzt ist, sollte es einen MTU-Puffer geben, der bereit ist, dieses Paket zu empfangen, wobei die Prozedur im Zustand 1908 fortgesetzt wird.
Andernfalls wird im Zustand 1906 ein neuer MTU-Puffer zum Speichern nicht wieder zusammensetzbarer Pakete mit einer Größe von bis zu 1522 Bytes vorbereitet oder initialisiert. Beispielhaft umfasst dieser Initialisierungsprozess das Erhalten eines Frei-Ring-Deskriptors aus einem durch den Frei-Ring-Manager 1012 gehaltenen Cache und das Wiedergewinnen seines Pufferidentifizierers (z. B. einer Bezugnahme auf einen leeren Host-Speicherpuffer). Falls der Cache leer ist, können neue Deskriptoren aus dem Frei-Deskriptor-Ring im Host-Speicher wiedergewonnen werden, um den Cache aufzufüllen.
Wenn ein neuer Deskriptor aus dem Cache oder aus dem Frei-Deskriptor-Ring erhalten wird, wird der in dem Deskriptor enthaltene Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in einem Datenfeld freier Puffer gespeichert. Die Anfangsadresse des Puffers oder eine andere Angabe des ersten Speicherplatzes in dem Puffer wird im Feld 1124 der nächsten Adresse der MTU-Puffer-Tabelle 1008 angeordnet. Der Index oder die Stelle des Pufferidentifizierers in dem Datenfeld freier Puffer wird im MTU-Puffer-Index 1122 gespeichert und der Gültigkeitsindikator 1126 auf einem gültigen Zustand gesetzt.
Im Zustand 1908 wird das Paket an die Adresse oder an den Platz, die/der in dem Feld der nächsten Adresse der MTU-Puffer-Tabelle 1008 angegeben ist, in den MTU-Puffer kopiert oder übertragen (z. B. über eine DMA-Operation). Wie oben beschrieben wurde, können in einer Ausführungsform der Erfindung Auffüllbytes vor dem Kopf eingefügt werden, um den Beginn des Schicht-Drei-Protokollkopfs (z. B. des IP-Kopfs) des Pakets auf eine Sechzehn-Byte-Grenze auszurichten. Außerdem kann das Paket in einer Zelle vorgegebener Größe (z. B. zwei Kilobytes) in dem MTU-Puffer positioniert werden.
Im Zustand 1910 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um an den Host-Computer notwendige Informationen für die Verarbeitung des Pakets zu liefern. Insbesondere werden in dem Deskriptor der MTU-Puffer-Index (z. B. der Platz des Pufferidentifizierers für den MTU-Puffer in dem Datenfeld freier Puffer) und der Versatz (z. B. der Versatz zu dem Paket oder zu der Zelle des Pakets in dem Puffer) im Datenindexfeld bzw. im Datenversatzfeld angeordnet. Die Größe des Pakets wird in einem Datengrößefeld gespeichert. Ein Kopfgrößefeld in dem Deskriptor kann auf null gesetzt werden, um anzugeben, dass das gesamte Paket in dem MTU-Puffer angeordnet wurde (wobei z. B. kein getrennter Kopfabschnitt in einem Kopfpuffer gespeichert wurde). Falls der MTU-Puffer voll ist, wird ein Datenfreigabemerker in dem Deskriptor gesetzt. Allerdings kann der MTU-Puffer erst in einem späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform der Erfindung kann der Datenfreigabemerker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden. Ein Kopffreigabemerker kann gelöscht (z. B. nicht gesetzt) werden, da es keinen getrennten Kopfabschnitt gibt, der zu dem Host-Computer befördert wird.
Ferner wird das Deskriptortypfeld auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein nicht wieder zusammensetzbares Paket an den Host-Speicher übertragen hat. Außerdem wird ein vorgegebener Wert (z. B. null) im Besitzindikatorfeld des Deskriptors gespeichert, um anzugeben, dass die DMA-Maschine 120 ein Paket an den Host-Computer freigibt und den Besitz des Deskriptors übergibt. In einer Ausführungsform der Erfindung wird der Besitzindikator erst im Endzustand 1999 unten gesetzt. In einer alternativen Ausführungsform der Erfindung kann der Deskriptor durch Ausgeben einer Unterbrechung oder einer anderen Warnung freigegeben werden. In einer nochmals weiteren alternativen Ausführungsform kann das Ändern des Deskriptortypfelds des Deskriptors das Freigeben des Deskriptors signalisieren.
Im Zustand 1912 stellt die DMA-Maschine 120 fest, ob der MTU-Puffer voll ist. In dieser Ausführungsform der Erfindung, in der jeder Puffer eine Größe von acht Kilobytes hat, kann jedem Eintrag in dem MTU-Puffer ein Raum von zwei Kilobytes zugewiesen werden, wobei ein Zähler verwendet werden kann, um die in einem MTU-Puffer angeordneten Einträge zu verfolgen. Wenn eine vorgegebene Anzahl von Einträgen (z. B. vier) gespeichert worden sind, kann der Puffer als voll betrachtet werden. In einer alternativen Ausführungsform der Erfindung kann Einträgen in einem MTU-Puffer eine bestimmte Menge Raum zugewiesen werden oder nicht zugewiesen werden, wobei die DMA-Maschine 120 in diesem Fall berechnen kann, wie viel Speicherraum in dem Puffer noch zu verwenden ist. Falls kein Raum verbleibt oder falls noch weniger als eine vorgegebene Menge Raum verfügbar ist, kann der Puffer als voll betrachtet werden.
Falls der MTU-Puffer voll ist, wird der Puffer im Zustand 1914 ungültig gemacht, um sicherzustellen, dass er nicht wieder verwendet wird. Beispielhaft umfasst dies das Setzen des Gültigkeitsindikators der MTU-Puffer-Tabelle auf ungültig und das Übermitteln dieses Status an den Host-Computer. In dieser Ausführungsform der Erfindung wird ein Datenfreigabemerker in dem Deskriptor gesetzt. Daraufhin wird die veranschaulichte Prozedur mit dem Endzustand 1999 abgeschlossen.
Falls der MTU-Puffer nicht voll ist, wird im Zustand 1916 das Feld der nächsten Adresse der MTU-Puffer-Tabelle 1008 aktualisiert, um die Adresse anzugeben, an der das nächste Paket zu speichern ist. Daraufhin wird die veranschaulichte Prozedur mit dem Endzustand 1999 abgeschlossen.
Im Zustand 1920 (der vom Zustand 1900 erreicht wird) ist festgestellt worden, dass das vorliegende Paket ein kleines Paket ist, das zur Speicherung in einem Kopfpuffer geeignet ist. Somit stellt die DMA-Maschine 120 (z. B. der DMA-Manager 1002) fest, ob es einen gültigen (z. B. aktiven) Kopfpuffer gibt. Beispielhaft wird diese Feststellung dadurch vorgenommen, dass der Gültigkeitsindikator 1116 der Kopfpuffertabelle 1006 untersucht wird, die das Management des aktiven Kopfpuffers ausführt. Falls der Gültigkeitsindikator gesetzt ist, gibt es einen Kopfpuffer, der bereit ist, dieses Paket zu empfangen, wobei die Prozedur im Zustand 1924 fortgesetzt wird.
Andernfalls wird im Zustand 1922 ein neuer Kopfpuffer zum Speichern kleiner Pakete und von Köpfen wieder zusammengesetzter Pakete vorbereitet oder initialisiert. Beispielhaft umfasst dieser Initialisierungsprozess das Erhalten eines Frei-Ring-Deskriptors aus einem durch den Frei-Ring-Manager 1012 gehaltenen Cache und das Wiedergewinnen seiner Bezugnahme auf einen leeren Puffer. Falls der Cache leer ist, können neue Deskriptoren aus dem Frei-Deskriptor-Ring im Host-Speicher wiedergewonnen werden, um den Cache aufzufüllen.
Wenn ein neuer Deskriptor aus dem Cache oder aus dem Frei-Deskriptor-Ring erhalten wird, wird der in dem Deskriptor enthaltene Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in einem Datenfeld freier Puffer gespeichert. Die Anfangsadresse des Puffers oder ein anderer Indikator des ersten Speicherplatzes oder der ersten Zelle in dem Puffer wird im Feld 1114 der nächsten Adresse der Kopf puffertabelle 1006 angeordnet. Ferner wird die Position des Pufferidentifizierers in dem Datenfeld freier Puffer im Kopfpufferindex 1112 gespeichert und der Gültigkeitsindikator 1116 auf einen gültigen Zustand gesetzt.
Im Zustand 1924 wird das Paket an die Adresse oder an den Platz, die/der in dem Feld der nächsten Adresse der Kopfpufferabelle 1006 angegeben ist, in den Kopfpuffer kopiert oder übertragen (z. B. über eine DMA-Operation). Wie oben beschrieben wurde, können in einer Ausführungsform der Erfindung vor dem Kopf Auffüllbytes eingefügt werden, um den Beginn des Schicht-Drei-Protokollkopfs (z. B. des IP-Kopfs) des Pakets auf eine Sechzehn-Byte-Grenze auszurichten. Außerdem kann das Paket in einer Zelle vorgegebener Größe (z. B. 256 Bytes) in dem Puffer positioniert werden.
Im Zustand 1926 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um notwendige Informationen zur Verarbeitung des Pakets an den Host-Computer (z. B. an einen Software-Treiber) zu liefern. Insbesondere werden in dem Deskriptor der Kopfpufferindex (z. B. der Index des Elements des Datenfelds freier Puffer, das den Identifizierer des Kopfpuffers enthält) und der Versatz im Kopfindexfeld bzw. im Kopfversatzfeld angeordnet. Beispielhaft dient dieser Versatz dazu, das erste Byte des Pakets und das erste Auffüllbyte, das dem Paket vorausgeht, oder den Platz der Zelle des Pakets in dem Puffer zu identifizieren. Die Größe des Pakets wird ebenfalls in dem Deskriptor, beispielhaft in einem Kopfgrößefeld, gespeichert. Ein Datengrößefeld in dem Deskriptor kann auf null gesetzt werden, um anzugeben, dass das gesamte Paket in dem Kopfpuffer angeordnet wurde (wobei z. B. kein getrennter Datenabschnitt in einem anderen Puffer gespeichert wurde). Falls der Kopfpuffer voll ist, kann ein Kopffreigabemerker in dem Deskriptor gesetzt werden. Allerdings kann der Kopfpuffer erst in einem späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform der Erfindung kann der Kopffreigabemerker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden. Ein Datenfreigabemerker kann gelöscht (z. B. nicht gesetzt) werden, da es keinen getrennten Datenabschnitt gibt, der zu dem Host-Computer befördert wird.
Das Deskriptortypfeld wird auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein nicht wieder zusammensetzbares Paket in den Host-Computer übertragen hat. Außerdem wird ein vorgegebener Wert (z. B. null) im Besitzindikatorfeld des Deskriptors gespeichert, um anzugeben, dass die DMA-Maschine 120 ein Paket an den Host-Computer freigibt und den Besitz des Deskriptors übergibt. In einer Ausführungsform der Erfindung wird der Besitzindikator erst im Endzustand 1999 unten gesetzt.
Im Zustand 1928 wird festgestellt, ob der Kopfpuffer voll ist. In dieser Ausführungsform der Erfindung, in der jeder Puffer eine Größe von acht Kilobytes hat und die Einträge in dem Kopfpuffer nicht größer als 256 Bytes sind, wird ein Zähler verwendet, um die in jedem neuen Kopfpuffer angeordneten Einträge zu verfolgen. Wenn zweiunddreißig Einträge gespeichert worden sind, wird der Puffer als voll betrachtet.
Falls der Puffer voll ist, wird der Kopfpuffer im Zustand 1930 ungültig gemacht, um sicherzustellen, dass er nicht wieder verwendet wird. Beispielhaft umfasst dies das Setzen des Gültigkeitsindikators der Kopfpuffertabelle auf ungültig und das Übermitteln dieses Status an den Host-Computer. In dieser Ausführungsform der Erfindung wird ein Kopffreigabemerker in dem Deskriptor gesetzt. Daraufhin wird die veranschaulichte Prozedur mit dem Endzustand 1999 abgeschlossen.
Falls der Kopfpuffer nicht voll ist, wird im Zustand 1932 das Feld der nächsten Adresse der Kopfpuffertabelle 1006 aktualisiert, um die Adresse anzugeben, an der der nächste Kopf oder das nächste kleine Paket zu speichern ist. Daraufhin wird die veranschaulichte Prozedur mit dem Endzustand 1999 abgeschlossen.
Im Zustand 1940 (der vom Zustand 1902 erreicht wird) ist festgestellt worden, dass das Paket ein Jumbo-Paket ist (z. B. eine Größe größer als 1522 Bytes hat). In dieser Ausführungsform der Erfindung wird der Datenabschnitt eines Jumbo-Pakets in einem Jumbo-Puffer gespeichert. Sein Kopf wird ebenfalls in dem Kopfpuffer gespeichert, es sei denn, dass das Teilen von Jumbo-Paketen freigegeben ist, wobei sein Kopf in diesem Fall in einem Kopfpuffer gespeichert wird. Somit stellt die DMA-Maschine 120 fest, ob ein gültiger (z. B. aktiver) Jumbo-Puffer vorhanden ist. Beispielhaft wird diese Feststellung dadurch vorgenommen, dass der Gültigkeitsindikator 1136 der Jumbo-Puffertabelle 1010 untersucht wird, die das Management eines aktiven Jumbo-Puffers ausführt. Falls der Gültigkeitsindikator gesetzt ist, gibt es einen Jumbo-Puffer, der bereit ist, dieses Paket zu empfangen, wobei die Prozedur im Zustand 1944 fortgesetzt wird.
Andernfalls wird im Zustand 1942 ein neuer Jumbo-Puffer zum Speichern eines nicht wieder zusammensetzbaren Pakets, das größer als 1522 Bytes ist, vorbereitet oder initialisiert. Beispielhaft umfasst dieser Initialisierungsprozess das Erhalten eines Frei-Ring-Deskriptors aus einem durch den Frei-Ring-Manager 1012 gehaltenen Cache und das Wiedergewinnen seiner Bezugnahme auf einen leeren Puffer. Falls der Cache leer ist, können neue Deskriptoren aus dem Frei-Deskriptor-Ring im Host-Speicher wiedergewonnen werden, um den Cache aufzufüllen.
Wenn ein neuer Deskriptor aus dem Cache oder aus dem Frei-Deskriptor-Ring erhalten wird, wird der in dem Deskriptor enthaltene Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in einem Datenfeld freier Puffer gespeichert. Die Anfangsadresse des Puffers oder eine andere Angabe des ersten Speicherplatzes in dem Puffer wird im Feld 1134 der nächsten Adresse der Jumbo-Puffertabelle 1010 angeordnet. Die Stelle des Pufferidentifizierers in dem Datenfeld freier Puffer wird im Jumbo-Puffer-Index 1132 gespeichert und der Gültigkeitsindikator 1136 auf einen gültigen Zustand gesetzt.
Daraufhin stellt die DMA-Maschine 120 im Zustand 1944 fest, ob das Teilen von Jumbo-Puffern freigegeben ist. Falls es freigegeben ist, wird der Kopf eines Jumbo-Pakets in einem Kopfpuffer gespeichert, während die Daten des Pakets in einem oder in mehreren Jumbo-Puffern gespeichert werden. Falls es nicht freigegeben ist, wird das gesamte Paket in einem oder in mehreren Jumbo-Puffern gespeichert. Beispielhaft wird das Teilen von Jumbo-Paketen gemäß der Konfiguration eines programmierbaren Indikators (z. B. eines Merkers, eines Bits, eines Registers), der durch Software, die in dem Host-Computer arbeitet, (z. B. durch einen Gerätetreiber) gesetzt wird, freigegeben oder gesperrt. Falls das Teilen freigegeben ist, wird die veranschaulichte Prozedur im Zustand 1960 fortgesetzt. Andernfalls geht die Prozedur zum Zustand 1946 über.
Im Zustand 1946 stellt die DMA-Maschine 120 fest, ob das Paket in einen Jumbo-Puffer passt. Falls das Paket z. B. in einer Ausführungsform der Erfindung, die Acht-Kilobyte-Seiten verwendet, größer als acht Kilobytes ist, wird ein zweiter Jumbo-Puffer benötigt, um die zusätzlichen Inhalte zu speichern. Falls das Paket zu groß ist, wird die veranschaulichte Prozedur im Zustand 1952 fortgesetzt.
Andernfalls wird das Paket im Zustand 1948 an den in dem Feld 1134 der nächsten Adresse der Jumbo-Puffertabelle 1010 angegebenen Platz in dem momentanen Jumbo-Puffer kopiert oder übertragen (z. B. über eine DMA-Operation). Wenn das Paket intakt wie dieses übertragen wird, kann eine Auffüllung hinzugefügt werden, um einen Kopfabschnitt des Pakets auf eine Sechzehn-Byte-Grenze auszurichten. Für den Fachmann auf dem Gebiet ist klar, dass das Feld der nächsten Adresse nicht aktualisiert werden kann, um dieses neue Paket zu berücksichtigen, da der Jumbo-Puffer freigegeben wird. Mit anderen Worten, in einer Ausführungsform der Erfindung wird ein Jumbo-Puffer nur einmal (z. B. zum Speichern eines Pakets oder eines Abschnitts eines Pakets) verwendet. In einer alternativen Ausführungsform der Erfindung kann ein Jumbo-Puffer Abschnitte zweier oder mehrerer Pakete speichern, wobei in diesem Fall möglicherweise das Feld 1134 der nächsten Adresse aktualisiert werden muss.
Im Zustand 1950 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um den Jumbo-Puffer freizugeben und Informationen zur Verarbeitung des Pakets an den Host-Computer zu liefern. Der Jumbo-Puffer-Index (z. B. der Index des Pufferidentifizierers, der dem Jumbo-Puffer entspricht, in dem Datenfeld freier Puffer) und der Versatz des ersten Bytes des Pakets in dem Jumbo-Puffer werden in dem Deskriptor in einem Datenindexfeld bzw. in einem Datengrößefeld angeordnet. Die Größe des Pakets (z. B. die Paketlänge) wird in einem Datengrößefeld gespeichert.
Ein Kopfgrößefeld kann gelöscht werden (z. B. eine Null gespeichert werden), um anzugeben, dass der Kopfpuffer nicht verwendet wurde (z. B., dass der Kopf nicht getrennt von den Daten des Pakets gespeichert wurde). Da das Paket intakt gespeichert wurde, können das Kopfindexfeld und das Kopfversatzfeld verwendet oder nicht verwendet werden (wobei z. B. die in ihren Feldern gespeicherten Werte keine Rolle spielen). Ein Kopffreigabemerker wird gelöscht und ein Datenfreigabemerker wird gesetzt, um anzugeben, dass keine weiteren Daten in diesem Jumbo-Puffer angeordnet werden (da er z. B. freigegeben wird).
Das Deskriptortypfeld wird auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein nicht wieder zusammensetzbares Paket an den Host-Speicher übertragen hat. Schließlich wird ein vorgegebener Wert (z. B. null) in dem Besitzindikatorfeld des Deskriptors gespeichert, um anzugeben, dass die DMA-Maschine 120 ein Paket an den Host-Computer freigibt und den Besitz des Deskriptors übergibt. In einer Ausführungsform der Erfindung wird der Besitzindikator erst im Endzustand 1999 unten geändert. Nach dem Zustand 1950 wird die veranschaulichte Prozedur im Zustand 1958 wieder aufgenommen. In einer alternativen Aus führungsform der Erfindung gibt die DMA-Maschine 120 möglicherweise erst im Endzustand 1999 eine Unterbrechung aus oder verwendet erst dann eine andere Einrichtung, um den Host-Computer zu warnen, dass ein Deskriptor freigegeben wird.
Im Zustand 1952 wird ein erster Abschnitt des Pakets an dem in dem Feld 1134 der nächsten Adresse des Puffers identifizierten Platz in dem vorliegenden (z. B. gültigen) Jumbo-Puffer gespeichert. Da das gesamte Paket nicht in diesen Puffer passt, wird im Zustand 1954 ein neuer Jumbo-Puffer vorbereitet und der Rest des Pakets in diesem Puffer gespeichert.
Im Zustand 1956 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert. Die Inhalte sind ähnlich den im Zustand 1950 beschriebenen, wobei dieser Deskriptor aber reflektieren muss, dass zwei Jumbo-Puffer zum Speichern des Pakets verwendet wurden. Somit werden in dem Deskriptor wie oben der Jumbo-Puffer-Index (z. B. der Index des Elements des Datenfelds, das den Pufferidentifizierer des Kopfpuffers enthält, in dem Datenfeld freier Puffer) und der Versatz des ersten Bytes des Pakets in dem ersten Jumbo-Puffer angeordnet. Die Größe des Pakets (z. B. die Paketlänge) wird in einem Datengrößefeld gespeichert.
Ein Kopfgrößefeld kann gelöscht werden (z. B. eine Null gespeichert werden), um anzugeben, dass der Kopfpuffer nicht verwendet wurde (z. B., dass der Kopf nicht getrennt von den Daten des Pakets gespeichert wurde). Da es keinen getrennten Paketkopf gibt, können ein Kopfindexfeld und ein Kopfversatzfeld verwendet oder nicht verwendet werden (wobei z. B. die in ihren Feldern gespeicherten Werte keine Rolle spielen).
Ein Kopffreigabemerker wird gelöscht und ein Datenfreigabemerker wird gesetzt, um anzugeben, dass keine weiteren Daten in diesen Jumbo-Puffern angeordnet werden (da sie z. B. freigegeben werden). Ferner wird ein Paketteilungsmerker gesetzt, um anzugeben, dass ein zweiter Jumbo-Puffer verwendet wurde, und der Index des Pufferidentifizierers (in dem Datenfeld freier Puffer) für den zweiten Puffer wird in einem Feld des nächsten Index gespeichert.
Das Deskriptortypfeld wird auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein nicht wieder zusammensetzbares Paket an den Host-Speicher übertragen hat. Außerdem wird ein vorgegebener Wert (z. B. null) in dem Besitz indikatorfeld des Deskriptors gespeichert, um anzugeben, dass die DMA-Maschine 120 ein Paket an den Host-Computer freigibt und den Besitz des Deskriptors übergibt. In einer Ausführungsform der Erfindung wird der Besitzindikator erst im Endzustand 1999 unten geändert.
Im Zustand 1958 wird der Eintrag des Jumbo-Puffers in der Jumbo-Puffertabelle 1010 ungültig gemacht (z. B. der Gültigkeitsindikator 1136 auf ungültig gesetzt), um sicherzustellen, dass er nicht wieder verwendet wird. In der oben beschriebenen Prozedur wurde ein Jumbo-Paket in höchstens zwei Jumbo-Puffern gespeichert. In einer alternativen Ausführungsform der Erfindung kann ein Jumbo-Puffer über irgendeine Anzahl von Puffern gespeichert werden. Wie für den Fachmann auf dem Gebiet klar ist, ist der Deskriptor, der so konfiguriert ist, dass er die Übertragung eines solchen Pakets berichtet, dementsprechend konstruiert.
Nach dem Zustand 1958 wird die veranschaulichte Prozedur im Endzustand 1999 abgeschlossen.
Im Zustand 1960 (der vom Zustand 1944 erreicht wird) ist festgestellt worden, dass das vorliegende Jumbo-Paket geteilt wird, um den Paketkopf in einem Kopfpuffer zu speichern und um die Paketdaten in einem oder in mehreren Jumbo-Puffern zu speichern. Somit stellt die DMA-Maschine 120 (z. B. der DMA-Manager 1002) zunächst fest, ob es einen gültigen (z. B. aktiven) Kopfpuffer gibt. Beispielhaft wird diese Feststellung dadurch vorgenommen, dass der Gültigkeitsindikator 1116 der Kopfpuffertabelle 1006 untersucht wird, die das Management des aktiven Kopfpuffers ausführt. Falls der Gültigkeitsindikator gesetzt ist, gibt es einen Kopfpuffer, der bereit ist, dieses Paket zu empfangen, wobei die Prozedur im Zustand 1964 fortgesetzt wird.
Andernfalls wird im Zustand 1962 ein neuer Kopfpuffer vorbereitet oder initialisiert, um kleine Pakete und Köpfe anderer Pakete zu speichern. Beispielhaft umfasst dieser Initialisierungsprozess das Erhalten eines Frei-Ring-Deskriptors aus einem durch den Frei-Ring-Manager 1012 gehaltenen Cache und das Wiedergewinnen seiner Bezugnahme auf einen leeren Puffer. Falls der Cache leer ist, können neue Deskriptoren aus dem Frei-Deskriptor-Ring im Host-Speicher wiedergewonnen werden, um den Cache aufzufüllen.
Wenn ein neuer Deskriptor aus dem Cache oder aus dem Frei-Deskriptor-Ring er halten wird, wird der in dem Deskriptor enthaltene Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in einem Datenfeld freier Puffer gespeichert. Die Anfangsadresse des Puffers oder eine andere Angabe des ersten Speicherplatzes oder der ersten Zelle in dem Puffer wird im Feld 1114 der nächsten Adresse der Kopfpuffertabelle 1006 angeordnet. Der Index oder die Stelle des Pufferidentifizierers in dem Datenfeld freier Puffer wird im Kopfpufferindex 1112 gespeichert und der Gültigkeitsindikator 1116 auf einen gültigen Zustand gesetzt.
Im Zustand 1964 wird der Kopf des Pakets an die Adresse oder an den Platz, die/der in dem Feld der nächsten Adresse der Kopfpuffertabelle 1006 angegeben ist, in den Kopfpuffer kopiert oder übertragen (z. B. über eine DMA-Operation). Wie oben beschrieben wurde, können in einer Ausführungsform der Erfindung Auffüllbytes vor dem Kopf eingefügt werden, um den Beginn des Schicht-Drei-Protokollkopfs (z. B. des IP-Kopfs) des Pakets auf eine Sechzehn-Byte-Grenze auszurichten. Außerdem kann der Kopf in einer Zelle vorgegebener Größe (z. B. 256 Bytes) in dem Puffer positioniert werden.
Im Zustand 1966 stellt die DMA-Maschine 120 fest, ob die Daten des Pakets (z. B. die TCP-Nutzinformationen) in einen Jumbo-Puffer passen. Falls das Paket zu groß ist, um in einen (z. B. in den momentanen Jumbo-Puffer) zu passen, wird die veranschaulichte Prozedur im Zustand 1972 fortgesetzt.
Im Zustand 1968 werden die Daten des Pakets an den Platz, der in dem Feld 1134 der nächsten Adresse der Jumbo-Puffertabelle 1010 angegeben ist, in den momentanen Jumbo-Puffer kopiert oder übertragen (z. B. über eine DMA-Operation). Dem Fachmann auf dem Gebiet ist klar, dass das Feld der nächsten Adresse möglicherweise nicht aktualisiert zu werden braucht, um dieses neue Paket zu berücksichtigen, da der Jumbo-Puffer freigegeben wird. Mit anderen Worten, in einer Ausführungsform der Erfindung wird ein Jumbo-Puffer nur einmal (zum Speichern eines Pakets oder eines Abschnitts eines Pakets) verwendet.
Im Zustand 1970 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um den Jumbo-Puffer freizugeben und Informationen zur Verarbeitung des Pakets an den Host-Computer zu liefern. Der Kopfpufferindex (z. B. die Stelle des Pufferidentifizierers, der dem Kopfpuffer entspricht, im Datenfeld freier Puffer) und der Versatz des Kopfs des Pakets werden im Kopfindexfeld bzw. im Kopfversatzfeld in dem Deskriptor angeordnet. Beispielhaft dient dieser Versatz dazu, das erste Byte des Kopfs, das erste Auffüllbyte, das dem Kopf vorausgeht, oder die Zelle, in der der Kopf gespeichert ist, zu identifizieren. Der Jumbo-Puffer-Index (z. B. der Index des Pufferidentifizierers, der auf den Jumbo-Puffer Bezug nimmt, in dem Datenfeld freier Puffer) und der Versatz des ersten Bytes der Daten des Pakets in dem Jumbo-Puffer werden im Datenindexfeld bzw. im Datenversatzfeld angeordnet. Das Kopfgrößefeld und das Datengrößefeld werden zum Speichern der Größe des Kopfs (z. B. des Versatzes der Nutzinformationen in dem Paket) bzw. der Daten (z. B. der Nutzinformationsgröße) des Pakets verwendet.
Falls der Kopfpuffer voll ist, kann ein Kopffreigabemerker in dem Deskriptor gesetzt werden. Allerdings kann der Kopfpuffer erst in einen späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform der Erfindung kann der Kopffreigabemerker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden. Außerdem wird ein Datenfreigabemerker gesetzt, da keine weiteren Daten in dem Jumbo-Puffer angeordnet werden (da er z. B. an den Host-Computer freigegeben wird).
Das Deskriptortypfeld wird auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein nicht wieder zusammensetzbares Paket an den Host-Speicher übertragen hat. Außerdem wird ein vorgegebener Wert (z. B. null) in dem Besitzindikatorfeld des Deskriptors gespeichert, um anzugeben, dass die DMA-Maschine 120 ein Paket an den Host-Computer freigibt und den Besitz des Deskriptors übergibt. In einer Ausführungsform der Erfindung wird der Besitzindikator erst im Endzustand 1999 unten gesetzt.
Nach dem Zustand 1970 geht die veranschaulichte Prozedur zum Zustand 1978 über.
Im Zustand 1972 wird ein erster Abschnitt der Daten des Pakets an dem Platz, der in dem Feld 1134 der nächsten Adresse des Puffers identifiziert ist, in dem vorliegenden (z. B. gültigen) Jumbo-Puffer gespeichert. Da nicht alle Daten des Pakets in diesen Puffer passen, wird im Zustand 1974 ein neuer Jumbo-Puffer vorbereitet und der Rest des Pakets in diesem Puffer gespeichert.
Im Zustand 1976 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert. Die Inhalte sind ähnlich den in den Zuständen 1970 beschriebenen, wobei dieser Deskriptor aber reflektieren muss, dass zum Speichern des Pakets zwei Jumbo- Puffer verwendet wurden. Der Kopfpufferindex (z. B. das Element des Datenfelds freier Puffer, das den Identifizierer des Kopfpuffers enthält) und der Versatz des Kopfs werden in dem Deskriptor im Kopfindexfeld bzw. im Kopfversatzfeld angeordnet. Der Jumbo-Puffer-Index (z. B. das Element des Datenfelds freier Puffer, das den Pufferidentifizierer des Jumbo-Puffers enthält) und der Versatz des ersten Bytes der Daten des Pakets in dem Jumbo-Puffer werden in dem Datenindexfeld bzw. in dem Datenversatzfeld angeordnet. Das Kopfgrößefeld und das Datengrößefeld werden verwendet, um die Größe des Kopfs (z. B. den Versatz der Nutzinformationen in dem Paket) bzw. der Daten (z. B. die Nutzinformationsgröße) des Pakets zu speichern.
Falls der Kopfpuffer voll ist, wird ein Kopffreigabemerker in dem Deskriptor gesetzt. Allerdings kann der Kopfpuffer erst in einem späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform der Erfindung kann der Kopffreigabemerker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden. Ein Datenfreigabemerker wird ebenfalls gesetzt, da keine weiteren Daten in dem Jumbo-Puffer angeordnet werden (da er z. B. an den Host-Computer freigegeben wird). Ferner wird ein Paketteilungsmerker gesetzt, um anzugeben, dass ein zweiter Jumbo-Puffer verwendet wurde, und die Stelle oder der Index des Pufferidentifizierers des zweiten Puffers in dem Datenfeld freier Puffer in einem Feld des nächsten Index gespeichert.
Das Deskriptortypfeld wird auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein nicht wieder zusammensetzbares Paket an den Host-Speicher übertragen hat. Schließlich wird ein vorgegebener Wert (z. B. null) in dem Besitzindikatorfeld des Deskriptors gespeichert, um anzugeben, dass die DMA-Maschine 120 ein Paket an den Host-Computer freigibt und den Besitz des Deskriptors übergibt. In einer Ausführungsform der Erfindung wird der Besitzindikator erst im Endzustand 1999 unten gesetzt. In einer alternativen Ausführungsform der Erfindung gibt die DMA-Maschine 120 eine Unterbrechung aus oder verwendet ein anderes Signal, um den Host-Computer zu warnen, dass ein Deskriptor freigegeben wird.
Im Zustand 1978 wird der Eintrag des Jumbo-Puffers in der Jumbo-Puffertabelle 1010 ungültig gemacht (z. B. der Gültigkeitsindikator 1136 auf ungültig gesetzt), um sicherzustellen, dass er nicht wieder verwendet wird. In der oben beschriebenen Prozedur wurde ein Jumbo-Paket höchstens in zwei Jumbo-Puffern gespei chert. In einer alternativen Ausführungsform der Erfindung kann ein Jumbo-Puffer über irgendeine Anzahl von Puffern gespeichert werden. Wie für den Fachmann auf dem Gebiet klar ist, ist der Deskriptor, der so konfiguriert wird, dass er die Übertragung eines solchen Pakets berichtet, dementsprechend konstruiert.
Im Zustand 1980 wird festgestellt, ob der Kopfpuffer voll ist. In dieser Ausführungsform der Erfindung, in der jeder Puffer eine Größe von acht Kilobytes hat und die Einträge in dem Kopfpuffer nicht größer als 256 Bytes sind, kann ein Zähler verwendet werden, um die in jedem neuen Kopfpuffer angeordneten Einträge zu verfolgen. Wenn zweiunddreißig Einträge gespeichert worden sind, wird der Puffer als voll betrachtet.
Falls der Puffer voll ist, wird der Kopfpuffer im Zustand 1982 ungültig gemacht, um sicherzustellen, dass er nicht wieder verwendet wird. Beispielhaft umfasst dies das Setzen des Gültigkeitsindikators der Kopfpuffertabelle auf ungültig und das Übermitteln dieses Status an den Host-Computer. In dieser Ausführungsform der Erfindung wird ein Kopffreigabemerker in dem Deskriptor gesetzt. Daraufhin wird die veranschaulichte Prozedur mit dem Endzustand 1999 abgeschlossen.
Falls der Kopfpuffer nicht voll ist, wird im Zustand 1984 das Feld der nächsten Adresse der Kopfpuffertabelle 1006 aktualisiert, um die Adresse anzugeben, an der der nächste Kopf oder das nächste kleine Paket zu speichern ist. Daraufhin wird die veranschaulichte Prozedur mit dem Endzustand 1999 abgeschlossen.
Im Endzustand 1999 kann ein Deskriptor an den Host-Computer übergeben werden, indem wie oben beschrieben ein besonderer Wert (z. B. null) in dem Besitzindikatorfeld des Deskriptors gespeichert wird. Beispielhaft erfasst der Host-Computer (oder Software, die in dem Host-Computer arbeitet) die Änderung und versteht, dass die DMA-Maschine 120 den Besitz des Deskriptors an den Host-Computer zurückgibt.
EIN VERFAHREN ZUM ÜBERTRAGEN EINES PAKETS MIT DEM OPERATIONSCODE 6 ODER MIT DEM OPERATIONSCODE 7
Die 20A–20B zeigen eine beispielhafte Prozedur, in der die DMA-Maschine 120 ein Paket, dem der Operationscode 6 oder 7 zugeordnet ist, an einen Host-Speicherpuffer überträgt. Wie TABELLE 1 widerspiegelt, können die Operations codes 6 und 7 angeben, dass ein Paket mit den für die NIC 100 im Voraus gewählten Protokollen kompatibel und das erste Paket eines neuen Flusses ist. Der Unterschied zwischen diesen Operationscodes ist in dieser Ausführungsform der Erfindung, dass der Operationscode 7 verwendet wird, wenn ein vorhandener Fluss (z. B. in der Flussdatenbank 110 und/oder in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004) durch einen neuen Fluss zu ersetzen ist. Im Gegensatz dazu braucht beim Operationscode 6 kein Fluss abgebaut zu werden. Allerdings wird für beide Codes ein neuer Fluss aufgebaut, wobei die Daten des zugeordneten Pakets mit Daten von anderen Paketen in dem neu aufgebauten Fluss wieder zusammengesetzt werden können. Da die Paketdaten wieder zusammenzusetzen sind, sollte der Kopf des Pakets in einem Kopfpuffer gespeichert werden und sollten seine Daten in einem neuen Flusswiederzusammensetzungspuffer gespeichert werden.
Wie in einem vorangegangenen Abschnitt beschrieben wurde, kann der Fluss, der abgebaut wird, um (im Fall des Operationscode 7) Platz für einen neuen Fluss zu machen, der zuletzt verwendete Fluss sein. Da die Flussdatenbank 110 und die Flusswiederzusammensetzungs-Puffer-Tabelle 1004 in der gegenwärtig beschriebenen Ausführungsform der Erfindung nur eine begrenzte Anzahl von Einträgen enthalten, muss ein alter Fluss abgebaut werden, wenn sie voll sind und ein neuer Fluss ankommt. Die Wahl des zuletzt aktiven Flusses zum Ersatz wirkt sich wahrscheinlich am wenigsten auf den Netzverkehr über die NIC 100 aus. In einer Ausführungsform der Erfindung baut die DMA-Maschine 120 den Fluss in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 ab, der die gleiche Flussnummer wie der Fluss hat, der in der Flussdatenbank 110 ersetzt worden ist.
Im Zustand 2000 stellt die DMA-Maschine 120 fest, ob es einen gültigen (z. B. aktiven) Kopfpuffer gibt. Beispielhaft wird diese Feststellung dadurch vorgenommen, dass der Gültigkeitsindikator 1116 der Kopfpuffertabelle 1006 untersucht wird, die das Management des aktiven Kopfpuffers ausführt. Falls der Gültigkeitsindikator gesetzt ist, gibt es einen Kopfpuffer, der bereit ist, dieses Paket zu empfangen, wobei die Prozedur im Zustand 2004 fortgesetzt wird.
Andernfalls wird im Zustand 2002 ein neuer Kopfpuffer zum Speichern kleiner Pakete und Köpfe wieder zusammengesetzter Pakete vorbereitet oder initialisiert. Beispielhaft umfasst dieser Initialisierungsprozess das Erhalten eines Frei-Ring-Deskriptors aus einem durch den Frei-Ring-Manager 1012 gehaltenen Cache und das Wiedergewinnen seiner Bezugnahme auf einen leeren Puffer. Falls der Cache leer ist, können neue Deskriptoren aus dem Frei-Deskriptor-Ring im Host-Speicher wiedergewonnen werden, um den Cache aufzufüllen.
Wenn ein neuer Deskriptor aus dem Cache oder aus dem Frei-Deskriptor-Ring erhalten wird, wird der in dem Deskriptor enthaltene Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in einem Datenfeld freier Puffer gespeichert. Die Anfangsadresse des Puffers oder eine andere Angabe des ersten Speicherplatzes oder der ersten Zelle in dem Puffer wird im Feld 1114 der nächsten Adresse der Kopfpuffertabelle 1006 angeordnet. Die Stelle oder der Index des Pufferidentifizierers in dem Datenfeld freier Puffer wird im Kopfpufferindex 1112 gespeichert und der Gültigkeitsindikator 1116 auf einen gültigen Zustand gesetzt.
Im Zustand 2004 wird der Kopf des Pakets an die Adresse oder an den Platz, die/der in dem Feld der nächsten Adresse der Kopfpuffertabelle 1006 angegeben ist, in den Kopfpuffer kopiert oder übertragen. Wie oben beschrieben wurde, können in einer Ausführungsform der Erfindung Auffüllbytes vor dem Kopf eingeführt werden, um den Beginn des Schicht-Drei-Protokollkopfs (z. B. des IP-Kopfs) des Pakets auf eine Sechzehn-Byte-Grenze auszurichten. Außerdem kann der Kopf des Pakets in einer Zelle vorgegebener Größe (z. B. 256 Bytes) in dem Puffer positioniert werden.
Wie oben diskutiert wurde, gibt der Operationscode 7 an, dass ein alter Fluss in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 abzubauen ist, um Platz für einen neuen Fluss zu machen. Dies erfordert das Freigeben irgendeines Flusswiederzusammensetzungspuffers, der dem Fluss, der abgebaut wird, zugeordnet sein kann.
Somit wird im Zustand 2006 für einen Fluss mit der Flussnummer, die aus der Steuerwarteschlange 118 für dieses Paket gelesen worden ist, festgestellt, ob ein Flusswiederzusammensetzungspuffer gültig (z. B. aktiv) ist. Wie in einem vorangegangenen Abschnitt erläutert wurde, repräsentiert die Flussnummer für den Operationscode 7 den Eintrag in der Flussdatenbank 110 (und in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004), der durch den neuen Fluss ersetzt wird. Somit untersucht die DMA-Maschine 120 den Gültigkeitsindikator im Eintrag des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004. Beispielhaft gibt es einen aktiven Puffer, der Daten von einem oder von mehreren Paketen in dem Fluss speichert, der ersetzt wird, falls der Indikator gültig ist. Falls es einen gültigen Flusswiederzusammensetzungspuffer für diesen Fluss gibt, wird die veranschaulichte Prozedur im Zustand 2008 fortgesetzt. Ansonsten geht die Prozedur zum Zustand 2010 über. Selbstverständlich geht die veranschaulichte Prozedur für den Operationscode 7 normal zum Zustand 2008 über und für den Operationscode 6 normal zum Zustand 2010 über.
Im Zustand 2008 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um den Wiederzusammensetzungspuffer des ersetzten Flusses freizugeben. Insbesondere wird der Flusswiederzusammensetzungs-Puffer-Index (z. B. der Index des Pufferidentifizierers des Flusswiederzusammensetzungspufters in dem Datenfeld freier Puffer) in den Deskriptor geschrieben. In dieser Ausführungsform der Erfindung braucht kein Versatz in dem Datenversatzfeld des Deskriptors gespeichert zu werden und wird das Datengrößefeld auf null gesetzt, da in dem Puffer, der freigegeben wird, keine neuen Daten gespeichert wurden. Ähnlich wird der Kopfpuffer noch nicht freigegeben, so dass das Kopfindexfeld und das Kopfversatzfeld des Deskriptors nicht verwendet zu werden brauchen und eine Null im Kopfgrößefeld gespeichert werden kann.
Da der Kopfpuffer nicht freigegeben wird, wird der Kopffreigabemerker des Deskriptors gelöscht (z. B. eine Null in dem Merker gespeichert). Allerdings wird der Datenfreigabemerker gesetzt (z. B. eine Eins in dem Merker gespeichert), da keine weiteren Daten in dem freigegebenen Flusswiederzusammensetzungspuffer angeordnet werden. Ferner wird ein Flussfreigabemerker in dem Deskriptor gesetzt, um anzugeben, dass der dem freigegebenen Flusswiederzusammensetzungspuffer zugeordnete Fluss abgebaut wird.
Das Deskriptortypfeld wird auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 einen verbrauchten Flusspuffer (z. B. einen Flusswiederzusammensetzungspuffer, der eine gewisse Zeit nicht verwendet worden ist) freigibt. Schließlich wird der Deskriptor, der dazu verwendet wird, den Wiederzusammensetzungspuffer des ersetzten Flusses freizugeben und den zugeordneten Fluss abzuschließen, durch Ändern seines Besitzindikatorfelds (z. B. von eins auf null) an den Host-Computer übergeben. In einer alternativen Ausführungsform der Erfindung gibt die DMA-Maschine 120 eine Unterbrechung aus oder verwendet sie eine andere Einrichtung, um den Host-Computer zu warnen, dass ein Deskriptor freigegeben wird.
Im Zustand 2010 wird für den Fluss, der aufgebaut wird, ein neuer Flusswiederzusammensetzungspuffer vorbereitet. Beispielhaft wird aus einem durch den Frei-Ring-Manager 1012 gehaltenen Cache ein Frei-Ring-Deskriptor erhalten und sein Pufferidentifizierer (z. B. eine Bezugnahme auf einen leeren Speicherpuffer) wiedergewonnen. Falls der Cache leer ist, können neue Deskriptoren aus dem Frei-Deskriptor-Ring im Host-Speicher wiedergewonnen werden, um den Cache aufzufüllen.
Wenn aus dem Cache oder aus dem Frei-Deskriptor-Ring ein neuer Deskriptor erhalten wird, wird der in dem Deskriptor enthaltene Pufferidentifizierer (z. B. Zeiger, Adresse, Index) in einem Datenfeld freier Puffer gespeichert. Die Anfangsadresse des Puffers oder eine andere Angabe des ersten Speicherplatzes in dem Puffer wird in dem Feld 1104 der nächsten Adresse des Eintrags des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 angeordnet. Der Eintrag des Flusses in der Tabelle kann durch seine Flussnummer erkannt werden. Die Stelle oder der Index des Pufferidentifizierers in dem Datenfeld freier Puffer wird im Wiederzusammensetzungspufferindex 1102 gespeichert und der Gültigkeitsindikator 1106 auf einen gültigen Zustand gesetzt.
Im Zustand 2012 werden die Daten des Pakets an die Adresse oder an den Platz, der in dem Feld der nächsten Adresse des Eintrags des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 angegeben ist, kopiert oder übertragen (z. B. über eine DMA-Operation).
Im Zustand 2014 wird ein Abschluss-Deskriptor geschrieben oder konfiguriert, um Informationen für die Verarbeitung des Pakets an den Host-Computer zu liefern. Insbesondere werden in dem Deskriptor der Kopfpufferindex (z. B. der Platz oder die Stelle des Pufferidentifizierers, der auf den Kopfpuffer Bezug nimmt, in dem Datenfeld freier Puffer) und der Versatz des Kopfs des Pakets in dem Kopfpuffer angeordnet. Beispielhaft identifiziert der Versatz das erste Byte des Kopfs, das erste Auffüllbyte, das dem Kopf vorausgeht, oder den Platz der Zelle des Kopfs in dem Kopfpuffer.
Der Flusswiederzusammensetzungs-Puffer-Index (z. B. der Platz oder die Stelle des Pufferidentifizierers, der auf den Flusswiederzusammensetzungspuffer Bezug nimmt, in dem Datenfeld freier Puffer) und der Versatz der Daten des Pakets in diesem Puffer werden ebenfalls in dem Deskriptor gespeichert. Allerdings wird erkannt, dass der für die Daten dieses Pakets berichtete Versatz null sein kann, da die Paketdaten ganz zu Beginn des neuen Flusswiederzusammensetzungspuffers gespeichert werden.
Die Größe der Daten (z. B. die Größe der TCP-Nutzinformationen des Pakets) und des Kopfs (z. B. der Versatz der TCP-Nutzinformationen in dem Paket) des Pakets werden im Datengrößefeld bzw. im Kopfgrößefeld gespeichert. Das Deskriptortypfeld wird auf einen Wert geändert, der angibt, dass die DMA-Maschine 120 ein Flusspaket an den Host-Speicher übertragen hat. Falls der Kopfpuffer voll ist, aber kein Datenfreigabemerker gesetzt ist, wird ein Kopffreigabemerker gesetzt, da in diesem Flusswiederzusammensetzungspuffer weitere Daten angeordnet werden. Der Kopfpuffer kann erst in einem späteren Zustand dieser Prozedur getestet werden, um zu sehen, ob er voll ist. In einer solchen Ausführungsform kann der Kopffreigabemerker zu diesem Zeitpunkt gesetzt (oder gelöscht) werden.
In einer Ausführungsform der Erfindung kann in Abhängigkeit von dem dynamischen Paketblockbildungsmodul 122 außerdem ein Flussfreigabemerker gesetzt werden. Zum Beispiel wird der Flussfreigabemerker gelöscht (z. B. eine Null gespeichert), falls das Paketblockbildungsmodul feststellt, dass bald ein weiteres Paket in dem gleichen Fluss an den Host-Computer übertragen wird. Dies gibt an, dass der Host-Computer auf das nächste Flusspaket warten sollte, bevor dieses verarbeitet wird. Durch gemeinsames Verarbeiten mehrerer Pakete aus einem einzigen Fluss können die Pakete effizienter verarbeitet werden und wird für den Netzverkehr weniger Prozessorzeit benötigt. Falls dagegen keine weiteren Pakete in dem gleichen Fluss identifiziert werden, kann der Flussfreigabemerker gesetzt werden, um anzugeben, dass der Host-Computer die bisher empfangenen Flusspakete verarbeiten sollte, ohne auf weitere zu warten.
Im Zustand 2016 wird der Eintrag des Flusses in der Flusswiederzusammensetzungs-Puffer-Tabelle 1004 aktualisiert. Insbesondere wird das Feld 1104 der nächsten Adresse aktualisiert, um den Platz in dem Wiederzusammensetzungspuffer zu identifizieren, an dem die Daten des nächsten Flusspakets gespeichert werden sollten.
Im Zustand 2018 wird festgestellt, ob der Kopfpuffer voll ist. In dieser Ausführungsform der Erfindung, in der jeder Puffer eine Größe von acht Kilobytes hat und die Einträge in dem Kopfpuffer nicht größer als 256 Bytes sind, kann ein Zähler verwendet werden, um die in jedem neuen Kopfpuffer angeordneten Einträge zu verfolgen. Wenn zweiunddreißig Einträge gespeichert worden sind, wird der Puffer als voll betrachtet.
Falls der Puffer voll ist, wird der Kopfpuffer im Zustand 2020 ungültig gemacht, um sicherzustellen, dass er nicht wieder verwendet wird. Beispielhaft umfasst dies das Setzen des Gültigkeitsindikators der Kopfpuffertabelle auf ungültig und das Übermitteln dieses Status an den Host-Computer. In dieser Ausführungsform der Erfindung wird ein Kopffreigabemerker in dem Deskriptor gesetzt.
Falls der Kopfpuffer nicht voll ist, wird im Zustand 2022 das Feld der nächsten Adresse der Kopfpuffertabelle 1006 aktualisiert, um die Adresse anzugeben, an der der nächste Kopf oder das nächste kleine Paket zu speichern ist.
Daraufhin wird die einem Paket mit den Operationscodes 6 und 7 zugeordnete Verarbeitung mit dem Endzustand 2099 abgeschlossen. In diesem Endzustand wird der für dieses Paket verwendete Deskriptor (z. B. der Deskriptor, der im Zustand 2014 konfiguriert wurde) durch Ändern seines Besitzindikatorfelds (z. B. von eins auf null) an den Host-Computer übergeben. In einer alternativen Ausführungsform der Erfindung gibt die DMA-Maschine 120 eine Unterbrechung aus oder verwendet sie eine andere Einrichtung (wie etwa z. B. das Deskriptortypfeld des Deskriptors), um den Host-Computer zu warnen, dass ein Deskriptor freigegeben wird.
Eine Ausführung eines Paketblockbildungsmoduls
21 ist ein Diagramm eines dynamischen Paketblockbildungsmoduls 122 in einer Ausführungsform der Erfindung. In dieser Ausführungsform warnt das Paketblockbildungsmodul 122 einen Host-Computer vor der Übertragung oder bevorstehenden Übertragung mehrerer Pakete aus einem Kommunikationsfluss. Die verwandten Pakete können dann eher durch einen geeigneten Protokollstapel gemeinsam als immer nur eins verarbeitet werden. Wie der Fachmann auf dem Gebiet erkennt, erhöht dies 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-Maschi ne 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, stellt das Paketblockbildungsmodul 122 fest, ob bald ein verwandtes Paket (z. B. ein Paket in dem gleichen Fluss) ebenfalls übertragen wird. Insbesondere untersucht das Paketblockbildungsmodul 122 Pakete, die nach dem vorliegenden Paket übertragen werden sollen. Wie für den Fachmann auf dem Gebiet klar ist, warten zu einer gegebenen Zeit wahrscheinlich umso mehr Pakete auf die Übertragung zu einem Host-Computer, je höher die Rate der Paketankunft an der NIC 100 ist. Je mehr Pakete auf die Übertragung warten, desto mehr Pakete können durch das dynamische Paketblockbildungsmodul untersucht werden und desto größeren Nutzen kann es liefern. Insbesondere, während die Anzahl der auf die Übertragung wartenden Pakete zunimmt, kann das Paketblockbildungsmodul 122 eine größere Anzahl verwandter Pakete zur gemeinsamen Verarbeitung identifizieren. Während die Anzahl der gemeinsam verarbeiteten Pakete zunimmt, nimmt die Dauer der Host-Prozessorzeit, die zum Verarbeiten jenes Pakets erforderlich ist, ab.
Somit warnt das Paketblockbildungsmodul den Host-Computer, falls ein verwandtes Paket ermittelt wird, so dass die Pakete als eine Gruppe verarbeitet werden können. Wie in einem früheren Abschnitt beschrieben wurde, warnt das dynamische Paketblockbildungsmodul 122 den Host-Computer in einer Ausführungsform der Erfindung vor der 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 Paketblockbildungsmodul 122 gelöscht werden.
Im Gegensatz dazu kann das dynamische Paketblockbildungsmodul 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 festgestellt 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 reflektieren kann).
Nunmehr anhand von 21 enthält das Paketblockbildungsmodul 122 in einer Ausführungsform der Erfindung einen Speicher 2102 und einen Controller 2104. Beispielhaft enthält jeder Eintrag im Speicher 2102 wie etwa der Eintrag 2106 zwei Felder: die Flussnummer 2108 und den Gültigkeitsindikator 2110. In alternativen Ausführungsformen der Erfindung können andere Informationen im Speicher 2102 gespeichert werden. Ein Lesezeiger 2112 und ein Schreibzeiger 2114 dienen als Indizes in den Speicher 2102.
In der veranschaulichten Ausführungsform ist der Speicher 2102 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 2102 nach einem Eintrag mit einer Flussnummer durchsucht werden, die mit der Flussnummer des übertragenen Pakets übereinstimmt. Da der Speicher 2102 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 2102 in Hardware implementiert, wobei die Einträge logisch als ein Ring angeordnet sind. In alternativen Ausführungsformen kann der Speicher 2102 praktisch irgendein Datenstrukturtyp (z. B. Datenfeld, Tabelle, Liste, Warteschlange) sein, der in Hardware oder Software implementiert ist. In einer besonderen alternativen Auführungsform ist der Speicher 2102 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 2102 mit der Tiefe der Paketwarteschlange übereinstimmt, kann die Flussnummer eines Pakets, wenn es in der Paketwarteschlange gespeichert wird, automatisch im Speicher 2102 gespeichert werden. Obgleich in dieser Ausführungsform die gleiche Anzahl von Einträgen bereitgestellt wird, kann der Speicher 2102 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 Paket verwandte Informationen in der Steuerwarteschlange gespeichert werden.
In der veranschaulichten Ausführungsform der Erfindung ist die Flussnummer 2108 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 2108 kann den Index des Flussschlüssels des Pakets in der Flussdatenbank 110 enthalten.
Der Gültigkeitsindikator 2110 zeigt an, ob die in dem Eintrag gespeicherten Informationen gültig oder aktuell sind. In dieser Ausführungsform kann der Gültigkeitsindikator 2110 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ültigkeitsindikator 2110 im Eintrag 2106 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ültigkeitsindikator 2110 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ültigkeitsindikator 2110 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ültigkeitsindikator 2110 kann während des Betriebs des Paketblockbildungsmoduls durch den Controller 2104 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 Paketblockbildungsmodul 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 Paketblockbildungsmodul 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 2102 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), macht der Controller 2104 den Speichereintrag, der diesem Paket entspricht, ungültig. Daraufhin wird der Speicher 2102 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 2102 gespeichert.
In einer alternativen Ausführungsform der Erfindung kann der Speicher 2102 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 2102 können weiter bevölkert werden, wenn ein Paket in der Paketwarteschlange gespeichert wird. Wenn der Speicher 2102 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 2102 ungültig gemacht worden ist. Somit können die Einträge im Speicher 2102 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 2104 würde somit ununterbrochen versuchen, Informatio nen aus den Einträgen in der Steuerwarteschlange 118 in den Speicher 2102 zu kopieren. Die Funktion des Bevölkerns des Speichers 2102 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 2102 zu helfen. Insbesondere kann der zweite Lesezeiger durch das Paketblockbildungsmodul 122 verwendet werden, um Einträge für den Speicher 2102 zu ermitteln und zu holen. Beispielhaft könnte festgestellt werden, dass seit der letzten Prüfung durch den Controller 2104 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 2102 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 2102 gibt. Daraufhin würde der Vorgriff-Lesezeiger inkrementiert.
Nunmehr wieder in 21 identifiziert der Lesezeiger 2112 des dynamischen Paketblockbildungsmoduls 122 den momentanen Eintrag im Speicher 2102 (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 2114 identifiziert die Stelle, an der der nächste Eintrag im Speicher 2102 gespeichert werden soll. Beispielhaft wird der Schreibzeiger jedes Mal inkrementiert, wenn ein Eintrag zum Speicher 2102 hinzugefügt wird. Eine Art der gemeinsamen 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 reflektieren. 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 gemeinsamen 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 gemeinsamen 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 verarbeitet 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.
Wie in einem früheren Abschnitt diskutiert wurde, 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än dige Datenseite an den Anwendungs- oder Anwenderspeicherraum geliefert wird.
Die 22A–22B zeigen ein Verfahren der dynamischen Paketblockbildung mit dem Paketblockbildungsmodul 122. In dem veranschaulichten Verfahren wird der Speicher 2102 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 2102 gespeichert und der Gültigkeitsindikator 2110 in Übereinstimmung mit dem Operationscode gesetzt. Zum Beispiel kann der Gültigkeitsindikator 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 Paketblockbildungsmodul 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 2102 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.
22A kann als ein Verfahren zum Suchen nach einem verwandten Paket betrachtet werden, während 22B als ein Verfahren zum Bevölkern des Speichers des dynamischen Paketblockbildungsmoduls betrachtet werden kann.
Die 22A–22B widerspiegeln jeweils einen "Zyklus" einer dynamischen Paketblockbildungsoperation (z. B. einer Suche und Erzeugung eines neuen Speichereintrags). Beispielhaft wird die Operation des Paketblockbildungsmoduls 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 2104 sicherzustellen, dass der Speicher 2102 mit Einträgen für Pakete bevölkert wird, während sie in der Paketwarteschlange 116 gespeichert werden. Falls der Speicher 2102 nicht groß genug ist, um für jedes Paket in der Warteschlange 116 einen Eintrag zu speichern, versucht der Controller 2104, den Speicher so voll wie möglich zu halten und einen ungültig gemachten Eintrag schnell durch einen neuen zu ersetzen.
Der Zustand 2200 ist ein Startzyklus für einen Speichersuchzyklus. Im Zustand 2202 wird festgestellt, ob ein Paket (z. B. das Paket vorn in der Paketwarteschlange) an den Host-Computer übertragen wird. Diese Feststellung 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 2202 durch die DMA-Maschine 120 begonnen, während ein Paket in einen Puffer in dem Host-Computer kopiert wird. Ein Zweck des Zustands 2202 ist es einfach festzustellen, ob der Speicher 2102 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 2202 fortgesetzt.
Wenn es dagegen Zeit ist, eine Suche durchzuführen (wenn z. B. gerade ein Paket übertragen wird), wird das Verfahren im Zustand 2204 fortgesetzt. Im Zustand 2204 entspricht der Eintrag im Speicher 2102 dem Ungültigmachen des Pakets, das gerade übertragen wird. Beispielhaft besteht dies im Speichern eines vorgegebenen Wertes (z. B. null) im Gültigkeitsindikator 2110 für den Eintrag des Pakets. In einer vorliegenden Ausführungsform der Erfindung identifiziert der Lesezeiger 2112 den Eintrag, der dem zu übertragenden Paket entspricht. Wie der Fachmann auf dem Gebiet erkennt, ist ein Grund dafür, dass der Eintrag eines übertragenen Pakets ungültig gemacht wird, der, dass der eigene Eintrag des übertragenen Pakets nicht identifiziert wird, wenn der Speicher 2102 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 Paketblockbildungsmodul 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 2102 als ein RAM anstatt als ein CAM implementiert ist.
Im Zustand 2206 wird der Lesezeiger 2112 inkrementiert, so dass er auf den nächsten Eintrag im Speicher 2102 zeigt. Falls der Lesezeiger auf den gleichen Eintrag inkrementiert wird, auf den der Schreibzeiger 2114 Bezug nimmt, und falls dieser Eintrag ebenfalls ungültig gemacht wird (was durch den Gültigkeitsindikator 2110 angezeigt wird), kann festgestellt werden, dass der Speicher 2102 jetzt leer ist.
Daraufhin wird der Speicher 2102 im Zustand 2208 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 2102 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ültigkeitsindikatoren) durchsucht. Wie oben erläutert wurde, kann ein Eintrag als ungültig gekennzeichnet werden (falls sein Gültigkeitsindikator 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 zu Blöcken gebildet 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 2212 wird der Host-Computer vor der 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 (in einem früheren Abschnitt beschriebenen) Abschluss-Deskriptors des übertragenen Pakets ein vorgegebener Wert gespeichert wird. Wie in dem vorigen Abschnitt beschrieben wurde, 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, wenn ein Paket übertragen wird. Insbesondere wird ein Flussfreigabemerker oder -indikator 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. Bei spielhaft 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 Paketblockbildungsmodul 122. Wie für den Fachmann auf dem Gebiet klar ist, sind andere Verfahren zum Benachrichtigen des Host-Computers über das Vorhandensein eines verwandten Pakets (z. B. ein Indikator, Merker, Schlüssel) ebenfalls geeignet.
In 22B ist der Zustand 2220 ein Startzustand für einen Speicherbevölkerungszyklus.
Im Zustand 2222 wird festgestellt, 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 Paketblockbildungsmoduls 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 2224 fortgesetzt.
Falls der Speicher 2102 im Zustand 2224 so konfiguriert wird, dass er weniger Einträge als die Paketwarteschlange 116 (und möglicherweise als die Steuerwarteschlange 118) speichert, wird der Speicher 2102 untersucht, um festzustellen, ob er voll ist.
In einer Ausführungsform der Erfindung kann der Speicher 2102 als voll betrachtet werden, falls der Gültigkeitsindikator für jeden Eintrag oder für den Eintrag, auf den der Schreibzeiger 2114 Bezug nimmt, gesetzt (z. B. gleich eins) ist. Falls der Speicher voll ist, wartet die veranschaulichte Prozedur, bis der Speicher nicht voll ist. Wie der Fachmann auf dem Gebiet erkennt, können der Speicher 2102 und andere Datenstrukturen in der NIC 100 durch Vergleich ihrer Lese- und Schreibzeiger auf Sättigung (z. B. darauf, ob sie gefüllt sind) getestet werden.
Im Zustand 2226 wird ein neues Paket dadurch im Speicher 2102 dargestellt, dass seine Flussnummer in dem durch den Schreibzeiger 2114 identifizierten Eintrag gespeichert wird und ein geeigneter Wert im Gültigkeitsindikatorfeld des Eintrags gespeichert wird. Falls das Paket z. B. (wie z. B. durch seinen Operationscode angezeigt wird) nicht wieder zusammensetzbar ist, kann der Gültigkeitsindikator des Eintrags auf einen ungültigen Zustand gesetzt werden. Für den Betrieb des dynamischen Paketblockbildungsmoduls 122 kann ein TCP-Steuerpaket als wieder zusammensetzbar oder als nicht wieder zusammensetzbar betrachtet werden. Somit kann der Gültigkeitsindikator 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 2102 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 2228 wird der Schreibzeiger 2114 auf den nächsten Eintrag des Speichers 2102 inkrementiert, wonach das veranschaulichte Verfahren im Endzustand 2230 endet. Falls der Schreibzeiger 2114 auf den gleichen Eintrag wie der Lesezeiger 2112 Bezug nimmt, kann festgestellt werden, dass der Speicher 2102 voll ist. Der Fachmann auf dem Gebiet erkennt, dass für den Speicher 2102 viele weitere geeignete Verfahren des Managements der Zeiger verwendet werden können.
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 2230 aus der in 22B veranschaulichten Prozedur entfernt werden, wobei die Prozedur in diesem Fall nach dem Zustand 2228 zum Zustand 2222 zurückkehrt.
In der veranschaulichten Ausführungsform der Erfindung nehmen die durch das dynamische Paketblockbildungsmodul 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 die Pakete in die Paketwarteschlange 116 eingereiht werden, wobei umso mehr Einträge im Speicher 2102 gehalten werden können, je mehr Pakete in der Paketwarteschlange sind.
Je mehr Einträge im Speicher 2102 gespeichert werden, desto weiter voraus kann das dynamische Paketblockbildungsmodul 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 gemeinsamen Verarbeitung identifiziert werden, nimmt die Dauer der beim Netzverkehr verbrauchten Prozessorzeit ab und die Gesamtprozessornutzung zu.
Für den Fachmann auf dem Gebiet ist klar, dass zum Identifizieren mehrerer Pakete aus einem einzigen Kommunikationsfluss oder aus einer einzigen Kommunikationsverbindung andere Systeme und Verfahren verwendet werden, ohne den Umfang der vorliegenden Erfindung zu überschreiten.
Frühes Verwerfen eines zufälligen Pakets in einer Ausführungsform der Erfindung
An einer Netzschnittstelle können Pakete mit einer höheren Rate von einem Netz ankommen, als sie an einen Host-Computer übertragen werden können. Wenn eine solche Situation vorliegt, muss die Netzschnittstelle häufig eines oder mehrere Pakete fallen lassen oder verwerfen. Somit werden in einer Ausführungsform der vorliegenden Erfindung ein System und ein Verfahren zum zufälligen Verwerfen eines Pakets geschaffen. Die in diesem Abschnitt diskutierten Systeme und Verfahren können auch auf andere Kommunikationsvorrichtungen wie etwa Gateways, Router, Brücken, Modems usw. anwendbar sein.
Wie der Fachmann auf dem Gebiet erkennt, ist ein Grund, dass ein Paket fallen gelassen werden kann, dass eine Netzschnittstelle bereits die maximale Anzahl von Paketen speichert, die sie zur Übertragung an einen Host-Computer speichern kann. Insbesondere kann eine Warteschlange, die an einen Host-Computer zu übertragende Pakete hält, wie etwa die (in 1A gezeigte) Paketwarteschlange 116 vollständig bevölkert sein, wenn ein weiteres Paket von einem Netz empfangen wird. Entweder das neue Paket oder ein bereits in der Warteschlange gespeichertes Paket kann fallen gelassen werden.
Teilweise wegen des diskontinuierlichen Wesens vielen Netzverkehrs können häufig mehrere Pakete fallen gelassen werden, wenn eine Netzschnittstelle überfüllt ist. Außerdem kann in einigen Netzschnittstellen eine besondere Netzverbindung oder ein besonderer Netzfluss (z. B. eine Verbindung oder ein Fluss, die/der alle fallen gelassenen Pakete enthält) benachteiligt werden, selbst wenn sie nicht für diese hohe Rate der Paketankunft verantwortlich ist, falls aufeinander folgende Pakete fallen gelassen werden. Falls eine Netzverbindung oder ein Netzfluss zu stark zu benachteiligen wird, kann die Netzentität, die den Verkehr in dieser Verbindung oder in diesem Fluss erzeugt, sie/ihn in dem Glauben abbauen, dass eine "unterbrochene Datenübergabe" ("broken pipe") festgestellt worden ist. Wie der Fachmann auf dem Gebiet erkennt, tritt eine unterbrochene Datenübergabe auf, wenn eine Netzentität ein Kommunikationsproblem in der Weise interpretiert, dass es angibt, dass eine Verbindung getrennt worden ist.
Für bestimmten Netzverkehr (z. B. TCP-Verkehr) kann das Fallenlassen eines Pakets ein Verfahren zur Flusssteuerung beginnen, in dem das Fenster einer Netzentität (z. B. die Anzahl der Pakete, die sie überträgt, bevor sie auf eine Quittierung wartet) schrumpft oder auf eine sehr niedrige Zahl zurückgesetzt wird. Somit muss die Kommunikationseinrichtung ihre Verbindung mit der empfangenden Entität jedes Mal neu synchronisieren, wenn durch eine Netzschnittstelle in einer empfangenden Entität ein Paket von einer TCP-Kommunikationseinrichtung fallen gelassen wird. Falls eine Kommunikationseinrichtung oder eine Teilmenge von Kommunikationseinrichtungen für einen großen Prozentsatz in der Entität empfangenen Netzverkehrs verantwortlich sind, scheint es gerecht, dass diese Kommunikationseinrichtungen proportional zum Betrag des Verkehrs benachteiligt werden sollten, für den sie verantwortlich sind.
Außerdem kann es klug sein zu verhindern, dass bestimmte Pakete oder Pakettypen verworfen werden. Zum Beispiel kann das Verwerfen eines kleinen Steuerpakets sehr wenig dazu beitragen, die Stauung in einer Netzschnittstelle zu mildern, aber dennoch eine drastische und negative Wirkung auf eine Netzverbindung oder auf einen Netzfluss haben. Ferner kann es dann, wenn eine Netzschnittstelle für Pakete optimiert ist, die ein besonderes Protokoll befolgen, effizienter sein, das Fallenlassen solcher Pakete zu vermeiden. Noch weiter können bestimmte Verbindungen, Flüsse oder Anwendungen priorisiert werden, wobei in diesem Fall Verkehr mit höherer Priorität nicht fallen gelassen werden sollte.
Somit wird in einer Ausführungsform einer Netzschnittstelle gemäß der vorliegenden Erfindung ein Verfahren geschaffen, um ein Paket zufällig zu verwerten, falls die Paketwarteschlange einer Kommunikationsvorrichtung voll ist oder zu einem gewissen Pegel gefüllt ist. Zu einem solchen Verfahren kann dadurch, dass bestimmte Typen zu verwerfender Pakete (z. B. Pakete von einem besonderen Fluss, von einer besonderen Verbindung oder von einer besonderen Anwendung) ausgewählt werden, oder dadurch, dass bestimmte Typen von Paketen (z. B. Steuerpakete, Pakete, die mit einem besonderen Protokoll oder mit einer besonderen Menge von Protokollen in Übereinstimmung sind) davon ausgenommen werden, verworfen zu werden, zu einem solchen Verfahren Intelligenz hinzugefügt werden.
Ein geschaffenes Verfahren ist dahingehend zufällig, dass verworfene Pakete zufällig aus jenen Paketen, die als verwerfbar betrachtet werden, ausgewählt werden. Das Anwenden einer Richtlinie des zufälligen Verwerfens kann dadurch, dass die Auswirkung fallen gelassener Pakete auf mehrere Verbindungen oder Flüsse aufgeteilt werden, ausreichen, um unterbrochene Datenübergaben zu vermeiden. Falls eine kleine Anzahl sendender Entitäten für einen Großteil des an einer Netzschnittstelle empfangenen Verkehrs verantwortlich sind, kann das zufällige Fallenlassen von Paketen außerdem sicherstellen, dass die störenden Entitäten proportional benachteiligt werden. Verschiedene Ausführungsformen der Erfindung, die im Folgenden diskutiert werden, schaffen verschiedene Kombinationen aus Zufälligkeit und Intelligenz, wobei in einer oder in mehreren Ausführungsformen eines dieser Attribute weggelassen werden kann.
24 zeigt ein System und ein Verfahren zum zufälligen Verwerten von Paketen in einer vorliegenden Ausführungsform der Erfindung. In dieser Ausführungsform ist die Paketwarteschlange 2400 eine Hardware-FIFO-Warteschlange (z. B. Hardware-Zuerst-Eingeben/Zuerst-Ausgeben-Warteschlange) mit einer Größe von 16 kB. In anderen Ausführungsformen der Erfindung kann die Paketwarteschlange kleiner oder größer sein oder einen anderen Datenstrukturtyp (z. B. Liste, Datenfeld, Tabelle, Halde) umfassen, der in Hardware oder Software implementiert ist.
Die Paketwarteschlange 2400 empfängt ähnlich der in einem vorangegangenen Abschnitt diskutierten Paketwarteschlange 116 Pakete von einem Netz, wobei sie sie zur Übertragung an einen Host-Computer hält. Die von einem Netz ankommenden Pakete können mit einer hohen Rate von dem Netz ankommen und können durch eines oder mehrere Module (z. B. durch die Einrichtung 106 zur syntaktischen Analyse, durch den Flussdatenbankmanager 108) verarbeitet oder untersucht werden, bevor sie in der Paketwarteschlange 2400 gespeichert werden. Zum Beispiel können dort, wo das Netz ein Gigabit Verkehr pro Sekunde senden kann, Pakete, die mit einer Menge von Protokollen (z. B. Ethernet, IP und TCP) in Übereinstimmung sind, mit einer Rate von etwa 1,48 Millionen Paketen pro Sekunden empfangen werden. Nachdem die Pakete in der Paketwarteschlange 2400 gespeichert worden sind, werden sie mit einer Rate, die teilweise von Ereignissen und Bedingungen abhängt, die intern für den Host-Computer sind, an einen Host-Computer übertragen. Somit kann die Netzschnittstelle die Rate der Paketsendung an den Host-Computer möglicherweise nicht steuern kann.
In der veranschaulichten Ausführungsform ist die Paketwarteschlange 2400 in mehrere Zonen oder Gebiete unterteilt, von denen sich jede bzw. jedes überschneiden oder eine gemeinsame Grenze besitzen kann. Die Paketwarteschlange 2400 kann in irgendeine Anzahl von Zonen unterteilt sein, wobei die Erfindung nicht auf die drei in 24 gezeigten Zonen beschränkt ist. Beispielhaft umfasst die (durch das Bezugszeichen 2402 repräsentierte) Zone null den Abschnitt der Paketwarteschlange 2400 von 0 kB (z. B. keine in der Warteschlange gespeicherten Pakete) bis 8 kB (z. B. halb voll). Die (durch das Bezugszeichen 2404 repräsentierte) Zone eins umfasst den Abschnitt der Paketwarteschlange von 8 kB bis 12 kB. Die (durch das Bezugszeichen 2406 repräsentierte) Zone zwei umfasst den verbleibenden Abschnitt der Paketwarteschlange von 12 kB bis 16 kB. In einer alternativen Ausführungsform können nur für einen Abschnitt der Paketwarteschlange 2400 Zonen definiert sein. Zum Beispiel kann nur die obere Hälfte (z. B. über 8 kB) in eine oder in mehrere Zonen unterteilt sein.
Die Anzahl und die Größe der verschiedenen Zonen und der Ort der Grenzen zwischen den Zonen können sich gemäß mehreren Faktoren ändern. Unter den Faktoren sind der Typ der an der Netzschnittstelle empfangenen Pakete (z. B. die Protokolle, gemäß denen die Pakete konfiguriert sind), die Größe der Pakete, die Rate der Paketankunft (z. B. erwartete Rate, Durchschnittsrate, Spitzenrate), die Rate der Paketübertragung an den Host-Computer, die Größe der Paketwarteschlange usw. Zum Beispiel ist die Paketwarteschlange 2400 in einer weiteren Ausführungsform der Erfindung in fünf Zonen unterteilt. Eine erste Zone verläuft von 0 kB bis 8 kB; eine zweite Zone reicht von 8 kB bis 10 kB; eine dritte von 10 kB bis 12 kB; eine vierte von 12 kB bis 14 kB; und eine letzte Zone verläuft von 14 kB bis 16 kB.
Während des Betriebs einer Netzschnittstelle gemäß einer vorliegenden Ausführungsform gibt der Verkehrsindikator 2408 an, wie voll die Paketwarteschlange 2400 ist. In einer Ausführungsform der Erfindung umfasst der Verkehrsindikator 2408 einen Lesezeiger 810 und/oder einen Schreibzeiger 812 (die in 8 gezeigt sind). In der gegenwärtig diskutierten Ausführungsform, in der die Paketwarteschlange 2400 vollständig aufgeteilt ist, befindet sich der Verkehrsindikator 2408 allgemein in einer der Zonen, in die die Paketwarteschlange unterteilt ist, oder an einer Unterteilungsgrenze. Somit kann während des Betriebs einer Netzschnittstelle je nachdem, wie voll die Paketwarteschlange ist (z. B. je nachdem, welche Zone durch den Verkehrsindikator 2408 identifiziert wird), wie oben beschrieben eine geeignete Maßnahme ergriffen werden.
In 24 wird ein Zähler 2410 inkrementiert, während Pakete an der Paketwarteschlange 2400 ankommen. In der veranschaulichten Ausführungsform durchläuft der Zähler 2410 ununterbrochen zyklisch einen begrenzten Bereich von Werten wie etwa null bis sieben. In einer Ausführungsform der Erfindung wird der Zähler jedes Mal um eins inkrementiert, wenn ein neues Paket empfangen wird. In einer alternativen Ausführungsform kann der Zähler 2410 nicht inkrementiert werden, wenn bestimmte "nicht verwerfbare" Pakete empfangen werden. Im Folgenden werden verschiedene beispielhafte Kriterien zum Identifizieren nicht verwerfbarer Pakete dargestellt.
Für eine oder mehrere Zonen der Paketwarteschlange 2400 gibt ein zugeordneter programmierbarer Wahrscheinlichkeitsindikator die Wahrscheinlichkeit an, dass ein Paket fallen gelassen wird, wenn der Verkehrsindikator 2408 angibt, dass das Niveau des Verkehrs in der Paketwarteschlange die zugeordnete Zone erreicht hat. Somit gibt der Wahrscheinlichkeitsindikator 2412 in der veranschaulichten Ausführungsform die Wahrscheinlichkeit an, dass ein Paket fallen gelassen wird, während die Paketwarteschlange weniger als halb voll ist (wenn sich der Verkehrsindikator 2408 z. B. in der Zone null befindet). Ähnlich geben die Wahrscheinlichkeitsindikatoren 2414 und 2416 die Wahrscheinlichkeit an, dass ein neues Paket fallen gelassen wird, wenn der Verkehrsindikator 2408 die Zonen eins bzw. zwei identifiziert.
In der veranschaulichten Ausführungsform umfassen die Wahrscheinlichkeitsindikatoren 2412, 2414 und 2416 jeweils eine Menge oder Maske von Unterindikatoren wie etwa von Bits oder Merkern. Beispielhaft ist die Anzahl der Unterindikatoren in einem Wahrscheinlichkeitsindikator mit dem Bereich von Zählerwerten – in diesem Fall acht – in Übereinstimmung. In einer Ausführungsform der Erfindung kann jeder Unterindikator einen von zwei Werten (z. B. null oder eins) haben, die angeben, ob ein Paket fallen gelassen wird. Somit können die Unterelemente eines Wahrscheinlichkeitsindikators von null bis sieben (beispielhaft von rechts nach links) nummeriert werden, so dass sie den acht möglichen Werten des Zählers 2410 entsprechen. Für jede Stelle in einem Wahrscheinlichkeitsindikator, die einen ersten Wert (z. B. eins) speichert, wird das nächste aus der Paketwarteschlange 2400 empfangene verwerfbare Paket fallen gelassen, wenn der Wert des Zählers 2410 mit der Zahl dieses Bits in Übereinstimmung ist. Wie oben diskutiert wurde, können bestimmte Pakettypen (z. B. Steuerpakete) nicht fallen gelassen werden. Beispielhaft wird der Zähler 2410 nur für verwerfbare Pakete inkrementiert.
Der Wahrscheinlichkeitsindikator 2412 (z. B. 00000000) in 24 gibt an, dass keine Pakete fallen zu lassen sind, solange die Paketwarteschlange weniger als halb voll ist (z. B., solange der Verkehrsindikator 2408 in der Zone null ist). Der Wahrscheinlichkeitsindikator 2414 (z. B. 00000001) gibt an, dass jedes achte Paket fallen zu lassen ist, wenn in der Paketwarteschlange wenigstens 8 kB gespeichert sind. Mit anderen Worten, wenn sich der Verkehrsindikator 2408 in der Zone eins befindet, gibt es eine Wahrscheinlichkeit von 12,5 %, dass ein verwerfbares Paket fallen gelassen wird. Insbesondere dann, wenn der Zähler 2410 gleich null ist, wird das nächste verwerfbare Paket oder ein bereits in der Paketwarteschlange gespeichertes Paket verworfen. Der Wahrscheinlichkeitsindikator 2416 (z. B. 01010101) gibt an, dass jedes zweite verwerfbare Paket fallen zu lassen ist. Somit gibt es eine Wahrscheinlichkeit von 50 %, dass ein verwerfbares Paket fallen gelassen wird, wenn die Warteschlange mehr als dreiviertel voll ist. Beispielhaft wird der Zähler 2410 weiter inkrementiert, wenn ein Paket fallen gelassen wird.
Als ein weiteres Beispiel können in der oben beschriebenen alternativen Ausführungsform, in der die Paketwarteschlange in fünf Zonen unterteilt ist, geeignete Wahrscheinlichkeitsindikatoren die folgenden enthalten. Für die Zonen null und eins 00000000; für die Zone zwei 00000001; für die Zone drei 00000101; und für die Zone vier 01111111. Somit wird in dieser alternativen Ausführungsform die Zone eins als eine Erweiterung zur Zone null behandelt. Ferner hat die Wahrscheinlichkeit, dass ein Paket fallen gelassen wird, einen weiteren Bereich von 0 % bis 87,5 %.
In einer oben beschriebenen alternativen Ausführungsform ist nur ein Abschnitt einer Paketwarteschlange in Zonen aufgeteilt. In dieser alternativen Ausführungsform kann einem nicht aufgeteilten Abschnitt eine Standardwahrscheinlichkeit oder die Wahrscheinlichkeit null (z. B. 00000000) des Fallenlassens eines Pakets zugeordnet sein. Beispielhaft stellt dies sicher, dass keine Pakete fallen gelassen werden, bevor das Niveau des in der Warteschlange gespeicherten Verkehrs einen ersten Schwellenwert erreicht. Selbst in einer Ausführungsform, in der die gesamte Warteschlange aufgeteilt ist, kann einer Zone, die einen Schwellenwert von 0 kB umfasst oder eingrenzt, eine Standardwahrscheinlichkeit oder die Wahrscheinlichkeit null zugeordnet sein.
Ebenso wie eine Paketwarteschlange für die vorliegende Erfindung in irgendeine Anzahl von Zonen unterteilt sein kann, können die Wahrscheinlichkeitsindikatoren Bitmasken irgendeiner Größe oder irgendeines Betrags umfassen und brauchen nicht die gleiche Größe oder den gleichen Betrag zu haben. Ferner sind die Wahrscheinlichkeitsindikatoren in der vorliegenden Ausführungsform programmierbar, was ermöglicht, sie sogar während des Betriebs einer Netzschnittstelle zu ändern.
Der Fachmann auf dem Gebiet erkennt, dass das Verwerfen von Paketen anhand eines Wahrscheinlichkeitsindikators eine Zufälligkeit in den Prozess des Verwerfens bringt. Eine Richtlinie des zufälligen frühen Verwerfens kann ausreichen, um das oben diskutierte Problem unterbrochener Datenübergaben zu vermeiden. Insbesondere werden in einer Ausführungsform der Erfindung alle Pakete als verwerfbar betrachtet, so dass alle Pakete vom Zähler 2410 gezählt werden und alle Kandidaten dafür sind, fallen gelassen zu werden. Wie bereits diskutiert wurde, wird dagegen in einer weiteren Ausführungsform der vorliegenden Erfindung im Prozess des Ausschließens bestimmter Typen von Paketen davon, verworfen zu werden, Intelligenz hinzugefügt.
Selbstverständlich bilden die Wahrscheinlichkeitsindikatoren und ein Zähler nur ein System, um das zufällige Verwerfen von Paketen in einer Netzschnittstelle zu ermöglichen. Andere Mechanismen sind ebenfalls geeignet. In einer alternativen Ausführungsform kann anstelle eines Zählers und/oder von Wahrscheinlichkeitsindikatoren ein Zufallszahlengenerator verwendet werden, um eine Richtlinie des zufälligen Verwerfens zu ermöglichen. Wenn z. B. eine Zufallszahl wie etwa M erzeugt wird, kann das M-te Paket (oder jedes M-te Paket), nachdem die Zahl erzeugt worden ist, fallen gelassen werden. Alternativ kann die Zufallszahl eine Wahrscheinlichkeit des Fallenlassens eines Pakets angeben. Somit kann die Zufallszahl auf einen bestimmten Bereich von Werten oder Wahrscheinlichkeiten begrenzt (z. B. in ihn Hash-codiert) werden. Als eine weitere Alternative kann ein Zufallszahlengenerator zusammen mit mehreren Zonen oder Schwellenwerten in einer Paketwarteschlange verwendet werden. In dieser alternativen Ausführungsform kann einem Paket- oder Warteschlangenschwellenwert ein programmierbarer Wert zugeordnet sein, der hier als N repräsentiert ist. Wenn ein Verkehrsindikator daraufhin diesen Schwellenwert oder diese Zone erreicht, kann das N-te Paket (oder jedes N-te Paket) fallen gelassen werden, bis ein weiterer Schwellenwert oder eine weitere Grenze erreicht ist.
In einer nochmals weiteren alternativen Ausführungsform der Erfindung wird die Wahrscheinlichkeit des Fallenlassens eines Pakets als ein binärer Bruch ausgedrückt. Wie der Fachmann auf dem Gebiet erkennt, besteht ein binärer Bruch aus einer Reihe von Bits, in denen jedes Bit die Hälfte des Betrags seines höherwertigen Nachbarn repräsentiert. Zum Beispiel kann ein binärer Bruch in einer Ausführungsform der Erfindung vier Stellen verwenden. Die Bits können von links nach rechts 0,5, 0,25, 0,125 und 0,0625 repräsentieren. Somit wird ein binärer Bruch 1010 in der Weise interpretiert, dass er eine Wahrscheinlichkeit von 62,5 % des Fallenlassens eines Pakets (z. B. 50 % plus 12,5 %) angibt. Je mehr Stellen (z. B. Bits) in einem binären Bruch verwendet werden, desto höher ist die Wahrscheinlichkeit, die erreicht werden kann.
In einer Implementierung dieser alternativen Ausführungsform wird jeder Ziffer ein getrennter Paketzähler zugeordnet. Der Zähler für das ganz linke Bit wird mit der doppelten Rate des nächsten Zählers inkrementiert, der doppelt so schnell wie der nächste Zähler inkrementiert wird usw. Mit anderen Worten, wenn der Zähler für das höchstwertige (z. B. linke) Bit von 0 auf 1 inkrementiert wird, ändern sich die anderen Zähler nicht. Wenn der höchstwertige Zähler erneut von 1 auf 0 zurück inkrementiert wird, wird der nächste Zähler von 0 auf 1 inkrementiert. Gleichfalls wird der Zähler für das dritte Bit erst von 0 auf 1 inkrementiert, wenn der zweite Zähler auf 0 zurückkehrt. Zusammengefasst ändert sich der Zähler für das höchstwertige Bit jedes Mal (d. h., er wird jedes Mal inkrementiert), wenn ein Paket empfangen wird. Der Zähler für das zweithöchstwertige Bit hält für zwei Pakete jeden Wert (d. h. 0 oder 1), bevor er inkrementiert wird. Ähnlich hält der Zähler für das dritthöchstwertige Bit jeden Zählerwert für vier Pakete, bevor er inkrementiert wird, und hält der Zähler für das niedrigstwertige Bit seinen Wert für acht Pakete, bevor er inkrementiert wird.
Jedes Mal, wenn ein Paket empfangen wird oder ein Zähler inkrementiert wird, werden die Zähler mit dem Wahrscheinlichkeitsindikator (z. B. mit dem angegebenen binären Bruch) verglichen. In einer Ausführungsform hängt die Feststellung, ob ein Paket fallen gelassen wird, davon ab, welche Bits des Bruchs gleich eins sind. Beispielhaft wird für jedes Bruchbit gleich eins ein zufälliges Paket fallen gelassen, falls der entsprechende Zähler gleich eins ist und die Zähler für irgendwelche höherwertigen Bits gleich null sind. Somit wird für den beispielhaften Bruch 1010 jedes Mal ein zufälliges Paket fallen gelassen, wenn der Zähler des höchstwertigen Bits gleich eins ist. Außerdem wird auch jedes Mal ein zufälliges Paket fallen gelassen, wenn der Zähler für das dritte Bit gleich eins ist und die Zähler für die ersten zwei Bits gleich null sind.
Der Fachmann auf dem Gebiet kann außerdem andere geeignete Mechanismen ableiten, um eine Wahrscheinlichkeit des Fallenlassens eines bei einer Netzschnittstelle empfangenen Pakets anzugeben oder zu erzwingen, ohne den Umfang der vorliegenden Erfindung zu überschreiten.
Wie bereits erwähnt wurde, kann einer Richtlinie des zufälligen Verwerfens Intelligenz verliehen werden, um das Verwerfen bestimmter Pakettypen zu vermeiden. In einem vorangegangenen Abschnitt wurden Verfahren zur syntaktischen Analyse eines von einem Netz empfangenen Pakets beschrieben. Insbesondere wird in einer vorliegenden Ausführungsform der Erfindung ein von einem Netz empfangenes Paket syntaktisch analysiert, bevor es in einer Paketwarteschlange wie etwa in der Paketwarteschlange 2400 angeordnet wird. Während der Prozedur zur syntaktischen Analyse können verschiedene das Paket betreffende Informationen entnommen werden. Diese Informationen können verwendet werden, um in eine Richtlinie des zufälligen Verwerfens Intelligenz einzuführen. Insbesondere können ein oder mehrere Felder eines Paketkopfs kopiert werden, kann eine Ursprungs- oder Zielentität des Pakets identifiziert werden, kann ein Protokoll identifiziert werden usw.
Somit können in verschiedenen Ausführungsformen der Erfindung bestimmte Pakete oder Pakettypen immun dagegen sein, verworfen zu werden. Zum Beispiel sind in der in 24 veranschaulichten Ausführungsform Steuerpakte immun. Wie dem Fachmann auf dem Gebiet klar ist, enthalten Steuerpakete häufig Informationen, die wesentlich für den Aufbau, für die Wiederherstellung oder für das Haften einer Kommunikationsverbindung sind. Somit kann das Fallenlassen eines Steuerpakets eine ernstere und stärker schädigende Wirkung haben als das Fallenlassen eines Pakets, das kein Steuerpaket ist. Außerdem kann das Fallenlassen eines Steuerpakets sehr wenig Raum in der Paketwarteschlange sparen, da Steuerpakete im Allgemeinen keine Daten enthalten.
Für das Immunisieren von Paketen sind viele weitere Kriterien möglich. Wenn ein Paket z. B. gemäß einer in einem vorangegangenen Abschnitt beschriebenen Prozedur syntaktisch analysiert wird, kann dem Paket ein No_Assist-Merker oder -Signal zugeordnet werden, der/das angibt, ob das Paket mit einer Menge von im Voraus gewählten Kommunikationsprotokollen kompatibel ist. Falls der Merker beispielhaft auf einen ersten Wert (z. B. eins) gesetzt wird oder das Signal angehoben wird, wird das Paket als inkompatibel betrachtet und ist somit für bestimmte Verarbeitungsverbesserungen (z. B. für das Wiederzusammensetzen von Paketdaten, für die Blockbildungsverarbeitung von Paketköpfen, für die Lastverteilung) untauglich. Da ein Paket, für das ein No_Assist-Merker auf einen ersten Wert gesetzt ist, ein Paket sein kann, das mit einem unerwarteten Protokoll oder einzigartigen Format in Übereinstimmung ist, kann es besser sein, solche Pakete nicht fallen zu lassen. Zum Beispiel möchte ein Netzmanager eventuell den Empfang aller solcher Pakete sicherstellen, um zu ermitteln, ob eine Prozedur zur syntaktischen Analyse um die Fähigkeit zur syntaktischen Analyse zusätzlicher Protokolle vermehrt werden sollte.
Ein weiterer Grund dafür, ein No_Assist-Paket (z. B. Pakete, die mit einer Menge von ausgewählten Protokollen inkompatibel sind) dagegen zu immunisieren, verworfen zu werden, betrifft die Reaktion auf das Fallenlassen des Pakets. Da die Protokolle des Pakets nicht identifiziert wurden, kann nicht bekannt sein, wie die Protokolle des Pakets auf den Verlust eines Pakets reagieren. Insbesondere dann, wenn der Absender des Pakets seine Übertragungsrate nicht (z. B. als eine Form der Stauungssteuerung) in Reaktion auf das fallen gelassene Paket verringert, nutzt es nichts, es fallen zu lassen.
In einer weiteren alternativen Ausführungsform der Erfindung kann die Flussnummer eines Pakets verwendet werden, um bestimmte Pakete zu immunisieren. Wie in einem vorangegangenen Abschnitt diskutiert wurde, kann eine Netzschnittstelle eine Flussdatenbank und einen Flussdatenbankmanager enthalten, um eine Aufzeichnung mehrerer durch die Netzschnittstelle empfangener Kommunikationsflüsse zu halten. Es kann wirksam sein zu verhindern, dass Pakete aus einem oder aus mehreren bestimmten Flüssen verworfen werden. Immunisierte Flüsse können einen Fluss, der eine Netzentität mit hoher Priorität umfasst, einen Fluss, der eine besondere Anwendung umfasst, usw. enthalten. Zum Beispiel kann es als verhältnismäßig wenig schädigend betrachtet werden, Pakete aus einer animierten oder Streaming-Graphikanwendung zu verwerfen, in der ein Paket oder wenige Pakete verloren gehen können, ohne die Zielentität ernsthaft zu beeinflussen, wobei die Pakete möglicherweise noch nicht einmal neu übertragen zu werden brauchen. Im Gegensatz dazu können die Folgen ernster sein, falls einige Pakete aus einer Dateiübertragungsverbindung fallen gelassen werden. Die Pakete müssen wahrscheinlich neu übertragen werden und im Ergebnis dessen kann das Fenster der sendenden Entität schrumpfen – so dass sich die Dateiübertragungsrate verringert.
In einer nochmals weiteren alternativen Ausführungsform der Erfindung kann ein Wahrscheinlichkeitsindikator eine Bitmaske umfassen, in der jedes Bit einem getrennten, spezifischen Fluss über die Netzschnittstelle entspricht. Insbesondere können die Bits den Flüssen entsprechen, die in der in einem vorangegangenen Abschnitt beschriebenen Flussdatenbank gehalten werden.
Obgleich die bisher in diesem Abschnitt diskutierten Ausführungsformen der Erfindung das Verwerfen von Paketen umfassen, während sie an einer Paketwarteschlange ankommen, können die Pakete in einer alternativen Ausführungsform aus der Warteschlange verworfen werden. Insbesondere, während die Paketwarteschlange gefüllt wird (z. B., während ein Verkehrsindikator vorgegebene Zonen oder Schwellenwerte erreicht), können bereits in der Warteschlange gespeicherte Pakete gemäß einem oder mehreren Wahrscheinlichkeitsindikatoren zufällig verworfen werden. Wenn z. B. in der in 24 veranschaulichten Ausführungsform der Verkehrsindikator 2408 einen bestimmten Schwellenwert wie etwa die Grenze zwischen den Zonen 1 und 2 oder das Ende der Warteschlange erreicht, können Pakete in einer oder in mehreren Zonen gemäß verwandten Wahrscheinlichkeitsindikatoren gelöscht werden. Diese Wahrscheinlichkeitsindikatoren haben wahrscheinlich andere Werte als die in 24 angegebenen.
In einer vorliegenden Ausführungsform der Erfindung sind die Wahrscheinlichkeitsindikatoren und/oder die Spezifikationen (z. B. die Grenzen), in die eine Paketwarteschlange aufgeteilt ist, programmierbar und können durch Software, die in einem Host-Computer arbeitet (z. B. durch einen Gerätetreiber) angepasst werden. Die Kriterien zum Immunisieren von Paketen können ebenfalls programmierbar sein. Somit können die Verfahren zum Verwerfen von Paketen in einer Netzschnittstelle oder in einer anderen Kommunikationsvorrichtung in Übereinstimmung mit den in diesem Abschnitt beschriebenen Ausführungsformen selbst während des fortgesetzten Betriebs einer solchen Vorrichtung geändert werden. Verschiedene weitere Ausführungsformen und Kriterien für das zufällige Verwerfen von Paketen und/oder für das Anwenden von Kriterien für das intelligente Verwerfen von Paketen sind dem Fachmann auf dem Gebiet klar.
Die 25A–25B umfassen einen Ablaufplan, der ein Verfahren zur Realisierung einer Richtlinie zum zufälligen Verwerfen von Paketen in einer Netzschnittstelle gemäß der Ausführungsform der Erfindung demonstriert, der im Wesentlichen ähnlich der in 24 veranschaulichten Ausführungsform ist. In dieser Ausführungsform wird ein Paket empfangen, während die Paketwarteschlange 2400 noch nicht voll ist. Wie für den Fachmann klar ist, schafft diese Ausführungsform ein Verfahren um festzustellen, ob das Paket zu verwerfen ist. Wenn ein weiteres Paket empfangen wird, nachdem die Paketwarteschlange 2400 voll ist, muss die Netzschnittstelle allgemein ein Paket – entweder das eben empfangene oder ein bereits in der Warteschlange gespeichertes – fallen lassen, wobei die einzige Entscheidung in diesem Fall nur ist, welches Paket fallen zu lassen ist.
In 25A ist der Zustand 2500 ein Startzustand. Der Zustand 2500 kann die Initialisierung der Netzschnittstelle (und der Paketwarteschlange 2400) reflektieren oder kann einen Punkt im Betrieb der Netzschnittstelle reflektieren, an dem einer oder mehrere Parameter oder Aspekte, die die Paketwarteschlange und die Richtlinie des zufälligen Verwerfens betreffen, zu ändern sind.
Im Zustand 2502 werden in der Paketwarteschlange 2400, vielleicht durch Angeben von Grenzen wie etwa der in 24 gezeigten 8-kB- und 12-kB-Grenze, eine oder mehrere Zonen identifiziert. Obgleich die in 24 gezeigten Zonen, wenn sie in Übereinstimmung betrachtet werden, die Paketwarteschlange 2400 vollständig umfassen, können die Zonen in einer alternativen Ausführungsform der Erfindung weniger als die gesamte Warteschlange umfassen.
Im Zustand 2504 werden einer oder mehrere Wahrscheinlichkeitsindikatoren zugewiesen und konfiguriert. In der veranschaulichten Ausführungsform wird jeder Zone ein Wahrscheinlichkeitsindikator zugeordnet. Alternativ kann mehreren Zonen ein Wahrscheinlichkeitsindikator zugeordnet werden. Nochmals weiter kann einer oder mehreren Zonen nicht explizit ein Wahrscheinlichkeitsindikator zugeordnet werden, wobei in diesem Fall ein Standard- oder Null-Wahrscheinlichkeitsindikator angenommen werden kann. Wie oben beschrieben wurde, kann ein Wahrscheinlichkeitsindikator die Form einer Mehrbitmaske annehmen, wobei die Anzahl der Bits in der Maske den Bereich möglicher Werte reflektiert, die durch einen Paketzähler gehalten werden. In einer weiteren Ausführungsform der Erfindung kann ein Wahrscheinlichkeitsindikator die Form einer Zufallszahl oder eines Schwellenwerts, mit dem eine zufällig erzeugte Zahl verglichen wird, annehmen, wenn eine Entscheidung getroffen werden muss, ob ein Paket zu verwerfen ist.
Falls im Zustand 2506 verhindert werden soll, dass bestimmte Pakettypen verworfen werden, werden Kriterien zum Identifizieren der ausgenommenen Pakete ausgedrückt. Einige Pakete, die ausgenommen werden können, sind Steuerpakete, Pakete, die mit unbekannten oder mit bestimmten bekannten Protokollen in Übereinstimmung sind, Pakete, die zu einer besonderen Netzverbindung oder zu einem besonderen Netzfluss gehören usw. In einer Ausführungsform der Erfindung werden keine Pakete davon ausgenommen, verworfen zu werden.
Im Zustand 2508 wird ein Paket- oder Verkehrszähler initialisiert. Wie oben beschrieben wurde, kann der Zähler, möglicherweise über einen beschränkten Bereich von Werten, inkrementiert werden, wenn in der Paketwarteschlange 2400 ein verwerfbares Paket zur Speicherung empfangen wird. Der beschränkte Bereich von Zählerwerten kann der Anzahl von Bits in einer Maskenform eines Wahrscheinlichkeitsindikators entsprechen. Alternativ kann der Zähler so konfiguriert werden, dass er über einen größeren Bereich inkrementiert wird, wobei ein Zählerwert in diesem Fall durch eine Modul- oder Hash-Funktion gefiltert werden kann, bevor er wie unten beschrieben mit einem Wahrscheinlichkeitsindikator verglichen wird.
Im Zustand 2510 wird ein Paket von einem Netz empfangen, wobei es vor seiner Ankunft in der Paketwarteschlange 2400 durch eines oder mehrere Module (z. B. eine Einrichtung zur syntaktischen Kopfanalyse, ein IPP-Modul) verarbeitet werden kann. Somit ist das Paket im Zustand 2510 bereit, in der Paketwarteschlange gespeichert zu werden. In der Paketwarteschlange können bereits eines oder mehrere Pakete gespeichert sein, wobei ein Verkehrsindikator (z. B. ein Zeiger oder Index) das Niveau des in der Warteschlange gespeicherten Verkehrs (z. B. durch einen Speicherplatz und/oder eine Zone in der Warteschlange) identifiziert.
Im Zustand 2512 kann festgestellt werden, ob das empfangene Paket verwerfbar ist. Falls z. B. die Richtlinie des zufälligen Verwerfens, die wirksam ist, die Ausnahme einiger Pakete davor, verworfen zu werden, zulässt, wird im Zustand 2512 festgestellt, ob das empfangene Paket irgendwelche der Ausnahmekriterien erfüllt. Wenn das der Fall ist, wird die veranschaulichte Prozedur im Zustand 2522 fortgesetzt. Andernfalls wird die Prozedur im Zustand 2514 fortgesetzt.
Im Zustand 2514 wird eine aktive Zone der Paketwarteschlange 2400 identifiziert.
Insbesondere wird die Zone der Paketwarteschlange festgestellt, in die die Warteschlange gegenwärtig mit Verkehr bevölkert wird. Das Niveau des in der Warteschlange gespeicherten Verkehrs hängt von der Anzahl und Größe der Pakete ab, die in der Warteschlange gespeichert worden sind, um auf die Übertragung zu einem Host-Computer zu warten. Je langsamer der Übertragungsprozess ist, desto höher ist das Niveau, das der Verkehr in der Warteschlange erreichen kann. Obgleich das Niveau des in der Warteschlange gespeicherten Verkehrs steigt und fällt, während Pakete gespeichert und übertragen werden, kann das Niveau zu einem Zeitpunkt identifiziert werden, indem der Verkehrsindikator untersucht wird. Der Verkehrsindikator kann einen Zeiger umfassen, der die Stelle des letzten oder nächsten zu speichernden Pakets in der Warteschlange identifiziert. Ein solcher Zeiger kann mit einem weiteren Zeiger verglichen werden, der das nächste an den Host-Computer übertragene Paket identifiziert, um zu offenbaren, wie viel Verkehr in der Warteschlange gespeichert ist.
Im Zustand 2516 wird der Zählerwert (in der Ausführungsform aus 24 z. B. ein Wert zwischen null und sieben) mit dem Wahrscheinlichkeitsindikator verglichen, der der aktiven Zone zugeordnet ist. Wie zuvor beschrieben wurde, wird der Zähler inkrementiert, während verwerfbare Pakete in der Warteschlange empfangen werden. Dieser Vergleich wird durchgeführt, um festzustellen, ob das empfangene Paket verworfen werden sollte. Wie oben erläutert wurde, wird in der Ausführungsform von 24 die Setzung des Wahrscheinlichkeitsindikatorbits, das den Zählerwerten entspricht, untersucht. Zum Beispiel wird das Bit Nummer N der Wahrscheinlichkeitsindikatormaske untersucht, falls der Zähler einen Wert N hat. Falls das Bit auf einen ersten Zustand (z. B. eins) gesetzt ist, ist das Paket zu verwerfen; andernfalls ist es nicht zu verwerfen.
Im Zustand 2518 wird der Zähler unabhängig davon, ob das Paket zu verwerfen ist, inkrementiert, um den Empfang eines verwerfbaren Pakets zu reflektieren. Falls der Zähler in der gegenwärtig diskutierten Ausführungsform der Erfindung einen Maximalwert (z. B. sieben) enthält, bevor er inkrementiert wird, verursacht sein Inkrementieren sein Zurücksetzen auf seinen Minimalwert (z. B. null).
Falls das Paket im Zustand 2520 zu verwerfen ist, wird die veranschaulichte Prozedur im Zustand 2524 fortgesetzt. Ansonsten wird die Prozedur im Zustand 2522 fortgesetzt. Im Zustand 2522 wird das Paket in der Paketwarteschlange 2400 gespeichert und die veranschaulichte Prozedur mit dem Endzustand 2526 abgeschlossen. Im Zustand 2524 wird das Paket verworfen und die veranschaulichte Prozedur mit dem Endzustand 2526 abgeschlossen.
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. Für den erfahrenen Praktiker auf dem Gebiet sind viele Abwandlungen und Änderungen klar. Dementsprechend soll die obige Offenbarung die Erfindung nicht beschränken; wobei der Umfang der Erfindung durch die beigefügten Ansprüche definiert ist.

Claims

Verfahren zum Übertragen eines Pakets von einer Kommunikationsvorrichtung an ein Host-Computersystem, wobei das Verfahren umfasst: syntaktisches Analysieren (134) eines Kopfabschnitts eines ersten Pakets, das bei der Kommunikationsvorrichtung (100) empfangen wird, um festzustellen, ob das erste Paket mit einem im Voraus gewählten Protokoll in Übereinstimmung ist; Erzeugen (134) eines Flussschlüssels, um einen ersten Kommunikationsfluss, der das erste Paket enthält, zu identifizieren; gekennzeichnet durch das Zuordnen (136) eines Operationscodes zu dem ersten Paket anhand der syntaktischen Analyse, um eine Weise anzugeben, in der das erste Paket an das Host-Computersystem übertragen werden sollte; und, falls der Kopf mit einem einer Menge von im Voraus gewählten Protokollen in Übereinstimmung ist: Speichern (1820) eines Datenabschnitts des ersten Pakets in einem Wiederzusammensetzungspuffer, der so konfiguriert ist, dass er Datenabschnitte von Paketen in dem ersten Kommunikationsfluss speichert; und Speichern (1804) des Kopfabschnitts in einen Kopfpuffer, der so konfiguriert ist, dass er Kopfabschnitte von Paketen, die mit dem im Voraus gewählten Protokoll übereinstimmen, und Pakete, die kleiner als eine vorgegebene Größe sind, speichert; und, falls der Kopfabschnitt mit einem Protokoll, das von den im Voraus gewählten Protokollen verschieden ist, in Übereinstimmung ist, Speichern des ersten Pakets in einem Nichtwiederzusammensetzungspuffer (1908), der so konfiguriert ist, dass er Pakete speichert, die nicht mit den im Voraus gewählten Protokollen in Übereinstimmung sind.
Verfahren nach Anspruch 1, bei dem die syntaktische Analyse (134) umfasst: Kopieren (402) eines Kopfabschnitts des ersten Pakets in einen Kopfspeicher (302); und Untersuchen (404, 406) des Kopfabschnitts in Übereinstimmung mit einer Reihe (2300) von Anweisungen zur syntaktischen Analyse; wobei die Anweisungen zur syntaktischen Analyse so konfiguriert sind, dass sie eine Menge von im Voraus gewählten Kommunikationsprotokollen reflektieren.
Verfahren nach Anspruch 2, bei dem die Anweisungen zur syntaktischen Analyse aktualisierbar sind.
Verfahren nach Anspruch 2, das ferner das Kopieren eines Wertes von einem Feld in einen Kopf des Kopfabschnitts umfasst.
Verfahren nach Anspruch 1, bei dem das syntaktische Analysieren (134) umfasst: Extrahieren eines Identifizierers einer Quelle des ersten Pakets aus dem Kopfabschnitt; und Extrahieren eines Identifizierers eines Ziels des ersten Pakets aus dem Kopfabschnitt.
Verfahren nach Anspruch 5, bei dem das Erzeugen (134) das Kombinieren des Quellen-Identifizierers mit dem Ziel-Identifizierer umfasst.
Verfahren nach Anspruch 1, bei dem das Erzeugen (134) das Wiedergewinnen eines Identifizierers einer Kommunikationsverbindung aus dem Kopfabschnitt umfasst.
Verfahren nach Anspruch 1, das ferner das Speichern des ersten Pakets in einem Paketspeicher vor der genannten Speicherung umfasst.
Verfahren nach Anspruch 1, das ferner das Speichern (136) des Flussschlüssels in einer Flussdatenbank (110) umfasst, wobei die Flussdatenbank so konfiguriert ist, dass sie das Management des ersten Kommunikationsflusses erleichtert.
Verfahren nach Anspruch 9, das ferner das Zuordnen einer Flussnummer zu dem ersten Paket umfasst, wobei die Flussnummer einen Index des Flussschlüssels in der Flussdatenbank umfasst.
Verfahren nach Anspruch 10, das ferner das Speichern der Flussnummer in einem Flussspeicher umfasst.
Verfahren nach Anspruch 9, das ferner das Aktualisieren (136) eines dem Flussschlüssel zugeordneten Eintrags in der Flussdatenbank, wenn ein zweites Paket in dem ersten Kommunikationsfluss empfangen wird, umfasst.
Verfahren nach Anspruch 1, bei dem das Zuordnen umfasst: Wiedergewinnen eines oder mehrerer Kopffelder des Kopfabschnitts; und Analysieren der Kopffelder, um einen Status des ersten Pakets zu bestimmen.
Verfahren nach Anspruch 13, bei dem das Analysieren umfasst: Bestimmen (612), ob das erste Paket einen Datenabschnitt enthält; und falls das erste Paket einen Datenabschnitt enthält, Bestimmen (1606, 1608), ob der Datenabschnitt eine vorgegebene Größe überschreitet.
Verfahren nach Anspruch 13, bei dem das Analysieren das Bestimmen (616), ob das erste Paket außer der Reihenfolge in dem ersten Kommunikationsfluss empfangen wurde, umfasst.
Verfahren nach Anspruch 1, das ferner das Speichern (140) des Operationscodes in einem Steuerspeicher (118) umfasst.
Verfahren nach Anspruch 1, das ferner das Bestimmen, ob ein zweites Paket, das von dem Netz empfangen wurde, ein Teil des ersten Kommunikationsflusses ist, umfasst.
Verfahren nach Anspruch 17, bei dem das Bestimmen umfasst: Halten eines Paketspeichers (116), der so konfiguriert ist, dass er ein oder mehrere Pakete, die von dem Netz empfangen werden, speichert; Halten eines Flussspeichers (2102), der so konfiguriert ist, dass er für jedes des einen oder der mehreren Pakete einen Identifizierer eines das Paket enthaltenden Kommunikationsflusses speichert; und Durchsuchen (2208) des Flussspeichers nach einem ersten Identifizierer des ersten Kommunikationsflusses.
Verfahren nach Anspruch 18, bei dem der erste Identifizierer den ersten Flussschlüssel umfasst.
Verfahren nach Anspruch 18, bei dem der erste Identifizierer eine Flussnummer des ersten Pakets umfasst, wobei die Flussnummer ein Index des Flussschlüssels in einer Flussdatenbank ist.
Verfahren nach Anspruch 1, bei dem das Host-Computersystem mehrere Prozessoren umfasst und das Verfahren ferner umfasst: Identifizieren einer Menge von Prozessoren in dem Host-Computersystem, die für die Verarbeitung von Paketen verfügbar ist; und Zuordnen (138) eines ersten Prozessoridentifizierers zu dem ersten Paket, um einen ersten Prozessor in dem Host-Computersystem für die Verarbeitung des ersten Pakets zu identifizieren.
Verfahren nach Anspruch 21, das ferner umfasst: Empfangen eines zweiten Pakets in dem ersten Kommunikationsfluss; und Zuordnen des ersten Prozessoridentifizierers zu dem zweiten Paket.
Verfahren nach Anspruch 21, das ferner umfasst: Empfangen eines zweiten Pakets von einem zweiten Kommunikationsfluss; und Zuordnen eines zweiten Prozessor-Identifizierers zu dem zweiten Paket, um einen zweiten Prozessor in dem Host-Computersystem für die Verarbeitung des zweiten Pakets zu identifizieren.
Verfahren nach Anspruch 1, das ferner das Warnen (148) des Host-Computersystems vor der Ankunft des ersten Pakets umfasst.
Verfahren nach Anspruch 1, das ferner umfasst: Halten der Konfiguration eines Paketspeichers (2400), damit er Pakete, die von dem Netz empfangen werden, speichert; und zufälliges Verwerfen (2524) eines Pakets, falls der Paketspeicher ein vorgegebenes Verkehrsniveau enthält.
Verfahren nach Anspruch 25, bei dem der Paketspeicher mehrere Zonen (2402, 2404) umfasst und das zufällige Verwerfen umfasst: Identifizieren (2514) eines (2402) der mehreren Zonen, wobei ein Verkehrsniveau, das in dem Paketspeicher gespeichert ist, die Zone erreicht hat; Anwenden (2520) eines Wahrscheinlichkeitsindikators (2412), der der Zone zugeordnet ist, um eine Wahrscheinlichkeit zu bestimmen, dass das erste Paket verworfen werden sollte; und falls die Wahrscheinlichkeit einen vorgegebenen Schwellenwert übersteigt, Verwerfen des ersten Pakets.
Verfahren nach Anspruch 1, bei dem die Kommunikationsvorrichtung eine Netzschnittstelle ist.
Verfahren nach Anspruch 1, das ferner umfasst: Speichern des Flussschlüssels in einer Datenbank (110); Speichern einer Flussnummer des Pakets in einem Flussspeicher, wobei die Flussnummer einen Index des Flussschlüssels in der Datenbank enthält; Speichern des Pakets in einem Paketspeicher (116), wobei der Paketspeicher mehrere Zonen (2402, 2404) umfasst; Angeben, ob der Paketspeicher ein weiteres Paket mit der Flussnummer oder dem Flussschlüssel enthält; Bestimmen (2514) eines Niveaus des in dem Paketspeicher gespeicherten Netzverkehrs; und Anwenden (2520) eines Wahrscheinlichkeitsindikators (2414), der einer der Zonen zugeordnet ist, um festzustellen, ob ein von dem Netz empfangenes Paket verworfen werden soll.
Computersystem zum Empfangen eines Pakets von einem Netz, wobei das System umfasst: einen Speicher, der so konfiguriert ist, dass er von einem Netz empfangene Pakete speichert, wobei der Speicher einen ersten Speicherbereich (1008), einen zweiten Speicherbereich (1006) und einen dritten Speicherbereich (1010) umfasst; eine Einrichtung zum Speichern von Datenabschnitten von Paketen, die mit einer im Voraus gewählten Menge von Protokollen in Übereinstimmung sind, in dem ersten Speicherbereich (1008); eine Einrichtung zum Speichern von Kopfabschnitten der übereinstimmenden Pakete in dem zweiten Speicherbereich (1006); und eine Einrichtung zum Speichern von Paketen, die größer als eine vorgegebene Größe sind und nicht mit der im Voraus gewählten Menge von Protokollen in Übereinstimmung sind, in dem dritten Speicherbereich (1010); und eine Kommunikationsvorrichtung (100), die so konfiguriert ist, dass sie von dem Netz ein erstes Paket empfängt, und umfasst: eine Einrichtung (106) zur syntaktischen Analyse, die so konfiguriert ist, dass sie aus einem Kopfabschnitt eines ersten Pakets Informationen extrahiert; einen Flussmanager (108), der so konfiguriert ist, dass er die Informationen untersucht und einen Operationscode erzeugt, um anzuzeigen, wie das erste Paket an den Speicher übertragen werden kann; eine Flussdatenbank (110), die so konfiguriert ist, dass sie einen Identifizierer eines ersten Kommunikationsflusses der das erste Paket enthält, speichert; und eine Wiederzusammensetzungseinrichtung (120), die einen Datenabschnitt des ersten Pakets in dem ersten Speicherbereich in Übereinstimmung mit dem Operationscode speichert.
Computersystem nach Anspruch 29, bei dem der zweite Speicherbereich ferner so konfiguriert ist, dass er Pakete, die kleiner als die vorgegebene Größe sind, speichert.
Computersystem nach Anspruch 29, bei dem die Wiederzusammensetzungseinrichtung außerdem so konfiguriert ist, dass sie einen Kopfabschnitt des ersten Pakets in dem zweiten Speicherbereich speichert.
Computersystem nach Anspruch 29, bei dem die Wiederzusammensetzungseinrichtung außerdem so konfiguriert ist, dass sie ein zweites Paket in dem dritten Speicherbereich speichert, falls ein dem zweiten Paket zugeordneter Operationscode angibt, dass das zweite Paket nicht mit der im Voraus gewählten Menge von Protokollen in Übereinstimmung ist.
Computersystem nach Anspruch 29, wobei die Kommunikationsvorrichtung ferner einen Steuerspeicher (118) umfasst, der so konfiguriert ist, dass er den Operationscode speichert.
Computersystem nach Anspruch 29, wobei: das Computersystem ferner mehrere Prozessoren umfasst; und die Kommunikationsvorrichtung ferner eine Lastverteilungseinrichtung (112) umfasst, die so konfiguriert ist, dass sie einen der mehreren Prozessoren für die Verarbeitung des ersten Pakets auswählt.
Computersystem nach Anspruch 29, wobei die Kommunikationsvorrichtung (100) ferner umfasst: einen Paketspeicher (116), der so konfiguriert ist, dass er vom Netz empfan gene Pakete speichert; und ein Paketblockbildungsmodul (122), das so konfiguriert ist, dass es feststellt, ob der Paketspeicher ein weiteres Paket in dem ersten Kommunikationsfluss enthält.
Computersystem nach Anspruch 35, bei dem der Paketspeicher (116) mehrere Zonen (2402, 2404, 2406) umfasst und bei dem jeder der mehreren Zonen ein Wahrscheinlichkeitsindikator (2412, 2414, 2416) zugeordnet ist, der so konfiguriert ist, dass er eine Wahrscheinlichkeit zum Verwerfen eines bei der Kommunikationsvorrichtung empfangenen Pakets angibt.
Computerprogramm, das, wenn es in einem Computer oder Computernetz ausgeführt wird, das Verfahren nach einem der Ansprüche 1 bis 28 ausführt.
Computerlesbares Speichermedium, das das Computerprogramm nach Anspruch 37 enthält.