OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES

L’OID OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES est envoyé à pilotes miniport compatibles RSSv2pour effectuer des déplacements d’entrées de table d’indirection individuelles. Cet OID est un OID synchrone, ce qui signifie qu’il ne peut pas retourner NDIS_STATUS_PENDING. Il est émis en tant que requête de méthode uniquement, à IRQL == DISPATCH_LEVEL.

Cet appel utilise le point d’entrée xxxSynchronousOidRequest xxx est miniport ou Filter en fonction du type de pilote qui reçoit la requête. Ce point d’entrée provoque une vérification du bogue système si elle voit un état de retour NDIS_STATUS_PENDING.

OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES utilise la structure NDIS_RSS_SET_INDIRECTION_ENTRIES pour indiquer à un adaptateur miniport d’effectuer de manière synchrone un ensemble d’actions, où chaque action déplace une seule entrée de la table d’indirection RSS d’un VPort spécifié vers un processeur spécifié.

Remarques

Cet OID doit s’exécuter et se terminer dans le contexte du processeur qui l’a émis. Les pilotes miniport doivent exécuter entièrement cet OID lors du retour NDIS_STATUS_SUCCESS à la couche supérieure. Cela signifie que le pilote miniport doit être prêt à recevoir des demandes OID de retour à dos pour déplacer plusieurs ites sur un nouveau processeur immédiatement après la fin du premier déplacement avec NDIS_STATUS_SUCCESS.

Les protocoles de couche supérieure émettent des OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES pour définir les paramètres de processeur principal et/ou par défaut pour qu’ils pointent vers différents processeurs.

Cet OID peut être émis pour actif ou paramètres de direction du trafic inactifs. Pour plus d’informations sur les paramètres de direction, consultez mise à l’échelle côté réception version 2 (RSSv2). Pour les paramètres/ites dans le 'état de inactif, le pilote miniport doit valider et mettre en cache le processeur cible jusqu’à ce que le prochain changement d’état RSS approprié (activation ou désactivation). À ce stade, les numéros de processeur mis en cache deviennent actifs et sont utilisés pour diriger le trafic. Les mises à jour apportées à paramètres de actifs (qui doivent également être validés) doivent être prises immédiatement en vigueur pour diriger le trafic.

OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES devez être émis sur un adaptateur miniport avec l’indicateur NDIS_OID_REQUEST_FLAGS_VPORT_ID_VALID effacé. Cela est dû à la possibilité que différents VPorts soient référencés par différents éléments dans le tableau.

Cet OID est appelé uniquement à IRQL == DISPATCH_LEVEL.

Les pilotes miniport doivent être prêts à gérer au moins autant d’actions de déplacement de table indirecte qu’ils publient dans la structure NDIS_NIC_SWITCH_CAPABILITIES. Cela est défini dans le NumberOfIndirectionTableEntriesPerNonDefaultPFVPort ou NumberOfIndirectionTableEntriesForDefaultVPort membre de cette structure, ou 128 en mode RSS natif.

Les pilotes miniport doivent tenter d’exécuter autant d’entrées que possible et mettre à jour la EntryStatus membre de chaque NDIS_RSS_SET_INDIRECTION_ENTRY avec le résultat de l’opération.

Gestionnaire OID pour OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES

Le gestionnaire OID pour OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES doit se comporter comme suit :

• Un retour de NDIS_STATUS_PENDING n’est pas autorisé en raison du type d’appel synchrone de l’OID.
• Finalisez les déplacements ITE entrants destinés au processeur actuel (précédemment lancés sur les processeurs distants).
• Il est fortement recommandé pour les pilotes miniport d’effectuer une passe de validation de paramètre complète. Si ce n’est pas possible, effectuez une validation et une exécution un par un des entrées de tableau. Les pilotes miniport doivent vérifier spécifiquement si tous les objets référencés sont valides :
  • Le retour de NDIS_STATUS_PENDING dans le champ EntryStatus pour un ITE n’est pas autorisé.
  • L’adaptateur miniport existe et est dans un bon état. Sinon, définissez le champ EntryStatus de l’entrée sur NDIS_STATUS_ADAPTER_NOT_FOUND, NDIS_STATUS_ADAPTER_NOT_READY, etc.
  • Chaque VPort existe et est dans un bon état. Sinon, définissez le champ EntryStatus de l’entrée sur NDIS_STATUS_INVALID_PORT, NDIS_STATUS_INVALID_PORT_STATE, etc.
  • Chaque index d’entrée de table indirection se trouve dans la plage configurée. Cette plage est 0xFFFF ou se trouve dans la plage [0...NumberOfIndirectionTableEntries - 1] définie par l’OID OID_GEN_RECEIVE_SCALE_PARAMETERS_V2. Les index d’entrée 0xFFFF et 0xFFFE ont des significations spéciales : 0xFFFF définit le processeur par défaut, tandis que 0xFFFE définit le processeur principal. En cas d’erreur, le gestionnaire définit le champ EntryStatus de l’entrée sur NDIS_STATUS_INVALID_PARAMETER.
  • La couche supérieure et le pilote miniport s’attendent à ce que l’ITE pointe vers le processeur actuel (processeur d’acteur) avant le déplacement. En d’autres termes, l’ITE ne peut pas être redirigé à distance. Si ce n’est pas vrai, définissez le champ EntryStatus de l’entrée sur NDIS_STATUS_NOT_ACCEPTED.
  • Tous les processeurs cibles sont valides et font partie de l’ensemble RSS de l’adaptateur miniport. Sinon, définissez le champ EntryStatus de l’entrée sur NDIS_STATUS_INVALID_DATA.
• Soit par la suite, soit dans le cadre de la validation des paramètres, validez la situation des ressources. Vérifiez que le nombre de files d’attente à utiliser après un déplacement de lot complet (évacuation) ne dépasse pas le NumberOfQueues défini dans la structure de NDIS_RECEIVE_SCALE_PARAMETERS_V2 pendant une demande de OID_GEN_RECEIVE_SCALE_PARAMETERS_V2. Sinon, NDIS_STATUS_NO_QUEUES est retourné. NDIS_STATUS_NO_QUEUES doit être utilisé pour toutes les conditions qui représentent une violation du nombre configuré de files d’attente. NDIS_STATUS_RESOURCES ne doit être utilisé que pour désigner des conditions de mémoire insuffisante temporaires.
• Dans le cadre des vérifications de ressources, pour chaque entité de mise à l’échelle (par exemple, VPort), le pilote miniport doit gérer une condition lorsque tous les ites pointant vers l’UC actuelle sont déplacées.

Si toutes les vérifications ci-dessus passent, le pilote miniport doit pouvoir appliquer inconditionnellement la nouvelle configuration et définir le champ EntryStatus de chaque entrée sur NDIS_STATUS_SUCCESS.

En général, le gestionnaire de cet OID doit être très léger. Il ne doit pas appeler les services NDIS ou de système d’exploitation autres que pour les opérations de synchronisation possibles telles que les verrous de rotation et NdisMConfigMSIXTableEntry.

Le pilote miniport ne doit pas appeler NDIS pour indiquer l’état ou les événements PnP.

Le pilote miniport ne doit pas non plus utiliser les indications complètes de réception/transmission dans le contexte de ce gestionnaire OID, car cela entraîne une récursivité. La couche supérieure peut appeler cet OID à partir du contexte de réception ou de transmission des indications.

Déplacement de toutes les entrées de table indirection

Les pilotes miniport doivent reconnaître et gérer une demande spéciale qui déplace toutes les entrées de table d’indirection loin du processeur actuel. Étant donné que RSSv2 fonctionne avec des déplacements ITE individuels, les pilotes miniport doivent garantir l’atomicité de l’opération globale. S’il rencontre une erreur au milieu d’un lot lors du traitement du tableau correspondant de commandes de déplacement, le pilote miniport doit rétablir toutes les commandes qui ont déjà été effectuées et marquer toutes les commandes comme « ayant échoué » dans la EntryStatus champ. Le protocole de couche supérieure s’attend toujours à ce que le lot « déplacer tous les ites » contienne toutes les commandes marquées comme « réussies » ou toutes les commandes marquées comme « ayant échoué », et il suppose que le trafic obéit à l’état résultant (avant ou après le déplacement). Si la couche supérieure ne voit que certaines entrées marquées comme « ayant échoué », elle vérifie le système et pointe vers le pilote miniport comme cause.

Pour aider le pilote miniport à gérer la commande « déplacer tous les ites » et pour éviter les interblocages, les protocoles de couche supérieure regroupent les commandes de déplacement dans le lot en paires de SwitchId + VPortId champs, de sorte que :

• Les commandes que la couche supérieure souhaite exécuter ensemble, dans le cadre de la commande « déplacer tout », pour le même VPort, sont placées consécutivement dans le lot global.
• Le pilote miniport ne doit pas tenter d’exécuter le lot de commandes global, qui peut cibler différents VPorts, de manière « déplacer tout ». Seul le groupe de commandes qui ciblent le même VPort (marqué avec le même SwitchId + VPortId paire) doit être exécuté conformément à la sémantique « déplacer tout ».
• Lorsque la couche supérieure ne s’intéresse pas à la sémantique « déplacer tout », il peut interagir entre les commandes vers le même VPort avec des commandes vers des ports virtuels différents. Dans ce cas, si le deuxième groupe de commandes vers le même VPort ne peut pas être exécuté en raison d’une violation de « nombre de files d’attente », le pilote miniport marque ce groupe avec le code d’état correspondant (NDIS_STATUS_NO_QUEUES) et la couche supérieure prend en charge la récupération.

Par exemple, si le protocole de couche supérieure interpose une série de commandes comme suit :

• VPort=1 ITE[0,1]
• VPort=2 ITE[0]
• VPort=1 ITE[2]

Le pilote miniport n’a pas besoin d’essayer d’exécuter atomiquement les quatre commandes de déplacement, ou les trois commandes de déplacement pour VPort=1 (ITE[0,1,2]). Il doit uniquement exécuter le groupe VPort=1 ITE[0,1] de manière « déplacer tout », puis le groupe VPort=2 ITE[0], puis VPort=1 ITE[2]. Les trois groupes de commandes peuvent avoir un résultat différent. Par exemple, les groupes de VPort=1 ITE[0,1] et de VPort=2 ITE[0] peuvent réussir, et le groupe VPort=1 ITE[2] peut échouer. Le résultat doit être reflété dans le EntryStatus correspondant membre de chaque structure de commandes. De cette façon, le pilote miniport n’a pas besoin de prendre des précautions pour l’exécution sécurisée du lot global (par exemple, verrouiller l’adaptateur entier). Seules les commandes qui ciblent un VPort spécifique doivent être sérialisées, plus fines par verrouillage par port virtuel peuvent être utilisées, et certains interblocages sont évités.

Conditions d’erreur et codes d’état

Cet OID retourne les codes d’état suivants lorsqu’une erreur se produit :

Exigences

Version: Windows 10, version 1709 Header: Ntddndis.h (include Ndis.h)

Voir aussi

• mise à l’échelle côté réception version 2 (RSSv2)
• NDIS_RSS_SET_INDIRECTION_ENTRIES
• NDIS_RSS_SET_INDIRECTION_ENTRY
• NDIS_NIC_SWITCH_CAPABILITIES
• OID_GEN_RECEIVE_SCALE_PARAMETERS_V2
• NDIS_RECEIVE_SCALE_PARAMETERS_V2