Dans NetAdapterCx, les descripteurs de paquets sont des structures petites, compactes et extensibles au runtime qui décrivent un paquet réseau. Chaque paquet nécessite les éléments suivants :
Un descripteur principal
Un ou plusieurs descripteurs de fragments
Zéro ou plusieurs extensions de paquets
Le descripteur principal du paquet est la structure NET_PACKET . Il contient uniquement les métadonnées de base applicables à tous les paquets, telles que la disposition de cadrage d’un paquet donné et l’index du premier descripteur de fragment du paquet.
Chaque paquet doit également avoir un ou plusieurs descripteurs de fragments, ou NET_FRAGMENT structures, qui décrivent l’emplacement dans la mémoire système où résident les données du paquet.
Les extensions sont facultatives et contiennent des métadonnées par paquet ou par fragment pour les fonctionnalités spécifiques au scénario. Par instance, les extensions de paquets peuvent contenir les informations de déchargement pour la somme de contrôle, le déchargement d’envoi volumineux (LSO) et la fusion de segments de réception (RSC), ou elles peuvent contenir des détails spécifiques à l’application. Les extensions de fragment peuvent contenir des informations d’adresse virtuelle, des informations d’adresse DMA logique ou d’autres informations pour le fragment.
Ensemble, ces descripteurs et extensions contiennent toutes les métadonnées relatives à un paquet réseau. Voici deux exemples de la façon dont ils décrivent un paquet. La première figure montre un scénario dans lequel le paquet entier est stocké dans un fragment de mémoire unique et où le déchargement de la somme de contrôle a été activé.
La deuxième figure montre un paquet stocké sur deux fragments de mémoire, avec le déchargement RSC et la somme de contrôle activés.
Stockage et accès du descripteur de paquets
Les descripteurs de paquets et les descripteurs de fragments sont tous deux stockés dans des structures NET_RING . Un pilote client de carte réseau accède aux anneaux réseau et effectue des opérations sur ceux-ci en appelant l’interface d’itérateur Net Ring, ce qui permet au pilote de travailler avec NetAdapterCx pour publier des données réseau sur le matériel et drainer les données terminées vers le système d’exploitation.
Pour plus d’informations sur les anneaux réseau et l’interface d’itérateur Net Ring, consultez Présentation des anneaux réseau.
Extensibilité du descripteur de paquets
L’extensibilité est une fonctionnalité de base du descripteur de paquets NetAdapterCx, qui constitue la base de la capacité de version et des performances du descripteur. Au moment de l’exécution, le système d’exploitation alloue tous les descripteurs de paquets pour chaque file d’attente de paquets dans un bloc contigu, ainsi que toutes les extensions pouvant être autorisées. Chaque bloc d’extension se trouve immédiatement derrière le descripteur principal, comme illustré dans la figure suivante :
Les pilotes clients de carte réseau ne sont pas autorisés à coder en dur le décalage sur un bloc d’extension. Au lieu de cela, ils doivent interroger au moment de l’exécution le décalage vers une extension particulière. Par exemple, un pilote peut interroger le décalage vers l’extension B et récupérer 70 octets comme dans la figure suivante :
Une fois qu’une file d’attente de paquets et ses descripteurs sont créés, tous leurs décalages d’extension sont garantis par le système comme étant constants, les pilotes n’ont pas à interroger souvent les décalages. En outre, étant donné que toutes les extensions sont pré-allouées par le système dans un bloc au moment de l’initialisation de la file d’attente de paquets, il n’est pas nécessaire d’allouer des blocs au runtime, de rechercher un descripteur spécifique dans une liste ou de devoir stocker des pointeurs vers chaque extension de paquet.
Capacité de version du descripteur de paquets
Le descripteur de paquet principal de NetAdapterCx peut être facilement étendu dans les versions ultérieures en ajoutant de nouveaux champs à la fin, comme dans la figure suivante :
Les pilotes clients plus récents qui connaissent les champs V2 peuvent y accéder, tandis que les pilotes V1 plus anciens utilisent des décalages d’extension pour ignorer les champs V2 afin qu’ils puissent accéder aux champs qu’ils comprennent. En outre, chaque extension peut être versionnée de la même façon, comme le montre la figure suivante :
Un pilote client qui comprend la nouvelle extension peut l’utiliser. D’autres pilotes clients peuvent ignorer les nouveaux champs. Cela permet à différentes parties du descripteur de paquets d’être versionnée indépendamment.
Performances des descripteurs de paquets et des chemins de données
La fonctionnalité d’extensibilité décrite précédemment offre des avantages pour aider les pilotes clients à répondre aux exigences de performances des cartes réseau qui peuvent atteindre des centaines de gigabits par seconde, avec des milliers de files d’attente :
Les descripteurs de paquets sont conservés aussi compacts que possible pour améliorer les accès au cache du processeur, car les fonctionnalités et les extensions qui ne sont pas utilisées occupent 0 octet d’espace dans les descripteurs.
Il n’y a pas de déréférencement de pointeur, seulement l’arithmétique de décalage, car les extensions sont en ligne, ce qui permet non seulement d’économiser de l’espace, mais également d’aider les accès au cache du processeur.
Les extensions étant allouées au moment de la création de la file d’attente, les pilotes n’ont pas besoin d’allouer et de libérer de la mémoire dans le chemin de données actif ou de gérer des listes de lookaside de blocs de contexte.
La première étape de l’utilisation des extensions de paquets dans votre pilote client de carte réseau consiste à déclarer vos déchargements matériels pris en charge. Lorsque vous publiez la prise en charge des déchargements tels que la somme de contrôle et l’authentification LSO, NetAdapterCx inscrit automatiquement les extensions de paquets associées en votre nom.
Interrogation des décalages d’extension de paquets pour les files d’attente de chemins de données
Après avoir inscrit des extensions de paquets en déclarant la prise en charge de votre déchargement matériel, vous aurez besoin des décalages d’extension pour accéder à chacune d’elles au fur et à mesure que vous traitez vos paquets. Pour réduire les appels hors de votre pilote et améliorer les performances, vous pouvez interroger les décalages de vos extensions pendant la fonction de rappel EvtNetAdapterCreateTx(Rx)Queue et stocker les informations de décalage dans votre contexte de file d’attente.
Pour obtenir un exemple d’interrogation des décalages d’extension et de leur stockage dans le contexte de file d’attente, consultez Transmettre et recevoir des files d’attente.
Obtention d’extensions de paquets au moment de l’exécution
Une fois que vous avez stocké les décalages d’extension dans votre contexte de file d’attente, vous pouvez les utiliser chaque fois que vous avez besoin d’informations dans une extension. Par exemple, vous pouvez appeler la méthode NetExtensionGetPacketChecksum pendant que vous programmez des descripteurs sur du matériel pour une file d’attente de transmission :
// Get the extension offset from the device context
PMY_TX_QUEUE_CONTEXT queueContext = GetMyTxQueueContext(txQueue);
NET_EXTENSION checksumExtension = queueContext->ChecksumExtension;
// Get the checksum info for this packet
NET_PACKET_CHECKSUM* checksumInfo = NetExtensionGetPacketChecksum(checksumExtension, packetIndex);
// Do work with the checksum info
if (packet->Layout.Layer3Type == NET_PACKET_LAYER3_TYPE_IPV4_NO_OPTIONS ||
packet->Layout.Layer3Type == NET_PACKET_LAYER3_TYPE_IPV4_WITH_OPTIONS ||
packet->Layout.Layer3Type == NET_PACKET_LAYER3_TYPE_IPV4_UNSPECIFIED_OPTIONS)
{
if(checksumInfo->Layer4 == NET_PACKET_TX_CHECKSUM_REQUIRED)
{
...
}
}
...
Constantes d’extension de paquets prédéfinies et méthodes d’assistance
NetAdapterCx fournit des définitions pour les constantes d’extension de paquet connues.
Constant
Définition
NET_PACKET_EXTENSION_INVALID_OFFSET
Protège contre les tailles de décalage non valides.
Nom et version de l’extension de paquet RSC (Receive Segment Coalescence).
En outre, NetAdapterCx fournit des méthodes d’assistance qui agissent comme des wrappers autour de la méthode NetExtensionGetData . Chacune de ces méthodes retourne un pointeur vers le type de structure approprié.
Actuellement, les pilotes clients sont limités aux extensions de fragment préexistantes définies par le système d’exploitation.
Inscription d’extensions de fragments
NetAdapterCx inscrit automatiquement la plupart des extensions de fragments en interprétant les fonctionnalités exprimées d’un pilote. Par exemple, si le pilote exprime qu’il prend en charge DMA, le framework ajoute automatiquement l’extension NET_FRAGMENT_LOGICAL_ADDRESS nécessaire pour la programmation DMA.
Interrogation des décalages d’extension de fragment pour les files d’attente de chemins de données
Les applications de finances et d’opérations sont personnalisées à l’aide d’extensions, qui vous permettent d’ajouter des fonctionnalités aux éléments de modèle et au code source dans l’arbre d’objets d’application (AOA) à l’aide de Visual Studio.