Receive Side Scale 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.

Vue d’ensemble

Par rapport à RSSv1, RSSv2 réduit le temps entre la mesure de la charge du processeur et la mise à jour de la table d’indirection. Cela é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 OID, 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 les fonctionnalités RSS appropriées et de contrôler la table d’indirection respectivement. OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 est un OID standard, tandis que OID_GEN_RSS_SET_INDIRECTION_ENTRIES est un OID synchrone qui ne peut pas retourner 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

Cette rubrique utilise les termes suivants :

Fonctionnalité RSSv2 publicitaire dans un pilote miniport

Les pilotes miniport publient 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 fonctionnalité est nécessaire pour activer la fonctionnalité d’équilibrage de charge du processeur de RSSv2, ainsi que l’indicateur de NDIS_RECEIVE_FILTER_DYNAMIC_PROCESSOR_AFFINITY_CHANGE_SUPPORTED qui active l’équilibrage dynamique RSSv1 pour les VPorts non par défaut (VMQs).

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 VPorts 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 publie la prise en charge de RSSv2, NDIS convertit les OID RSSv1 en OID RSSv2 si nécessaire pour configurer la diffusion 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 set OID 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/désactivation RSS et les mises à jour de clés de hachage.
• OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES est un OID de méthode utilisé pour effectuer la modification des entrées de table indirection.

Gestion des OID RSSv2

OID_GEN_RECEIVE_SCALE_PARAMETERS est utilisé uniquement pour interroger 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 par les pilotes de filtre léger NDIS (LWFs) avant NDIS 6.80.

OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES est toutefois un OID synchrone qui ne peut pas retourner NDIS_STATUS_PENDING. Cet OID doit être exécuté et terminé dans le contexte du processeur qui provient de l’OID. Comme OID_GEN_RECEIVE_SCALE_PARAMETERS_V2, il n’est pas non plus visible par les LWFS NDIS antérieures à NDIS 6.80. Les LWFs dans NDIS 6.80 et versions ultérieures ne sont pas autorisées à retarder cet OID ou à passer à un autre processeur. Sa charge utile contient un tableau d’actions « déplacer ITE » simples, chacune contenant une commande pour déplacer un seul ITE 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 :

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 étant « actifs » ou « inactifs », résumés dans le tableau suivant :

Lorsqu’un paramètre de direction est dans 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 RSS est activé, l’état actuel suivi pour le processeur par défaut et la table d’indirection doivent 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, pendant l’activation RSS matérielle, toutes les entrées commencent à pointer vers le processeur principal avant que les mises à jour pour déplacer les entrées de table d’indirection soient émises et exécutées par le matériel, le processeur principal peut rencontrer un court blocage. Si le pilote miniport a suivi le processeur par défaut et les informations ITE, il peut diriger le trafic vers l’endroit où il est déjà attendu par la couche supérieure.

Notez que si les pilotes miniports doivent suivre toutes les mises à jour des paramètres de direction inactifs, ils doivent différer la validation de ces paramètres jusqu’à ce que le changement d’état RSS tente de rendre 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 inactifs sont valides pour le nouvel état RSS. Toutefois, le pilote miniport doit toujours valider les paramètres et échouer la transition d’état RSS s’il découvre que les paramètres de direction inactifs suivis ne sont pas valides.

É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 :

Mises à jour aux ites et aux processeurs principaux/par défaut (à l’aide de OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES) est appelé à partir du processeur auquel l’entrée correspondante pointe actuellement. Pour un VPort donné, la couche supérieure garantit qu’aucun OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES OID pour déplacer des ites ou définir les processeurs principaux/par défaut sera émis dans les circonstances suivantes :

1. Alors que OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 est en cours.
2. Une fois la séquence de suppression VPort lancée. Par exemple, la couche supérieure émet l’OID de filtre défini uniquement après la fin du dernier OID pour déplacer les ites.

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 laisser la table d’indirection en l’objet 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 OID ne sera émis pendant ou après la suppression de 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 :

1. 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.
2. La couche supérieure ne doit pas demander une mise à jour de table indirection qui enfreint le nombre actuellement configuré de files d’attente pour un VPort. Le pilote miniport doit appliquer cette opération et retourner une défaillance.
3. 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

OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES

Interface de requête OID synchrone dans NDIS 6.80