Sur un hyperviseur bien chargé, une part non négligeable des cycles CPU ne sert à rien de facturable. Elle part dans le vSwitch, le chiffrement TLS, les checksums, la sérialisation, la copie mémoire entre le réseau et le disque. Google a mis un nom là-dessus en profilant plus de 20 000 machines de son parc pendant trois ans : le « datacenter tax », entre 22 et 27 % des cycles d'exécution sur une fenêtre de onze mois. Un quart de votre parc tourne pour faire de la plomberie.
Le DPU (Data Processing Unit, ou SmartNIC selon le niveau de programmabilité) est la réponse matérielle à ce constat : déporter la plomberie sur une carte PCIe qui embarque son propre SoC, sa propre RAM et son propre système. NVIDIA vend du BlueField, AMD vend du Pensando, Intel a poussé ses IPU. Le discours commercial est séduisant. La réalité d'exploitation est plus rugueuse, et le taux d'adoption réel en dit long.
Ce qu'il y a réellement sur la carte
Un DPU n'est pas une carte réseau avec un peu de logique en plus. C'est un ordinateur complet greffé sur le bus PCIe, avec son OS et son cycle de vie propre.
Le BlueField-3 de NVIDIA annonce 400 Gb/s de bande passante, 16 cœurs Arm Cortex-A78, 16 Go de DDR5, du PCIe Gen5 et une consommation maximale de 150 W. L'Elba d'AMD Pensando joue sur un autre registre : 2 x 200 Gb/s en ligne, 16 cœurs Cortex-A72, et surtout un pipeline programmable en P4 composé de 144 unités de traitement de correspondance (MPU), plus des moteurs dédiés au chiffrement, à la compression, aux checksums et au hachage de déduplication.
La distinction compte. Les cœurs Arm servent au plan de contrôle : ils font tourner un Linux, l'agent OVS, l'agent de supervision. Le trafic réel, lui, ne passe pas par ces cœurs, sinon rien ne tiendrait la ligne. Il passe par le pipeline matériel, l'ASIC ou les MPU P4. C'est ce qu'un ingénieur découvre au premier bench raté : croire qu'on va faire tourner du code applicatif sur les cœurs Arm de la carte, c'est se heurter à ce que la littérature académique appelle poliment des « wimpy cores », des cœurs faiblards avec quelques Mo de cache et une capacité mémoire très contrainte.
L'offload vSwitch, le seul cas d'usage vraiment mûr
Sur une infra de virtualisation, la fonction la plus coûteuse est le commutateur virtuel. Chaque paquet entre une VM et le réseau traverse OVS, subit une décision de forwarding, une encapsulation VXLAN ou Geneve, éventuellement du NAT et un filtrage. À 25 Gb/s ça se voit ; à 100 Gb/s ça mange des cœurs entiers.
Le mécanisme d'offload est standardisé côté noyau Linux, et il ne dépend pas d'un constructeur. OVS continue de calculer les flux en logiciel, mais les flux établis sont poussés dans le matériel via tc flower, le mode switchdev et les représentants SR-IOV. Le résultat : un chemin rapide entièrement matériel pour le régime établi, et un repli logiciel pour les premiers paquets, les exceptions et tout ce qui n'est pas offloadable. Même logique côté filtrage, où le noyau a gagné une infrastructure d'offload matériel pour netfilter et conntrack.
Deux conséquences opérationnelles que personne ne mentionne dans les plaquettes.
D'abord, l'offload est partiel par construction. Toute fonctionnalité que le pipeline matériel ne connaît pas fait retomber le flux en logiciel, silencieusement. Vous croyez avoir déchargé le CPU, et un conntrack exotique ou une règle de QoS non supportée ramène la moitié du trafic sur le chemin lent. La règle qu'on applique : on ne déclare jamais un offload actif sans avoir compté les flux réellement en hardware, pas ceux qu'on a demandés.
Ensuite, le débogage change de nature. Quand le chemin de données vit dans un ASIC, tcpdump sur l'hôte ne voit plus rien du trafic offloadé. Les méthodes de diagnostic réseau classiques restent valables, mais il faut y ajouter les compteurs matériels de la carte, et accepter que le point d'observation se soit déplacé. C'est exactement le même changement de paradigme que celui imposé par eBPF sur le chemin de données du noyau : la visibilité ne disparaît pas, elle se déplace, et l'outillage doit suivre.
Chiffrement et stockage : le vrai gain est ailleurs
Le second cas d'usage sérieux, c'est le chiffrement en ligne. IPsec, TLS, chiffrement au repos vers du NVMe-oF : les moteurs cryptographiques de la carte traitent ça à la vitesse du lien, sans consommer un cycle hôte. Sur une infra qui chiffre tout le trafic est-ouest par défaut, l'économie est réelle et mesurable.
Le stockage suit la même logique. Un DPU peut présenter à l'hôte un disque NVMe local qui est en réalité un volume distant, avec le protocole NVMe-oF entièrement géré côté carte. L'hôte ne sait pas qu'il fait du réseau. Combiné à un tuning NVMe correct côté cible, ça supprime toute la pile de stockage logicielle du domaine de responsabilité de l'hyperviseur.
Et c'est là qu'apparaît l'argument le plus défendable, celui qui n'a rien à voir avec la performance : l'isolation. Quand le plan de contrôle réseau et stockage tourne sur la carte et non sur l'hôte, un tenant qui compromet l'hyperviseur ne compromet pas le plan d'infrastructure. La frontière de sécurité devient matérielle. C'est la même famille de raisonnement que le confidential computing : on cesse de faire confiance à l'hôte. Pour un opérateur multi-tenant, c'est un argument bien plus solide que les cœurs économisés.
Le chiffre marketing qu'il faut savoir lire
NVIDIA annonce qu'un BlueField-3 délivre l'équivalent des services d'infrastructure de « jusqu'à 300 cœurs CPU ». Ce chiffre est une borne théorique, obtenue sur des charges d'infrastructure saturées à 400 Gb/s. Sur une infra d'hébergement classique en 25 ou 100 Gb/s, avec des VM qui font surtout du HTTP et de la base de données, on est très loin du compte.
La comptabilité honnête ressemble à ceci : sur un hyperviseur qui pousse réellement du trafic, l'offload vSwitch récupère typiquement quelques cœurs par machine. Face à ça, il faut poser le coût réel de la carte : le prix du matériel, les 150 W qu'elle consomme (à comparer aux cœurs libérés), et surtout un second système d'exploitation à opérer par serveur. Firmware, mises à jour, droits d'accès, outils de gestion, supervision, procédures de bascule. Le DPU ne réduit pas votre surface d'exploitation, il en ajoute une.
Le calcul se retourne quand le trafic est massif, régulier, et que le coût du cœur est élevé. Il ne se retourne jamais sur un parc de trente hyperviseurs à 20 % de charge réseau.
Pourquoi l'adoption n'a pas pris hors hyperscale
Les faits sont têtus. Gartner classait déjà les SmartNIC comme applicables à « moins de 1 % de l'audience cible » dans son Hype Cycle réseau. VMware avait sorti en 2022 le vSphere Distributed Services Engine, capable de piloter des DPU et d'y faire tourner un pare-feu distribué. Le produit n'a pas trouvé son public, VMware l'a reconnu publiquement. Aujourd'hui, AWS et Azure représentent à eux deux environ les deux tiers des achats de DPU, et l'adoption reste concentrée chez ceux qui louent de la capacité serveur à très grande échelle.
La raison est structurelle, pas conjoncturelle. Un DPU est rentable quand vous écrivez vous-même le plan de données qui tourne dessus, que vous l'amortissez sur des dizaines de milliers de serveurs et que le cœur CPU que vous libérez est directement revendu. AWS a construit Nitro sur exactement ce raisonnement. Un hébergeur qui exploite quelques centaines d'hyperviseurs n'a ni le volume ni l'équipe pour porter un plan de données P4 maison, et se retrouve donc dépendant du logiciel du constructeur, avec un écosystème d'outils, d'API et de documentation que la littérature académique décrit sans complaisance comme incomplet.
Le verdict côté ops
Ce qu'on ferait, et ce qu'on ne ferait pas.
Ça a du sens si vous exploitez du 100 Gb/s ou plus par hyperviseur en trafic soutenu, si vous chiffrez systématiquement l'est-ouest, si vous êtes multi-tenant avec une exigence d'isolation forte entre le plan d'infrastructure et l'hôte, ou si vous montez des infrastructures GPU dédiées à l'IA où le réseau est le goulot d'étranglement et où le DPU arrive de toute façon dans le châssis de référence.
C'est du sur-engineering pour une PME, et sans nuance. Si votre trafic par hôte plafonne à 10 Gb/s, si votre vSwitch consomme moins d'un cœur, si vous n'avez pas d'équipe réseau dédiée : la carte vous coûtera plus cher en temps d'exploitation qu'elle ne vous rapportera en cycles. Le levier utile est ailleurs, et il est gratuit.
La recommandation actionnable, celle qu'on donne systématiquement avant de parler matériel : mesurez d'abord. Sur vos hyperviseurs, isolez la consommation CPU réelle du chemin de données avec perf top et les compteurs par vhost, et comparez-la au coût d'un cœur chez vous. Tant que le plan de données représente moins de 10 % de votre CPU total, la bonne réponse n'est pas un DPU. C'est l'offload matériel déjà présent sur vos cartes actuelles (checksum, GRO, TSO, RSS bien réparti), un tuning TCP sérieux, et éventuellement une politique réseau en eBPF plutôt qu'en iptables. Ces trois chantiers coûtent des jours-homme, pas des dizaines de milliers d'euros de cartes, et ils rendent souvent plus de cycles qu'un DPU mal exploité.
Le jour où ces leviers sont épuisés et que le CPU reste le facteur limitant, alors la question du DPU devient légitime. Pas avant.
Dimensionner une infra sur des mesures plutôt que sur des plaquettes constructeur, arbitrer entre un chantier de tuning et un achat matériel, exploiter le résultat dans la durée : c'est le quotidien des infrastructures que nous opérons dans les datacenters Fullsave de Toulouse et TDF de Bordeaux. Si vous hésitez à investir dans du matériel d'accélération alors que personne n'a mesuré où partent réellement vos cycles, on peut poser le diagnostic avant l'achat.
Sources
- A Survey on Heterogeneous Computing Using SmartNICs and Emerging Data Processing Units : état de l'art académique sur les DPU, leurs modèles de programmation et leurs limites matérielles.
- Profiling a Warehouse-Scale Computer (Google Research, ISCA 2015) : origine du « datacenter tax », mesuré entre 22 et 27 % des cycles sur plus de 20 000 machines.
- Flow Hardware offload with Linux TC flower (documentation Open vSwitch) : mécanique officielle de l'offload OVS via
tc floweretswitchdev. - Accelerating netfilter with hardware offload (LWN.net) : analyse noyau de l'infrastructure d'offload matériel pour netfilter et conntrack.
- AMD Pensando Elba product brief : spécifications du pipeline P4 à 144 MPU et des moteurs d'offload.
- AI could finally see DPUs take off in enterprise networks (The Register) : bilan lucide de l'adoption réelle, échec du VMware Distributed Services Engine et concentration chez les hyperscalers.
