DPDK : bien planifier le traitement des paquets dans l'espace utilisateur

Principe fondamental du DPDK et classification correcte

DPDK Il s'agit d'un framework destiné aux applications qui doivent traiter des paquets réseau avec un surcoût minimal dans l'espace utilisateur. Au lieu d'emprunter la voie habituelle passant par la pile réseau du noyau, les sockets et leurs structures de paquets, une application peut utiliser directement certaines cartes réseau pour son propre chemin de données. Cela vise avant tout à obtenir des débits de paquets élevés, de faibles latences et un traitement facilement prévisible en présence de nombreux petits paquets.

L'expression „ sans limites du noyau “ est ici simplifiée. Le noyau Linux reste présent pour le système d'exploitation, la gestion de la mémoire, les processus, la sécurité et de nombreuses tâches administratives. DPDK ne remplace pas non plus les limites de la carte réseau, ni celles liées au PCIe, à la bande passante mémoire ou au processeur. Pour les interfaces liées, il contourne principalement le chemin de données habituel du noyau et transfère le traitement des paquets vers une application spécialisée.

Dans le chemin réseau standard sous Linux, les pilotes réseau, le NAPI, la gestion des paquets et la couche socket fonctionnent de concert. Ce chemin n'est pas systématiquement basé uniquement sur les interruptions. Un DPDK-Pilote en mode sondage interroge les files d'attente de réception directement depuis l'espace utilisateur. L'application reçoit les paquets par lots, les vérifie ou les modifie, puis les transmet à une file d'attente d'envoi ou à une étape de traitement ultérieure.

Il ne s'agit pas d'un réglage général du noyau et ce n'est généralement pas la première mesure à prendre pour une application web classique comportant peu de connexions TCP. Ce n’est que lorsque le chemin de transmission des paquets lui-même présente une limitation avérée, par exemple dans le cadre de l’équilibrage de charge de couche 4, du filtrage ou des points d’extrémité de tunnel, que le gain potentiel justifie l’effort opérationnel supplémentaire. Les caractéristiques liées à la version doivent être vérifiées par rapport à la documentation de la version (release tag) concrètement utilisée ; une version candidate (release candidate) ne doit pas être assimilée à une version déployée en production.

Fonctionnement du chemin d'accès aux paquets dans l'espace utilisateur

À l'entrée, l'application configure une ou plusieurs files d'attente Rx de la carte réseau. Un cœur d'exécution attribué interroge une file d'attente en boucle et reçoit une rafale de paquets disponibles. Ceux-ci Traitement par rafales réduit le nombre d'appels de fonction et la charge administrative par paquet. Après classification, transfert ou modification, l'application place les paquets regroupés dans une file d'attente Tx.

Le polling évite de nombreux changements d'interruption dans le chemin de données fortement sollicité et rend le travail d'un cœur plus prévisible. Le prix à payer est un processeur actif en permanence : même lorsque la file d'attente est vide, le lcore continue de vérifier s'il y a de nouveaux paquets. C'est pourquoi ce modèle convient mieux à une charge élevée constante qu'à des interfaces où le trafic est rare ou très variable.

Les données de paquet et les métadonnées se trouvent dans rte_mbuf-objets. Ceux-ci proviennent d'un mempool créé au préalable et contiennent, par exemple, la longueur du paquet, le port d'entrée, des informations de déchargement et, le cas échéant, un hachage RSS. Des pools réservés à l'avance, une affectation fixe entre la file d'attente et le noyau, ainsi que des chemins de traitement courts favorisent localité du cache et évitons les structures de données communes inutiles.

Le « Zero Copy » n'est toutefois pas une fonctionnalité automatique de DPDK. La décision de copier ou non les données, et à quel endroit, dépend de la carte réseau, du pilote, des déchargements et de la logique applicative. Les trames volumineuses ou segmentées peuvent être constituées de plusieurs mbufs liés entre eux ; cela s'applique notamment aux trames jumbo. Quiconque reformate, fusionne ou transfère des données de paquets entre des tampons incompatibles doit tenir compte des éventuels déplacements de mémoire dans son propre chemin de données.

Architecture, ressources et contraintes strictes

Les couches d'abstraction d'environnement, en abrégé EAL, initialise DPDK et fournit notamment la réservation de mémoire, l'accès aux périphériques, les temporisateurs ainsi que l'affectation des cœurs logiques. Sur cette base, l'application configure les files d'attente Ethernet, les pools de mémoire et leur traitement. Un « lcore » est ici un cœur logique alloué à DPDK, et non pas simplement un thread d’application se déplaçant au hasard. Ces propriétés fondamentales de l’EAL sont documentées ici dans la documentation de DPDK 25.07 ; les détails spécifiques à la version doivent en outre être vérifiés pour la version utilisée.

Pour garantir un chemin de données linéaire, un noyau traite souvent un paquet dans son intégralité : de la réception à l'envoi, en passant par la prise de décision. Ce modèle « run-to-completion » évite les transferts entre noyaux. À l'inverse, un pipeline sépare par exemple l'analyse syntaxique, la recherche de flux et le transfert en différentes étapes. Il permet d'organiser les responsabilités, mais ajoute des boucles, une synchronisation et une localité de mémoire potentiellement moins bonne entre les étapes.

La planification doit également tenir compte de la structure NUMA. Dans la mesure du possible, la file d'attente, le lcore et les pools de paquets doivent se trouver sur le même nœud NUMA, afin que le chemin d'accès aux données n'accède pas régulièrement à la mémoire d'un autre socle de processeur. Les performances réalisables dépendent en outre des fonctionnalités des cartes réseau (NIC), de la connexion PCIe, de la bande passante mémoire, de la fréquence d'horloge du processeur, de la taille des paquets et de la complexité de chaque décision relative aux paquets.

Un équilibreur de charge L4 peut, grâce aux informations IP et de port fournies par DPDK, analyser rapidement les flux, les attribuer et acheminer les paquets. Cependant, cela n'accélère pas automatiquement la terminaison TLS, les états NAT complexes, la journalisation, les contrôles de santé ou les backends lents. De même, le plan de contrôle a besoin de temps CPU disponible pour la configuration, la télémétrie et la gestion des erreurs. DPDK accélère donc un chemin de données clairement délimité, mais pas nécessairement l'ensemble du service.

La taille et la durée de vie des tampons de paquets font également partie de l'architecture. Les mempools limitent le nombre de tampons disponibles simultanément, tandis que l'application doit gérer correctement les changements de propriété. Des pools trop petits peuvent s'épuiser sous la charge ; des réservations trop importantes mobilisent de la mémoire. La taille appropriée résulte des files d'attente, des tailles de rafales, du chemin des paquets et des pics de charge attendus, et non d'une valeur par défaut universelle.

Vérifier les conditions préalables à l'utilisation du DPDK

Le DPDK ne peut être planifié que si le matériel, la mémoire et l'affectation des cœurs de processeur sont compatibles entre eux. Une simple installation ne suffit pas à créer un chemin de données performant : le PMD doit prendre en charge le modèle concret de carte réseau, et les ressources doivent pouvoir être réservées pour l'application. L'analyse suivante distingue les prérequis techniques minimaux des hypothèses qui ne s'appliquent qu'à l'appareil effectivement utilisé.

Les « hugepages » constituent la méthode habituelle pour les pools de paquets volumineux, mais ne sont pas une condition incontournable pour toutes les applications DPDK. L’EAL prend également en charge l’option –no-huge. Ce mode spécial ne constitue pas une recommandation standard à part entière : il convient de vérifier la compatibilité, la gestion de la mémoire et les limites des pilotes avant toute mise en service pilote. Les principes de base du système et de l’EAL utilisés ici sont documentés dans la version 25.07 de DPDK ; vérifiez également la compatibilité de ces options avec la version effectivement installée.

La situation est particulièrement critique Liaison avec l'appareil. De nombreux PMD exigent que la carte réseau concernée soit déconnectée du pilote standard du noyau et, par exemple, reliée à vfio-pci est liée. L'interface n'est alors plus accessible de manière standard par la pile réseau Linux habituelle. La procédure concrète doit toutefois être adaptée au PMD et ne peut pas être appliquée de manière générale à toutes les cartes réseau prises en charge.

Les PMD bifurqués constituent une exception importante. La documentation du pilote précise que ces PMD ne doivent pas être déliés du pilote du noyau correspondant. Le pilote du noyau peut ainsi rester lié tandis qu’un chemin de données de l’espace utilisateur utilise certaines ressources. La documentation liée, sans mention de version, correspond à l'état de développement 26.11.0-rc1 et ne constitue pas un guide spécifique à la version 26.07. Vérifiez la prise en charge des périphériques et les outils du noyau disponibles dans le manuel du PMD concrètement utilisé.

Avant toute modification, la requête d'état suivante fournit un inventaire des périphériques PCI et de leurs pilotes actuellement associés. Elle ne modifie pas elle-même ces associations. Exécutez-la sur le système cible en indiquant le chemin d'accès correspondant à la structure source ou aux outils DPDK installés.

./usertools/dpdk-devbind.py --status

L'accès à la gestion de la planification et le chemin d'accès aux données de production doivent être séparés, même si le PMD sélectionné ne remplace pas le pilote du noyau. L'accessibilité via SSH ou la console ne doit pas dépendre d'une interface dont la liaison ou la répartition du trafic est modifiée pendant la phase pilote. Une interface de gestion distincte, un accès hors bande ou une voie de secours locale préalablement testée limitent le risque de mauvaise configuration.

Comparaison entre DPDK, AF_XDP et Kernelstack

Le choix du chemin de données n'est pas une question de classement, mais une décision opérationnelle. La pile du noyau Linux, AF_XDP et DPDK ont chacun un impact différent sur la charge de travail, l'accès aux périphériques et la consommation du processeur. Le choix de l'option appropriée dépend de la question de savoir si c'est réellement le débit de paquets ou la latence qui constitue la limite dans le chemin réseau, ou si ce sont l'application, le chiffrement et les backends qui constituent le goulot d'étranglement.

AF_XDP est une option intermédiaire destinée aux équipes qui souhaitent traiter les paquets en amont tout en restant proches du modèle réseau Linux. Le noyau décrit un mode « Copy » ainsi que le mode « Zero Copy », qui nécessite la prise en charge par les pilotes. Si le mode « Zero Copy » est explicitement requis, la création de sockets peut échouer si le pilote ne prend pas en charge cette fonctionnalité. L'article suivant aide à comprendre le fonctionnement de la couche XDP : XDP et eXpress Data Path.

DPDK, en revanche, utilise des pilotes en mode poll et traite les files d'attente directement depuis l'application. Cela permet de contourner les composants liés aux sockets et aux interruptions pour le chemin de données DPDK, mais implique de prendre en charge la gestion de la mémoire, des files d'attente et de l'allocation des cœurs. Zero Copy Il ne s'agit ni d'une promesse générale de performances, ni d'une caractéristique inhérente à n'importe quel chemin DPDK ; le nombre de copies dépend de l'application, des déchargements et des transferts de mémoire.

Choisissez la pile du noyau si le routage, le pare-feu, l'observabilité et la simplicité d'exploitation priment sur un chemin de paquets spécialisé. Envisagez AF_XDP en cas d'accélération ciblée avec connexion au noyau. DPDK n'est rentable que si vous avez un besoin avéré de débit de paquets élevé ou de latence constante, si la prise en charge des cartes réseau (NIC) est assurée et si vous disposez d'une équipe capable d'assumer durablement la charge de travail supplémentaire liée à l'exploitation.

Planifier judicieusement les files d'attente, l'affectation des processeurs et la NUMA

Une solution robuste Affectation aux files d'attente commence par la proximité entre le NIC, le CPU et la mémoire. L'EAL prend en charge la sélection des cœurs logiques, la réservation de mémoire et l'allocation des périphériques. Pour un chemin de données simple, il est généralement judicieux d’attribuer de manière fixe une file d’attente Rx à un lcore, de créer le mempool correspondant sur le nœud NUMA local, puis de transférer le traitement vers une file d’attente Tx appropriée. Ces informations de base sur l’EAL sont documentées dans la documentation de DPDK 25.07 et doivent être vérifiées par rapport à la version utilisée pour les options spécifiques à celle-ci.

Voici un exemple, non spécifique à un produit, d'hôte comportant deux nœuds NUMA : la carte réseau du nœud 0 reçoit deux files d'attente de réception (Rx) ; un lcore du nœud 0 traite intégralement chacune de ces files d'attente. Les tampons de paquets se trouvent également sur le nœud 0. Un autre cœur, qui n'effectue pas de sondage, reste disponible pour les tâches d'administration, tandis que le nœud 1 est réservé à d'autres services ou à des chemins de données clairement distincts.

• Chemin d'accès aux données : pour chaque file d'attente, un lcore attribué de manière fixe, des pools de mémoire locaux et des paires Rx/Tx clairement nommées.
• Administration : réserver de la capacité CPU pour la télémétrie, la logique de commande, les événements et les services du système d'exploitation.
• Réserve : prévoir une marge de capacité pour les pics de charge, le dépannage et les extensions prévues, plutôt que d'utiliser en permanence tous les cœurs.

Ne partagez pas une file d'attente Rx entre plusieurs lcores. Le guide PMD déconseille le partage des files d'attente Rx et Tx, car les verrous globaux nécessaires à cette opération peuvent fortement nuire aux performances. L'accès simultané de plusieurs lcores à une file d'attente Tx n'est prévu comme exception documentée que si le pilote dispose de la capacité RTE_ETH_TX_OFFLOAD_MT_LOCKFREE signale. Vérifiez cette capacité pour la combinaison NIC/PMD concernée ; ne la déduisez ni de la vitesse du port, ni d'un commutateur de déchargement général.

Un pipeline comportant des étapes distinctes d'analyse, de classification et d'envoi permet de clarifier les responsabilités. L'approche par pipeline documentée transfère les paquets vers d'autres cœurs via des anneaux, ce qui entraîne des accès mémoire et des transferts supplémentaires. Pour les filtres simples ou le transfert L4, le mode « run-to-completion » par file d’attente est souvent plus facile à planifier. Il ne faut recourir à plusieurs étapes que si la répartition des tâches justifie l’effort supplémentaire qu’elle implique dans le profil de charge concret.

Voir aussi Délestages matériels ne doivent pas être pris en compte dans la planification. Les fonctions de somme de contrôle, de segmentation, de RSS ou de flux disponibles dépendent des capacités du périphérique Ethernet concerné et de son PMD. Vérifie-les avant la conception et considère l'absence de déchargement comme un cas de planification normal, et non comme une exception.

Surveiller le bon fonctionnement du DPDK en toute sécurité

L'exploitation d'un chemin de données DPDK nécessite des métriques qui prennent en compte à la fois le traitement des paquets et les ressources. Il convient de recenser au minimum les paquets traités, rejetés et erronés, ainsi que les valeurs propres à l'application concernant les taux de traitement, les réserves de mémoire et Répartition de la latence plutôt qu'une simple valeur moyenne. Les compteurs supplémentaires de ports, de files d'attente ou de pilotes disponibles dépendent du PMD, de la carte réseau et de l'application concernés, et doivent être vérifiés pour la combinaison utilisée.

Le polling est un conflit d'objectifs délibéré. Un lcore interroge en continu sa file d'attente Rx afin que les paquets puissent être traités sans passer par le chemin d'interruption habituel. Même en cas de trafic faible ou inexistant, la boucle de polling reste néanmoins active. Prévoyez donc, outre les lcores du chemin de données, une capacité CPU pour la logique de contrôle, la télémétrie et le système d'exploitation. La documentation EAL utilisée à titre complémentaire se réfère à DPDK 25.07 ; les fonctionnalités spécifiques à chaque version doivent être vérifiées dans la version installée.

Pour l'analyse des causes, la corrélation temporelle est importante. Si la perte de paquets coïncide avec l'augmentation des compteurs d'erreurs, la diminution des réserves du mempool ou une saturation du chemin de données lcore, il s'agit dans un premier temps d'indices vérifiables, mais pas encore d'une preuve formelle de la cause. Les temps de réponse fluctuants peuvent notamment être liés à une mémoire éloignée du NUMA, à des tâches concurrentes ou à des transferts de pipeline. Comparez ces hypothèses respectivement avec l’affectation des cœurs, la répartition des files d’attente et les valeurs mesurées au cours de la même fenêtre temporelle.

Une capture rapide au niveau de l'interface ne garantit pas un enregistrement complet et sans perte des paquets sur le long terme. Pour les statistiques de flux ou l'analyse des en-têtes, quelques métadonnées peuvent suffire. Si chaque paquet doit être stocké, la bande passante de stockage, la capacité de la mémoire tampon, le débit d'écriture et le support de stockage choisi limitent également la mise en place du système. La protection des données et les règles de conservation constituent à cet égard des exigences indépendantes que le débit du réseau ne permet pas de résoudre.

Prévoyez les machines virtuelles et les conteneurs comme une tâche d'intégration distincte. Déterminez, pour la plateforme concernée, comment sont fournis l'accès aux périphériques, le stockage, l'affectation des cœurs de processeur et les droits requis. Vérifiez cette configuration à l'aide du PMD utilisé, au lieu de reprendre systématiquement les paramètres d'exemple. Le guide Linux référencé correspond actuellement à la version de développement 26.11.0-rc1 ; pour une installation en production, c'est la documentation de la version effectivement installée qui fait foi.

Vérifier systématiquement les défauts typiques

Lors d'un dépannage, il convient tout d'abord de distinguer les symptômes observables des causes possibles. Ne modifiez pas simultanément la liaison du pilote, le numéro de file d'attente et les paramètres de mémoire, car cela rendrait alors impossible l'identification de la cause du problème. Les compteurs non destructifs, les informations de configuration et une comparaison entre la file d'attente concernée et une file d'attente non concernée fournissent généralement des indications plus fiables avant toute intervention.

En cas de comportement anormal de la file d'attente, vérifie le propriétaire de la file d'attente et le nœud NUMA du mempool. Dans le modèle « run-to-completion », le lcore attribué gère la réception, le traitement et l'envoi ; un pipeline transfère les paquets vers d'autres cœurs. Ne partagez toutefois pas la file d'attente Rx entre les lcores. L'accès simultané à une file d'attente Tx n'est autorisé que si RTE_ETH_TX_OFFLOAD_MT_LOCKFREE-Cette fonctionnalité est prévue à titre exceptionnel. Un verrouillage auto-complété fait que le partage de file d'attente n'est pas une stratégie d'évolutivité recommandée.

En l'absence de déchargement matériel, la bonne question n'est pas seulement de savoir quel commutateur a été activé, mais quelles capacités le périphérique et le PMD fournissent réellement. Une application peut prévoir une fonctionnalité souhaitée sans que celle-ci soit disponible pour ce modèle. Comparez la prise en charge de la carte réseau concernée avec les capacités signalées lors de l'exécution avant de faire dépendre le chemin de données de ce déchargement.

Les résultats de testpmd doivent être considérés comme une référence ou un test fonctionnel, et non comme une preuve des performances de l'application future. En mode « io-Forwarding », les paquets sont transférés tels quels, sans que leur contenu ne soit analysé à des fins de traitement technique. Ce mode ne prend pas en charge les analyseurs syntaxiques, les tables de flux, le NAT, le chiffrement ni l'état des protocoles. La documentation liée et non versionnée correspond à la version 26.11.0-rc1 ; vérifiez le comportement dans le manuel de la version installée. Notez le mode de transfert, la taille des paquets, le nombre de files d'attente Rx/Tx et le nombre de cœurs de transfert, puis répétez la comparaison avec une logique de traitement réelle.

Déploiement, gestion des versions et décision de mise en service

Commencez par un test isolé et un test documenté profil de charge: tailles des paquets, charge de pointe, nombre de flux et étapes de traitement requises. Vérifie la carte NIC spécifique, ainsi que le pilote « Poll Mode » adapté et les fonctionnalités requises, à l’aide de la liste officielle du matériel et de la matrice des pilotes. La simple présence d’un fabricant dans la liste ne garantit ni la compatibilité avec toutes les cartes, ni la prise en charge de toutes les fonctions de déchargement. Effectue ensuite des tests avec une logique d’application réelle, et pas uniquement avec un exemple de transfert.

Notez la version de DPDK, le firmware, les pilotes, le noyau et la configuration pour chaque essai. Avant toute mise à jour, lisez les notes de mise à jour correspondant exactement à la version ciblée et notez les modifications qui concernent votre chemin d'accès aux données. Les notes de mise à jour de versions différentes ne remplacent pas cette mise en correspondance, car les fonctionnalités et les restrictions peuvent varier d'une version à l'autre.

Un point à vérifier en particulier, mentionné dans les notes de mise à jour de DPDK 26.07, concerne la modification de l'algorithme de vidage/remplissage du cache du mempool : sa taille effective correspond désormais à la taille configurée ; auparavant, elle était supérieure de 50 %. Ce n’est que lorsque chaque lcore d’un mempool se contente exclusivement de prélever ou de restituer des objets que les notes de mise à jour recommandent de doubler la taille configurée du cache, afin d’éviter un éventuel doublement du taux d’échecs de cache. Cela concerne par exemple les pipelines avec des lcores Rx et Tx séparés, et non de manière générale le mode « run-to-completion ». Cette modification concerne la version 26.07 ; la page historique de la version liée se trouve désormais dans la documentation relative à la version 26.11.0-rc1.

Commencez par un projet pilote à portée limitée et définissez des critères d'arrêt précis. Comparez le débit, les centiles de latence élevés, les pertes de paquets et la charge CPU dans des conditions identiques à celles de l'exploitation actuelle. Vérifiez la surveillance, les redémarrages et le retour à la configuration précédente. Tenez compte des coûts d'exploitation ; il n'est pas possible d'en déduire une garantie générale de débit.

Le choix de DPDK s'avère particulièrement judicieux lorsque les avantages mesurés justifient l'effort de maintenance supplémentaire. Pour situer cette solution dans le contexte de la plateforme système environnante, l'article précise que Le noyau Linux dans le domaine de l'hébergement la planification. Pour les services d'hébergement classiques, conservez également le chemin d'accès réseau existant comme base de comparaison lors du test.