Partager via

OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES

  • Article

Avertissement

Certaines informations dans cette rubrique concernent un produit en préversion, qui peut être substantiellement modifié avant sa commercialisation. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies ici.

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

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

Cet appel utilise le point d’entrée XxxSynchronousOidRequest, où Xxx est soit Miniport soit Filter selon le type de pilote recevant la demande. Ce point d’entrée provoque un bug check système s’il voit un statut de retour NDIS_STATUS_PENDING.

OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES utilise la structure NDIS_RSS_SET_INDIRECTION_ENTRIES pour demander à un adaptateur de miniport d’exécuter 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é.

Notes

Cet OID doit être exécuté et complété dans le contexte du processeur qui l’a émis. Les pilotes de miniport doivent exécuter complètement cet OID après avoir retourné NDIS_STATUS_SUCCESS à la couche supérieure. Cela signifie que le pilote de miniport doit être prêt à recevoir des demandes OID consécutives pour déplacer plusieurs ITE sur un nouveau processeur immédiatement après la fin du premier déplacement avec NDIS_STATUS_SUCCESS.

Conseil

Exécuter complètement cet OID signifie que le pilote de miniport doit être prêt à tenter avec succès une autre action pour déplacer une ITE. Il ne prescrit pas où le trafic reçu en cours de vol est indiqué juste après le déplacement de la file d’attente, ce qui peut être soit sur le processeur source, soit sur le processeur cible.

Les protocoles de couche supérieure émettent 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 pointer vers différents processeurs.

Cet OID peut être émis pour les paramètres de direction du trafic actifs ou inactifs. Pour plus d’informations sur les paramètres de direction, veuillez consulter la section Receive side scaling version 2 (RSSv2). Pour les paramètres/ITE dans l’état inactif, le pilote de miniport doit valider et mettre en cache le processeur cible jusqu’au prochain changement d’état RSS pertinent (activation ou désactivation). À ce moment-là, les numéros de processeur mis en cache deviennent actifs et sont utilisés pour diriger le trafic. Les mises à jour des paramètres actifs (qui doivent également être validés) doivent être immédiatement prises en compte pour diriger le trafic.

OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES doit être émis à un adaptateur de miniport avec le drapeau 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 de la matrice.

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

Les pilotes de miniport doivent être prêts à gérer au moins autant d’actions de déplacement d’entrées de table d’indirection qu’ils en annoncent 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 de miniport doivent tenter d’exécuter autant d’entrées qu’ils le peuvent et mettre à jour le membre EntryStatus de chaque NDIS_RSS_SET_INDIRECTION_ENTRY avec le résultat de l’opération.

Gestionnaire d’OID pour OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES

Le gestionnaire d’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.
  • Finaliser 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 fortement recommandé aux pilotes de miniport d’effectuer une validation complète des paramètres. Si ce n’est pas possible, effectuer une validation et une exécution des entrées du tableau une par une. Les pilotes de miniport doivent vérifier spécifiquement si tous les objets référencés sont valides :
    • Retourner NDIS_STATUS_PENDING dans le champ EntryStatus pour un ITE n’est pas autorisé.
    • L’adaptateur de miniport existe et est en bon état. Sinon, définir 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éfinir le champ EntryStatus de l’entrée sur NDIS_STATUS_INVALID_PORT, NDIS_STATUS_INVALID_PORT_STATE, etc.
    • Chaque index d’entrée de la table d’indirection est dans la plage configurée. Cette plage est soit 0xFFFF soit dans la plage [0...NumberOfIndirectionTableEntries - 1] définie par l’OID OID_GEN_RECEIVE_SCALE_PARAMETERS_V2. Les indices 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 de 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 le cas, définir 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 de miniport. Sinon, définir 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, valider la situation des ressources. Valider que le nombre de files d’attente à utiliser après un déplacement complet par lots (évacuation) ne dépasse pas le NumberOfQueues défini dans la structure NDIS_RECEIVE_SCALE_PARAMETERS_V2 lors d’une demande OID_GEN_RECEIVE_SCALE_PARAMETERS_V2. Sinon, NDIS_STATUS_NO_QUEUES est retourné. NDIS_STATUS_NO_QUEUES doit être utilisé pour toutes les conditions représentant une violation du nombre de files d’attente configuré. NDIS_STATUS_RESOURCES ne doit être utilisé que pour désigner des conditions transitoires de manque de mémoire.
  • Dans le cadre des vérifications des ressources, pour chaque entité de mise à l’échelle (par exemple, VPort), le pilote de miniport doit gérer une condition lorsque toutes les ITE pointant vers le processeur actuel sont déplacées.

Si toutes les vérifications ci-dessus réussissent, le pilote de miniport doit pouvoir 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 les services NDIS ou du système d’exploitation, sauf pour des opérations de synchronisation possibles comme les spinlocks et NdisMConfigMSIXTableEntry.

Le pilote de miniport ne doit pas appeler NDIS pour indiquer le statut ou les événements PnP.

Le pilote de miniport ne doit pas non plus utiliser les indications de réception/transmission complètes dans le contexte de ce gestionnaire d’OID, car cela conduit à une récursion. La couche supérieure peut invoquer cet OID dans le contexte des indications de réception ou de transmission.

Déplacement de toutes les entrées de la table d’indirection

Les pilotes de miniport doivent reconnaître et gérer une demande spéciale qui déplace toutes les entrées de la table d’indirection loin du processeur actuel. Parce que RSSv2 fonctionne avec des déplacements individuels d’ITE, les pilotes de miniport doivent garantir l’atomicité de l’opération globale. S’il rencontre une erreur au milieu d’un lot lors du traitement de la matrice correspondante de commandes de déplacement, le pilote de miniport doit annuler toutes les commandes déjà exécutées et marquer toutes les commandes comme « échouées » dans le champ EntryStatus par commande. Le protocole de couche supérieure s’attend toujours à ce que le lot « déplacer toutes les ITE » contienne soit toutes les commandes marquées comme « réussies », soit toutes les commandes marquées comme « échouées », et il supposera que le trafic obéit à l’état résultant (soit avant, soit après le déplacement). Si la couche supérieure voit seulement certaines entrées marquées comme « échouées », elle effectuera un bug check du système et pointera le pilote de miniport comme cause.

Pour aider le pilote de miniport à gérer la commande « déplacer toutes les ITE » et pour éviter les blocages, 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 de 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 ciblant le même VPort (étiqueté avec la même paire SwitchId + VPortId) doit être exécuté conformément aux sémantiques « déplacer tout ».
  • Lorsque la couche supérieure ne se soucie pas des sémantiques « déplacer tout », elle peut entrelacer des commandes au même VPort avec des commandes à différents VPorts. Dans ce cas, si le deuxième groupe de commandes au même VPort ne peut pas être exécuté en raison d’une violation du « nombre de files d’attente », le pilote de miniport marque ce groupe avec le code de statut correspondant (NDIS_STATUS_NO_QUEUES) et la couche supérieure prend la responsabilité de la récupération.

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

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

Le pilote de miniport n’a pas besoin de tenter d’exécuter de manière atomique les quatre commandes de déplacement, ni les trois commandes de déplacement pour VPort=1 (ITE[0,1,2]). Il a seulement besoin d’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 pour VPort=1 ITE[0,1] et 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 membre EntryStatus correspondant de chaque structure de commande. De cette façon, le pilote de miniport n’a pas besoin de prendre des précautions pour une exécution sécurisée du lot global (par exemple, verrouiller l’ensemble de l’adaptateur). Seules les commandes ciblant un VPort spécifique doivent être sérialisées, un verrouillage par VPort plus fin peut être utilisé, et certains blocages sont évités.

Remarque

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

Conditions d’erreur et codes de statut

Cet OID renvoie les codes de statut suivants lorsqu’une erreur se produit :

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

Spécifications

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

Voir aussi