OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES

  • Article

Avertissement

Certaines informations de cette rubrique concernent le produit pré-publié, qui peut être sensiblement modifié avant sa commercialisation. Microsoft exclut toute garantie, expresse ou implicite, concernant les informations fournies ici.

RSSv2 est disponible en préversion uniquement dans Windows 10, version 1809.

L’OID OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES est envoyé aux pilotes miniport compatibles RSSv2 pour 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. Elle est émise en tant que demande de méthode uniquement, à l’adresse IRQL == DISPATCH_LEVEL.

Cet appel utilise le point d’entrée XxxSynchronousOidRequest , où Xxx est Miniport ou Filter en fonction du type de pilote recevant la demande. Ce point d’entrée provoque un bogue système case activée s’il voit un NDIS_STATUS_PENDING retour status.

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 cible 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 de NDIS_STATUS_SUCCESS à la couche supérieure. Cela signifie que le pilote miniport doit être prêt à recevoir des demandes OID dos à dos pour déplacer plusieurs ITE sur un nouveau processeur immédiatement après la fin du premier déplacement avec NDIS_STATUS_SUCCESS.

Conseil

L’exécution complète de cet OID signifie que le pilote miniport doit être prêt à tenter avec succès une autre action pour déplacer un ITE. Il ne spécifie pas où le trafic de réception en vol est indiqué juste après le déplacement de la file d’attente, ce qui peut être sur le processeur source ou le processeur cible.

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

Cet OID peut être émis pour les paramètres de direction du trafic actif ou inactif . Pour plus d’informations sur les paramètres de direction, consultez Recevoir la mise à l’échelle côté version 2 (RSSv2). Pour les paramètres/ITE à l’état inactif , le pilote miniport doit valider et mettre en cache le processeur cible jusqu’à ce que la prochaine modification d’état RSS pertinente (activation ou désactivation) soit effectuée. À ce stade, les numéros de processeur mis en cache deviennent actifs et sont utilisés pour diriger le trafic. Mises à jour aux paramètres actifs (qui doivent également être validés) doivent être immédiatement appliqués pour diriger le trafic.

OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES doit ê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 dans IRQL == DISPATCH_LEVEL.

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

Les pilotes miniport doivent essayer d’exécuter autant d’entrées que possible et mettre à jour le membre EntryStatus 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 tous les déplacements d’ITE entrants qui étaient destinés au processeur actuel (précédemment initiés sur des processeurs distants).
  • Il est vivement 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 case activée spécifiquement si tous les objets référencés sont valides :
    • Le retour NDIS_STATUS_PENDING dans le champ EntryStatus d’un ITE n’est pas autorisé.
    • L’adaptateur miniport existe et est en 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 en 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 d’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 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 du jeu RSS de l’adaptateur miniport. Sinon, définissez le champ EntryStatus de l’entrée sur NDIS_STATUS_INVALID_DATA.
  • Par la suite ou dans le cadre de la validation du paramètre, 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 la valeur NumberOfQueues définie dans la structure NDIS_RECEIVE_SCALE_PARAMETERS_V2 lors d’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 doit uniquement être utilisé pour désigner des conditions temporaires de mémoire insuffisante.
  • Dans le cadre des vérifications des ressources, pour chaque entité de mise à l’échelle (par exemple, VPort), le pilote miniport doit gérer une condition lorsque tous les ITE qui pointent vers le processeur currrent sont déplacés de celle-ci.

Si toutes les vérifications ci-dessus réussissent, le pilote miniport doit être en mesure d’appliquer inconditionnellement la nouvelle configuration et doit 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 NDIS ou les services du système d’exploitation autres que pour les opérations de synchronisation possibles telles que spinlocks et NdisMConfigMSIXTableEntry.

Le pilote miniport ne doit pas appeler NDIS pour indiquer status ou des é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 des indications de réception ou de transmission.

Déplacement de toutes les entrées de table d’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 du processeur actuel. Étant donné que RSSv2 fonctionne avec des mouvements 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 le champ EntryStatus par commande. Le protocole de couche supérieure s’attend toujours à ce que le lot « déplacer tous les ITE » contienne toutes les commandes marquées comme « réussies » ou toutes les commandes marquées comme « échec », 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 « échec », elle présente un bogue case activée le système et pointe vers le pilote miniport comme cause.

Pour faciliter la gestion par le pilote miniport de 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 par paires de champs SwitchId + VPortId , 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 à « tout déplacer ». Seul le groupe de commandes qui ciblent le même VPort (marqué avec la même paire SwitchId + VPortId ) doit être exécuté conformément à la sémantique « déplacer tout ».
  • Lorsque la couche supérieure ne se soucie pas de la sémantique « déplacer tout », elle peut entrelacer des commandes vers le même VPort avec des commandes vers différentes VPort(s). Dans ce cas, si le deuxième groupe de commandes du 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 status correspondant (NDIS_STATUS_NO_QUEUES) et la couche supérieure assume la responsabilité de la récupération.

Par exemple, si le protocole de couche supérieure entrelace 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 suffit d’exécuter le VPort=1 ITE[0,1] groupe de façon « déplacer tout », puis le VPort=2 ITE[0] groupe, puis VPort=1 ITE[2]. Les trois groupes de commandes peuvent avoir un résultat différent. Par exemple, les groupes pour VPort=1 ITE[0,1] et VPort=2 ITE[0] peuvent réussir, et le VPort=1 ITE[2] groupe peut échouer. Le résultat doit être reflété dans le membre EntryStatus correspondant de chaque structure de commande. De cette façon, le pilote miniport n’a pas besoin de prendre des précautions pour une exécution sûre du lot global (par exemple, verrouiller l’ensemble de l’adaptateur). Seules les commandes qui ciblent un VPort spécifique doivent être sérialisées, le verrouillage par VPort plus précis peut être utilisé et certains blocages sont évités.

Notes

L’ensemble du groupe des entrées de commande doit être marqué avec la même entrée status.

Conditions d’erreur et codes status

Cet OID retourne les codes status suivants lorsqu’une erreur se produit :

Code d’état État d’erreur
NDIS_STATUS_INVALID_LENGTH L’OID était mal formé.
NDIS_STATUS_INVALID_PARAMETER D’autres champs, que ce soit dans l’en-tête ou dans l’OID lui-même (mais pas dans les entrées de commande individuelles) contiennent des valeurs non valides.

Configuration requise

Version : Windows 10, version 1709 En-tête : Ntddndis.h (include Ndis.h)

Voir aussi