English 
简体中文 
繁體中文 
Русский 
Español 
Deutsch 
Français 
Português 
Italiano 
Türkçe 
Polski 
Nederlands 
日本語 
한국어 
Bahasa Indonesia 
Bahasa Melayu 
العربية 
हिन्दी 
Tiếng Việt 
ภาษาไทย 
বাংলা 
اردو 
Kiswahili 
Oʻzbekcha 
አማርኛ 
فارسی SmartNIC et DPU : optique sur adaptateurs programmables
Une unité de traitement de données (DPU) ou un SmartNIC est un NIC doté de ses propres processeurs, mémoire et système d’exploitation, placé entre le bus PCIe du serveur et le réseau. Pour l’optique, rien ne change au niveau de la cage — les mêmes modules et câbles QSFP56/QSFP112/OSFP — mais l’entité qui lit le module, applique la politique et configure le débit et la FEC est désormais un petit ordinateur sur la carte, exécutant souvent une pile Linux ou de type SONiC. Cette page liste les familles de DPU actuelles et leurs ports, explique où réside la gestion des modules, et couvre les conséquences propres à l’optique : alimentation, refroidissement, cages bi-port et fabrics de back-end pour l’IA.
Familles et ports
| Famille | Génération | Ports | Cages | PCIe hôte | Cœurs |
|---|---|---|---|---|---|
| Nvidia BlueField-2 | 2020 | 2 × 25/100G ou 1 × 200G | SFP56 / QSFP56 | Gen 4 x16 | 8 × Arm A72 |
| Nvidia BlueField-3 | 2023 | 2 × 200G ou 1 × 400G ; variantes SuperNIC 400G | QSFP112 / OSFP | Gen 5 x16 | 16 × Arm A78 |
| Nvidia ConnectX-8 SuperNIC | 2024–25 | 1 × 800G ou 2 × 400G | OSFP (bi-port) / QSFP112 | Gen 6 x16 | (NIC + programmabilité limitée) |
| AMD Pensando Elba / Giglio / Salina (400) | 2021–25 | 2 × 100/200G ; 2 × 400G | QSFP56 / QSFP112 | Gen 4/5 x16 | 16 × Arm A72/N1 + pipeline P4 |
| Intel IPU E2000 (Mount Evans) | 2022 | 2 × 100G (200G au total) | QSFP28/56 | Gen 4 x16 | 16 × Arm N1 + P4 |
| Marvell Octeon 10 DPU | 2022 | jusqu’à 400G agrégés | QSFP-DD | Gen 5 | Arm N2 |
| Microsoft/Fungible, Napatech, Xilinx Alveo SN1000 | divers | 2 × 100G | QSFP28 | — | FPGA / MIPS |
Les cages de port et les débits suivent les mêmes règles que pour les NIC classiques (Ports NIC et PCIe).
Où réside la gestion des modules
| Mode | Qui lit le module | Outils |
|---|---|---|
| Mode embarqué / DPU (le côté Arm possède les ports) | l’OS propre du DPU (Ubuntu/DOCA, SONiC-DASH, Linux constructeur) via son pilote | ethtool -m, mlxlink côté Arm ; l’hôte ne voit que des fonctions virtuelles |
| Mode hôte / NIC séparé | pilote de l’hôte, comme sur un ConnectX | ethtool, mlxlink côté hôte (Outils NIC) |
| Mode restreint | le DPU contrôle, l’hôte ne peut pas modifier les réglages de liaison | politique appliquée sur le DPU |
Conséquences : le firmware et les réglages de liaison (débit, FEC, éclatement) se configurent sur le DPU (mlxconfig, outils DOCA, penctl de Pensando) et survivent aux redémarrages de l’hôte ; un module rejeté ou déclassé par le DPU est invisible pour l’administrateur de l’hôte tant que les journaux du DPU n’ont pas été lus. La politique de module elle-même est permissive chez Nvidia et AMD (décode n’importe quel EEPROM), comme sur leurs NIC (Compatibilité optique sur les NIC).
Alimentation et refroidissement
| Élément | Réalité du DPU |
|---|---|
| Puissance de la carte | 75–150 W (BlueField-3 ~150 W avec connecteur auxiliaire) — la carte elle-même est plus chaude que n’importe quel module qu’elle porte |
| Budget de cage | cages QSFP112/OSFP dimensionnées pour des modules de 15–20 W ; vérifier la fiche de la carte |
| Ventilation | les cartes pleine hauteur dans les serveurs GPU partagent une allée chaude avec les GPU ; une température DDM de module de 60–70 °C est normale, alarmes au-delà de 75 (Classes de température) |
| OSFP bi-port | une cage OSFP transporte 2 × 400G ; le module (ou le DAC/AOC bi-port) est un seul dispositif de classe 800G avec son propre dissipateur thermique (OSFP) |
| Choix de l’optique | DAC quand le ToR est à moins de 2 m, sinon AOC ou 400G/800G DR/FR ; les variantes LPO réduisent la puissance du module sur les liaisons courtes (Puissance et consommation) |
Fabrics de back-end pour l’IA
Dans les clusters GPU, un DPU ou SuperNIC par GPU se connecte au fabric de back-end optimisé par rail, InfiniBand ou RoCE Ethernet (Fabrics GPU) :
| Liaison | Optique typique |
|---|---|
| NDR 400G IB par GPU | OSFP bi-port 2 × 400G ; DAC/ACC ≤ 3 m vers le leaf de rail, AOC 3–50 m, optique DR4/SR4 au-delà (Câbles IB) |
| XDR 800G IB / 800G Ethernet par GPU | OSFP 800G bi-port, 2 × DR4 ou SR8 |
| Front-end / stockage | ports 100/200G séparés sur le DPU ou un second NIC |
L’identité et la longueur des câbles sont validées par le fabric manager ; les versions de firmware des modules font partie de la nomenclature qualifiée du cluster (Câblage d’un cluster IA, Fiabilité et surveillance des liaisons).
SONiC et P4 sur la carte
Les DPU exécutant des pipelines SONiC-DASH ou P4 traitent leurs ports comme un petit commutateur : l’éclatement de port, la FEC et le débit se règlent dans la base de configuration du DPU, et l’EEPROM du transceiver apparaît sous les mêmes commandes show interfaces transceiver que sur un commutateur SONiC (Paysage des NOS). Le comportement envers les modules tiers est celui du plugin de la plateforme — permissif.
Dans CodingBox
Un module destiné à un DPU se qualifie comme un module pour un commutateur ou un NIC : facteur de forme et conformité (applications QSFP112/OSFP, 400G/800G dans CMIS), classe de puissance par rapport à la cage, et version de firmware pour la nomenclature du cluster — tout cela lisible sur le banc avant l’installation de la carte (Check transceiver, CMIS).