Receive Side Scaling Version 2 (RSSv2)
La mise à l’échelle côté réception améliore les performances du système liées à la gestion des données réseau sur les systèmes multiprocesseurs. NDIS 6.80 et versions ultérieures prennent en charge RSS Version 2 (RSSv2), qui étend RSS en offrant une diffusion dynamique par VPort de files d’attente.
Aperçu
Par rapport à RSSv1, RSSv2 raccourcit le temps entre la mesure de la charge du processeur et la mise à jour de la table d’indirection, ce qui évite le ralentissement pendant les situations de trafic élevé. Pour ce faire, RSSv2 effectue ses actions à IRQL = DISPATCH_LEVEL, dans le contexte du processeur de gestion de la requête, et fonctionne uniquement sur un sous-ensemble d’entrées de table indirection pointant vers le processeur actuel. Cela signifie que RSSv2 peut répartir dynamiquement les files d’attente de réception sur plusieurs processeurs beaucoup plus réactifs que RSSv1.
Deux OIDs, OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 et OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES, ont été introduits dans RSSv2 pour les pilotes miniport afin de définir respectivement les fonctionnalités RSS appropriées et de contrôler la table d’indirection. OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 est un OID régulier, tandis que OID_GEN_RSS_SET_INDIRECTION_ENTRIES est un OID synchrone qui ne peut pas renvoyer NDIS_STATUS_PENDING. Pour plus d’informations sur ces OID, consultez leurs pages de référence individuelles. Pour plus d’informations sur les OID synchrones, consultez l'interface de requête OID synchrone dans NDIS 6.80.
Terminologie RSSv2
Cet article utilise les termes suivants :
| Terme | Définition |
|---|---|
| RSSv1 | Mécanisme de mise à l'échelle côté réception de première génération. Utilise OID_GEN_RECEIVE_SCALE_PARAMETERS. |
| RSSv2 | Le mécanisme de mise à l'échelle côté réception de deuxième génération pris en charge dans Windows 10, version 1803 et suivantes, décrit dans cet article. |
| Entité de mise à l'échelle | Adaptateur miniport lui-même en mode RSS natif ou VPort en mode RSSv2. |
| ITE | Une entrée de table d'indirection (ITE) d'une entité de mise à l'échelle donnée. Le nombre total d'ETI par port VP ne peut pas dépasser NumberOfIndirectionTableEntriesPerNonDefaultPFVPort ou NumberOfIndirectionTableEntriesForDefaultVPort en mode VMQ ou 128 dans le cas du RSS natif. NumberOfIndirectionTableEntriesPerNonDefaultPFVPort et NumberOfIndirectionTableEntriesForDefaultVPort sont des membres de la structure NDIS_NIC_SWITCH_CAPABILITIES. |
| Mode de mise à l’échelle | La stratégie de vmswitch par port qui contrôle la manière dont ses ETI sont gérés au moment de l'exécution. Cela peut être statique (aucun déplacement ITE en raison de modifications de charge) ou dynamique (expansion et fusion en fonction de la charge de trafic actuelle). |
| File d'attente | Objet matériel sous-jacent (file d’attente) qui sauvegarde un ITE. En fonction du matériel et de la table d'indirection, la file d'attente de configuration peut contenir plusieurs ETI. Le nombre total de files d’attente, y compris celle utilisée par la file d’attente par défaut, ne peut pas dépasser la limite préconfigurée généralement définie par un administrateur. |
| Processeur par défaut | Processeur qui reçoit des paquets pour lesquels le hachage ne peut pas être calculé. Chaque VPort a un processeur par défaut. |
| Processeur principal | Processeur spécifié comme membre ProcessorAffinity de la structure NDIS_NIC_SWITCH_VPORT_PARAMETERS lors de la création de VPort. Ce processeur peut être mis à jour au moment de l’exécution et spécifie où le trafic VMQ est dirigé. |
| CPU source | Processeur auquel l’ITE est actuellement mappé. |
| Processeur cible | Processeur auquel l’ITE est re mappé (à l’aide de RSSv2). |
| CPU de l’acteur | Processeur sur lequel les requêtes RSSv2 sont effectuées. |
Annonce de la fonctionnalité RSSv2 dans un pilote miniport
Les pilotes de mini-port annoncent la prise en charge de RSSv2 en définissant le membre CapabilitiesFlags de la structure NDIS_RECEIVE_SCALE_CAPABILITIES avec l'indicateur NDIS_RSS_CAPS_SUPPORTS_INDEPENDENT_ENTRY_MOVE. Cette capacité est nécessaire pour activer la fonctionnalité d'équilibrage de la charge du processeur de RSSv2, ainsi que l'indicateur NDIS_RECEIVE_FILTER_DYNAMIC_PROCESSOR_AFFINITY_CHANGE_SUPPORTED qui permet l'équilibrage dynamique de RSSv1 pour les VPorts (VMQ) qui ne sont pas par défaut.
Remarque
Les protocoles de couche supérieure supposent que le processeur principal du VPort par défaut peut être déplacé pour les pilotes miniport RSSv2.
Si un adaptateur miniport ne publie pas de fonctionnalité RSSv2, tous les VPorts avec VMQ restent en mode de propagation statique, même si ces ports virtuels sont demandés pour effectuer une diffusion dynamique. L’OID RSSv1 pour la configuration des paramètres RSS, OID_GEN_RECEIVE_SCALE_PARAMETERS, est utilisé pour ces ports virtuels qui sont toujours en mode de propagation statique.
Les pilotes miniport n’ont besoin d’implémenter qu’un mécanisme de contrôle RSS ( RSSv1 ou RSSv2). Si le pilote annonce la prise en charge de RSSv2, NDIS convertira les OID RSSv1 en OID RSSv2 si nécessaire pour configurer la répartition par VPort. Le pilote miniport doit prendre en charge les deux nouveaux OID et modifier le comportement du RSSv1 OID_GEN_RECEIVE_SCALE_PARAMETERS OID comme suit :
- OID_GEN_RECEIVE_SCALE_PARAMETERS est utilisé uniquement pour les requêtes de requête dans RSSv2 et non pour la définition des paramètres RSS.
- OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 est une requête et un OID de définition utilisé pour configurer les paramètres de l’entité de mise à l’échelle, tels que le nombre de files d’attente, le nombre d’ITEs, l'activation/la désactivation du RSS et les mises à jour des clés de hachage.
- OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES est un OID de méthode utilisé pour modifier les entrées de la table d'indirection.
Gestion des OID RSSv2
OID_GEN_RECEIVE_SCALE_PARAMETERS est utilisé uniquement pour consulter les paramètres RSS actuels d’une entité de mise à l’échelle donnée. Dans RSSv1, cet OID est utilisé pour définir des paramètres. Pour les pilotes miniport compatibles RSSv2, NDIS effectue automatiquement cette conversion de rôle pour le pilote et émet les deux OID suivants pour définir des paramètres à la place.
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 est un OID standard et est géré de la même façon que le OID_GEN_RECEIVE_SCALE_PARAMETERS OID a été géré dans RSSv1. Cet OID n'est pas visible pour les pilotes de filtres légers du NDIS (LWF) antérieurs au NDIS 6.80.
OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES, cependant, est un OID synchrone qui ne peut pas renvoyer NDIS_STATUS_PENDING. Cet OID doit être exécuté et complété dans le contexte du processeur qui a généré l'OID. Comme OID_GEN_RECEIVE_SCALE_PARAMETERS_V2, il n'est pas non plus visible par les LWF NDIS antérieurs à NDIS 6.80. Les LWFs dans NDIS 6.80 et versions ultérieures ne sont pas autorisés à retarder cet OID ou à passer à un autre processeur. Sa charge utile contient un tableau d'actions simples « move ITE », chacune contenant une commande pour déplacer un ITE unique pour une entité de mise à l'échelle vers un processeur cible différent. Les éléments du tableau peuvent référencer différentes entités de mise à l’échelle (VPorts).
Chaque type de pilote NDIS, miniport, filtre et protocole a des points d’entrée pour prendre en charge l’interface de requête OID synchrone :
| Type de pilote NDIS | Gestionnaires OID synchrones | Fonction pour générer des OID synchrones |
|---|---|---|
| Miniport | MiniportSynchronousOidRequest | N/A |
| Filtre | NdisFSynchronousOidRequest | |
| Protocole | N/A | NdisSynchronousOidRequest |
Transitions d’état RSS, mises à jour ITE et processeurs principaux/par défaut
Paramètres de direction
Dans RSSv2, différents paramètres sont utilisés pour diriger le trafic vers le processeur approprié en fonction de l’état RSS (activé ou désactivé). Lorsque RSS est désactivé, seul le processeur principal est utilisé pour diriger le trafic. Lorsque RSS est activé, le processeur par défaut et tous les ites sont utilisés pour diriger le trafic. Ces paramètres de direction sont étiquetés comme « actifs » ou « inactifs », résumés dans le tableau suivant :
| Paramètre de direction | RSS désactivé | RSS activé |
|---|---|---|
| Processeur principal | Actif | Inactif |
| Processeur par défaut | Inactif | Actif |
| ITE[0..N] | Inactif | Actif |
Lorsqu’un paramètre de direction est à l’état actif, il dirige le trafic. À partir du moment d’une transition d’état RSS qui rend un paramètre inactif, les pilotes miniport doivent suivre les modifications apportées au paramètre jusqu’à ce que la transition inverse l’active à nouveau. Cela signifie qu’un pilote miniport doit suivre toutes les mises à jour apportées au processeur par défaut et aux entrées de table d’indirection tandis que RSS est désactivé pour cette entité de mise à l’échelle. Lorsque le RSS est activé, l'état actuel suivi pour le processeur par défaut et la table d'indirection doit prendre effet.
Par exemple, considérez le scénario lorsque les vRSS logiciels sont déjà activés. Dans ce cas, la table d’indirection existe déjà dans le protocole de couche supérieure et est activement utilisée par le code de propagation logicielle de la couche supérieure. Si, lors de l'activation matérielle du RSS, toutes les entrées commencent à pointer vers le processeur primaire avant que les mises à jour visant à déplacer les entrées de la table d'indirection ne soient émises et exécutées par le matériel, le processeur primaire risque de connaître un court blocage. Si le pilote du miniport a suivi les informations relatives au processeur par défaut et à l'ETI, il peut diriger le trafic vers l'endroit où il est déjà attendu par la couche supérieure.
Bien que les pilotes de miniport doivent suivre toutes les mises à jour des paramètres de direction inactifs, ils doivent différer la validation de ces paramètres jusqu’à ce qu’une tentative de changement d’état RSS rende ces paramètres actifs. Par exemple, dans le cas d’une propagation logicielle alors que le flux RSS matériel est désactivé, les protocoles de couche supérieure peuvent utiliser n’importe quel processeur pour la propagation (y compris en dehors de l’ensemble RSS de l’adaptateur). Les couches supérieures garantissent que, au moment de la transition d’état RSS, tous les paramètres de inactifs sont valides pour le nouvel état RSS. Cependant, le pilote du miniport doit toujours valider les paramètres et échouer la transition d'état RSS s'il découvre que l'un des paramètres de direction inactive suivis n'est pas valide.
État initial et mises à jour des paramètres de direction
Le tableau suivant décrit l’état initial de l’entité de mise à l’échelle après la création (par exemple, après la création de VPort), ainsi que la façon dont les paramètres peuvent être mis à jour :
| Paramètre | Description |
|---|---|
| Processeur principal |
|
| Processeur par défaut |
|
| Table d'indirection |
|
Les mises à jour des ETI et des processeurs primaires/par défaut (à l'aide de l'OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES) sont demandées à partir du processeur vers lequel l'entrée correspondante pointe actuellement. Pour un VPort donné, la couche supérieure garantit qu'aucun OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES visant à déplacer des ITE ou à définir les processeurs primaires/par défaut ne sera émis dans ces problèmes :
- Pendant que l'OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 est en cours.
- Une fois la séquence de suppression VPort lancée. Par exemple, la couche supérieure n'émet l'OID « set filter » qu'une fois que le dernier OID de déplacement d'ITE est terminé.
Désactivation RSS
Pendant la désactivation RSS, le protocole de couche supérieure peut choisir de pointer tous les ites vers le processeur principal, puis d’émettre l’OID pour désactiver RSS, ou il peut choisir de quitter la table d’indirection as-is et de désactiver RSS. Dans les deux cas, le trafic de réception doit cibler le processeur principal.
RSSv2 gère une exigence de RSSv1 qui permet au protocole de couche supérieure de supprimer un VPort sans désactiver d’abord RSS. La couche supérieure peut définir le filtre de réception sur le VPort sur zéro, ce qui garantit qu’aucun trafic de réception ne transite par le VPort, puis effectuez la suppression de VPort sans désactiver RSS. La couche supérieure garantit qu'aucun OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES ne sera émis pendant ou après la suppression d'un VPort.
Lors de la désactivation RSS et de la suppression de VPort, le pilote miniport doit s’occuper des opérations internes en attente qui peuvent exister en raison des déplacements de file d’attente précédents.
Invariants RSSv2
Le protocole de couche supérieure garantit que les invariants importants ne sont pas violés avant d’effectuer des fonctions de gestion ou des déplacements ITE. Par exemple:
- Avant de réduire le nombre de files d’attente, la couche supérieure garantit que la table d’indirection ne référence pas plus de processeurs que le nouveau nombre de files d’attente d’un VPort.
- La couche supérieure ne doit pas demander une mise à jour de table indirection qui enfreint le nombre de files d’attente actuellement configurées pour un VPort. Le pilote du mini-port doit appliquer cette règle et renvoyer un échec.
- Avant de modifier le nombre d’entrées de table d’indirection pour les adaptateurs VMMQ-RESTRICTED, la couche supérieure garantit que le contenu de la table d’indirection est normalisé à la puissance de 2.
Liens connexes
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2