Les SmartNIC dans l'hébergement : bien évaluer l'accélération réseau

Bien cerner le rôle des SmartNIC dans l'hébergement

Le terme SmartNIC Il ne s'agit pas d'un nom de produit normalisé de manière uniforme. Pour la planification de l'hébergement, ce n'est donc pas l'étiquette qui est déterminante, mais la fonction vérifiable dans le chemin de données : quels paquets, règles et tunnels la carte peut-elle traiter, quelles tâches incombent à l'hôte et quel logiciel contrôle ces fonctions ? Une vitesse de port élevée ne répond pas à ces questions.

Une carte réseau classique assure principalement la connexion Ethernet et prend en charge les fonctions de déchargement de base courantes, telles que les sommes de contrôle ou la segmentation. Une SmartNIC élargit ce cadre avec des fonctions de routage spécialisées ou programmables. Il peut s'agir notamment de règles de flux, de fonctions de commutation virtuelles, de SR-IOV, de traitement des tunnels ou de tâches cryptographiques. La disponibilité de ces fonctions dépend toutefois à la fois du modèle, du micrologiciel, du pilote et de l'intégration à la plateforme.

A DPU est généralement dotée d'une architecture plus élaborée : outre le circuit ASIC réseau, elle dispose de ses propres ressources de calcul et peut exploiter un chemin de données d'infrastructure distinct. NVIDIA décrit pour BlueField un mode DPU, dans lequel le système Arm intégré contrôle les ressources NIC et le chemin de données, ainsi qu’un mode NIC, dans lequel la carte se comporte comme un adaptateur vis-à-vis de l’hôte externe. Il en résulte ainsi, selon le mode de fonctionnement, un espace de gestion et de confiance distinct.

Cette classification a des conséquences pratiques sur l'approvisionnement et l'exploitation. Une carte dotée de sa propre logique de calcul n’est pas automatiquement le meilleur choix lorsque seuls des délestages de base simples sont nécessaires. À l’inverse, un chemin d’infrastructure externalisé peut s’avérer utile pour la séparation des clients ou les fonctions de sécurité, mais nécessite alors la maintenance du micrologiciel, des concepts d’accès, une surveillance et des processus de récupération pour des composants supplémentaires.

Même un port 100 GbE ou plus rapide ne permet pas d'accélérer les règles de pare-feu, les superpositions ou le chiffrement. Les facteurs déterminants sont la taille des paquets, le nombre de flux parallèles, l'étendue des règles et la question de savoir si les actions requises peuvent effectivement être mises en œuvre au niveau matériel. Ce n'est que lorsque le processeur du serveur constitue manifestement un goulot d'étranglement dans le chemin des données réseau qu'une liste de fonctionnalités peut se traduire par un gain de capacité potentiel.

Comment le déchargement matériel modifie le chemin des données

Sans déchargement supplémentaire, un paquet arrive d'abord à la carte réseau physique, puis est traité par l'hôte. En fonction de l’architecture, il traverse la pile réseau du noyau, le pare-feu, un pont ou un commutateur virtuel, le routage et, le cas échéant, l’encapsulation pour un réseau superposé. Ce n’est qu’ensuite qu’il atteint une machine virtuelle, un conteneur ou un autre port physique. Chaque étape peut entraîner une consommation de temps CPU et la formation de files d’attente.

Ce chemin devient particulièrement important en cas de nombreux petits paquets, de connexions éphémères ou de politiques client volumineuses. Ce n’est pas seulement le volume de données transférées qui sollicite l’hôte, mais aussi le traitement répété de chaque paquet et de chaque flux. C’est pourquoi accélération du réseau Il ne s'agit pas d'une caractéristique générale d'un serveur, mais d'un allègement ciblé d'un chemin de données précisément identifié.

À l'adresse suivante : Déchargement matériel Les composants de contrôle peuvent transmettre les règles de transfert et de filtrage autorisées à un chemin de données matériel. Le modèle Linux « switchdev » décrit à cet effet le transfert du chemin de données de transfert du noyau vers un commutateur. Les règles qui sont effectivement prises en charge dépendent de la carte concernée, de son pilote et de l'intégration réseau qui la surpasse.

La documentation OVS de la branche de développement 4.0.90 qualifie expressément de « expérimentale » une section distincte consacrée à l'offload matériel Flow. Pour cette configuration précise d'OVS avec DPDK, elle distingue l'offload complet des correspondances et des actions de l'offload partiel, dans lequel seules les correspondances sont déchargées. Cette description ne constitue pas une preuve de compatibilité stable et universelle pour d’autres versions d’OVS, cartes réseau ou plateformes.

Dans la pratique, toute déclaration relative à l'offload doit donc préciser le chemin de données concret : version logicielle utilisée, pilotes, micrologiciel, champs de correspondance et actions. Un commutateur activé ne prouve ni que les flux concernés sont déchargés, ni que les exigences de sécurité et de sémantique réseau sont toujours respectées. Dans le cas du filtrage VLAN, switchdev exige par exemple que le matériel respecte les règles de pontage VLAN et rejette les identifiants VLAN non autorisés. L'offload est donc la mise en œuvre technique des règles existantes, et non un moyen de les contourner.

Dans quels cas les SmartNIC sont-ils utiles dans le domaine de l'hébergement ?

Les SmartNIC sont particulièrement pertinents sur les plateformes de virtualisation comptant de nombreuses machines virtuelles et impliquant des décisions de routage récurrentes. La technologie SR-IOV permet d’attribuer une fonction virtuelle à une machine virtuelle ; dans une architecture « switchdev », les interfaces « Representor » représentent des fonctions physiques ou virtuelles au sein du système d’exploitation. Les règles régissant le trafic entre ces ports peuvent ainsi être implémentées au niveau matériel. L'intérêt de cette solution dépend toutefois des fonctionnalités requises par les machines virtuelles.

Réseaux superposés multi-clients et Microsegmentation constituent un autre angle d'approche. Lorsque de nombreux réseaux clients appliquent de manière répétée des affectations VLAN ou overlay, des règles de contrôle d'accès et d'autres décisions similaires relatives aux flux, un chemin de données matériel adapté peut alléger la charge des processeurs des hôtes. La condition préalable reste que le nombre de règles, les champs de correspondance et les actions soient disponibles dans la carte choisie ainsi que dans le pilote, et que la sémantique des politiques soit entièrement préservée.

Pour OpenShift Container Platform 4.22, Red Hat documente le déchargement matériel pour les nœuds bare metal équipés d’une carte SmartNIC compatible et d’un opérateur réseau SR-IOV actif. Seules la communication de pod à pod et la communication de pod à service ClusterIP avec des pods standard sont prises en charge ; les applications DPDK ne sont pas compatibles avec cette fonctionnalité. De plus, cet avantage se limite aux segments de communication dont les nœuds participants utilisent des SmartNIC compatibles.

Dans le cas de réseaux d'hôtes ou de sites chiffrés, le déchargement IPsec peut prendre en charge certaines tâches ou l'ensemble du processus d'encapsulation, de décapsulation, de chiffrement et de protection contre la relecture. NVIDIA documente à cet effet différents types de déchargement, notamment le « Crypto-offload » et le « Full-offload ». Il n'en résulte toutefois pas une compatibilité universelle : la prise en charge et les limites de performances dépendent du modèle, du micrologiciel et de l'algorithme de cryptographie utilisé.

Un simple serveur d'hébergement web est délibérément choisi comme contre-exemple. S'il fournit principalement un petit nombre de réponses HTTP volumineuses et ne présente aucune charge CPU dans le chemin des paquets, on peut envisager une solution plus spécialisée matériel serveur ne font qu'alourdir les coûts d'exploitation. Il convient tout d'abord de déterminer si le goulot d'étranglement provient de l'application, de la base de données, du stockage ou du réseau. Les SmartNIC ne constituent pas une alternative valable à ce diagnostic.

Comparer les cas d'utilisation d'un point de vue technique

Ce n'est pas la vitesse nominale du port qui détermine si une SmartNIC est utile, mais le chemin de données concret. Son utilisation est particulièrement justifiée lorsque de nombreuses règles récurrentes, un nombre élevé de flux ou des fonctions de superposition et de sécurité mobilisent en permanence du temps de processeur de l'hôte. L'avantage reste dépendant du chemin: Une section accélérée ne profite qu'aux connexions qui s'effectuent effectivement via du matériel compatible et selon des règles prises en charge.

Dans le cas des plateformes de virtualisation, SR-IOV Une approche classique : les fonctions virtuelles sont attribuées à une machine virtuelle, tandis que les interfaces « Representor » du système d'exploitation mappent les ports de ces fonctions. Cela permet de mettre en œuvre au niveau matériel les règles de transfert entre les ports virtuels et physiques dans une architecture orientée « switchdev ». Cela ne remplace toutefois pas la vérification visant à s'assurer que la séparation des mandants souhaitée et le modèle d'exploitation sont bien préservés.

Kubernetes est l'antithèse d'une promesse générale d'accélération. L'intégration documentée d'OpenShift 4.22 s'applique à certains chemins de trafic pris en charge, à des nœuds SmartNIC compatibles et à des conditions préalables liées aux charges de travail. Lorsqu’un nœud capable de déchargement communique avec un nœud standard, ce dernier traite sa partie dans le noyau, limitant ainsi le chemin global. Un déploiement doit donc dans un premier temps prendre en compte un pool de nœuds délimité et des voies de communication réelles.

Dans le cas de réseaux d'hôtes ou de sites cryptés, ces termes doivent être utilisés avec une grande précision. Selon la plateforme, les variantes IPsec documentées vont du « crypto-offload » au « full offload » pour l'encapsulation, la décapsulation, le chiffrement et la protection contre la relecture. Il n'en résulte toutefois aucune garantie générale de débit : le modèle, le micrologiciel, les algorithmes utilisés et les limites propres au produit déterminent quelles opérations sont effectivement déchargées.

Vérifier la compatibilité avant le déploiement

Un projet d'acquisition commence par un état des lieux impartial, et non par l'activation d'options de déchargement. Recensez le modèle exact de la carte, y compris son identifiant PCI, la version du micrologiciel, les pilotes et le noyau. De plus, il faut connaître le mode eSwitch ainsi que la version et la configuration d’Open vSwitch, d’OVN, de l’hyperviseur ou de la plateforme Kubernetes, car la capacité de la carte ne suffit pas à elle seule à garantir une intégration logicielle complète.

La sémantique de règle requise doit être définie au préalable sous la forme d'une description du chemin de données : par exemple, attribution de VLAN, IPv4 ou IPv6, TCP ou UDP, type de tunnel, modification d'en-tête, transfert ou rejet. La documentation expérimentale d’OVS 4.0.90 montre, pour sa configuration DPDK, que l’absence d’actions matérielles peut entraîner un déchargement partiel. Il en résulte, pour toute autre version ou plateforme, uniquement une demande de vérification, et non une garantie quant à l’étendue de ses fonctionnalités.

Les matrices de plateforme sont Preuves de compatibilité liées à la version, aucune déclaration générale concernant une famille de cartes réseau. OpenShift 4.22 mentionne des cartes réseau spécifiques pour son intégration de déchargement matériel, notamment BlueField-2 en mode ConnectX-6. On ne peut en déduire ni la prise en charge d’un autre firmware, ni celle d’un autre mode DPU, ni celle d’une distribution différente. Documentez donc séparément chaque combinaison de matériel, de firmware, de pilote et de version de la plateforme.

Pour Linux-switchdev, il est également essentiel que le matériel respecte la sémantique du réseau logiciel. Dans le cas du filtrage VLAN, par exemple, un commutateur assurant le déchargement doit respecter les règles VLAN du pont et rejeter les identifiants VLAN non autorisés. Cette exigence montre pourquoi les listes de fonctions et la politique de sécurité doivent être vérifiées conjointement : l'accélération ne doit pas entraîner une segmentation du réseau différente.

Comparer les avantages et les inconvénients du SmartNIC par rapport au processeur et aux logiciels

Une SmartNIC n'est qu'une option parmi d'autres lorsque le traitement réseau est limité. Il convient tout d'abord de vérifier si une capacité CPU accrue, un nombre adéquat de files d'attente, le RSS, la répartition des IRQ ou un réglage du noyau permettent déjà de résoudre le goulot d'étranglement. Pour mieux comprendre le fonctionnement des SoftIRQ, des files d'attente et de la répartition des interruptions, consultez l'article consacré à Débit du processeur et du réseau dans l'hébergement principes complémentaires. En l'absence de preuve d'un goulot d'étranglement du réseau, la nécessité d'un matériel spécialisé supplémentaire reste une hypothèse.

DPDK et AF_XDP permettent de raccourcir les chemins logiciels sur les processeurs hôtes, mais nécessitent chacun une conception spécifique de l'architecture et des processeurs. L'affirmation concernant l'interrogation continue ne peut pas s'appliquer de manière générale aux deux approches : dans la documentation OVS-DPDK relative à la configuration décrite, un thread interroge en continu les périphériques DPDK et occupe ainsi entièrement un cœur de processeur. L'affectation NUMA, l'isolation des cœurs ainsi que les versions spécifiques d'OVS et de DPDK restent donc des éléments à prendre en compte dans la conception.

Même une carte réseau de serveur classique peut assurer une décharge suffisante pour les sommes de contrôle, la segmentation ou certaines fonctionnalités de tunnel. Ce choix est approprié lorsqu'il n'est pas nécessaire de disposer de règles de commutation virtuelles complexes, d'une isolation des clients ou de chemins de données de sécurité implémentés en matériel. Les SmartNIC deviennent particulièrement intéressantes lorsque les fonctions requises vont au-delà de ces caractéristiques de base et sont récurrentes à long terme.

Le principe de capacité est simple, mais important : si, sur un hôte, les cœurs de processeur sont sollicités par le traitement des paquets et qu'une partie représentative de ces paquets peut être entièrement déchargée, cela peut libérer de la marge de capacité CPU. Cette marge ne compte toutefois comme capacité utilisable que si ni l’application, ni la mémoire, ni le stockage, ni un plan de secours logiciel ne constituent le prochain goulot d’étranglement. Elle ne découle pas directement du débit de la liaison ou du prix de la carte.

Comparez donc les différentes solutions en vous basant sur le même profil de charge : taille des paquets, débit de connexion, nombre de règles, tunnels, chiffrement et pic de charge prévu. Pour ce faire, mesurez la part du CPU consacrée au chemin de données indépendamment du travail de l'application et vérifiez quels flux s'exécutent réellement au niveau matériel. Un goulot d'étranglement du processeur Le passage par un pare-feu, une couche superposée ou un routage virtuel constitue un motif valable d'évaluation ; une charge système globalement élevée ne l'est pas.

Rendre l'offload visible pendant le fonctionnement

Une fois la mise en place effectuée, il ne suffit pas de considérer qu'une option de déchargement est active. Une preuve de bon fonctionnement fiable établit le lien entre le État du flux avec les compteurs de la carte, les taux de perte et d'erreur, l'utilisation du processeur ainsi qu'un profil de charge similaire au trafic futur. Ce n'est qu'ensemble que ces données permettent de déterminer si les flux pertinents sont effectivement traités par le matériel ou si l'hôte continue d'assumer la majeure partie du cheminement des données.

Pour effectuer cette comparaison, les opérateurs doivent prendre en compte les mêmes tailles de paquets, protocoles, nombres de connexions et politiques avant et après une modification. Un débit purement « gigabit » peut facilement masquer un goulot d'étranglement en cas de petits paquets ou de nombreux flux parallèles. La latence, le temps CPU par hôte impliqué, la charge Softirq, les pertes de file d'attente et la répartition du trafic entre les nœuds et les ports sont tout aussi importants.

Les commandes suivantes ne modifient aucune configuration. La première requête prend en compte aussi bien les périphériques PCI apparaissant comme « contrôleurs Ethernet » que ceux apparaissant comme « contrôleurs réseau ». ethtool -k affiche les fonctionnalités de déchargement proposées ou activées sur le Netdev, mais ne prouve pas de manière exhaustive l'existence d'un déchargement eSwitch, SmartNIC ou de flux. Les autres sorties correspondent également à des données d'inventaire et de configuration, et ne constituent pas la preuve d'une règle spécifique entièrement déchargée.

lspci -nn | grep -Ei 'Ethernet controller|Network controller'
ethtool -k <interface>
ethtool -i <interface>
devlink dev show
ovs-vsctl get Open_vSwitch . other_config

Avec Open vSwitch, il convient notamment de faire la distinction entre l'accélération matérielle configurée et le résultat observé. La documentation de développement d'OVS 4.0.90 qualifie son déchargement matériel des flux d'« expérimental » et ne décrit un déchargement complet ou partiel que pour cette configuration OVS avec DPDK. Pour une utilisation en production, il est donc nécessaire d’analyser les informations de flux et les compteurs matériels conjointement avec les compteurs logiciels de l’hôte.

La surveillance nécessite en outre une référence temporelle. Un test rapide peut confirmer certaines règles, tandis qu'un profil proche de la production peut par la suite déclencher des capacités de table, des chemins de journalisation rares ou des reconfigurations. Il est donc judicieux de consigner les valeurs normales et les anomalies pour chaque modèle de carte, firmware, pilote et version de plateforme. Cela permet ainsi, après les mises à jour, de vérifier si le Chemin des données ou si seule la charge observée a changé.

Dans l'intégration OpenShift 4.22, la vue doit en outre couvrir l'intégralité du chemin de communication. La prise en charge documentée du déchargement matériel ne s'applique qu'à certaines charges de travail et à certains types de communication. Si un nœud compatible communique avec un nœud ne disposant pas d’une SmartNIC adaptée, ce dernier traite sa partie dans le noyau ; les points de mesure sur un seul hôte peuvent alors ne pas refléter le chemin de bout en bout dans son intégralité.

Cas d'erreurs typiques et scénarios de rechute

Le type d'erreur le plus fréquent est transfert incomplet. Un flux peut être identifié au niveau matériel à l'aide de caractéristiques simples, mais doit revenir partiellement ou entièrement dans le chemin logiciel en cas d'action non prise en charge. La documentation expérimentale d’OVS 4.0.90 décrit ce déchargement partiel pour sa configuration DPDK. Il ne s’agit pas d’une affirmation générale valable pour toutes les installations OVS, mais cela met en évidence le point à vérifier lors de chaque intégration concrète.

Le diagnostic commence en suivant le chemin réel : port d'entrée, fonction virtuelle ou représentateur, règle de commutation, traitement du tunnel ou de la politique, et charge de travail cible. Si les compteurs en amont et en aval d'une étape ne concordent pas de manière plausible, cela justifie de vérifier les correspondances, les actions et le repli. Une fonctionnalité activée ne remplace pas cette attribution, car les capacités de la carte ne couvrent pas toutes les combinaisons de règles souhaitées.

Les clusters hétérogènes compliquent la comparaison. Dans OpenShift 4.22, le déchargement matériel n'a lieu que si les pods et services concernés sont affectés à des nœuds équipés d'une SmartNIC compatible. Si un tel chemin rencontre un nœud standard, son traitement s'effectue dans le noyau, ce qui limite la communication globale. Un seul nœud accéléré n'occupe donc pas un chemin de cluster entièrement accéléré.

Une configuration inadaptée des pods ou du réseau peut également empêcher l'effet escompté. Red Hat souligne expressément, concernant la fonctionnalité OpenShift 4.22, que l'activation du déchargement matériel sans pods configurés en conséquence peut nuire au débit des pods. Les opérateurs ne doivent donc pas tenter de remédier à un écart en activant d’autres options, mais doivent d’abord vérifier la connexion de la charge de travail, le mode réseau et les débits réellement atteints.

La capacité de régulation et les écarts de firmware relèvent de la même catégorie d'erreurs : en présence de nombreux clients, de connexions éphémères ou de politiques dynamiques, le volume de flux concerné peut évoluer différemment de ce qui était prévu. Un pilote lié à une version spécifique ou un micrologiciel différent peut également offrir des fonctionnalités différentes de celles prévues pour la combinaison de plateformes. C'est pourquoi les données d'inventaire et les compteurs doivent toujours être archivés avec l'ensemble concret des règles.

A parcours de rechute contrôlé permet de maintenir le système en état de fonctionnement tout en garantissant la possibilité d'effectuer des diagnostics. Cela signifie que le traitement logiciel reste disponible en tant qu'alternative prévue et que les modifications sont déployées progressivement, avec des fenêtres de comparaison et des critères d'abandon clairs. Le « software fallback » n’est pas pour autant automatiquement un défaut, mais peut constituer le traitement attendu d’actions que la voie matérielle choisie ne prend pas entièrement en charge.

Prendre des décisions réalistes en matière d'approvisionnement et d'exploitation

Une décision d'achat commence par l'charge de travail, et non par la vitesse du port ou la désignation du produit. Le recours à du matériel spécialisé se justifie lorsque le traitement récurrent de paquets mobilise de manière avérée du temps CPU : par exemple, dans le cas de nombreux réseaux virtuels, d'ensembles de politiques stables, de trafic en superposition ou d'un chemin de chiffrement défini. En l’absence de cette preuve, un réglage du processeur et des files d’attente, ou une carte réseau classique dotée de fonctions de déchargement de base adaptées, peut constituer la solution la plus simple.

Ensuite, il faut que le Certificat de compatibilité pour la combinaison spécifique : modèle de carte et mode de fonctionnement, micrologiciel, pilotes, noyau, commutateur virtuel ou CNI, ainsi que les fonctions de correspondance et d'action requises. Les accélérateurs d’infrastructure programmables peuvent, par exemple, prendre en charge le déchargement de flux pour des fonctions liées à l’état ou à la session ; cela ne signifie toutefois pas que chaque SmartNIC ou chaque plateforme offre la même fonctionnalité.

La réduction attendue de la charge du processeur ne se traduit par un gain de capacité que si le traitement des paquets constituait le goulot d'étranglement et que les cœurs libérés peuvent être utilisés à bon escient. S'ils sont par exemple affectés à des bases de données, à des « web workers » ou mis en réserve, il s'agit d'un choix architectural et non d'un gain de performance automatique. Le reste de l’équipement du serveur reste donc déterminant ; le processeur, la mémoire vive et le stockage doivent être adaptés à l’application, tout comme le réseau. L’article consacré à matériel serveur ayant une incidence sur les performances dans le domaine de l'hébergement web.

Avec IPsec, le contrôle est particulièrement précis : les variantes d'offload documentées vont de l'offload cryptographique à l'externalisation complète de l'encapsulation, de la décapsulation, du chiffrement et de la protection contre la relecture. La variante utilisable dépend du modèle, de la génération, du micrologiciel et de la configuration cryptographique. Les remarques spécifiques au produit peuvent en outre mentionner des restrictions concernant certaines générations ou certaines bandes passantes ; celles-ci doivent être prises en compte lors de la validation avant le déploiement.

Une DPU ajoute à la décision son propre domaine de gestion et de confiance. En mode BlueField-DPU, le système Arm intégré contrôle les ressources NIC et le chemin d'accès aux données, au lieu que la carte ne fonctionne simplement comme un adaptateur hôte. Cela permet de séparer les tâches d'infrastructure de l'hôte, mais nécessite une approche robuste en matière de droits d'accès, d'images, de mises à jour, de surveillance et de restauration.

D'un point de vue économique, le prix de la carte n'est donc pas le seul élément qui compte. Il faut également prendre en compte la capacité du processeur hôte économisée ou évitée, la durée de vie prévue de la plateforme, ainsi que les coûts supplémentaires liés à la qualification, aux pièces de rechange, à la maintenance du micrologiciel et à la reprise après incident. Une SmartNIC s’avère pertinente lorsque ce calcul repose sur un chemin de données reproductible et un cycle de vie maîtrisable à long terme – et non pas simplement parce qu’un matériel spécialisé semble a priori plus rapide.