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 fusion des datagrammes UDP réduit le coût du processeur pour traiter les paquets dans les flux à bande passante élevée, ce qui entraîne un débit plus élevé et moins de cycles par octet.
Les sections suivantes décrivent les règles applicables à la fusion de paquets UDP et à l'écriture d'un pilote de miniport URO.
- Règles applicables à la fusion de paquets UDP
- Écriture d'un pilote de miniport URO
- Considérations relatives à la programmation des pilotes URO
Règles applicables à la fusion de paquets UDP
La fusion URO ne peut être tentée que sur les paquets qui répondent à tous les critères suivants :
- IpHeader.Version est identique pour tous les paquets.
- IpHeader.SourceAddress et IpHeader.DestinationAddress sont identiques pour tous les paquets.
- UdpHeader.SourcePort et UdpHeader.DestinationPort sont identiques pour tous les paquets.
- UdpHeader.Length est identique pour tous les paquets, à l’exception du dernier, où elle peut être inférieure.
- UdpHeader.Length doit être différente de zéro.
- UdpHeader.Checksum, si elle est différente de zéro, doit être correcte sur tous les paquets. Cela signifie que le déchargement de somme de contrôle reçu doit valider le paquet.
- Les en-têtes de couche 2 doivent être identiques 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.HeaderChecksum des 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 (En-tête sans option IPv4) pour tous les paquets.
- IPv4Header.ToS est identique pour tous les paquets.
- IPv4Header.ECN est identique pour tous les paquets.
- IPv4Header.DontFragment est identique pour tous les paquets.
- IPv4Header.TTL est 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.TrafficClass et IPv6Header.ECN sont identiques pour tous les paquets.
- IPv6Header.FlowLabel est identique pour tous les paquets.
- IPv6Header.HopLimit est identique pour tous les paquets.
- IPv6Header.PayloadLength == UdpHeader.Length pour tous les paquets.
Structure des 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 donner au champ IPv4Header.TotalLength la valeur de la longueur totale de la SCU, ou au champ IPv6Header.PayloadLength la valeur de la longueur de la charge utile UDP et au champ UdpHeader.Length celle des charges utiles fusionnées.
Si les datagrammes fusionnés contiennent des en-têtes de couche 2 (L2), la SCU doit contenir un en-tête L2 valide. L’en-tête L2 de 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.
Tout paquet qui vérifie toutes les conditions pour être fusionné, mais dont la validation de somme de calcul échoue, doit être indiqué séparément. Les paquets reçus après lui ne doivent pas être fusionnés avec les paquets reçus avant.
Par exemple, supposons que les paquets 1, 2, 3, 4 et 5 sont reçus en provenance d'un même flux, mais que la validation de la somme de contrôle du paquet 3 échoue. Les paquets 1 et 2 peuvent être fusionnés, et les paquets 4 et 5 peuvent être fusionnés, mais le paquet 3 ne doit pas être fusionné avec l’une ou l’autre des SCU. Et 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 ne soit indiqué, et le paquet 3 doit être indiqué avant la SCU contenant les paquets 4 et 5.
Fusion de paquets et séparation de flux
Des paquets provenant de flux différents peuvent être fusionnés en parallèle, dans la mesure où le matériel et la mémoire le permettent. Des paquets provenant de flux différents ne doivent pas être fusionnés ensemble.
Des paquets provenant de plusieurs réceptions entrelacées peuvent être séparés et fusionnés avec leurs flux respectifs. Par exemple, imaginons des 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 en BB, tandis que le paquet du flux C peut être indiqué normalement ou fusionné avec une SCU à venir du flux C.
Les paquets issus d’un flux donné ne doivent pas être réorganisés entre eux. Par exemple, les paquets du flux A doivent être fusionnés dans l’ordre reçu, quels que soient les paquets des flux B et C intercalés entre eux.
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 standardisés d’énumération ont les attributs suivants :
Nom de sous-clé
Le nom du mot clé que vous devez spécifier dans le fichier INF et qui apparaît dans le registre.
ParamDesc
Le texte de l’affichage associé à SubkeyName.
Valeur
La valeur entière d’énumération associée à chaque option de la liste. Cette valeur est stockée dans NDI\params\ SubkeyName\Value.
EnumDesc
Le texte de l’affichage associé à chaque valeur qui apparaît dans le menu.
Par défaut
Valeur par défaut du menu.
| Nom de sous-clé | ParamDesc | Valeur | EnumDesc |
|---|---|---|---|
| *UdpRsc | URO | 0 | Désactivé |
| 1 (par défaut) | Enabled |
Pour en savoir plus sur l’utilisation des mots clés d’énumération, se reporter à Mots clés d'énumération.
Écriture d'un pilote de miniport URO
À partir de NDIS 6.89, l’interface NDIS pour URO facilite la communication entre TCP/IP et le pilote de 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 traite 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 de 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 entre 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 une désactivation d'URO par runtime seul. Les modifications apportées avec cet indicateur ne sont pas sauvegardé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 traiter correctement. Pour désactiver 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 des pilotes URO
Lors de l’implémentation d’un pilote de miniport compatible URO, il convient de tenir compte des problèmes suivants.
API Winsock URO
Pour en savoir plus sur l’API Winsock URO, se reporter à Options de socket IPPROTO_UDP. Consulter les informations sur UDP_RECV_MAX_COALESCED_SIZE et UDP_COALESCED_INFO.
Mises à jour de la pile TCP/IP Windows
Le transport TCP/IP Microsoft active URO au moment de la liaison avec NDIS, à moins que la configuration ne 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 d'URO matériel, la fonctionnalité URO logicielle existante continuera d’être disponible.