Évolution des performances de la table de routage sous Linux

Vincent Bernat 9 novembre 2026

Dans des articles précédents, j’ai expliqué comment le noyau Linux gérait les tables de routage IPv4 et IPv6. J’ai suivi l’évolution des performances de recherche entre Linux 2.6.32 et 4.16 pour IPv4, avec l’impact des mitigations contre Meltdown et Spectre, ainsi qu’entre Linux 2.6.39 et 4.18 pour IPv6. Cet article met à jour ces chiffres jusqu’à Linux 7.3 et expose les responsables de chaque régression ! 🕵️‍♂️

J’ai mesuré les performances sur un AMD EPYC 8024P, un processeur Zen 4c loué à Scaleway tournant à 2,4 GHz sans le mode turbo. J’ai compilé les noyaux avec GCC 10.2 : cette version convient à la fois aux noyaux les plus anciens et aux plus récents.

IPv6#

J’ai testé quatre scénarios :

une vue complète et récente avec environ 260 000 préfixes ;
une vue complète datant de 2017 avec environ 40 000 préfixes ;
un ensemble de 40 000 préfixes /48 organisés de façon à obtenir un résultat deux fois sur trois ;
un ensemble de 40 000 préfixes /128 choisis aléatoirement de façon à ce qu’une recherche sur 400 réussisse.

Pour Linux 4.15, Wei Wang a remplacé le verrou par du RCU et un verrou tournant dans le commit 66f5d6ce53e6. Pour Linux 4.18, David Ahern a amélioré les structures de données impliquées dans la recherche. Pour Linux 5.9, Brian Vazquez a retiré des appels indirects coûteux dans le commit 55cced4f813b.

L’importante régression de 200 ns introduite dans Linux 6.5 a balayé toutes ces améliorations. Cette version implémente une mitigation pour la vulnérabilité « Speculative Return Stack Overflow », affectant les processeurs AMD, dans le commit fb3bd914b3ec. Cette mitigation ajoute environ 20 cycles à chaque retour de fonction. Elle a ensuite été portée sur des noyaux plus anciens (5.10, 5.15, 6.1 et 6.4). Pour rendre les résultats plus lisibles, je l’ai désactivée pour ces versions via l’option spec_rstack_overflow=off.

Vous pouvez consulter les vulnérabilités impactant votre processeur et les mitigations appliquées avec la commande lscpu. Certaines mitigations dépendent du microcode et du micrologiciel¹.

$ lscpu | grep '^Vuln'
Vulnerability Gather data sampling:      Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit:             Not affected
Vulnerability L1tf:                      Not affected
Vulnerability Mds:                       Not affected
Vulnerability Meltdown:                  Not affected
Vulnerability Mmio stale data:           Not affected
Vulnerability Reg file data sampling:    Not affected
Vulnerability Retbleed:                  Not affected
Vulnerability Spec rstack overflow:      Mitigation; Safe RET
Vulnerability Spec store bypass:         Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:                Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:                Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP always-on; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Vulnerability Srbds:                     Not affected
Vulnerability Tsa:                       Vulnerable: Clear CPU buffers attempted, no microcode
Vulnerability Tsx async abort:           Not affected
Vulnerability Vmscape:                   Mitigation; IBPB before exit to userspace

IPv4#

J’ai testé trois scénarios :

une vue complète et récente avec plus de 1 000 000 de préfixes ;
un sous-ensemble d’une vue complète de 2017 avec 500 000 préfixes ;
un ensemble de 500 000 préfixes /32 contigus.

L’impact de 30 ns dû à la mitigation de SRSO dans Linux 6.5 est plus petit que pour IPv6 car la recherche d’une route IPv4 traverse moins de fonctions : environ 4 pour IPv4 et 25 pour IPv6.

Dans Linux 5.11, j’ai introduit une régression dans le commit c0c5a60f0f13 après avoir corrigé le comportement de net.ipv4.conf.all.ignore_routes_with_linkdown² ! En conséquence, la fonction ip_ignore_linkdown() dépense 5 cycles supplémentaires pour répondre car elle doit suivre trois pointeurs supplémentaires. La fonction fib_lookup() l’appelle dans le code suivant :

if (ip_ignore_linkdown(nhc->nhc_dev) &&
    nhc->nhc_flags & RTNH_F_LINKDOWN &&
    !(fib_flags & FIB_LOOKUP_IGNORE_LINKSTATE))
    return false;

En changeant l’ordre des conditions, nous pouvons éviter l’appel à ip_ignore_linkdown() dans la majorité des cas où le lien n’est pas inactif :

if (nhc->nhc_flags & RTNH_F_LINKDOWN &&
    !(fib_flags & FIB_LOOKUP_IGNORE_LINKSTATE) &&
    ip_ignore_linkdown(nhc->nhc_dev))
    return false;

Voici la distribution des temps de recherche avant d’appliquer ce correctif au-dessus de net-next³ :

min=128 max=4657 count=994104 95th=134 90th=133 50th=132 mad=0
    value │                         ┊                            count
      128 │                                                        120
      129 │                                                       2232
      130 │▒                                                     25224
      131 │▒▒▒▒▒▒▒▒▒▒▒▒▒░                                       264264
      132 │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░░░             516480
      133 │▒▒▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░      126864
      134 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░      21624

La nuance de gris la plus claire représente la fonction de répartition. Après l’application du correctif, la médiane s’est améliorée de 132 à 126 cycles⁴ :

min=124 max=208839 count=994104 95th=128 90th=127 50th=126 mad=0
    value │                         ┊                            count
      124 │                                                        576
      125 │▒▒                                                    49440
      126 │▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░                      584904
      127 │▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░       284592
      128 │▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░      45288

Impact des mitigations#

Pour réduire l’impact des mitigations, vous pouvez les désactiver avec mitigations=off, n’en désactiver qu’une seule avec spec_rstack_overflow=off ou vous protéger à partir de Linux 6.17 d’un ensemble de vecteurs d’attaque avec mitigations=auto,no_user_kernel.

L’impact varie fortement selon le processeur. Par exemple, sur un Xeon W-2295, un processeur Intel de 2020 orienté bureautique, l’impact des mitigations est de seulement quelques cycles pour IPv4 et moins de 3 % pour IPv6. La mitigation qui ralentit le plus est celle pour la vulnérabilité « Indirect Target Selection » qui a été corrigée avec l’architecture Sapphire Rapids.

En mettant de côté les régressions introduites par les mitigations des attaques contre les processeurs, les performances d’IPv4 ont décliné lentement tandis que celles d’IPv6 se sont améliorées avant de se stabiliser. Si les performances de routage sont importantes, vous avez plusieurs possibilités :

choisir un processeur différent tel qu’un AMD Zen 5, un Xeon de quatrième génération ou peut-être un ARM Neoverse V2 ;
désactiver partiellement ou totalement les mitigations ;
contourner le routage avec XDP/eBPF⁵ ;
déléguer le routage à la carte réseau.