Eric Dumazet: les « petites files d’attente » dans l’économie des serveurs Linux

Résumé

• Eric Dumazet assure actuellement la maintenance du réseau générique, de TCP et des sockets dans Linux, et siège au comité de pilotage technique de la Netdev Foundation. Ces responsabilités sont partagées entre plusieurs mainteneurs et réviseurs, ce qui signifie qu’il détient une responsabilité d’intégration importante, et non un monopole personnel sur le réseau Linux.
• Sa contribution la plus claire et la plus facile à isoler est l’introduction, en 2012, de TCP Small Queues par une série de correctifs. TSQ vise à empêcher un flux TCP unique de pousser trop de données dans la file d’attente du périphérique située sous la couche transport. Il lie le quota local de file d’attente de la socket aux événements d’achèvement des paquets, réduisant ainsi la latence d’envoi et la pression mémoire, sans pour autant éliminer toutes les files d’attente sur le chemin réseau.
• Dumazet a ensuite participé à la création de l’ordonnanceursch_fqet fait progresser le pacing interne de TCP, faisant du « moment d’envoi » une variable de contrôle explicite. La file d’attente équitable distingue les flux, le pacing répartit les paquets dans le temps. Ces mécanismes sous-tendent plusieurs conceptions de contrôle de congestion, y compris les scénarios d’utilisation de BBR, mais BBR a des auteurs et une histoire d’évolution distincts et ne peut être attribué à Dumazet comme une invention personnelle.
• Ses travaux publics récents relient en outre la disposition des structures, le trafic de lignes de cache et le coût d’état par socket à l’efficacité à l’échelle d’un parc de machines. La conclusion plus large est la suivante: le réseau Linux est également un système de comptabilité du CPU, de la mémoire, de la profondeur des files d’attente et du temps. Il peut avoir des effets économiques significatifs sur les infrastructures, mais les preuves publiques ne permettent pas de fournir des montants précis ou des pourcentages de performance universels.

Un serveur à haut débit peut encore être ralenti par ses propres paquets

La meilleure introduction n’est pas un titre d’entreprise, mais une file d’attente d’envoi à l’intérieur d’un hôte Linux. L’application a écrit des données, TCP estime qu’il peut continuer à envoyer et le noyau a remis les données aux couches inférieures. Pour l’application, ces octets semblent déjà partis; en réalité, ils peuvent encore être en attente sur la même machine.

La courbe de débit reste belle, de sorte que le problème est facile à ignorer. Les requêtes interactives peuvent être placées derrière de gros transferts de fichiers, les tampons continuent d’occuper de la mémoire, et l’écart se creuse entre ce que TCP comprend comme « données en transit sur le réseau » et ce qui n’est que « des données bloquées dans les files d’attente inférieures de la machine ». TCP Small Queues a modifié cette relation: il limite la quantité de données qu’une socket unique peut remettre aux couches inférieures et ne restaure son droit d’envoi qu’après que le périphérique a réellement terminé la transmission.

Les documents publics détaillent le travail d’ingénierie sans combler les lacunes biographiques

Les preuves les plus fiables sur Dumazet proviennent de Linux lui-même: le fichierMAINTAINERS, les discussions sur les correctifs, la documentation officielle, les conférences techniques et les revues publiques de longue durée. Ces documents confirment ses responsabilités actuelles en matière de réseau générique, de TCP et de sockets, ainsi que son rôle au comité de pilotage technique de la Netdev Foundation et l’affiliation à Google indiquée par l’adresse de messagerie du mainteneur.

Ces documents ne fournissent pas une biographie personnelle complète, un poste actuel chez Google confirmé de manière indépendante, des statistiques complètes sur les correctifs et les revues, ni la répartition précise de son temps. Combler les lacunes avec des détails « plausibles » affaiblirait au contraire le reportage. Ce profil repose donc sur des objets directement vérifiables: les mécanismes, les choix de conception, les avis de revue et les explications publiques.

La valeur de Dumazet ne repose pas sur une marque personnelle, mais sur la manière dont une responsabilité technique devient une infrastructure publique après avoir été modifiée, testée et déployée par d’autres.

Le statut de mainteneur le rapproche des décisions clés sans le placer au-dessus de la communauté

Au 4 août 2026, les enregistrements actuels de Linux désignent Dumazet comme mainteneur du réseau générique, de TCP et des sockets. Un mainteneur peut demander aux auteurs de reconcevoir une interface, refuser une charge de support impossible à assumer à long terme, intégrer des modifications ayant passé la revue et porter la responsabilité de l’intégration lorsque le sous-système est soumis à la branche principale.

Le même document montre clairement que le pouvoir est partagé. David S. Miller, Jakub Kicinski et Paolo Abeni sont coresponsables du réseau générique; Neal Cardwell partage avec Dumazet la responsabilité de TCP; d’autres réviseurs et spécialistes interviennent selon le contenu du correctif. Le code doit en outre passer par les couches d’architecture, les pilotes, la sécurité, les tests automatisés, les branches stables et le processus final de la branche principale. L’influence de Dumazet est grande précisément parce qu’elle est contrainte par ce système distribué.

Quand le nombre de connexions augmente, les détails de Linux deviennent une question d’économie des serveurs

Sur un petit hôte, quelques octets de plus par socket ou un défaut de cache supplémentaire peuvent être presque imperceptibles. Sur un serveur hébergeant des centaines de milliers de connexions, le même coût est amplifié de façon répétée et finit par concurrencer le calcul applicatif, la capacité mémoire et la consommation d’énergie.

« Économie des serveurs » ne signifie pas qu’il existe un montant public et vérifiable d’économies. Cela décrit la manière dont les coûts techniques se traduisent en résultats de parc: combien de connexions un hôte peut-il héberger, quelle part du CPU est consommée par le traitement réseau, combien de mémoire l’état des sockets consomme-t-il et combien d’objectifs de latence sont manqués à cause des files d’attente locales. Les distributions et les opérateurs décident toujours de la version du noyau, de la qdisc, du contrôle de congestion et de la configuration de la NIC; Dumazet modifie le point de départ qu’ils partagent.

Derrière l’apparente simplicité de TCP se cache un grand livre de ressources complexe

On résume souvent TCP à un flux d’octets fiable. Pour tenir cette promesse, le noyau doit décider combien de données peuvent rester sans accusé de réception, quand retransmettre, comment comptabiliser la mémoire, comment ordonnancer les paquets et comment des milliers de sockets partagent le CPU et les files d’attente des périphériques.

Ainsi, une implémentation TCP peut être « correcte sur le plan protocolaire » mais « inefficace sur le plan système »: files d’attente locales trop profondes, rafales trop importantes, contention sur l’état partagé ou disposition de structures gaspillant le cache. Le thème commun des travaux publics de Dumazet est une logique de comptabilité des ressources. Les octets sont inscrits dans le compte de la socket, les événements d’achèvement rendent du quota, le moment d’envoi est explicitement calculé, les flux sont distingués, les champs chauds et froids sont réorganisés.

L’objectif n’est pas de refuser la mise en mémoire tampon, mais d’éviter qu’un second réseau non géré se forme à l’intérieur de l’hôte.

Avant TSQ, l’expéditeur pouvait créer un arriéré qu’il ne maîtrisait plus

TCP pouvait autrefois remettre de grandes quantités de données à la qdisc et à la couche pilote. Même si la fenêtre de congestion était raisonnable du point de vue de bout en bout, des files d’attente locales profondes pouvaient encore accumuler de nombreux paquets sous la couche transport. Lorsqu’un flux plus urgent arrivait, l’application ne pouvait plus retirer les données déjà transmises aux couches inférieures.

Cet arriéré affaiblissait la rétroaction. TCP s’appuie sur les accusés de réception distants pour comprendre la progression du chemin, mais une partie des données n’avait même pas quitté l’hôte. L’arriéré consommait aussi de la mémoire, surtout lorsque de nombreux flux actifs faisaient la même chose. Le système devait empêcher chaque socket de traiter les files d’attente inférieures comme un entrepôt illimité tout en maintenant le débit.

Les correctifs TSQ de 2012 ont rendu à la socket son budget de file d’attente locale

Les correctifs TCP Small Queues de 2012 ont fixé pour chaque socket un quota de données mises en file sous TCP. Une fois le quota épuisé, la socket suspend la transmission vers le bas; elle ne redevient éligible à l’envoi qu’après l’achèvement des paquets déjà en file.

L’idée du mécanisme n’est pas compliquée: enregistrer les octets en file localement et traiter l’achèvement comme la preuve que les couches inférieures ont libéré de la capacité. Son importance réside dans le fait de ramener le point de contrôle à la couche transport qui connaît réellement le flux. Pour maintenir le lien occupé, une socket unique n’a plus besoin d’accumuler à l’avance de grandes quantités de données. Les applications héritent de cette règle de noyau plus stricte sans modification.

Les événements d’achèvement des paquets deviennent une rétroaction efficace à l’intérieur de l’hôte

L’achèvement des paquets ressemble à une étape de récupération de ressources. TSQ en a fait un signal de contrôle: les couches inférieures ont progressé, la socket peut continuer à envoyer.

Cette rétroaction locale résout un problème différent des accusés de réception distants. Les ACK distants indiquent la progression sur le chemin, l’achèvement local indique la progression sous TCP; les statistiques de la qdisc, du pilote et de la NIC décrivent d’autres états. Aucun signal unique ne peut expliquer la situation globale. La contribution de TSQ est de rendre l’un de ces signaux suffisant pour limiter la mise en file excessive sur la machine, sans remplacer le contrôle de congestion de bout en bout.

TSQ traite une source de bufferbloat, pas toutes les files d’attente

Décrire TSQ comme un correctif qui « élimine le bufferbloat » serait exagéré. Il cible l’arriéré local sous TCP du côté de l’expéditeur. La qdisc, le pilote, la NIC, le réseau d’accès, les routeurs, les commutateurs et le côté récepteur peuvent encore mettre en file.

Une formulation plus précise est plus utile: TSQ limite la capacité d’une socket TCP à créer de grandes files d’attente cachées à l’intérieur de l’hôte, ce qui peut réduire la latence et la pression mémoire et rapprocher l’état TCP de la progression réelle du matériel. Il ne remplace ni la gestion active des files d’attente, ni des files d’attente de périphérique raisonnables, ni le contrôle de congestion de bout en bout.

Seuils, délestage et charge déterminent les gains réels de TSQ

L’effet réel de TSQ dépend des seuils locaux, de la taille des paquets, du comportement de la qdisc, des files d’attente du périphérique, du délestage de segmentation et de la composition du trafic. Un service interactif avec de nombreuses connexions courtes n’obtiendra pas les mêmes résultats qu’une tâche de copie massive et continue.

L’implémentation actuelle a également dépassé la forme des correctifs initiaux de 2012. Des contributeurs ultérieurs ont modifié les seuils, les interactions et les cas limites. Le reportage peut attribuer clairement le point de départ à Dumazet tout en reconnaissant que le mécanisme actuel en production est le fruit d’une maintenance collective sur de nombreuses années.

sch_fqsépare les flux et introduit le « temps » dans l’ordonnancement

Dumazet a publié en 2013 un travail sur l’ordonnanceur Linuxsch_fq. Il maintient un état par flux et utilise des structures ordonnées dans le temps pour libérer les paquets à l’instant d’envoi prévu. Les nouveaux flux peuvent être servis assez rapidement, tandis que les flux déjà soumis au pacing attendent leur propre créneau.

Il résout deux problèmes liés: éviter qu’un gros flux monopolise la file d’attente locale du périphérique et faire en sorte que l’instant d’envoi calculé par TCP soit réellement exécuté.sch_fqne garantit pas que chaque application obtienne le même résultat; il fournit une politique de service local plus disciplinée et la face d’exécution du pacing.

La file d’attente équitable est une politique, pas la promesse d’une égalité parfaite des résultats

Le mot « équitable » est facile à comprendre trop fortement. Qu’une file distingue différents flux ne signifie pas que les performances de toutes les applications soient identiques. La taille des paquets, le chemin réseau, le récepteur distant, le contrôle de congestion, le délestage et le nombre de connexions modifient tous le résultat.

L’identité de flux est elle-même un choix de politique: une application peut ouvrir de nombreuses connexions, une autre une seule.sch_fqpeut réduire le monopole local d’un flux unique, mais il ne décide pas pour l’opérateur de l’équité entre utilisateurs, entreprises et métiers. C’est un outil d’ordonnancement, pas une preuve d’équité au sens social.

Le pacing convertit une estimation de débit en une suite d’instants d’envoi

Un algorithme de contrôle de congestion peut calculer un débit moyen correct tout en libérant d’un coup tout un lot de données. La moyenne est juste, mais des rafales sur de courtes périodes créent quand même des files d’attente.

Le pacing traite la forme de l’envoi: répartir les paquets dans le temps. Il peut rendre les files d’attente plus stables, faciliter la coexistence des flux et exprimer plus fidèlement l’intention du modèle de congestion. L’implémentation dépend toutefois des horodatages, des minuteries, de la qdisc, de la segmentation et du comportement de la NIC. Un débit dans le logiciel n’a de sens que s’il devient finalement un espacement réel des paquets sur le câble.

Le pacing et le contrôle de congestion traitent des parties différentes

Le contrôle de congestion décide de l’agressivité de l’expéditeur; le pacing décide du moment où les données déjà autorisées partent. Un bon modèle de congestion peut être ruiné par des rafales, et un pacing parfait peut exécuter un mauvais débit.

Le travail de Dumazet sur le pacing appartient donc à la couche d’infrastructure. Il donne à plusieurs algorithmes de contrôle de congestion la capacité de transformer un débit en temps. La conception et la paternité d’un modèle précis doivent être attribuées à ses propres ingénieurs.

BBR repose sur l’infrastructure de pacing, mais a des auteurs et une histoire de conception distincts

BBR est souvent associé à Dumazet parce qu’il dépend fortement du pacing et parce qu’il est apparu dans l’environnement d’ingénierie TCP de Google. Cette association ne signifie pas qu’il a inventé BBR à lui seul. BBR a des auteurs, un modèle et une évolution de versions clairement distincts.

Un récit plus exact met d’ailleurs mieux en valeur sa contribution: files d’attente, pacing, comptabilité des sockets et observabilité ont fourni les conditions d’exécution des algorithmes ultérieurs. Dumazet doit recevoir une attribution claire au niveau de l’infrastructure, tandis que le travail de Neal Cardwell et des autres contributeurs au contrôle de congestion doit être préservé.

TSO économise du CPU mais peut recréer les rafales que le pacing veut éviter

Le délestage de segmentation TCP (TSO) permet au noyau de remettre de grands segments à la NIC, qui les découpe ensuite en paquets au débit de la ligne. Il réduit nettement le coût CPU par paquet, mais ajoute une couche matérielle entre l’instant d’envoi logiciel et l’émission réelle sur le câble.

Si les grands segments sont libérés d’un coup, la NIC peut encore former des rafales. TSQ, la qdisc, TSO, le pilote et le matériel doivent être conçus comme un seul système. Une optimisation avantageuse sur le plan du CPU peut être nuisible sur le plan de la latence si elle n’est pas coordonnée avec la forme du trafic.

Pacing quantum, horodatages et NIC doivent décrire la même réalité

Le noyau utilise le quantum d’ordonnancement, la précision des minuteries, les horodatages des paquets, l’unité de délestage et les files d’attente matérielles. Si le quantum est trop grand, les rafales subsistent; s’il est trop petit, le coût d’ordonnancement augmente; si la NIC s’exécute à une granularité différente, le comportement sur le câble s’écarte du modèle logiciel.

La qdisc n’est donc pas un défaut sans importance, mais un élément de la conception capacité-latence. Les développeurs doivent mesurer tout le chemin d’envoi; un banc d’essai qui se contente du nom de l’algorithme de contrôle de congestion ou du débit de la liaison passe à côté des nombreux mécanismes qui déterminent réellement le résultat.

Le pacing interne de TCP réduit la dépendance à une qdisc particulière

En 2017, Dumazet a publié un travail sur le pacing interne de TCP. TCP a acquis une capacité plus directe à retarder l’envoi en fonction de son propre état de débit et de ses minuteries, sans dépendre entièrement de la présence attendue d’une qdisc particulière.

La qdisc n’a pas perdu son utilité: elle continue d’assurer l’ordre et la politique. Le changement consiste seulement à rapprocher une partie de la logique de contrôle de la couche transport qui possède réellement l’intention d’envoi. Le calendrier final reste réalisé conjointement par TCP, la qdisc, le pilote et la NIC.

La qdisc reste un choix de l’opérateur et modifie directement les performances du service

Linux propose plusieurs disciplines de file d’attente pour répondre à différents objectifs.sch_fqest étroitement lié au pacing; FQ-CoDel combine une file par flux et une gestion active des files d’attente. Ce ne sont pas le même algorithme.

Différentes distributions, images cloud, équipements réseau et hôtes de conteneurs peuvent utiliser différentes valeurs par défaut, et le délestage matériel modifie encore le lieu d’exécution. Le noyau amont fournit les capacités, les opérateurs décident si ces capacités agissent réellement dans les services.

Quelques octets de plus par socket peuvent finir par limiter tout un parc

Chaque connexion conserve des numéros de séquence, des minuteries, un état de congestion, des files d’envoi et de réception et des champs de comptabilité. Lorsque le nombre de connexions est assez grand, chaque octet est multiplié et chaque champ fréquemment utilisé devient une charge pour le cache.

Réduire la mémoire par socket peut accroître la densité de connexions; une meilleure disposition peut réduire les défauts de cache et le trafic de cohérence entre CPU. C’est le lien le plus fiable entre le travail de Dumazet et l’économie des serveurs, mais il ne permet pas d’établir un taux d’économie universel, ni d’attribuer une valeur à une contribution individuelle.

Quand chaque paquet la touche, une ligne de cache devient une infrastructure

Le processeur déplace des lignes de cache entières, et non des champs isolés du code source. Mélanger des données chaudes et des champs froids fait circuler en boucle des octets inutiles; deux CPU qui modifient des champs différents mais situés sur la même ligne de cache peuvent créer de la contention de cohérence.

Les travaux récents de Dumazet adoptent ce point de vue physique. Séparer les points chauds des points froids vise à réduire le trafic mémoire qui croît avec le nombre de paquets et de sockets. L’effet dépend du CPU et de la charge; le profil d’un parc ne peut pas devenir une règle pour tous les systèmes.

Les travaux de 2024 sur les structures de données montrent une ingénierie de performance mature

La présentation publique de 2024 sur les structures de données réorganisées de manière auxiliaire part du profilage: quels champs sont les plus souvent consultés, quelles lignes de cache circulent le plus, quelles structures occupent la mémoire principale. Les outils peuvent proposer des suggestions de disposition, mais ne remplacent pas le jugement humain sur l’alignement, les verrous, la compatibilité et le coût de maintenance.

Les gains d’une infrastructure mature proviennent souvent de détails discrets: un défaut de cache de moins, une ligne de cache qui ne migre plus sans cesse, ou un champ qui n’est plus consulté trop souvent. Cela n’a pas le nom voyant d’un nouvel algorithme de congestion, mais peut décider de l’efficacité à l’échelle réelle.

Un profil hyperscale est une preuve solide, mais une science publique incomplète

Les grands opérateurs peuvent observer des échelles de connexions, des combinaisons de trafic et de nouvelles NIC difficiles à reproduire dans un laboratoire ordinaire. L’affiliation à Google donne à Dumazet accès à ce type de preuves de production, car de nombreux petits coûts ne se manifestent qu’à très grande échelle.

Les mêmes conditions tracent aussi la frontière de la preuve publique: les charges internes, les outils et les données complètes ne sont pas toujours publiables. Les présentations de conférence peuvent expliquer la méthode et la direction sans fournir toutes les entrées reproductibles. La démarche raisonnable n’est pas de rejeter ces éléments, mais d’en borner les conclusions et de convertir autant que possible les charges réelles en tests publics et en intégration continue.

Les verrous et les files du côté réception appartiennent au même grand livre de ressources

L’article se concentre sur le chemin d’envoi, mais les travaux plus larges de Dumazet touchent aussi aux sockets et au chemin de réception. Les paquets entrants doivent être interrogés, alloués, classés, mis en file et livrés entre CPU; à haut débit de paquets, les files partagées et les verrous deviennent eux-mêmes des goulots d’étranglement.

Linux évolue par traitement par lots, déplacement du travail et réduction de la contention. La logique est la même que celle de TSQ: fournir assez de coordination pour rester correct, sans que la coordination elle-même ne consomme la puissance de calcul dont les applications ont besoin. Il est difficile d’établir de manière fiable une liste complète des contributions; des mécanismes représentatifs rendent mieux compte de cette méthode continue.

Le traitement par lots améliore le débit et modifie en même temps la relation entre latence et flux

Traiter plusieurs paquets ou achèvements à la fois permet d’amortir les verrous, les appels de fonction et les déplacements de cache. NAPI, les pilotes, le délestage et la gestion des files reposent sur cette méthode.

Mais un lot doit attendre de se former et peut aussi entrer dans la couche suivante sous forme de rafale. Plus le lot est grand, meilleure est l’amortisation, plus le premier élément attend et plus un flux unique peut occuper longtemps les ressources. TSQ, la file équitable et le pacing ne s’opposent pas au traitement par lots; ils lui fixent des limites.

Les performances finales de TCP sous Linux proviennent d’un ensemble de couches qui peuvent se neutraliser

Le contrôle de congestion exprime l’intention d’envoi, TCP génère les paquets et les horodatages, TSQ limite l’arriéré local, la qdisc ordonne, TSO agrège, le pilote mappe les tampons, la NIC émet les paquets, puis le réseau ajoute ses propres files et pertes.

Toute amélioration d’une couche peut être annulée dans la suivante. Un pacing précis peut être neutralisé par un délestage à granularité grossière, une qdisc à faible latence peut être submergée par une mise en file excessive, et une structure compacte peut être ralentie par un nouveau verrou. La valeur systémique de Dumazet tient au traitement de ces coutures, et non à l’optimisation d’un algorithme isolé.

La revue publique des correctifs transforme une optimisation locale en infrastructure partagée

Une modification de performance n’est d’abord qu’une affirmation: c’est plus rapide, plus économe en mémoire ou à latence plus faible. Pour entrer dans Linux, elle doit être publiquement mise à l’épreuve sur netdev: les mesures sont-elles fiables, l’interface est-elle générale, des architectures rares vont-elles casser, les tests sont-ils suffisants, qui assurera la maintenance à l’avenir.

Un mainteneur peut demander de scinder un correctif, refuser une abstraction propre à un fournisseur ou reporter une modification qui n’est pas prête. C’est plus lent qu’un correctif interne, mais cela traduit les besoins d’une entreprise en capacité publique du noyau. L’autorité de Dumazet repose en grande partie sur ce jugement de long terme: non seulement cela fonctionne-t-il aujourd’hui, mais sera-ce supportable à l’avenir.

netetnet-nextséparent les corrections urgentes des fonctionnalités futures

Les corrections réseau passent généralement parnet, tandis que les nouvelles fonctionnalités et les refactorisations passent parnet-next. Cette séparation évite que le chemin de maintenance urgent soit pollué par les grands changements de la prochaine version.

La frontière exige toujours du jugement. Une « correction » peut modifier le comportement, et une nouvelle fonctionnalité peut exposer un ancien défaut. Les mainteneurs demandent de scinder les séries afin que les corrections rétroportables et les refactorisations futures soient examinées séparément. Une date de sortie commerciale ne remplace pas la maturité technique.

Les revues, les refus et les reconceptions n’apparaissent pas dans le nombre de commits

Les statistiques de commits ne montrent que le code intégré; elles ne mesurent ni le fardeau futur évité par un refus, ni la valeur créée par un avis de revue qui oblige à refaire une interface. Intégrer un correctif signifie assumer la responsabilité de l’intégration, pas que le mainteneur a inventé l’idée du correctif.

Le profil de Dumazet doit donc à la fois énumérer les travaux attribuables avec certitude — TSQ,sch_fq, le pacing et les structures de données — et reconnaître que la maintenance de long terme ne peut pas être expliquée par un classement de commits. Tout le code qu’il intègre ne doit pas automatiquement devenir son invention personnelle.

Les tests peuvent réduire le risque, sans représenter toutes les machines que Linux rencontrera

Les systèmes de construction, les autotests du noyau, KUnit, syzbot, les laboratoires de pilotes et les déploiements en aval détectent de nombreuses régressions. Ils ne peuvent toujours pas couvrir toutes les architectures de CPU, NIC, qdisc, combinaisons de protocoles et charges de travail.

Une modification bénéfique dans un scénario hyperscale peut nuire à de rares appareils embarqués. Les mainteneurs doivent encore tenir compte de la compatibilité, des retours en arrière et des chemins non couverts. Les tests renforcent la gouvernance publique, sans éliminer l’expérience et le jugement.

Le rétroport stable est une seconde décision après l’intégration dans la branche principale

Un correctif intégré dans la branche principale n’entre pas automatiquement dans tous les noyaux stables. Le mainteneur stable évalue s’il corrige un problème réel, s’il est assez petit et s’il introduit de nouvelles dépendances ou de nouveaux comportements. Les distributions choisissent ensuite à nouveau.

Les modifications de performance sont particulièrement sensibles au contexte. Un correctif rétroporté sans le code environnant peut créer de nouvelles régressions. L’impact sur l’infrastructure se produit donc par étapes: amont, stable, distribution, déploiement cloud et configuration opérationnelle. Personne ne contrôle toute la chaîne.

La responsabilité actuelle de maintenance de TCP et des sockets est volontairement partagée

Le fichierMAINTAINERSrépartit la responsabilité entre Dumazet, Neal Cardwell et d’autres mainteneurs et réviseurs. Cela réduit la dépendance à un point unique et fait entrer les connaissances sur le contrôle de congestion, les sockets, les pilotes et les tests dans les décisions.

La responsabilité partagée exige aussi une appropriation claire. Si personne ne répond clairement dans les zones de chevauchement, un vide du type « tout le monde croit que l’autre s’en occupe » peut se former. Une succession saine n’efface pas l’expérience de Dumazet, mais permet à d’autres d’expliquer pourquoi ces mécanismes existent et de les modifier en sécurité.

La Netdev Foundation peut fournir des fonds, mais ne peut pas devenir un organe d’intégration du code

La Netdev Foundation soutient, sous la supervision de la Linux Foundation, les tests, les outils, les déplacements et la recherche; Dumazet y siège au TSC. Elle peut influer sur l’affectation des ressources, mais ne peut garantir l’intégration d’un correctif.

Cette séparation est importante. Une maintenance approfondie exige des salaires, du matériel et de l’intégration continue; nier les coûts économiques n’est pas réaliste. Mais la légitimité amont reste fondée sur la revue technique publique. Le financement doit accroître la capacité de décision de la communauté, et non remplacer la décision.

L’affiliation à Google apporte des ressources d’ingénierie, mais ne signifie pas posséder TCP sous Linux

L’adresse de messagerie du mainteneur suffit à prouver l’affiliation à Google, mais pas à confirmer un poste complet. Un hyperscaler peut fournir des profils de production, du matériel et du temps de maintenance à long terme; lorsque les modifications remontent, les autres utilisateurs de Linux en bénéficient aussi.

Le problème est l’asymétrie des preuves: les besoins des grands parcs sont plus visibles, tandis qu’une partie des charges reste privée. La revue publique est le contrepoids. Les modifications doivent être assez générales, compréhensibles et acceptables par des mainteneurs extérieurs à Google. L’entreprise fournit des ressources, elle ne possède pas la pile protocolaire.

Les opérateurs en aval décident si les changements amont modifient réellement les services des utilisateurs

Les distributions choisissent le noyau et les rétroports, les plateformes cloud choisissent la qdisc et le contrôle de congestion, les équipementiers peuvent fixer longtemps d’anciennes versions, les fabricants de NIC définissent les capacités matérielles, les applications créent les modèles de trafic. Les données publiques ne fournissent pas de statistiques complètes sur la proportion réelle d’activation de TSQ ou desch_fqdans tous les environnements.

Un mécanisme peut exister sans être activé, ou fonctionner en tant que valeur par défaut sans que personne le sache. L’influence de Dumazet est donc large mais indirecte: il modifie l’ensemble des capacités offertes par le noyau public, que les opérateurs transforment ensuite en performances concrètes de service.

Les piles en espace utilisateur se disputent des charges spécialisées, pas tous les rôles de Linux

DPDK, VPP et les piles spécialisées peuvent contourner une partie du chemin noyau et obtenir des débits de paquets plus élevés ou un contrôle plus fort, mais exigent souvent des cœurs dédiés, des pages de grande taille, la liaison de périphériques et un modèle d’exploitation distinct.

L’avantage de TCP sous Linux est l’intégration: sockets ordinaires, sécurité, espaces de noms, supervision, pilotes et un immense parc d’applications. Le travail de Dumazet réduit l’écart de coût du chemin général, sans prouver qu’il est le meilleur dans tous les scénarios. Les systèmes spécialisés peuvent contourner; Linux continue de servir des applications plus larges.

Linux reste le choix par défaut parce que l’intégration vaut plus que le simple débit de paquets

La pile réseau ne doit pas seulement être rapide, mais aussi compatible, réparable, observable et capable de prendre en charge le routage, la sécurité, les espaces de noms et un grand nombre de matériels. Un chemin rapide isolé peut offrir un débit plus élevé, mais augmente aussi les coûts de déploiement et de support.

Lorsqu’une application utilise Linux par une socket ordinaire, elle hérite automatiquement de TSQ, du pacing et de la comptabilité mémoire. Cette invisibilité est un avantage: l’utilisateur n’a pas besoin de connaître l’auteur du correctif, le bénéfice d’infrastructure existe quand même.

Un hôte plus rapide ne prouve pas que tout le chemin réseau est meilleur

Des files d’attente locales plus courtes ne réparent pas un accès congestionné, une destination surchargée ni les pertes des routeurs intermédiaires. TSQ et le pacing contrôlent l’hôte émetteur, pas le réseau complet.

Ils peuvent réduire une source de latence et lisser le trafic, sans garantir l’expérience applicative. Le résultat de bout en bout reste déterminé par l’application, le récepteur, le chemin réseau et la configuration opérationnelle.

Un seul banc d’essai ne peut pas représenter tous les serveurs, NIC et charges

La taille des paquets, le nombre de connexions, le CPU, le cache, la NIC, le délestage, la qdisc, les minuteries, la version du noyau et la charge métier modifient tous le résultat. Un profil à l’échelle de Google peut révéler des coûts réels, mais ne peut pas prédire un pourcentage précis pour un autre système.

Un reportage fiable doit conserver les conditions expérimentales. Les présentations publiques de Dumazet sont des preuves opérationnelles de première main précieuses; pour tirer des conclusions plus générales, il faut des tests reproductibles et des mesures indépendantes.

La succession est une question technique, car de nombreuses raisons de conception restent dans la mémoire des personnes

Une limitation étrange peut provenir d’une NIC devenue rare, d’une API encore utilisée par certains ou d’une régression survenue il y a des années. Le code ne documente pas toujours la raison.

Les mainteneurs de longue durée portent cette histoire, créant à la fois de la valeur et un risque de personne clé. La documentation, les tests, les archives de messagerie et davantage de mainteneurs transforment la mémoire individuelle en savoir institutionnel. Une succession saine doit préserver les principes derrière TSQ, le pacing et la comptabilité des sockets, tout en permettant aux successeurs de s’adapter au nouveau matériel.

Le pacing matériel et la mémoire des périphériques peuvent à nouveau déplacer la frontière de contrôle

Les nouvelles NIC peuvent ordonnancer les paquets, gérer davantage de files, fournir une télémétrie plus riche et utiliser la mémoire locale du périphérique. Cela peut réduire le CPU, mais déplace aussi davantage de comportements dans le micrologiciel et le matériel.

La difficulté de la prochaine étape est la coordination: Linux doit exprimer l’intention de transmission, savoir ce que le matériel a réellement fait et se rétablir en cas de divergence. Les API de pilote, les horodatages et les rapports d’erreur seront aussi importants que les algorithmes de débit. Les principes du travail de Dumazet restent applicables: le contrôle près de l’intention, la rétroaction indispensable, les files cachées limitées, les frontières observables.

L’économie du cache pourrait apporter les prochains gains plus souvent qu’une nouvelle formule de transport

De nouveaux algorithmes de contrôle de congestion apparaîtront encore, mais la prochaine amélioration significative des grands hôtes pourrait venir de la séparation des structures, de la suppression d’un verrou, de l’ajustement d’un lot ou de la fin des migrations répétées d’une ligne de cache entre CPU.

Ces modifications n’ont pas de marque voyante, mais peuvent améliorer simultanément de nombreux algorithmes et applications. Les travaux de 2024 montrent qu’une pile protocolaire mature doit de plus en plus être optimisée en fonction des coûts physiques réels. La question passe de « quel nouveau protocole gagne » à « combien chaque connexion existante consomme discrètement de ressources machine ».

La contribution la plus durable de Dumazet est la discipline des ressources, pas le mythe de l’invention héroïque

Un récit erroné ferait de Dumazet l’inventeur solitaire du TCP moderne sous Linux et de BBR; un autre noierait entièrement son jugement personnel dans la « contribution communautaire ». Les preuves soutiennent une position intermédiaire plus exacte.

Il a introduit TSQ, fait progresser les bases desch_fq, développé le pacing interne et montré publiquement des optimisations de structures respectueuses du cache; il assume en même temps des responsabilités réelles dans un système de maintenance partagé. Sa contribution est d’avoir amené Linux à traiter les paquets et les sockets comme des demandes portant sur un temps, une mémoire, des files d’attente et une localité CPU limités.

L’impact final se répartit entre conception, revue, intégration et exploitation. Un correctif est facile à attribuer, mais l’augmentation de la densité d’un parc ou la réduction des pannes est difficile à attribuer à une seule personne. Cette impossibilité de quantification précise n’est pas une raison d’exagérer ou d’effacer un individu: elle montre que la valeur d’une infrastructure naît de décisions d’ingénierie identifiables et d’une exécution collective.