‭Segmentation des paquets UDP (USO)

UDP Segmentation Offload (USO), pris en charge dans Windows 10, version 2004 et ultérieure, est une fonctionnalité qui permet aux cartes d’interface réseau (NIC) de déléguer la segmentation des datagrammes UDP plus grands que l’unité de transmission maximale (MTU) du support réseau. Ainsi, Windows réduit l’utilisation du processeur associée au traitement TCP/IP par paquet. Les exigences de l'OSU sont similaires à celles de la version 2 de la charge d'envoi importante (LSOv2), qui concerne le protocole de transport TCP.

Exigences pour USO

Cette section fait principalement référence au protocole NDIS et aux pilotes miniport. Les pilotes de filtre léger NDIS (LWFs) doivent respecter les exigences du pilote de protocole lors de la modification ou de l’envoi de paquets, et peuvent également supposer que tous les paquets fournis à son FilterSendNetBufferLists gestionnaire répondent aux exigences du pilote de protocole.

Les pilotes miniports peuvent déléguer la segmentation des grands paquets UDP plus grands que la MTU du support réseau. Une carte réseau qui prend en charge la segmentation de paquets UDP volumineux doit également être en mesure d’effectuer les opérations suivantes :

• Calculer les checksums IP pour les paquets envoyés contenant des options IPv4
• Calculer les sommes de contrôle UDP pour les paquets envoyés

Un pilote miniport qui prend en charge USO doit déterminer le type de délégation à partir des informations hors bande (OOB) de la structure NET_BUFFER_LIST. Si la valeur de la structure NDIS_UDP_SEGMENTATION_OFFLOAD_NET_BUFFER_LIST_INFO est non nulle, alors le pilote miniport doit effectuer l’USO. Toute NET_BUFFER_LIST contenant des données OOB de l'OSU contient également une structure NET_BUFFER unique. Cependant, dans le cas où le pilote miniport a reçu OID_TCP_OFFLOAD_PARAMETERS pour désactiver l’USO, après que le pilote miniport a complété l’OID avec succès, il doit rejeter et retourner toute NET_BUFFER_LIST ayant le champ OOB USO défini.

Le transport TCP/IP décharge uniquement les paquets UDP qui répondent aux critères suivants :

• Le paquet est un paquet UDP.
• La longueur du paquet doit être supérieure à la taille maximale du segment (MSS) * (MinSegmentCount - 1).
• Si le pilote miniport ne définit pas la fonctionnalité de SubMssFinalSegmentSupported, chaque paquet UDP volumineux déchargé par le transport doit avoir Length % MSS == 0. Autrement dit, le paquet volumineux est divisible en N paquets, chaque segment de paquet contenant exactement MSS octets utilisateur. Si le pilote miniport définit la fonctionnalité SubMssFinalSegmentSupported, cette condition de divisibilité de longueur de paquet sur le transport ne s’applique pas. En d’autres termes, le segment final peut être inférieur à MSS.
• Le paquet n’est pas un paquet de bouclage.
• Le bit MF dans l’en-tête IP du grand paquet UDP délégué par le transport TCP/IP ne sera pas défini, et le Fragment Offset dans l’en-tête IP sera zéro.
• L’application a spécifié UDP_SEND_MSG_SIZE/WSASetUdpSendMessageSize.

Avant de décharger un paquet UDP volumineux pour la segmentation, le transport TCP/IP effectue les opérations suivantes :

• Met à jour les informations de segmentation de paquets volumineuses associées à la structure NET_BUFFER_LIST. Ces informations sont une structure NDIS_UDP_SEGMENTATION_OFFLOAD_NET_BUFFER_LIST_INFO qui fait partie des informations OOB de la structure NET_BUFFER_LIST. Le transport TCP/IP définit la valeur MSS à la MSS souhaitée.
• Calcule la somme complémentaire de l’en-tête pseudo UDP et écrit cette somme dans le champ Checksum de l’en-tête UDP. Le transport TCP/IP calcule la somme des compléments sur les champs suivants dans le pseudo-header : adresse IP source, adresse IP de destination et protocole.

La somme complémentaire à un pour le pseudo-en-tête fournie par le transport TCP/IP donne à la NIC un avantage pour calculer la vraie somme de contrôle UDP pour chaque paquet que la NIC dérive du grand paquet UDP, sans avoir à examiner l’en-tête IP.

Notez que RFC 768 et RFC 2460 stipulent que le pseudo-header est calculé sur l’adresse IP source, l’adresse IP de destination, le protocole et la longueur UDP (longueur de l’en-tête UDP plus la longueur de la charge utile UDP, sans inclure la longueur du pseudo-header). Toutefois, étant donné que le pilote miniport sous-jacent et la carte réseau génèrent des datagrammes UDP à partir du paquet volumineux transmis par le transport TCP/IP, le transport ne connaît pas la taille de la charge utile UDP pour chaque datagramme UDP et ne peut donc pas inclure la longueur UDP dans le calcul du pseudo-en-tête. Au lieu de cela, comme décrit dans la section suivante, la NIC étend la somme de contrôle du pseudo-en-tête fournie par le transport TCP/IP pour couvrir la longueur UDP de chaque datagramme UDP généré.

Envoi de paquets avec USO

Après que le pilote miniport a obtenu la NET_BUFFER_LIST dans sa fonction de rappel MiniportSendNetBufferLists, il peut appeler la macro NET_BUFFER_LIST_INFO avec un _Id de UdpSegmentationOffloadInfo pour obtenir la valeur MSS et le protocole IP.

Le pilote miniport obtient la longueur totale du paquet volumineux à partir de la longueur de la première structure de NET_BUFFER et utilise la valeur MSS pour diviser le paquet UDP volumineux en paquets UDP plus petits. Chacun des paquets plus petits contient MSS ou moins d’octets de données utilisateur. Seul le dernier paquet créé à partir du paquet volumineux segmenté doit contenir moins de MSS octets de données utilisateur. Tous les autres paquets créés à partir du paquet segmenté doivent contenir MSS octets de données utilisateur. Si un pilote miniport n’adhère pas à cette règle, les datagrammes UDP sont remis de manière incorrecte. Si le pilote miniport ne définit pas la fonctionnalité de SubMssFinalSegmentSupported, la longueur des paquets est divisée par le MSS et chacun des paquets segmentés contient MSS octets d'utilisateur.

Le pilote miniport fixe les en-têtes MAC, IP et UDP sur chaque segment dérivé du paquet volumineux. Le pilote de miniport doit calculer les sommes de contrôle IP et UDP pour ces paquets dérivés. Pour calculer la somme de contrôle UDP pour chaque paquet dérivé du grand paquet UDP, la NIC calcule la partie variable de la somme de contrôle UDP (pour l’en-tête UDP et la charge utile UDP), ajoute cette somme de contrôle à la somme complémentaire à un pour le pseudo-en-tête calculée par le transport TCP/IP, puis calcule le complément à un de 16 bits pour la somme de contrôle. Pour plus d’informations sur le calcul de ces sommes de contrôle, voir RFC 768 et RFC 2460.

La longueur des données utilisateur UDP dans le paquet UDP volumineux doit être inférieure ou égale à la valeur affectée par le pilote miniport à MaxOffLoadSize.

Après qu’un pilote a émis une indication de statut pour indiquer un changement de la valeur MaxOffLoadSize, le pilote ne doit causer un bug check s’il reçoit une demande d’envoi LSO utilisant la valeur MaxOffLoadSize précédente. Au lieu de cela, le pilote doit refuser la demande d'envoi. Les pilotes doivent échouer toute demande d’envoi qu’ils ne peuvent effectuer, pour aucune raison (taille, nombre minimal de segments, options IP, etc.). Les pilotes doivent envoyer une indication d’état dès que possible si leurs fonctionnalités changent.

Un pilote intermédiaire qui émet indépendamment des indications d'état signalant une modification de la valeur de MaxOffLoadSize doit veiller à ce que l'adaptateur miniport sous-jacent, qui n'a pas émis d'indication d'état, ne reçoive aucun paquet dont la taille dépasse la valeur MaxOffLoadSize signalée par l'adaptateur miniport.

Un pilote miniport-intermédiaire qui répond à OID_TCP_OFFLOAD_PARAMETERS pour désactiver les services USO doit être prêt pour une petite fenêtre de temps où des demandes USO pourraient encore atteindre le pilote miniport.

Le nombre de paquets de segmentation dérivés du paquet UDP volumineux doit être égal ou supérieur à la valeur MinSegmentCount spécifiée par le pilote miniport.

Lors du traitement d’un paquet UDP volumineux, le pilote miniport est chargé uniquement de segmenter le paquet et d’attacher les en-têtes MAC, IP et UDP aux paquets dérivés du paquet UDP volumineux. Si le miniport ne parvient pas à envoyer au moins un paquet segmenté, la NBL doit finalement être complétée avec un statut d’échec. Le miniport peut continuer à envoyer des paquets suivants, mais il n’est pas nécessaire de le faire. La NBL ne peut pas être complétée de retour à NDIS tant que tous les paquets segmentés n’ont pas été transmis ou échoués.

Les pilotes miniport compatibles USO doivent également effectuer les opérations suivantes :

• Prendre en charge IPv4 et IPv6.
• Assurer la réplication des options IPv4 du grand paquet dans chaque paquet segmenté généré par la carte réseau.
• Utilisez l’en-tête IP et UDP dans la structure NET_BUFFER_LIST en tant que modèle pour générer des en-têtes UDP et IP pour chaque paquet segmenté.
• Utilisez des valeurs d’identification IP (ID IP) dans la plage de 0x0000 à 0xFFFF. Par exemple, si l’en-tête IP du modèle commence par une valeur de champ Identification de 0xFFFE, le premier paquet de datagramme UDP doit avoir une valeur de 0xFFFE, suivie de 0xFFFF, 0x0000, 0x0001, et ainsi de suite.
• Si le paquet UDP volumineux contient des options IP, le pilote miniport copie ces options, non altérées, à chaque paquet dérivé du paquet UDP volumineux.
• Pour déterminer l’emplacement de l’en-tête UDP, utilisez le décalage d’octets dans le membre UdpHeaderOffset de NDIS_UDP_SEGMENTATION_OFFLOAD_NET_BUFFER_LIST_INFO, en commençant par le premier octet du paquet.
• Augmentez les statistiques de transmission basées sur les paquets segmentés. Par exemple, inclure le nombre d’octets des en-têtes Ethernet, IP et UDP pour chaque segment de paquet, et le nombre de paquets est le nombre de segments de taille MSS, pas 1.
• Définissez la longueur totale UDP et les champs de longueur IP en fonction de chaque taille de datagramme segmentée.

Modifications de l’interface NDIS

Cette section décrit les modifications apportées à NDIS 6.83 qui permettent à la pile de pilotes TCP/IP hôte d’exploiter les fonctionnalités USO exposées par les pilotes miniport.

NDIS et le pilote miniport effectuent les opérations suivantes :

• Annoncer que la NIC prend en charge la capacité USO
• Activer ou désactiver USO
• Obtenir l’état actuel de la fonctionnalité USO

Annoncer la capacité USO

Les pilotes miniports annoncent la capacité USO en remplissant le champ UdpSegmentation de la structure NDIS_OFFLOAD, qui est passée dans les paramètres de NdisMSetMiniportAttributes. Le champ Header.Revision de la structure NDIS_OFFLOAD doit être défini sur NDIS_OFFLOAD_REVISION_6 et le champ Header.Size doit être défini sur NDIS_SIZEOF_NDIS_OFFLOAD_REVISION_6.

Interroger l’état de l’USO

L’état actuel de l’USO peut être interrogé avec OID_TCP_OFFLOAD_CURRENT_CONFIG. NDIS gère cet OID et ne le transmet pas au pilote miniport.

Modifier l’état de l’USO

USO peut être activé ou désactivé à l’aide de OID_TCP_OFFLOAD_PARAMETERS. Après que le pilote miniport a traité l’OID, il doit envoyer une indication de statut NDIS_STATUS_TASK_OFFLOAD_CURRENT_CONFIG avec l’état de délégation mis à jour.

Mots clés USO

Les mots clés d’énumération USO sont les suivants :

• *UsoIPv4
• *UsoIPv6

Ces valeurs décrivent si l’authentification USO est activée ou désactivée pour ce protocole IP particulier. Les paramètres USO ne dépendent pas de la configuration NDIS_TCP_IP_CHECKSUM_OFFLOAD. Par exemple, la désactivation de *UDPChecksumOffloadIPv4 ne désactive pas implicitement *UsoIPv4.