Eric Dumazet et les petites files d'attente dans l'économie des serveurs Linux

Résumé

• Eric Dumazet est actuellement enregistré comme mainteneur Linux pour la mise en réseau générale, TCP et les sockets, et membre du comité de pilotage technique de la Netdev Foundation. Ces responsabilités sont partagées avec d'autres mainteneurs et relecteurs. Elles impliquent une responsabilité d'intégration considérable, mais aucune autorité exclusive sur la mise en réseau Linux.
• Sa contribution la plus clairement identifiable est TCP Small Queues, introduite par une série de correctifs de 2012. TSQ empêche un flux TCP unique de placer trop de données dans les files d'attente sous la couche transport. La libération locale de file est liée à la complétion des paquets, ce qui peut réduire la latence et la mémoire côté émetteur sans éliminer toutes les files d'attente du chemin.
• Les travaux ultérieurs de Dumazet sursch_fqet le pacing TCP interne ont fait du moment d'envoi une variable de contrôle explicite. Le fair queueing sépare les flux, le pacing répartit les paquets dans le temps. Cette infrastructure aide plusieurs approches de contrôle de congestion, y compris les environnements avec BBR. BBR a toutefois ses propres auteurs et sa propre histoire de développement.
• Ses travaux publics plus récents relient la disposition des structures, le trafic des lignes de cache et l'état par socket à l'efficacité des parcs. La leçon principale est la suivante: la mise en réseau Linux est aussi un système de comptabilité pour le CPU, la mémoire, la profondeur des files et le temps. L'effet économique peut être considérable sur de grands parcs, mais les sources publiques ne permettent de le traduire ni en une valeur monétaire personnelle ni en un gain de performance universel.

Un serveur rapide peut encore attendre derrière ses propres paquets

La scène la plus révélatrice est une file d'attente d'envoi dans un hôte Linux. L'application a écrit des données, TCP considère qu'une transmission supplémentaire est possible et le noyau a remis les octets aux couches inférieures. Pour l'application, ils semblent partis; en réalité, ils peuvent attendre dans la même machine.

Un débit élevé masque le problème. Une requête interactive est placée derrière un grand transfert, les tampons immobilisent de la mémoire et la notion de « en vol » de TCP s'éloigne de ce qui est seulement congestionné localement. TCP Small Queues a modifié cette relation: un socket ne peut placer qu'une quantité limitée de données sous TCP et obtient un nouveau droit d'envoi lorsque le périphérique signale un progrès réel.

Le dossier public est techniquement riche et volontairement limité sur le plan biographique

Les preuves les plus solides proviennent de Linux lui-même:MAINTAINERS, discussions de correctifs, documentation, présentations de conférences et années de revues publiques. Elles confirment les responsabilités actuelles de Dumazet dans la mise en réseau générale, TCP et les sockets, son siège au TSC de la Netdev Foundation et une affiliation à Google via l'adresse du mainteneur.

Elles ne fournissent ni une biographie complète, ni un titre Google actuel confirmé de manière indépendante, ni des statistiques complètes de correctifs et de revues, ni une répartition précise du temps. Combler ces lacunes par des détails plausibles serait malhonnête. Le profil se concentre donc sur des mécanismes et des décisions vérifiables. Dumazet apparaît comme un responsable technique dont le travail ne devient une infrastructure partagée qu'après revue, modification, test et déploiement par d'autres.

Le statut de mainteneur rapproche Dumazet des décisions, pas au-dessus de la communauté

À la date de référence du 4 août 2026, les documents Linux indiquaient Dumazet pour la mise en réseau générale, TCP et les sockets. Un mainteneur peut rejeter une interface, exiger une refonte, appliquer des modifications acceptées et assumer la responsabilité d'intégration vers la branche principale.

La même source montre une autorité partagée. David S. Miller, Jakub Kicinski et Paolo Abeni figurent parmi les mainteneurs généraux du réseau; Neal Cardwell partage la responsabilité TCP, et d'autres spécialistes relisent selon le correctif. L'architecture, les pilotes, la sécurité, les tests, le noyau stable et le processus de développement principal constituent des limites supplémentaires. L'influence de Dumazet est précisément crédible parce qu'il opère à l'intérieur de ce système distribué.

Avec la croissance du nombre de connexions, Linux est devenu une infrastructure économique

Sur une petite machine, quelques octets supplémentaires par socket ou un défaut de cache passent inaperçus. Sur un hôte avec des centaines de milliers de connexions, le même coût se multiplie jusqu'à concurrencer l'application, la mémoire et l'énergie pour les ressources.

« Économie des serveurs » ne désigne pas un montant d'économies publiquement documenté. Il s'agit des conséquences à l'échelle du parc: densité de connexions, CPU restant pour l'application, mémoire réseau et objectifs de latence manqués à cause des files locales. Les distributions et les opérateurs choisissent le noyau, la qdisc, le contrôle de congestion et la configuration de la NIC. Dumazet ne contrôle pas ces décisions; il améliore la base commune.

Derrière la tâche familière de TCP se cache un système comptable dense

TCP est décrit comme un flux d'octets fiable. L'implémentation décide en même temps de la quantité de données non acquittées autorisée, du moment des retransmissions, de la charge mémoire, du moment d'envoi des paquets et du nombre de sockets partageant CPU et files.

Une pile peut être conforme au protocole et pourtant lente: trop de contre-pression locale, des rafales, de la contention de verrous ou des structures peu adaptées au cache. Le travail de Dumazet suit sans cesse une logique comptable. Les octets sont imputés au socket, la complétion rend du crédit, les temps d'envoi sont calculés et les champs chauds sont séparés des champs froids. L'hôte doit saturer les liens sans construire à l'intérieur un second réseau incontrôlé.

Avant TCP Small Queues, l'émetteur pouvait créer une contre-pression qu'il ne contrôlait plus

Avant TSQ, TCP pouvait pousser de grandes quantités de données dans la qdisc et le pilote. La fenêtre de congestion pouvait être correcte du point de vue du réseau, tandis qu'en dessous se trouvait une file locale profonde. Si un flux urgent arrive, l'application ne peut pas récupérer les paquets déjà remis.

Cette file faussait le retour d'information. TCP voyait des ACK du réseau alors qu'une partie des données n'avait pas encore quitté l'hôte. De nombreux flux immobilisaient aussi une mémoire considérable. Le système avait besoin d'un moyen de maintenir un débit élevé sans donner à chaque socket un espace de stockage illimité sous TCP.

La série de correctifs TSQ de 2012 a rendu au socket un budget local de file

Les correctifs de 2012 ont limité par socket la quantité de données en attente sous TCP. Lorsque le budget local est épuisé, le socket s'arrête. À la complétion des paquets, il reçoit un nouveau droit d'envoi.

L'idée était simple: compter les octets locaux et utiliser la complétion comme signe d'espace libre. L'essentiel était de redonner le contrôle à la couche transport, qui comprend le flux. Un socket n'avait plus besoin de placer à l'avance une grande réserve pour occuper le lien. Les applications ont bénéficié, sans changement de code, d'une règle interne plus disciplinée.

La complétion des paquets est devenue un signal de retour pratique dans l'hôte

La complétion peut sembler n'être qu'un simple nettoyage. TSQ en a fait de l'information: des capacités ont été libérées sous TCP, donc le socket peut continuer à envoyer.

Ce retour local complète les ACK distants. Les ACK montrent le progrès le long du chemin, la complétion montre le progrès sous TCP; les statistiques de qdisc, de pilote et de NIC montrent d'autres états. Aucun signal n'explique tout. TSQ en a utilisé un pour limiter la congestion locale sans remplacer le contrôle de congestion de bout en bout.

TSQ a éliminé une source de bufferbloat, pas toutes les files du chemin

TSQ n'a pas supprimé le bufferbloat. Il s'attaque à la contre-pression côté émetteur sous TCP. Des files restent possibles dans la qdisc, le pilote, la NIC, le réseau d'accès, les routeurs, les commutateurs et le récepteur.

L'affirmation plus étroite est plus forte: TSQ réduit la capacité d'un socket unique à construire une grande file cachée dans l'hôte. Cela peut réduire la latence et la charge mémoire et rapprocher TCP du progrès réel du périphérique. La gestion active des files d'attente et le contrôle de bout en bout restent nécessaires.

Les limites, les délestages et les charges de travail déterminent l'utilité de TSQ

L'effet dépend de la limite locale, de la taille des paquets, de la qdisc, des files matérielles, du délestage de segmentation et du mélange de flux. Les transferts courts interactifs réagissent différemment de la réplication continue.

L'implémentation a aussi évolué depuis 2012. Des contributeurs ultérieurs ont adapté les limites et les interactions. Dumazet peut être cité pour l'origine, sans présenter le mécanisme actuel comme une œuvre unique inchangée.

sch_fqa séparé les flux et fait du temps une entrée d'ordonnancement

En 2013, Dumazet a publié des travaux fondamentaux sur l'ordonnanceursch_fq. Il maintient un état par flux et une structure ordonnée dans le temps afin que les paquets soient libérés selon leur heure d'envoi cible. Les nouveaux flux peuvent être servis rapidement, les flux pacés attendent leur moment.

Cela empêche un flux volumineux de dominer la file locale et donne à TCP un endroit où les temps d'envoi calculés deviennent effectifs. Cela ne garantit pas des résultats applicatifs identiques, mais une politique de service locale plus disciplinée.

Le fair queueing est une politique, pas une promesse de résultats égaux

Le mot « équitable » paraît plus absolu que l'implémentation. La séparation des flux ne rend pas les résultats applicatifs égaux. La taille des paquets, le chemin, le récepteur, le contrôle de congestion, les délestages et le nombre de connexions restent pertinents.

La définition d'un flux est aussi politique. Une application peut ouvrir de nombreuses connexions, une autre une seule.sch_fqréduit la domination locale d'un flux, mais ne tranche pas l'équité entre utilisateurs ou entreprises. C'est un outil d'ordonnancement, pas une preuve universelle de justice.

Le pacing transforme une estimation de débit en une suite d'heures d'envoi

Un contrôleur de congestion peut choisir le bon débit moyen et libérer malgré tout les données autorisées sous forme de rafale. La moyenne est correcte, la file subit un pic de courte durée.

Le pacing répartit les paquets dans le temps. Cela stabilise les files, améliore le partage et reflète plus précisément l'intention du modèle. La mise en œuvre exige des horodatages, des minuteurs, une qdisc, la segmentation et la NIC. Un débit logiciel n'est réel que lorsqu'il apparaît comme des espacements physiques de paquets sur le lien.

Le pacing et le contrôle de congestion résolvent des parties différentes du problème

Le contrôle de congestion décide dans quelle mesure l'émetteur doit utiliser le chemin; le pacing décide quand les données autorisées sortent. Un bon modèle peut être endommagé par des rafales, et un pacing parfait peut exécuter précisément un mauvais débit.

Le travail de Dumazet sur le pacing est donc une infrastructure habilitante. Il permet à plusieurs algorithmes de traduire le débit en temps. La paternité d'un modèle concret de contrôle de congestion reste à ses développeurs.

BBR utilise l'infrastructure de pacing, mais a ses propres auteurs et son propre développement

BBR est souvent associé à Dumazet en raison de sa dépendance au pacing et de l'environnement Google. Cela n'en fait pas l'inventeur unique. BBR a ses propres auteurs nommés, modèles et versions.

L'histoire précise est que les files, le pacing, la comptabilité des sockets et l'instrumentation ont rendu des algorithmes ultérieurs pratiquement exécutables. Cette présentation reconnaît le fondement de Dumazet et préserve la contribution indépendante de Neal Cardwell et d'autres ingénieurs du contrôle de congestion.

TSO économise du CPU et peut ramener la rafale que le pacing devait éviter

Le délestage de segmentation TCP remet à la NIC un grand bloc de segments que le matériel divise plus tard en paquets. Cela réduit le coût CPU par paquet, mais place le matériel entre la décision de temporisation et le câble réel.

Si un grand bloc est libéré en une fois, la NIC peut créer une rafale. TSQ, qdisc, TSO, pilote et matériel doivent être compris comme un système. Une optimisation CPU peut dégrader la latence si la forme du trafic n'est pas prise en compte.

Le quantum de pacing, les horodatages et la NIC doivent décrire la même réalité

Le noyau travaille avec des quanta, la résolution des minuteurs, des horodatages, des unités de délestage et des files matérielles. Un grand quantum crée des rafales, un trop petit coûte du CPU, et une granularité différente de la NIC modifie le résultat sur le câble.

C'est pourquoi la qdisc fait partie de la planification de capacité. Les développeurs doivent mesurer le chemin complet. Un benchmark qui ne mentionne que le contrôle de congestion ou le débit du lien omet une grande partie de la mécanique.

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

En 2017, Dumazet a publié le pacing TCP interne. La couche transport pouvait retenir davantage les envois selon son propre débit et ses minuteurs, sans dépendre entièrement d'une configuration de qdisc particulière.

La qdisc restait importante pour l'ordre et la politique. Une partie de la logique s'est rapprochée du détenteur de l'intention d'envoi, mais le moment final demeure le résultat de TCP, de la qdisc, du pilote et de la NIC.

Le choix de la qdisc reste une décision d'opérateur avec de vraies conséquences de service

Linux propose des qdiscs pour différents objectifs.sch_fqest particulièrement pertinent pour le pacing, tandis que FQ-CoDel combine séparation des flux et gestion active des files. Les deux ne sont pas identiques.

Les valeurs par défaut diffèrent entre les distributions, les images cloud, les appliances et les hôtes de conteneurs; les délestages peuvent déplacer l'exécution. L'amont fournit des mécanismes, l'opérateur en fait un comportement de service réel.

Quelques octets par socket deviennent une limite de parc

Chaque connexion conserve des numéros de séquence, des minuteurs, l'état de congestion, des files et une comptabilité. À grande échelle, chaque octet se multiplie, et les champs fréquemment touchés sollicitent le cache.

Moins de mémoire par socket peut augmenter la densité; un meilleur agencement peut réduire les défauts de cache et le trafic de cohérence entre CPU. C'est le lien le plus fort avec l'économie des serveurs, mais cela ne permet ni un taux d'économie universel ni une évaluation personnelle en argent.

Une ligne de cache devient une infrastructure lorsque chaque paquet la touche

Les CPU déplacent des lignes de cache entières, pas des champs individuels du code source. Des données chaudes à côté de champs froids transportent des octets inutiles; deux CPU qui modifient des valeurs différentes de la même ligne génèrent quand même du trafic de cohérence.

Les travaux récents de Dumazet examinent le code sous cet angle physique. Séparer les champs chauds et froids réduit le trafic mémoire qui croît avec le nombre de paquets et de sockets. Le résultat dépend du CPU et de la charge; un profil de production n'est pas une loi universelle.

Les travaux sur les structures de données de 2024 montrent une phase mûre du développement de la performance

La conférence de 2024 a commencé par le profilage: quels champs sont chauds? Quelles lignes de cache bougent? Quelles structures dominent la mémoire? Les outils peuvent suggérer des réorganisations, mais l'alignement, le verrouillage, la compatibilité et la maintenance restent des décisions humaines.

Dans une infrastructure mature, un grand gain provient souvent d'un défaut de cache évité ou d'un champ déplacé plutôt que d'un nouvel algorithme. C'est moins visible et pourtant déterminant pour la mise à l'échelle.

Les profils hyperscale sont des preuves solides et une science publique incomplète

Les grands opérateurs voient des nombres de connexions, des NIC et des mélanges de trafic difficiles à reproduire ailleurs. L'affiliation de Dumazet à Google permet des observations où de petits coûts dans un grand parc deviennent évidents.

Une partie des charges, des outils et des données reste privée. Une conférence peut expliquer la méthode et la direction sans publier toutes les entrées. Cela exige une limitation de l'affirmation, pas un rejet. Idéalement, davantage d'observations privées sont traduites en tests publics et en charges de CI.

Les verrous et files côté réception relèvent de la même comptabilité des ressources

L'accent est mis sur l'envoi, mais le travail plus large de Dumazet inclut les sockets et le chemin de réception. Les paquets entrants exigent du polling, de la mémoire, de la classification, des files et un transfert CPU. À des débits élevés, les verrous et l'état partagé deviennent coûteux.

Linux passe à l'échelle grâce au traitement par lots, au déplacement du travail et à moins de contention. Le principe reste le même: assez de coordination pour la correction, mais pas au point que la comptabilité évince l'application.

Le traitement par lots augmente le débit et modifie la latence et l'équité

Traiter plusieurs paquets ou complétions ensemble amortit les verrous, les appels de fonction et les déplacements de cache. NAPI, les pilotes et les délestages s'appuient dessus.

Un lot met du temps à se former et peut arriver comme une rafale dans la couche suivante. Des lots plus grands améliorent l'efficacité et augmentent l'attente ou la domination. TSQ, le fair queueing et le pacing ne combattent pas le batching; ils posent des limites pour préserver le retour et la latence.

La performance TCP naît de couches qui peuvent s'annuler mutuellement

Le contrôle de congestion détermine l'intention, TCP crée les paquets et les temps, TSQ limite la contre-pression, la qdisc ordonne, TSO regroupe, le pilote mappe, la NIC envoie, le réseau ajoute des files et des pertes.

Un pacing précis peut être annulé par des délestages grossiers, une qdisc à faible latence par un enfilement excessif, un agencement compact par un nouveau verrou. Le travail de Dumazet est important parce qu'il traite ces transitions.

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

Un changement commence par une affirmation: moins de latence, de mémoire ou de CPU. Pour entrer dans Linux, il doit expliquer sur netdev la méthode de mesure, la généralité, les architectures rares, les tests et la maintenance future.

Les mainteneurs peuvent diviser les séries, rejeter des abstractions spécifiques à un fabricant ou reporter un travail inachevé. C'est plus lent qu'un correctif privé et plus durable. L'autorité de Dumazet réside aussi dans la question de savoir si Linux pourra porter une amélioration pendant des années.

netetnet-nextséparent la réparation urgente du développement futur

Les corrections vont généralement dansnet, les fonctionnalités et refactorisations dansnet-next. Ainsi, la maintenance actuelle n'est pas déstabilisée par le travail de la prochaine version.

La frontière exige du jugement. Une correction peut changer le comportement, une fonctionnalité révéler une ancienne erreur. Les mainteneurs divisent les séries pour rendre le risque visible. Une date de sortie produit seule n'est pas un motif de fusion.

Revue, rejet et refonte disparaissent dans les chiffres de commits

Les commits comptent la paternité visible, pas la revue qui a fait redessiner une interface, ni le rejet qui a évité des années de charge. Appliquer un correctif signifie une responsabilité d'intégration, pas une invention.

Le profil relie donc des travaux clairement attribuables comme TSQ,sch_fq, le pacing et l'agencement à une intendance non quantifiable. Tous les correctifs intégrés par Dumazet ne deviennent pas pour autant sa création personnelle.

Les tests réduisent le risque, mais ne peuvent pas représenter chaque machine Linux

Les compilations, les autotests, KUnit, syzbot, les laboratoires de pilotes et les déploiements en aval découvrent de nombreuses régressions, mais pas chaque CPU, NIC, qdisc et charge.

Une amélioration hyperscale peut nuire à un système embarqué rare. L'expérience, la réflexion sur la compatibilité et le retour en arrière restent nécessaires. Les tests renforcent la gouvernance, mais ne remplacent pas le jugement.

Les rétroportages stables créent une deuxième décision après la branche principale

Un correctif de la branche principale n'atteint pas automatiquement tous les noyaux stables. Il doit résoudre un problème réel et limité et introduire peu de risque. Les distributions décident ensuite à nouveau.

Les changements de performance dépendent souvent d'un contexte absent des anciennes branches. L'effet se propage par étapes via l'amont, les versions stables, les distributions, le cloud et la configuration. Personne ne contrôle toute la chaîne.

La maintenance TCP et des sockets est aujourd'hui délibérément partagée

MAINTAINERSrépartit la responsabilité entre Dumazet, Neal Cardwell et d'autres mainteneurs et relecteurs. Cela réduit la dépendance à une seule personne et relie les connaissances sur la congestion, les sockets, les pilotes et les tests.

La responsabilité partagée exige une propriété claire. Les chevauchements peuvent créer des lacunes si chacun attend l'autre. Une bonne succession répartit l'autorité et préserve les raisons des décisions.

La Netdev Foundation peut financer sans devenir une autorité de fusion

Sous la supervision de la Linux Foundation, elle soutient la CI, les outils, les déplacements et la recherche. Dumazet siège au TSC. Un financement ne garantit pas une fusion.

La maintenance approfondie coûte de l'argent, du matériel et du temps. Le reconnaître ne transfère toutefois pas la légitimité amont au bailleur de fonds. Le financement doit élargir la capacité de décision, pas acheter les décisions.

L'affiliation à Google apporte une capacité d'ingénierie, mais pas la propriété du TCP de Linux

L'adresse Google prouve une affiliation, pas un titre complet. Un hyperscaler peut financer le profilage, le matériel et le temps de revue dont tous profitent après l'intégration amont.

L'asymétrie se trouve dans les charges et données privées. La revue publique est le contrepoids: le correctif doit être générique, compréhensible et acceptable en dehors de Google. L'entreprise fournit du temps et des preuves, mais ne possède pas la pile.

Les opérateurs en aval décident si une amélioration amont modifie le service

Les distributions choisissent le noyau et les rétroportages, le cloud la qdisc et le contrôle de congestion, les appliances les versions, les fabricants de NIC les capacités, les applications le trafic. Il n'existe pas d'enquête complète sur l'utilisation de TSQ ou desch_fq.

Un mécanisme peut être présent et inactif, ou fonctionner par défaut sans être remarqué. L'impact de Dumazet est large et indirect: il modifie les options communes, les opérateurs les transforment en expérience utilisateur.

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

DPDK, VPP et les piles spécifiques à une application contournent des parties du noyau pour des débits de paquets élevés et le contrôle, mais exigent souvent des cœurs dédiés, des pages énormes, une liaison de périphérique et un modèle d'exploitation propre.

Le TCP de Linux intègre les sockets, la sécurité, les espaces de noms, l'observabilité, les pilotes et les applications. Le travail de Dumazet réduit le coût de ce chemin général, sans le déclarer meilleur pour tous les cas. Les cas spécialisés peuvent contourner; Linux reste la base large.

Linux reste la norme parce que l'intégration est plus que le débit brut de paquets

Une pile réseau doit être rapide, compatible, sûre, observable et maintenable sur de nombreux appareils. Un chemin rapide séparé peut fournir plus de pps et créer en même temps ses propres coûts d'exploitation et de support.

Une application Linux hérite de TSQ, du pacing et de la comptabilité via les sockets ordinaires. Cette invisibilité est une force: le bénéfice demeure même si les utilisateurs ignorent le nom de l'auteur.

Un hôte plus rapide ne prouve pas un meilleur chemin réseau

Une file locale plus courte ne répare ni un accès congestionné, ni un récepteur lent, ni des routeurs avec pertes. TSQ et le pacing disciplinent l'émetteur, pas tout le chemin.

Ils peuvent réduire une source de retard et lisser le flux. Le résultat applicatif reste le produit commun de l'émetteur, du récepteur, du réseau et de la configuration.

Un benchmark ne vaut pas pour chaque serveur, NIC et charge

La taille des paquets, le nombre de connexions, le CPU, le cache, la NIC, les délestages, la qdisc, les minuteurs, le noyau et la charge modifient les résultats. Un profil Google peut montrer des coûts réels sans fournir le pourcentage exact pour un autre parc.

Un bon reportage technique préserve les conditions. Les conférences de Dumazet sont une précieuse preuve opérationnelle attribuée; la généralisation exige des tests publics et des mesures indépendantes.

La succession est un problème technique parce qu'une grande partie du savoir de conception vit dans la mémoire

Une limite étrange peut exister à cause d'une ancienne NIC, d'une API encore utilisée ou d'une régression résolue depuis longtemps. Le code ne raconte pas toujours la raison.

Les mainteneurs de longue date portent ce contexte et créent de la valeur comme un risque de personne clé. La documentation, les tests, les archives et de nouveaux relecteurs transforment la mémoire privée en savoir institutionnel. Une bonne succession préserve les principes et permet l'adaptation au nouveau matériel.

Le pacing matériel et la mémoire de périphérique peuvent de nouveau déplacer la frontière

Les NIC modernes planifient les paquets, gèrent davantage de files et offrent de la télémétrie ou de la mémoire locale. Elles économisent du CPU et déplacent le comportement vers le micrologiciel.

Linux doit exprimer l'intention, voir le comportement matériel réel et réagir en cas d'écart. Les API de pilote, les horodatages et les erreurs deviennent aussi importants que le débit. Les principes de Dumazet demeurent: retour d'information, files cachées limitées, contrôle proche de l'intention et limites observables.

L'économie du cache pourrait fournir les prochains gains plus souvent que de nouvelles formules de transport

De nouveaux algorithmes de contrôle de congestion viendront. Sur les grands hôtes, le prochain gain matériel peut toutefois provenir de la séparation des structures, de moins de verrous, d'un meilleur traitement par lots ou de moins de lignes de cache migratrices.

Ces changements n'ont pas de marque forte, mais aident de nombreux algorithmes à la fois. Le travail de 2024 montre une pile mûre, polie sur les coûts physiques. La question passe de « Quel protocole gagne? » à « Quelle quantité de machine chaque connexion consomme-t-elle sans qu'on le voie? »

La contribution durable de Dumazet est une discipline des ressources, pas un mythe héroïque

Un mauvais récit fait de Dumazet l'inventeur unique du TCP Linux moderne et de BBR; un autre efface la personne dans la communauté. Les preuves permettent la précision.

Il a introduit TSQ, façonné les fondements desch_fq, développé le pacing interne et montré l'importance de la disposition des structures. En même temps, il porte aujourd'hui une responsabilité dans une gouvernance partagée. Sa contribution consiste à traiter les paquets et les sockets comme des créances sur un temps, une mémoire, des files et une localité CPU limités.

L'effet final se répartit entre conception, revue, intégration et exploitation. Un commit est attribuable; une densité de parc supérieure ou des pannes évitées ne le sont pas. Cette difficulté ne justifie ni la glorification ni l'effacement. Elle montre que la valeur d'une infrastructure naît de décisions identifiables et d'une mise en œuvre collective.