Partager via

Gestion des éléments de l’anneau net

Suivez les instructions de cette rubrique pour gérer vos structures NET_RING et leurs éléments pendant le transfert de données réseau. Les règles de cette rubrique décrivent les membres des éléments de l'anneau net que les pilotes clients peuvent modifier, ainsi que le moment approprié pour le faire, selon le scénario du chemin de données. Elles fournissent également des informations générales que les pilotes clients doivent garder à l'esprit concernant 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 le vérificateur de pilote, le vérificateur de pilotes signale une violation et déclenche une vérification de bogue sur l’appareil testé.

NET_RING

Lorsque la file d’attente de paquets parent de 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 réseau que les pilotes clients peuvent modifier.

Terrain Le pilote client est autorisé à modifier
OSReserved1 Non
ElementStride Non
NumberOfElements Non
ElementIndexMask Non
Indice de fin Non
OSReserved0 Non
OSReserved2 Non
BeginIndex Oui (obligatoire)
NextIndex Oui (facultatif) Remarque : l’infrastructure ne lit jamais NextIndex.
Gratter 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, ni ne doivent-ils jamais incrémenter BeginIndex au-delà de EndIndex pendant un appel à EvtPacketQueueAdvance.

Pour plus d’informations sur la propriété d’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 de données fonctionne. Que le champ Ignore du paquet soit défini ou non et que le pilote soit en train de recevoir (Rx) ou de transmettre (Tx) le paquet, cela 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 ignoré est défini par... Remarques
Rx Pilote client
  • Pendant Rx, les pilotes clients définissent Ignore si nécessaire et l’infrastructure le lit. Les pilotes clients n’ont pas besoin de lire Ignorer à un moment quelconque pendant Rx.
  • Si un pilote client définit le champ Ignorer pendant Rx, puis :
    • 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 Annuler les données réseau avec des anneaux de réseaux.
    • Les pilotes clients ne doivent pas associer de ressources au paquet puisque celles-ci ne seront pas libérées.
  • Si un pilote client ne définit pas le champ Ignorer pendant Rx, puis :
    • Les pilotes clients doivent remplir FragmentIndex, FragmentCount et tous les champs dans Layout.
    • FragmentIndex doit être compris entre BeginIndex inclusif et EndIndex exclusif dans l’anneau de fragment.
    • FragmentCount ne peut pas dépasser le nombre de fragments entre BeginIndex inclusif et EndIndex exclusif dans l’anneau de fragment.
    • Les pilotes clients doivent déplacer l’anneau de paquets BeginIndex s’ils déplacent l’anneau de fragment correspondant BeginIndex.
    • Après l’appel à EvtPacketQueueAdvance, si un pilote client incrémente l’anneau de paquet 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 d’Ignorer mais ne doivent jamais y écrire.
  • Si un paquet Tx est ignoré, le pilote ne doit pas lire de champs, sauf éventuellement pour Scratch, si nécessaire.

NET_PACKET_LAYOUT

Pendant les opérations Rx, le champ Disposition de l’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 est défini sur NetPacketLayer2TypeEthernet, Layer2HeaderLength doit être égal à 14 ou supérieur.
  • Si Layer2Type est défini sur NetPacketLayer2TypeNull, Layer2HeaderLength doit être défini sur 0.
  • Si Layer3Type est un type IPv4, Layer3HeaderLength doit être supérieur ou égal à 20 .
  • Si Layer3Type est un type IPv6, Layer3HeaderLength doit être supérieur ou égal à 40 .
  • Si Layer4Type est défini sur Tcp, Layer4HeaderLength doit être supérieur ou égal à 40 .
  • Si Layer4Type est défini sur Udp, Layer4HeaderLength doit être supérieur ou égal à 8 .
  • Les champs de type de couche doivent se trouver dans la plage d’énumération appropriée.

La mise en page n’est pas utilisée pendant Tx.

FRAGMENT_RÉSEAU

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

Rx ou Tx Remarques
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 s'attache, Capacity, ValidLength et Offset doivent tous être modifiés.
  • Décalage + ValidLength doit être inférieur à Capacité.
Tx
  • Les pilotes clients ne peuvent pas modifier les champs à l’exception de Scratch.
  • Last updated on