Transfert de requêtes OID vers des cartes réseau physiques
Cette rubrique explique comment les extensions de commutateur extensible Hyper-V demandent l’identificateur d’objet avant (OID) pour les cartes physiques sous-jacentes via le chemin de contrôle du commutateur extensible Hyper-V. L’extension peut également provenir de requêtes OID vers des cartes réseau physiques sous-jacentes en suivant les méthodes décrites dans cette rubrique.
Par exemple, la carte réseau externe peut être liée au bord de miniport virtuel d’un pilote intermédiaire de multiplexeur NDIS (MUX). Le pilote MUX est lié à une équipe d’un ou plusieurs réseaux physiques sur l’hôte. Cette configuration est connue sous le nom d’équipe de commutateur extensible.
Dans cette configuration, une extension de commutateur extensible est exposée à chaque carte réseau de l’équipe. Cela permet à l’extension de gérer la configuration et l’utilisation de cartes réseau individuelles dans l’équipe. Par exemple, une extension de transfert peut fournir la prise en charge d’une solution de basculement d’équilibrage de charge (LBFO) sur l’équipe en transférant les paquets sortants vers des adaptateurs individuels. Une extension de transfert qui gère une équipe de commutateur extensible est appelée fournisseur d’association. Pour plus d’informations sur les fournisseurs d’association, consultez Extensions du fournisseur d’association.
La figure suivante montre un exemple d’équipe de commutateur extensible pour NDIS 6.40 (Windows Server 2012 R2) et versions ultérieures.
La figure suivante montre un exemple d’équipe de commutateur extensible pour NDIS 6.30 (Windows Server 2012).
Note Dans l’interface de commutateur extensible Hyper-V, les pilotes de filtre NDIS sont appelés extensions de commutateur extensible et la pile de pilotes est appelée pile de pilotes de commutateur extensible.
Les requêtes OID doivent être encapsulées pour transférer la demande à une carte réseau physique sous-jacente. Les requêtes OID sont d’abord encapsulées à l’intérieur d’une structure NDIS_SWITCH_NIC_OID_REQUEST . Ensuite, les requêtes OID sont transférées via le chemin de contrôle de commutateur extensible par une demande de jeu d’OID de OID_SWITCH_NIC_REQUEST.
Les requêtes OID adressées aux adaptateurs physiques sous-jacents sont émises par les éléments suivants :
Interface de commutateur extensible.
Les requêtes OID, telles que les demandes de déchargement de matériel, sont émises par des pilotes de protocole ou de filtre qui s’exécutent dans l’un des éléments suivants :
Système d’exploitation de gestion qui s’exécute dans la partition parente Hyper-V.
Système d’exploitation invité qui s’exécute dans la partition enfant Hyper-V.
Lorsque ces requêtes OID sont reçues par le commutateur extensible, elles sont encapsulées et transférées sur le chemin de contrôle du commutateur extensible. Lorsqu’une extension de transfert reçoit la requête OID encapsulée, elle peut transférer la demande à une carte physique sous-jacente. Cette fonctionnalité est particulièrement utile pour configurer l’équipe de commutateur extensible pour les déchargements matériels.
Par exemple, le pilote MUX publie les fonctionnalités communes de l’ensemble de l’équipe de commutateur extensible. Toutefois, l’extension de transfert peut émettre des requêtes OID pour interroger ou définir les fonctionnalités individuelles des adaptateurs au sein de l’équipe. Ensuite, l’extension de transfert peut provenir d’un NDIS status indication de la carte réseau externe pour informer les pilotes qui se superposent des fonctionnalités qui s’appliquent à l’ensemble de l’équipe. Pour plus d’informations sur cette procédure, consultez Indications d’état NDIS d’origine à partir de cartes réseau physiques.
Lorsque l’extension de transfert transfère la requête OID sur le chemin de contrôle, elle est reçue par la carte réseau externe. À ce stade, la requête OID est décapsulée et transférée à la carte réseau physique spécifiée.
Note À compter de Windows Server 2012, seules les demandes d’OID de déchargement matériel sont encapsulées et transférées de cette manière. Par exemple, les requêtes OID de déchargement pour la file d’attente de machines virtuelles (VMQ) ou la sécurité du protocole Internet (IPsec) sont encapsulées et transférées sur le chemin de contrôle du commutateur extensible. Pour plus d’informations, consultez Gestion des requêtes OID de déchargement matériel sur des cartes réseau physiques.
Extension de transfert.
L’extension de transfert peut provenir de ses propres requêtes OID encapsulées et les transférer à une carte réseau physique sous-jacente. L’extension de transfert peut encapsuler des requêtes OID NDIS standard. L’extension de transfert peut également encapsuler des requêtes OID privées définies par le fournisseur de matériel indépendant (IHV) pour les cartes réseau physiques. Cela permet une extension de transfert qui a également été développée par l’IHV pour activer ou désactiver des attributs propriétaires sur des adaptateurs physiques individuels dans l’équipe.
En outre, l’extension de transfert peut provenir de requêtes OID de déchargement matériel encapsulée pour allouer des ressources à une partition enfant Hyper-V spécifiée. Par exemple, l’extension de transfert peut provenir de requêtes OID encapsulées de OID_RECEIVE_FILTER_ALLOCATE_QUEUE pour allouer une machine virtuelle à une partition enfant spécifiée. Dans ce cas, l’extension encapsule la requête comme provenant du port de commutateur extensible et de la connexion de carte réseau associée à la partition.
Note L’extension de transfert peut uniquement provenir de sa propre demande OID de déchargement matériel encapsulé si elle filtre la même requête OID que celle qui a été émise par des pilotes surchargés. Dans ce cas, l’extension ne doit pas transférer la requête OID d’origine. Au lieu de cela, l’extension doit appeler NdisFOidRequestComplete pour terminer cette demande lorsque NDIS appelle son FilterOidRequestComplete pour terminer la requête OID d’origine.
Filtrage ou capture d’extensions
Une extension de filtrage ou de capture peut provenir de ses propres requêtes OID encapsulées et les transférer à une carte réseau physique sous-jacente. Ces extensions peuvent encapsuler des requêtes OID NDIS standard ou des requêtes de requête OID privées définies par le fournisseur de matériel indépendant (IHV) pour les cartes réseau physiques.
Note Seules les extensions de transfert peuvent provenir de requêtes de jeu d’OID encapsulées vers des adaptateurs physiques sous-jacents.
L’extension de transfert doit suivre ces étapes lorsqu’elle transfère, redirige ou provient d’une requête OID encapsulée pour une carte physique sous-jacente :
Si l’extension de transfert est à l’origine d’une requête OID, elle doit initialiser une structure de NDIS_OID_REQUEST allouée à l’extension avec les informations relatives à la demande.
Si l’extension transfère une requête OID, elle ne doit pas modifier la structure NDIS_OID_REQUEST existante référencée par le paramètre OidRequest de la fonction FilterOidRequest . Au lieu de cela, l’extension doit appeler NdisAllocateCloneOidRequest pour allouer de la mémoire à une nouvelle structure NDIS_OID_REQUEST et copier toutes les informations de la structure NDIS_OID_REQUEST existante.
L’extension définit les membres d’une structure de NDIS_SWITCH_NIC_OID_REQUEST allouée à l’extension sur les valeurs suivantes :
Le membre DestinationPortId doit être défini sur l’identificateur du port de commutateur extensible auquel la carte réseau externe est connectée.
Le membre DestinationNicIndex doit être défini sur la valeur d’index différente de zéro de la carte réseau physique sous-jacente.
Pour plus d’informations sur ces valeurs d’index, consultez Valeurs d’index de carte réseau.
Si l’extension de transfert est à l’origine d’une demande d’OID de déchargement matériel pour une partition enfant Hyper-V, le membre SourcePortId doit être défini sur l’identificateur du port utilisé par la partition. En outre, le membre SourceNicIndex doit être défini sur l’index de carte réseau pour la connexion réseau à ce port.
Si l’extension de transfert est à l’origine d’une requête OID standard ou privée à ses propres fins, les membres SourcePortId et SourceNicIndex doivent être définis sur zéro.
Si l’extension de transfert transfère ou redirige une demande OID de déchargement matériel, elle doit conserver les valeurs des membres SourcePortId et SourceNicIndex qui ont été définis par l’interface de commutateur extensible.
Le membre OidRequest doit être défini sur un pointeur vers une structure de NDIS_OID_REQUEST initialisée pour la requête OID encapsulée. L’extension de transfert alloue et initialise cette structure ou utilise la copie cloné de la structure.
L’extension définit les membres d’une structure de NDIS_OID_REQUEST allouée à l’extension sur les valeurs suivantes :
Le membre Oid doit être défini sur OID_SWITCH_NIC_REQUEST.
Le membre InformationBuffer doit contenir un pointeur vers une mémoire tampon qui contient les données de requête OID générées ou filtrées.
Le membre InformationBufferLength doit contenir la longueur, en octets, de la mémoire tampon qui contient les données de requête OID générées ou filtrées.
L’extension définit les autres membres sur des valeurs valides pour la structure NDIS_OID_REQUEST .
L’extension appelle ReferenceSwitchNic pour incrémenter un compteur de références pour l’index de la carte réseau physique de destination. Cela garantit que l’interface de commutateur extensible ne supprimera pas la connexion de carte réseau physique alors que son compteur de référence n’est pas zéro.
Lorsque l’extension appelle ReferenceSwitchNic, elle définit le paramètre SwitchPortId sur la valeur spécifiée pour le membre DestinationPortId . L’extension définit également le paramètre SwitchNicIndex sur la valeur spécifiée pour le membre DestinationNicIndex .
Note Si ReferenceSwitchNic ne retourne pas NDIS_STATUS_SUCCESS, la requête OID ne peut pas être transférée à la carte réseau physique de destination.
Si l’extension de transfert est à l’origine d’une demande OID de déchargement matériel pour une partition enfant Hyper-V, elle appelle également ReferenceSwitchNic pour incrémenter un compteur de référence pour l’index de la connexion de carte réseau source associée à la partition. Cela garantit que l’interface de commutateur extensible ne supprimera pas la connexion de carte réseau physique alors que son compteur de référence n’est pas zéro.
Lorsque l’extension appelle ReferenceSwitchNic, elle définit le paramètre SwitchPortId sur la valeur spécifiée pour le membre SourcePortId . L’extension définit également le paramètre SwitchNicIndex sur la valeur spécifiée pour le membre SourceNicIndex .
Note Si ReferenceSwitchNic ne retourne pas NDIS_STATUS_SUCCESS, la requête OID ne peut pas être transférée à la carte réseau physique de destination.
L’extension appelle NdisFOidRequest pour transférer la requête OID encapsulée au port de commutateur extensible de destination et à la carte réseau spécifiés.
Note Si l’extension transfère une requête OID filtrée, elle doit appeler NdisFOidRequest dans le contexte de l’appel à sa fonction FilterOidRequest . Si l’extension transfère les requêtes OID qu’elle a générées, elle appelle NdisFIndicateStatus alors qu’elle se trouve dans les états Running, Restarting, Paused et Pausing . Pour plus d’informations sur ces états, consultez Filtrer les états et opérations du module.
Lorsque NDIS appelle la fonction FilterOidRequestComplete , l’extension appelle DereferenceSwitchNic pour effacer le compteur de référence de l’index de la carte réseau physique de destination.
Si l’extension de transfert provient d’une demande OID de déchargement matériel pour une partition enfant Hyper-V, elle appelle également DereferenceSwitchNic pour effacer le compteur de référence pour l’index de la connexion de carte réseau source pour la carte.
Dans les deux cas, l’extension définit les paramètres SwitchPortId et SwitchNicIndex sur les mêmes valeurs que celles utilisées dans l’appel à ReferenceSwitchNic.
Pour plus d’informations sur la façon dont l’extension émet des requêtes OID, consultez Génération de requêtes OID à partir d’un pilote de filtre NDIS.
Pour plus d’informations sur les pilotes MUX, consultez Pilotes intermédiaires MUX NDIS.