Résumé

  • 5x9 Networks annonce, pour un Xeon 6780E à 144 cœurs, un forwarder, 64 000 abonnés, 200 Mpps avec ACL et sans QoS hiérarchique, soit 800 Gbit/s avec des paquets de 500 octets. Les 1,6 Tbit/s résultent d'un passage à deux processeurs.
  • Le passage de seize Small VM à une Big VM retire des états répétés du cache. Il améliore la localité, mais agrandit potentiellement l'unité d'exécution, de changement et de panne qui porte les sessions.
  • Le support APRICOT ne publie ni synchronisation d'état, ni injection de panne, ni reprise de sessions, ni mise à niveau mesurée. Le débit et la résilience doivent donc faire l'objet de deux réceptions distinctes.

Le 11 février 2026, dans la session Network Operations d'APRICOT à Jakarta, Branimir Rajtar, CTO et cofondateur de 5x9 Networks, a présenté dix-neuf pages intitulées Getting 1+ Tbps from an x86 server. La démonstration décrit l'évolution d'un Broadband Network Gateway virtualisé. Elle mérite d'être lue comme une pièce d'ingénierie, et non comme une promesse détachée de ses composants.

Un BNG termine les sessions PPPoE ou IPoE des lignes fixes. Il assure le routage de couche 3 et peut porter la QoS par abonné, les ACL, l'AAA et les fonctions d'interception légale. Sa charge n'est donc pas un flux anonyme. Elle associe des paquets à un état dont la continuité doit être préservée lorsqu'un processus, une carte ou un serveur change.

Le point de départ de 5x9 comptait deux Xeon Gold de deuxième génération, dix-huit cœurs chacun, et seize instances de forwarder. Le support attribue à cette configuration 40 Mpps sans QoS hiérarchique et 26 Mpps avec cette fonction. Pour des paquets de 500 octets, il indique respectivement 160 et 100 Gbit/s. L'écart d'environ 35 % ne doit pas devenir une loi générale sur la QoS. Il montre, pour cette version, qu'un service supplémentaire modifie fortement le chiffre de capacité.

Les gains suivants viennent d'une succession de changements. Le support attribue 30 % à du matériel plus récent et à l'application, encore 30 % à l'optimisation de DPDK, du CPU, du PCIe, du BIOS et des cartes réseau, puis 20 % au profilage et à la réécriture de code. Ces pourcentages appartiennent au parcours du produit. Ils ne forment pas une recette universelle, mais localisent le travail : le débit dépend d'une combinaison précise de silicium, mémoire, disposition PCIe, firmware, pilote et logiciel.

Le goulot principal trouvé par 5x9 est le manque en cache et l'attente du processeur. Trop d'objets mémoire occupaient le cache; leurs modifications provoquaient des blocages; la lecture par lignes de cache ramenait plus de données que nécessaire. L'équipe a séparé les structures de lecture et d'écriture, modifié la planification PCIe/DMA et les fonctions de hachage, et annonce une réduction de 90 % de l'empreinte de la table de routage.

La décision Big VM part de ce mécanisme. Les seize Small VM gardaient plusieurs fois la même information dans le cache. Leur réunion dans une seule VM, utilisant un domaine NUMA entier et tous les cœurs du processeur, remplace ces copies par un jeu de travail commun.

Le bénéfice est concret. Une meilleure localité réduit les allers-retours vers la mémoire principale et les temps d'attente. Moins de processus peut aussi signifier moins de tables répliquées et moins de serveurs actifs. Le coût physique n'est pourtant pas aboli : il change de forme et de concentration.

Le résultat courant montré par 5x9 utilise un Xeon 6780E. Intel confirme officiellement 144 cœurs, 108 Mo de cache, jusqu'à 88 lignes PCIe 5.0 et un TDP de 330 W en mode serveur. Ces spécifications ne reproduisent pas le test BNG. Elles rappellent que la mémoire, les emplacements PCIe, les cartes réseau et l'alimentation restent dans le chemin.

Sur ce processeur, le support annonce un seul forwarder, 64 000 abonnés, 200 Mpps avec ACL et sans QoS hiérarchique, 800 Gbit/s pour des paquets de 500 octets et 32 Go de mémoire. Le passage à 1,6 Tbit/s utilise deux processeurs. Dire « sur un serveur » ne permet pas de faire disparaître le second CPU du calcul.

Deux autres limites réduisent la portée du titre. Selon 5x9, les performances commencent à baisser au-delà de 100 000 abonnés, même si 260 000 sont supportés. La QoS hiérarchique pour tous les utilisateurs retranche environ 30 %; le NAT pour tous, entre 30 et 40 %. Ces résultats restent ceux du fournisseur, mais ils suffisent à interdire une assimilation entre la voie à 800 Gbit/s et toutes les fonctions d'un service d'accès.

DPDK et SR-IOV expliquent le raccourcissement du chemin de données. Les Poll Mode Drivers de DPDK accèdent directement aux descripteurs de réception et d'émission et interrogent les files sans attendre les interruptions ordinaires. SR-IOV permet à une fonction physique PCIe d'exposer des fonctions virtuelles. Ni l'un ni l'autre ne décide où l'état d'une session est répliqué, comment une carte est remplacée, combien de sessions repartent à zéro ou quel serveur reprend la charge.

La séparation CUPS a la même limite. Dissocier contrôle et user plane permet de séparer politiques et transfert. Un contrôleur disponible ne prouve pas que les paquets et les sessions survivront à la perte de la Big VM, du CPU, de la voie PCIe, de la carte réseau ou du serveur.

Or le dossier public ne présente aucune topologie de redondance, aucune méthode de synchronisation d'état et aucune réserve N+1. Il ne montre pas d'arrêt volontaire du forwarder, de perte de fonction virtuelle, de carte, de CPU ou de serveur; aucune durée de redémarrage; aucun scénario de mise à niveau et de retour arrière; aucun nombre de sessions perdues ou rétablies; aucun test réunissant paquets variés, QoS, NAT et charge de contrôle; aucun résultat client en production.

Cette absence ne prouve pas que 5x9 ne possède pas ces mécanismes. Elle ne prouve pas non plus que la Big VM serait défaillante. Elle borne la conclusion disponible : le support mesure une voie de performance, pas le comportement du domaine d'état agrandi lorsqu'il doit être remplacé.

Avec les Small VM, la duplication du cache coûte du débit, mais chaque processus peut représenter un ensemble plus petit d'abonnés. Avec la Big VM, le jeu de travail devient plus efficace tandis qu'un plus grand nombre de sessions entre dans la même unité logicielle, matérielle et de maintenance. Des Big VM multiples, des serveurs distincts ou une réplication d'état peuvent réduire cet effet. La présentation ne documente pas cette couche.

Les pouvoirs sont donc séparés. 5x9 maîtrise le code, l'instrumentation, la configuration du test et l'énoncé commercial. Intel et les fournisseurs de cartes maîtrisent le silicium, le firmware et les matrices de compatibilité. L'opérateur d'accès choisit la topologie, les fonctions activées, la capacité de secours, la fenêtre de changement et le seuil de réception pour ses clients. APRICOT publie la discussion, sans certifier le produit.

Le payeur est d'abord cet opérateur. Il finance des processeurs récents, des cartes supportées, les emplacements PCIe, les licences, l'ingénierie, les essais répétés et la capacité inutilisée qui recevra le trafic en cas de panne. Réduire les serveurs actifs peut baisser l'espace et les dépenses, comme le propose 5x9. Le support ne publie ni consommation mesurée ni coût total. Un secours capable de reprendre les mêmes états et fonctions reste une dépense, même s'il attend.

Les abonnés portent le risque résiduel. Une reprise rapide et cohérente peut leur donner un accès moins coûteux et plus flexible. En son absence, un événement logiciel ou matériel peut corréler davantage de sessions. Aucun incident de ce type n'est allégué ici. La question est de savoir si le test d'acceptation l'a rendu mesurable.

La solution de rechange crédible ne rejette pas nécessairement la Big VM. Deux grands forwarders ou plus, répartis sur des serveurs avec réserve N+1 et état synchronisé, peuvent conserver l'avantage du cache. Il faut alors déclarer tailles de paquets, IPv4/IPv6, ACL, QoS, NAT, AAA, nombre de sessions actives et trafic de contrôle; arrêter le forwarder, perdre une carte ou un serveur, mettre à niveau puis revenir en arrière; enfin mesurer les sessions réinitialisées, le temps de reprise et le débit maintenu par le secours.

5x9 conserve d'ailleurs les Small VM pour des sites périphériques ou des populations plus faibles. La taille réduite du domaine de panne peut y valoir le coût du cache. Les solutions ASIC ou white box ne deviennent comparables que si elles subissent le même mélange de service et les mêmes pannes.

L'ASN, les préfixes et BGP restent hors de cette réception. Ils identifient un opérateur et sa route publique. Ils ne certifient ni la continuité de l'état PPPoE/IPoE, ni le NAT, ni la QoS à l'intérieur du BNG. Un RIR ou une conférence ne reçoit aucune autorité sur cette capacité interne parce qu'il voit la ressource de numérotation.

Le mérite technique de la présentation est d'avoir trouvé les contraintes dans les lignes de cache, les objets mémoire, NUMA, PCIe, les cartes et le code. La prochaine contrainte à mesurer est tout aussi matérielle : un forwarder, son état et le serveur qui les porte.

L'économie de cache ne réduit pas d'elle-même le domaine de panne. Les 800 Gbit/s sur un CPU et les 1,6 Tbit/s sur deux sont des résultats fournisseurs utiles, à condition de garder leurs bornes. Ils deviennent une capacité disponible lorsque le même service franchit une panne et un changement avec une reprise mesurée.

Sources