Déchargement de fusions de segments de réception UDP (URO)
À partir de Windows 11, version 24H2, le déchargement de fusions de segments de réception UDP (URO, UDP Receive Segment Coalescing Offload) permet aux cartes d’interface réseau (NIC) de fusionner des segments de réception UDP. Les cartes d'interface réseau peuvent combiner des datagrammes UDP issus du même flux qui correspondent à un ensemble de règles dans une mémoire tampon logiquement contiguë. Ces datagrammes combinés sont ensuite indiqués dans la pile de mise en réseau Windows sous la forme d’un seul paquet volumineux.
La coalescence des datagrammes UDP réduit le coût de la CPU pour traiter les paquets dans des flux à bande passante élevée, ce qui entraîne un débit plus élevé et moins de cycles utilisés par octet.
Les sections suivantes décrivent les règles de fusion des paquets UDP et comment écrire un pilote miniport URO.
- Règles de pour fusionner les paquets UDP
- Écriture d'un pilote de miniport URO
- considérations relatives à la programmation pour les pilotes URO
Règles de fusion des paquets UDP
La fusion URO ne peut être tentée que sur les paquets qui répondent à tous les critères suivants :
IpHeader.Versionest identique pour tous les paquets.IpHeader.SourceAddressetIpHeader.DestinationAddresssont identiques pour tous les paquets.UdpHeader.SourcePortetUdpHeader.DestinationPortsont identiques pour tous les paquets.UdpHeader.Lengthest identique pour tous les paquets, sauf le dernier paquet, qui peut être inférieur.UdpHeader.Lengthdoit être différent de zéro.UdpHeader.Checksum, s’il n’est pas égal à zéro, doit être correct sur tous les paquets. Cela signifie que le déchargement de somme de contrôle reçu doit valider le paquet.Layer 2 headersdoit être identique pour tous les paquets.
Si les paquets sont IPv4, ils doivent également répondre aux critères suivants :
IPv4Header.Protocol== 17 (UDP) pour tous les paquets.EthernetHeader.EtherType== 0x0800 pour tous les paquets.- La
IPv4Header.HeaderChecksumsur les paquets reçus doit être correcte. Cela signifie que le déchargement de somme de contrôle reçu doit valider l'en-tête. IPv4Header.HeaderLength== 5 (aucun en-tête d’option IPv4) pour tous les paquets.IPv4Header.ToSest identique pour tous les paquets.IPv4Header.ECNest identique pour tous les paquets.IPv4Header.DontFragmentest identique pour tous les paquets.IPv4Header.TTLest identique pour tous les paquets.IPv4Header.TotalLength==UdpHeader.Length* + length(IPv4Header) pour tous les paquets.
Si les paquets sont IPv6, ils doivent également répondre aux critères suivants :
IPv6Header.NextHeader== 17 (UDP) pour tous les paquets (aucun en-tête d’extension).EthernetHeader.EtherType== 0x86dd (IPv6) pour tous les paquets.IPv6Header.TrafficClassetIPv6Header.ECNsont identiques pour tous les paquets.IPv6Header.FlowLabelest identique pour tous les paquets.IPv6Header.HopLimitest identique pour tous les paquets.IPv6Header.PayloadLength==UdpHeader.Lengthpour tous les paquets.
Structure de paquets URO
L’unité de fusion unique (SCU) résultante doit avoir un en-tête IP unique et un en-tête UDP, suivi de la charge utile UDP pour tous les datagrammes fusionnés concaténés ensemble.
Les indications URO doivent définir le champ IPv4Header.TotalLength sur la longueur totale de la SCU, ou IPv6Header.PayloadLength champ sur la longueur de la charge utile UDP et UdpHeader.Length champ sur la longueur des charges utiles fusionnées.
Si les en-têtes de couche 2 (L2) sont présents dans des datagrammes fusionnés, la SCU doit contenir un en-tête L2 valide. L’en-tête L2 dans la SCU doit ressembler à l’en-tête L2 des datagrammes fusionnés.
Validation et indication de la somme de contrôle
Les indications URO doivent donner aux champs IPv4Header.HeaderChecksum et UdpHeader.Checksum une valeur nulle et remplir les informations hors bande du déchargement de la somme de contrôle sur la SCU en indiquant la réussite des sommes de contrôle IPv4 et UDP.
Un paquet qui correspond à toutes les conditions pour être fusionné, mais qui échoue à la validation de la somme de contrôle doit être signalé séparément. Les paquets reçus après cela ne doivent pas être fusionnés avec ceux reçus avant.
Par exemple, supposons que les paquets 1, 2, 3, 4 et 5 sont reçus à partir du même flux, mais que le paquet 3 échoue à la validation de la somme de contrôle. Les paquets 1 et 2 peuvent être fusionnés, et les paquets 4 et 5 peuvent être fusionnés, mais les paquets 3 ne doivent pas être fusionnés avec l’un ou l’autre SCU. Les paquets 1 et 2 ne doivent pas être fusionnés avec les paquets 4 et 5. Le paquet 2 est le dernier paquet d’une SCU et le paquet 4 démarre une nouvelle SCU. En outre, la SCU contenant les paquets 1 et 2 doit être indiquée avant que le paquet 3 soit indiqué et le paquet 3 doit être indiqué avant le SCU contenant les paquets 4 et 5.
Fusion des paquets et séparation des flux
Les paquets provenant de plusieurs flux peuvent être coalescés en parallèle, à mesure que le matériel et la mémoire permettent. Les paquets provenant de différents flux ne doivent pas être regroupés.
Des paquets provenant de plusieurs réceptions entrelacées peuvent être séparés et fusionnés avec leurs flux respectifs. Par exemple, étant donné les flux A, B et C, si les paquets arrivent dans l’ordre A, A, B, C, B, A, les paquets du flux A peuvent être fusionnés en AAA, et les paquets du flux B fusionnés en BB, tandis que le paquet du flux C peut être indiqué normalement ou fusionné avec un SCU en attente à partir du flux C.
Les paquets d’un flux donné ne doivent pas être réorganisés les uns par rapport aux autres. Par exemple, les paquets du flux A doivent être coalescés dans l'ordre reçu, indépendamment des paquets des flux B et C reçus entre-temps.
Mot clé INF pour contrôler URO
Le mot clé suivant peut être utilisé pour activer/désactiver URO avec un paramètre de clé de Registre :
*UdpRsc
Les mots clés INF normalisés par énumération ont les attributs suivants :
SubkeyName: nom du mot clé que vous devez spécifier dans le fichier INF et qui apparaît dans le Registre.
ParamDesc: texte d’affichage associé à SubkeyName.
Valeur: valeur entière d’énumération associée à chaque option de la liste. Cette valeur est stockée dans NDI\params\SubkeyName\Value.
EnumDesc: texte d’affichage associé à chaque valeur qui apparaît dans le menu.
par défaut : valeur par défaut du menu.
| SubkeyName | ParamDesc | Valeur | EnumDesc |
|---|---|---|---|
*UdpRsc |
URO | 0 | Handicapé |
| 1 (par défaut) | Activé |
Pour plus d’informations sur l’utilisation de mots clés d’énumération, consultez mots clés d’énumération.
Écriture d'un pilote de miniport URO
À compter de NDIS 6.89, l’interface NDIS pour URO facilite la communication entre TCP/IP et le pilote miniport NDIS.
Rapports sur la fonctionnalité URO
Un pilote de miniport annonce la prise en charge URO dans le membre UdpRsc de la structure NDIS_OFFLOAD, qu’il transmet à la fonction NdisMSetMiniportAttributes.
Interrogation de la fonctionnalité URO
Pour vérifier si un pilote miniport prend en charge URO, les pilotes NDIS et autres applications peuvent interroger l'OID OID_TCP_OFFLOAD_HARDWARE_CAPABILITIES, qui retourne la structure NDIS_OFFLOAD.
Interrogation de l'état URO
Pour déterminer l’état URO actuel, les pilotes NDIS et autres applications peuvent interroger la requête OID OID_TCP_OFFLOAD_CURRENT_CONFIG. NDIS gère cet OID et ne le transmet pas au miniport.
Modification de l'état URO
URO peut être activé ou désactivé en émettant la requête OID OID_TCP_OFFLOAD_PARAMETERS. Cet OID utilise une structure NDIS_OFFLOAD_PARAMETERS. Dans cette structure, le membre UdpRsc.Enabled peut avoir les valeurs suivantes :
| Valeur | Signification |
|---|---|
| NDIS_OFFLOAD_PARAMETERS_UDP_RSC_NO_CHANGE 0 |
Le pilote miniport ne doit pas modifier le paramètre actuel. |
| NDIS_OFFLOAD_PARAMETERS_UDP_RSC_DISABLED 1 |
URO est désactivé. |
| NDIS_OFFLOAD_PARAMETERS_UDP_RSC_ENABLED 2 |
URO est activé. |
Lorsqu’un pilote traite une requête OID OID_TCP_OFFLOAD_PARAMETERS avec l'indicateur NDIS_OFFLOAD_PARAMETERS_UDP_RSC_DISABLED, la carte d'interface réseau doit attendre de terminer la requête jusqu’à ce que tous les segments fusionnés existants et les indications URO en suspens soient indiqués. Cela garantit la synchronisation des événements d’activation/désactivation d’URO sur les composants NDIS.
Après avoir traité la requête OID OID_TCP_OFFLOAD_PARAMETERS, le pilote de miniport doit émettre une indication d’état NDIS_STATUS_TASK_OFFLOAD_CURRENT_CONFIG avec l’état de déchargement mis à jour.
L’indicateur NDIS_OFFLOAD_PARAMETERS_SKIP_REGISTRY_UPDATE dans NDIS_OFFLOAD_PARAMETERS permet de désactiver uniquement le runtime d’URO. Les modifications apportées avec cet indicateur ne sont pas enregistrées dans le Registre.
Désactiver URO dans NDIS 6.89 et versions ultérieures
Les pilotes ciblant NDIS 6.89 et versions ultérieures doivent comprendre les paquets URO et les gérer correctement. Pour vous désinscrire de l’URO :
- Les pilotes de filtre léger (LWF) définissent l'indicateur
NDIS_FILTER_DRIVER_UDP_RSC_NOT_SUPPORTEDdans la structure NDIS_FILTER_DRIVER_CHARACTERISTICS. - Les pilotes de protocole définissent l’indicateur
NDIS_PROTOCOL_DRIVER_UDP_RSC_NOT_SUPPORTEDdans la structure NDIS_PROTOCOL_DRIVER_CHARACTERISTICS.
Cette approche garantit que les composants qui ne sont pas familiarisés avec URO ne reçoivent pas de NBL URO. NDIS désactive URO sur le miniport pendant la liaison si un pilote LWF ou de protocole qui ne prend pas en charge URO est présent.
Considérations relatives à la programmation pour les pilotes URO
Tenez compte des problèmes suivants lors de l’implémentation d’un pilote miniport compatible URO.
Winsock URO API
Pour en savoir plus sur l’API Winsock URO, se reporter à Options de socket IPPROTO_UDP. Consultez les informations sur UDP_RECV_MAX_COALESCED_SIZE et UDP_COALESCED_INFO.
Mises à jour de la pile TCP/IP Windows
Le transport MICROSOFT TCP/IP active URO au moment de la liaison avec NDIS, sauf si la configuration l’empêche de le faire.
Les légendes WPF peuvent utiliser FWP_CALLOUT_FLAG_ALLOW_URO dans FWPS_CALLOUT2 pour annoncer leur prise en charge URO. Si une légende WFP incompatible est inscrite sur une couche sensible à URO, le système d’exploitation désactive URO au moment de l’inscription de la légende.
Si un socket adhère à URO avec une taille fusionnée maximale supérieure ou égale à celle de déchargement matérielle, la pile remet les NBL du matériel non modifiés au socket. Si un socket adhère à une taille fusionnée maximale plus petite, la pile désagrège la réception fusionnée compte tenu de la plus petite taille du socket.
Si un socket n’adhère pas à URO, la pile resegmente les réceptions pour ce socket. En l’absence de matériel URO, la fonctionnalité URO logicielle existante continue d’être disponible.