Partager via

Gestion des éléments d’anneau net

  • Article

Suivez les instructions de cette rubrique pour gérer vos structures NET_RING et leurs éléments lors du transfert de données réseau. Les règles de cette rubrique décrivent quels membres des pilotes clients des éléments d’anneau net peuvent modifier et quand, en fonction du scénario de chemin de données, ainsi que des informations générales que les pilotes clients doivent garder à l’esprit pour ces structures.

Important

Les pilotes clients doivent respecter ces instructions pendant toutes les phases de développement. Si un pilote client ne respecte pas ces instructions lors du test avec driver Verifier, driver verifier signale une violation et déclenche un bogue case activée sur l’appareil testé.

NET_RING

Lorsque la file d’attente de paquets parent de l’NET_RING est démarrée, tous les index de l’anneau sont initialisés à 0.

Le tableau suivant décrit les membres de l’anneau net que les pilotes clients peuvent modifier.

Champ Le pilote client est autorisé à modifier
OSReserved1 Non
ElementStride Non
NumberOfElements Non
ElementIndexMask Non
EndIndex Non
OSReserved0 Non
OSReserved2 Non
BeginIndex Oui (obligatoire)
NextIndex Oui (Facultatif) Remarque : l’infrastructure ne lit jamais NextIndex.
Vide Oui (facultatif) Remarque : l’infrastructure ne lit jamais Scratch.
Buffer Non

Les pilotes clients ne doivent pas modifier les membres en lecture seule de cette structure et ne doivent jamais incrémenter BeginIndex au-delà de EndIndex lors d’un appel à EvtPacketQueueAdvance.

Pour plus d’informations sur la propriété de l’index dans les anneaux nets, consultez Présentation des anneaux nets.

NET_PACKET

Les champs d’un NET_PACKET sont sensibles aux différents contextes dans lesquels le chemin des données opère. Si le champ Ignore du paquet est défini et si le pilote reçoit (Rx) ou transmet (Tx), le paquet modifie l’ensemble de règles appliqué au paquet.

Le tableau suivant fournit des instructions pour les pilotes dans chaque scénario.

Rx ou Tx Le champ Ignorer est défini par... Notes
Rx Pilote client
  • Pendant Rx, les pilotes clients définissent Ignorer si nécessaire, et l’infrastructure le lit. Les pilotes clients n’ont pas besoin de lire Ignorer à aucun moment pendant Rx.
  • Si un pilote client définit le champ Ignorer pendant Rx, alors :
    • Les pilotes clients doivent écrire dans le champ Ignorer lors de l’annulation des opérations Rx pour tout paquet qui n’a pas été correctement programmé sur le matériel. Pour plus d’informations, consultez Annulation des données réseau avec des anneaux réseau.
    • Les pilotes clients ne doivent pas associer des ressources au paquet, car ils ne seront pas libérés.
  • Si un pilote client ne définit pas le champ Ignorer pendant Rx, alors :
    • Les pilotes clients doivent remplir FragmentIndex, FragmentCount et tous les champs dans Disposition.
    • FragmentIndex doit être compris entre BeginIndex inclusive et EndIndex exclusif dans l’anneau de fragments.
    • FragmentCount ne peut pas dépasser le nombre de fragments entre BeginIndex inclusive et EndIndex exclusif dans l’anneau de fragments.
    • Les pilotes clients doivent déplacer l’anneau de paquets BeginIndex s’ils déplacent l’anneau de fragments BeginIndex correspondant.
    • Après l’appel à EvtPacketQueueAdvance, si un pilote client incrémente l’anneau de paquets BeginIndex , le pilote doit également incrémenter l’anneau de fragment BeginIndex au-delà des fragments de ce paquet. En d’autres termes, l’anneau de fragment BeginIndex doit se déplacer vers endIndex des fragments du paquet précédent.
Tx NetAdapterCx
  • Les pilotes clients ne doivent pas modifier les champs d’un paquet à l’exception de Scratch.
  • Les pilotes clients peuvent lire la valeur ignorer , mais ne doivent jamais y écrire.
  • Si un paquet Tx est ignoré, le pilote ne doit lire aucun champ, sauf éventuellement pour Scratch, si nécessaire.

NET_PACKET_LAYOUT

Pendant les opérations Rx, le champ Disposition du NET_PACKET est soumis aux règles suivantes :

  • Tous les champs à l’exception de Reserved0 doivent être initialisés par le pilote client.
  • Si Layer2Type a la valeur NetPacketLayer2TypeEthernet, Layer2HeaderLength doit être égal ou supérieur à 14 .
  • Si Layer2Type est défini sur NetPacketLayer2TypeNull, Layer2HeaderLength doit avoir la valeur 0.
  • Si Layer3Type est un type IPv4, Layer3HeaderLength doit être égal ou supérieur à 20 .
  • Si Layer3Type est un type IPv6, Layer3HeaderLength doit être égal ou supérieur à 40 .
  • Si Layer4Type a la valeur Tcp, Layer4HeaderLength doit être égal ou supérieur à 40 .
  • Si Layer4Type est défini sur Udp, Layer4HeaderLength doit être égal ou supérieur à 8 .
  • Les champs de type de couche doivent se trouver dans la plage d’énumération appropriée.

La disposition n’est pas utilisée pendant Tx.

NET_FRAGMENT

NET_FRAGMENT règles de champ varient selon que le pilote reçoit ou transmet, et si les mémoires tampons de fragments sont attachées aux paquets par le pilote ou par le framework.

Rx ou Tx Notes
Rx
  • Les pilotes clients ne peuvent pas écrire dans le champ OsReserved_Bounced .
  • Si le pilote n’est pas attaché, la capacité ne doit pas être modifiée, mais ValidLength et Offset doivent être modifiés.
  • Si le pilote est attaché, capacity, ValidLength et Offset doivent tous être modifiés.
  • Compenser + ValidLength doit être inférieur à Capacity.
Tx
  • Les pilotes clients ne peuvent pas modifier les champs à l’exception de Scratch.