Verwaltung von Net Ring-Elementen

Befolgen Sie die Anleitung in diesem Thema, um Ihre NET_RING-Strukturen und deren Elemente während der Netzwerkdatenübertragung zu verwalten. Die Regeln in diesem Thema beschreiben, welche Member der Net Ring-Elemente Clienttreiber je nach Datenpfadszenario ändern können, sowie allgemeine Informationen, die Clienttreiber für diese Strukturen berücksichtigen sollten.

Wichtig

Clienttreiber sollten diese Anweisungen in allen Entwicklungsphasen einhalten. Wenn ein Clienttreiber diese Anweisungen beim Testen mit driver verifier nicht einhält, meldet driver verifier einen Verstoß und löst eine Fehlerprüfung auf dem zu testden Gerät aus.

NET_RING

Wenn die übergeordnete Paketwarteschlange des NET_RING gestartet wird, werden alle Indizes im Ring mit 0 initialisiert.

In der folgenden Tabelle wird beschrieben, welche Member des Net Rings von Clienttreibern geändert werden können.

Feld	Der Clienttreiber darf geändert werden.
OSReserved1	Nein
ElementStride	Nein
Sizeinbytes	Nein
ElementIndexMask	Nein
Endindex	Nein
OSReserved0	Nein
OSReserved2	Nein
BeginIndex	Ja (erforderlich)
NextIndex	Ja (optional) Hinweis: Das Framework liest NextIndex nie.
Entwurf	Ja (optional) Hinweis: Das Framework liest nie Scratch.
Buffer	Nein

Clienttreiber dürfen keine schreibgeschützten Member dieser Struktur ändern und dürfen während eines Aufrufs von EvtPacketQueueAdvance niemals BeginIndex über EndIndex hinaus erhöhen.

Weitere Informationen zum Indexbesitz in Netzringen finden Sie unter Einführung in Netzringe.

NET_PACKET

Die Felder in einem NET_PACKET sind empfindlich auf die verschiedenen Kontexte, in denen der Datenpfad ausgeführt wird. Ob das Feld Ignorieren des Pakets festgelegt ist und ob der Treiber das Paket empfängt (Rx) oder das Paket übermittelt (Tx), ändert den Regelsatz, der auf das Paket angewendet wird.

Die folgende Tabelle enthält Anweisungen für Treiber in jedem Szenario.

Rx oder Tx	Feld ignorieren wird festgelegt durch...	Notizen
Rx	Clienttreiber	Während Rx legen Clienttreiber bei Bedarf Ignorieren fest, und das Framework liest es. Clienttreiber müssen während Rx zu keinem Zeitpunkt Ignorieren lesen. Wenn ein Clienttreiber das Feld Ignorieren während Rx festlegt, dann: Clienttreiber müssen beim Abbrechen von Rx-Vorgängen für alle Pakete, die nicht erfolgreich auf Hardware programmiert wurden, in das Feld Ignorieren schreiben. Weitere Informationen finden Sie unter Abbrechen von Netzwerkdaten mit Netzringen. Clienttreiber dürfen dem Paket keine Ressourcen zuordnen, da sie nicht freigegeben werden. Wenn ein Clienttreiber das Feld Ignorieren während Rx nicht festlegt, dann: Clienttreiber müssen FragmentIndex, FragmentCount und alle Felder in Layout auffüllen. FragmentIndex muss zwischen BeginIndex inclusive und EndIndex exclusive im Fragmentring liegen. FragmentCount darf die Anzahl der Fragmente zwischen BeginIndex inclusive und EndIndex exclusive im Fragmentring nicht überschreiten. Clienttreiber müssen den Paketring BeginIndex verschieben, wenn sie den entsprechenden Fragmentring BeginIndex verschieben. Wenn nach dem Aufruf von EvtPacketQueueAdvance ein Clienttreiber den Paketring BeginIndex erhöht, muss der Treiber auch den Fragmentring BeginIndex über die Fragmente für dieses Paket hinaus erhöhen. Anders ausgedrückt: Der Fragmentring BeginIndex sollte zum EndIndex der Fragmente des vorherigen Pakets verschoben werden.
Tx	NetAdapterCx	Clienttreiber dürfen keine Felder in paketen mit Ausnahme von Scratch ändern. Clienttreiber können den Wert von Ignore lesen, dürfen aber niemals in ihn schreiben. Wenn ein Tx-Paket ignoriert wird, darf der Treiber bei Bedarf keine Felder lesen, außer möglicherweise für Scratch.

NET_PACKET_LAYOUT

Während Rx-Vorgängen unterliegt das Feld Layout der NET_PACKET den folgenden Regeln:

• Alle Felder mit Ausnahme von Reserviert0 müssen vom Clienttreiber initialisiert werden.
• Wenn Layer2Type auf NetPacketLayer2TypeEthernet festgelegt ist, muss Layer2HeaderLengthmindestens 14 sein.
• Wenn Layer2Type auf NetPacketLayer2TypeNull festgelegt ist, muss Layer2HeaderLength auf 0 festgelegt werden.
• Wenn Layer3Type ein IPv4-Typ ist, muss Layer3HeaderLengthmindestens 20 sein .
• Wenn Layer3Type ein IPv6-Typ ist, muss Layer3HeaderLengthmindestens 40 sein .
• Wenn Layer4Type auf TCP festgelegt ist, muss Layer4HeaderLengthmindestens 40 sein .
• Wenn Layer4Type auf Udp festgelegt ist, muss Layer4HeaderLength8 oder höher sein.
• Die Ebenentypfelder müssen innerhalb des entsprechenden Enumerationsbereichs liegen.

Layout wird während Tx nicht verwendet.

NET_FRAGMENT

NET_FRAGMENT Feldregeln hängen davon ab, ob der Treiber empfängt oder sendet und ob die Fragmentpuffer vom Treiber oder vom Framework an die Pakete angefügt werden.

Rx oder Tx	Notizen
Rx	Clienttreiber können nicht in das feld OsReserved_Bounced schreiben. Wenn der Treiber nicht angefügt wird, darf Kapazität nicht geändert werden, aber ValidLength und Offset müssen geändert werden. Wenn der Treiber angefügt wird, müssen Kapazität, ValidLength und Offset geändert werden. Offset + ValidLength muss kleiner als Kapazität sein.
Tx	Clienttreiber können keine Felder mit Ausnahme von Scratch ändern.