Notre premier set de drivers RUST, pour les cartes Intel 1G, 10G et 40G est terminé (nous vous en écrirons un peu plus sur le sujet, mais nos benchs sont vraiment brillants !). Nous les faisons tourner en userspace, comme notre sonde !

Voici l'une des questions qui nous a régulièrement été posé lors du dernier FIC (International Cybersecurity Forum) 2022 :

Pourquoi n'avez-vous pas utilisé le DPDK ?

Comprendre :

En dehors d'un côté masochiste, y a-t-il une raison valable de ne pas utiliser le DPDK ?

Quand Intel, inventeur du DPDK en 2010, nous a choisi pour être l'une des 10 startups à faire partie de leur programme d'accélération Intel Ignite en 2022, la même question nous a été mainte fois posée par nos interlocuteurs abasourdis.

Notre relation avec le DPDK : "It's complicated"

Il est maintenant temps d’exprimer les réserves que nous avons sur le DPDK, dans notre cas bien précis, et les raisons qui nous ont motivé à choisir une autre voie.

La réponse à cette question pourrait se résumer ainsi : “on développe déjà tout en Rust ! Nous sommes tellement habitués à souffrir que décider de développer nos propres drivers de carte réseau n’a été qu'une décision comme une autre”. Du coup, oui, il y a définitivement un attrait pour la douleur.

Plus sérieusement, la réalité est la suivante : lorsque nous avons développé notre sonde réseau, avec pour objectif d’atteindre le 100Gbit/s, nous avons constaté que l’emploi du DPDK posait de nombreux problèmes. Tout particulièrement lorsque notre objectif était d’analyser les réseaux à des fins de cybersécurité.

Le DPDK est une technologie open source plutôt révolutionnaire. Elle a été initialement développée, puis proposée, par Intel pour les environnements Linux. Son objectif étant de fournir des librairies de Data Plane et des pilotes gérant les cartes réseaux.

Pour ceux qui ne sont pas familiers avec le DPDK, cette technologie est apparue en 2010 et venait dépoussiérer la stack réseau Linux existante, qui était vieillissante et pas vraiment performante.

Le DPDK, comment cela fonctionne ?

Lors de son démarrage, un logiciel réseau fait appel au noyau pour configurer une méthode d’acquisition des paquets. Plusieurs technologies existent, dont les plus populaires sont certainement AF_Packet (natif dans Linux),AF_XDP, DPDK, ou encore Netmap.

Avec le DPDK, le noyau sera par défaut entièrement contourné et un pilote (driver) différent, en charge de la gestion de la carte réseau, sera utilisé. Ce qui a permis au DPDK de s’imposer rapidement en remplacement de la pile réseau traditionnelle du Kernel/Linux.

Le DPDK utilise plusieurs stratégies afin d'obtenir des performances maximales. L'allocation par le DPDK de cœurs CPU dédiés garantit de meilleures performances des “applications réseau” (en termes de traitement de millions de paquets par secondes). Les “grandes pages mémoires” (hugepages), quant à elles, assurent un accès plus uniforme dans le temps aux ressources mémoires (memory pool), ce qui réduit le nombre de “TLB miss” (translation lookaside buffer). Il existe bien sûr beaucoup d'autres techniques d'optimisations (on peut notamment citer la récupération des paquets par batchs, ou encore le contournement du noyau, qui induit aussi une réduction des opérations de copie/récupération au niveau de la mémoire tampon.)

De manière générale, la charge réduite sur le processeur permet souvent d’obtenir des performances intéressantes. Et comme le rappelle Intel : “Le DPDK supprime certains des goulots d'étranglement impliqués dans le traitement des paquets. En déplaçant les tampons mémoire dans l'espace utilisateur et en effectuant des interrogations plutôt qu'un traitement basé sur les interruptions, le DPDK est en mesure d'améliorer les performances avec de petites tailles de paquets.” (R-IOV for NFV Solutions - Practical Considerations and Thoughts Technical Brief - Authors: Patrick Kutch Cloud Solutions Architect Solutions Enabling Team, Intel Brian Johnson Solutions Architect Networking Division, Intel).

Aujourd’hui, en environnement hypervisé, grâce à l’utilisation du DPDK, d’Open vSwitch (OVS) et de la gestion des Fonctions Virtuelles, il devient possible de bénéficier d’un nombre conséquent d’optimisations intéressantes, surtout dans le cas de la transmission de paquets inter-machines virtuelles (comprendre, les VM sur une seule machine physique).

Du coup, pourquoi pas le DPDK ?

Lors de nos expériences, nous avons constaté que le DPDK connaissait aussi certaines limitations, qui viennent impacter lourdement les performances des solutions reposant sur l’analyse protocolaire. Parmi ces limitations, nous en avons dégagé 4 principales, qui nous ont poussé à ne pas faire reposer notre solution sur cette technologie :

• 1 : La difficulté de compilation/maintenance du DPDK
• 2 : La difficulté de configuration/déploiement du DPDK
• 3 : L'absence (à date) de compatibilité avec le Rust
• 4 : Son framework qui impose d’avoir ses propres threads.

Ce dernier point implique qu’on ne peut pas l'utiliser uniquement comme un backend de lecture de paquet. Une solution utilisant le DPDK ne peut alors utiliser que le DPDK : nous souhaitions une large compatibilité.

Ce ne sont pas les seules contraintes ou limitations que nous avons rencontré, bien qu’elles aient été déterminantes dans notre abandon de cette technologie. Parmi les autres points qui nous ont contrarié, nous pourrions mentionner à titre d’exemple :

• Le DPDK est un cadriciel (Framework) compliqué à maintenir du fait de ses systèmes hérités (Legacy), ce qui le rend d'autant plus difficile à adapter pour des environnements réseaux complexes
• Lors de mises à jour du DPDK, on constate des pertes de comptabilité avec les matériels autrefois compatibles
• L’implémentation au niveau des cartes réseaux est également complexe à mettre en œuvre
• Le DPDK gère ses propres threads, qui sont externalisés du noyau. Il a donc son propre scheduler (ordonnanceur). Et comme il est initialisé au démarrage, il n’est pas possible d’y apporter des modifications, sauf par un redémarrage de tout le système. Ce qui a un impact sur la scalabilité dynamique de toute solution construite sur le DPDK
• Au cours de travaux de recherche et développement, nous ne sommes jamais parvenus à tenir un débit de 100Gbit/s (148.800.000 de paquets par seconde) avec des paquets de petites tailles (64 octets) avec le DPDK. Et cela, sur plusieurs cartes réseaux différentes. Ce niveau de performance est pourtant celui annoncé par le framework DPDK
• Les drivers de cartes réseau implémentés dans le DPDK ont leurs propres threads (de Cœur CPU), ce qui pousse parfois, selon les use case, à des systèmes de call-back (fonction de rappel) qui peuvent provoquer un overhead sur les ressources processeurs, qui est important lors de l’enregistrement des paquets en PCAP.
• A l’usage, nous avons noté un plateau lorsque certaines solutions à base de DPDK doivent utiliser plus de 30 cœurs.

Ces points peuvent néanmoins évoluer : le DPDK étant régulièrement mis à jour, il se peut que certains soient résolus lorsque vous lirez cette article.

L’objectif de NANO Corp. est l’observabilité unifiée, c’est à dire la capacité de superviser les réseaux physiques comme cloud avec la même plateforme. Le développement de nos sondes cloud (spoiler alert : grosse annonce à venir) nous imposait de prévoir les impacts potentiels du DPDK dans ces environnements.

Bien que nous n’en ayons pas fait l’expérience, car nous avons fait d'autres choix de développement, en environnement virtualisé, il a également été noté que le DPDK peut avoir des difficultés à rendre scalable la manipulation des paquets. Comme il est dit ici : « OVS-DPDK fonctionne de manière très similaire dans nos environnements de test, évoluant de manière linéaire pour les VNF initiaux, mais atteignant ensuite un plateau de débit système à mesure que d'autres VNF sont ajoutés. Nous montrons que ce plateau est fonction des ressources CPU allouées aux fonctions de commutation virtuelle de OVS-DPDK ». (Pitaev et al., 2018 Characterizing the Performance of Concurrent Virtualized Network Functions with OVS-DPDK, FD(.)IO VPP and SR-IOV). Nous craignons donc ceci : plus l’hyperviseur aura de machines virtuelles à gérer, plus la solution d’analyse de protocoles sera rapidement saturée. Une hypothèse qui s’est vérifié lors de nos recherches. Une saturation qu’il n’était pas pertinent de chercher à contourner tant que cette technologie n’aura pas évolué.

C’est à la lumière de toutes ces difficultés que nous avons décidé de contourner le DPDK et de redévelopper une solution fonctionnant entièrement en userspace, drivers de NIC compris. Article à venir sur le sujet.

Si vous avez rencontré des problèmes similaires ou si vous ne partagez pas cette analyse, nos chercheurs et développeurs maison se feront un plaisir d’échanger avec vous sur le sujet.

N’hésitez pas à prendre contact !