Linux 7.3 devrait gagner une option de scrutation active pour USB4STREAM, le protocole Intel qui transporte des paquets bruts entre deux hôtes reliés par un câble USB4 ou Thunderbolt. Le correctif, signé Mika Westerberg, mainteneur Thunderbolt chez Intel, ajoute un attribut ConfigFS qui bascule les anneaux de transfert de la remise par interruption vers la scrutation. Le raisonnement du correctif est direct : les interruptions et les tâches ordonnancées ajoutent de la latence, et certaines applications préfèrent ne pas la payer. Le coût est énoncé tout aussi clairement. Vous brûlez des cycles processeur en continu, et vous perdez la possibilité d'utiliser poll(2) sur l'interface. Le code attend la fenêtre de fusion dans l'arbre thunderbolt.
The short answer
USB4STREAM est le protocole Intel qui transporte des paquets bruts entre deux hôtes reliés par un câble USB4 ou Thunderbolt. Un correctif de Mika Westerberg, chez Intel, prévu pour Linux 7.3, ajoute un attribut ConfigFS qui bascule les anneaux de transfert d'un flux de la remise par interruption vers la scrutation active. Le correctif énonce directement son raisonnement : les interruptions et les tâches ordonnancées ajoutent une latence que les applications critiques préfèrent éviter. Les coûts sont énoncés aussi directement, à savoir une consommation processeur continue et la perte de poll(2) sur cette interface. Aucun chiffre de latence n'a été publié.
Deux machines et un câble Thunderbolt forment l'un des liens les plus rapides que l'on puisse monter sans acheter de commutateur, et Linux devient discrètement meilleur pour en faire autre chose que du stockage. Un correctif prévu pour Linux 7.3 pousse un peu plus loin, en proposant un compromis que tout ingénieur réseau a déjà accepté ailleurs.
Le sujet est USB4STREAM, le protocole d'Intel pour déplacer des paquets de données bruts entre deux hôtes via une connexion USB4 ou Thunderbolt. Le changement, signé Mika Westerberg chez Intel, ajoute un unique attribut ConfigFS qui bascule les anneaux de transfert d'un flux en mode scrutation.
Le raisonnement tient en une phrase
Le correctif ne l'enjolive pas. Utiliser des interruptions et ordonnancer des tâches augmente la latence, donc les applications critiques en latence peuvent vouloir l'éviter.
Déroulez le chemin par défaut et vous voyez où passe le temps. Les données arrivent dans l'anneau de transfert. Le matériel lève une interruption. Le noyau la traite et ordonnance une tâche. La tâche finit par s'exécuter et les données deviennent visibles pour votre processus. Chaque étape est peu coûteuse. Aucune n'est gratuite. Ensemble, elles posent un plancher sous la vitesse de réaction de votre application, et aucun réglage au-dessus de cette couche ne passe en dessous.
La scrutation active supprime la chaîne. Un processeur reste dans une boucle à demander à l'anneau si quelque chose est arrivé, si bien que les données sont disponibles à l'instant où le matériel les produit. Il n'y a pas d'interruption à servir ni de tâche à ordonnancer, parce que personne n'attend rien.
Vous avez déjà vu ce compromis
Si cela vous semble familier, c'est que le réseau a fait sa paix avec ce compromis depuis longtemps.
La scrutation NAPI fait la même chose pour les files des périphériques réseau. L'option de socket SO_BUSY_POLL l'expose par socket. Les cadriciels de contournement du noyau adoptés il y a des années par les télécoms et le trading ont poussé l'idée jusqu'au bout en retirant complètement le noyau du chemin de données. Chacun de ces cas est le même marché : dépenser un processeur en continu pour cesser d'attendre que la machine vous annonce quelque chose.
La nouveauté ici est la surface, pas l'idée. Il s'agit d'un interrupteur par flux sur un câble point à point entre deux hôtes, un endroit plus étroit et plus contrôlable pour faire ce compromis qu'une interface réseau partagée. Vous décidez pour un lien avec un pair.
Les coûts sont énoncés, et les deux comptent
Le premier est évident et se retrouve partout : un coeur tourne à vide, qu'il y ait du trafic ou non. Le repos coûte autant que la saturation. Sur un portable, c'est de la chaleur et de la batterie. Sur un serveur, c'est un coeur retiré du parc aussi longtemps que le flux existe.
Le second coût mérite qu'on s'y arrête. Activer le busy poll signifie que vous ne pouvez plus utiliser poll(2) sur cette interface.
Ce n'est pas une note de performance, c'est une contrainte sur l'écriture du programme. Une application bâtie autour d'une boucle d'événements attendant sur un ensemble de descripteurs ne peut pas simplement se voir activer cela par en dessous, parce que le mécanisme qu'elle utilise pour attendre est précisément celui qu'on retire. Si votre chemin de données fait déjà tourner un fil dédié en lectures serrées, vous dépensiez déjà le processeur et cela ne vous coûte rien de plus. Si votre flux est un descripteur parmi cinquante dans une boucle epoll, adopter le busy poll signifie restructurer, pas configurer.
Où vit le réglage
C'est du ConfigFS, donc un fichier, à un chemin de la forme /sys/kernel/config/thunderbolt/stream/[xdomain].[service]/$name/busy_poll. Le composant xdomain identifie l'hôte distant découvert à travers le câble et le composant service identifie ce que les deux extrémités ont convenu de parler. Écrire l'attribut bascule les anneaux de ce flux et de rien d'autre.
La granularité est la bonne partie. Ce n'est ni un paramètre de démarrage ni une option de module qui change le comportement pour tout le monde. Un flux, un pair, une décision.
Ce que nous ferions
Rien, sauf si vous avez déjà mesuré le problème que cela résout.
La scrutation active est la bonne réponse à une condition précise et vérifiable : votre charge est limitée par la latence, et vous avez tracé cette latence jusqu'au surcoût des interruptions et de l'ordonnancement plutôt que jusqu'à quelque chose au-dessus. Si vous ne l'avez pas mesuré, l'activer vous donne un coeur occupé en permanence et aucun bénéfice, et la restriction sur poll(2) peut imposer discrètement une réécriture non prévue.
Le point plus large mérite d'être retenu même si vous ne touchez jamais un câble Thunderbolt. Les liens d'hôte à hôte sur USB4 deviennent un vrai transport pour ceux qui ont besoin de deux machines proches et rapides, et le noyau leur offre désormais les mêmes leviers de latence que l'Ethernet possède depuis des années. C'est une catégorie de lien qui se prend au sérieux, pas une niche qui gagne un bouton.
Quant au calendrier, les correctifs vivent dans l'arbre thunderbolt et visent Linux 7.3. Rien n'est livré, et après la sortie de la 7.3 il faudra encore attendre un noyau de distribution qui le porte.
Sources et pour aller plus loin
- USB4STREAM adding busy poll option for lower latency at the cost of increased CPU cycles, Phoronix, 5 août 2026
- L'arbre noyau thunderbolt.git
- Documentation noyau sur ConfigFS
- Documentation réseau du noyau sur NAPI et la scrutation active
Questions fréquentes
Qu'est-ce qu'USB4STREAM et en quoi diffère-t-il du réseau sur Thunderbolt ?
USB4STREAM est un protocole défini par Intel pour acheminer des paquets de données bruts entre deux hôtes reliés par un câble USB4 ou Thunderbolt. Le mot important est bruts. C'est un transport de paquets, pas une interface réseau avec une adresse IP et une table de routage : ce qui tourne au-dessus est donc ce que l'application décide. Cela le distingue de l'approche plus ancienne consistant à exposer un lien Thunderbolt comme un périphérique réseau de type Ethernet, qui offre une interface familière au prix d'une pile réseau complète dont vous n'avez peut-être pas besoin. Les deux vivent dans la même partie du noyau et reposent sur la même mécanique XDomain qui permet à deux machines de se découvrir à travers le câble. Si vous voulez de l'IP entre deux machines, le périphérique réseau reste la réponse. Si vous voulez le chemin le plus court entre votre application et le câble, USB4STREAM est celui qui ne met pas de pile au milieu.
Que change réellement la scrutation active ?
Elle change qui remarque que des données sont arrivées. Dans le dispositif par défaut, le matériel lève une interruption, le noyau la traite, et une tâche est ordonnancée pour faire le vrai travail. Chacune de ces étapes est peu coûteuse individuellement et aucune n'est gratuite, et ensemble elles posent un plancher sous la vitesse de réaction de votre processus. La scrutation active supprime toute la chaîne : un processeur reste dans une boucle à demander à l'anneau de transfert s'il y a quelque chose, si bien que la réponse arrive aussi vite que le matériel peut la produire. Les ingénieurs réseau reconnaîtront immédiatement la forme de ce compromis, car c'est celui de la scrutation NAPI et de l'option de socket SO_BUSY_POLL, le même qui a poussé le trading haute fréquence et les charges télécom vers les cadriciels de contournement du noyau il y a des années. Le motif est ancien. La nouveauté, c'est qu'il devient un interrupteur par flux sur un lien USB4.
Quel est le coût, en clair ?
Un processeur qui ne fait rien d'autre que demander. La scrutation active signifie qu'un coeur tourne à vide, qu'il y ait du trafic ou non : vous payez les mêmes cycles au repos qu'en charge. Sur un portable, cela se voit en chaleur et en autonomie. Sur un serveur, c'est un coeur que vous ne pouvez allouer à rien d'autre. Le correctif signale un second coût facile à manquer : activer le busy poll empêche d'utiliser poll(2) sur l'interface. Ce n'est pas une note de bas de page, c'est un changement dans la façon d'écrire le programme. Tout ce qui est bâti autour d'une boucle d'événements attendant sur des descripteurs de fichiers doit être restructuré autour de la boucle de scrutation. Si votre application fait déjà tourner un fil dédié en lectures serrées, l'option ne vous coûte rien que vous ne dépensiez déjà. Si elle vit dans un epoll avec cinquante autres descripteurs, ce n'est pas un interrupteur que l'on bascule.
Comment l'activer, et faut-il le faire ?
C'est un attribut ConfigFS, donc un fichier. Le chemin prend la forme /sys/kernel/config/thunderbolt/stream/[xdomain].[service]/$name/busy_poll, où les composants xdomain et service identifient l'hôte distant et le service négocié avec lui. Écrire dans ce fichier bascule les anneaux de ce flux, ce qui est la bonne granularité : vous ne prenez pas une décision pour tout le système, vous la prenez pour un lien avec un pair. Faut-il le faire est une question sur votre charge de travail, pas sur la fonctionnalité. Le test honnête consiste à savoir si vous avez mesuré un problème de latence et si vous l'avez tracé jusqu'au surcoût des interruptions et de l'ordonnancement, plutôt que de l'avoir supposé. La scrutation active fait une vraie différence sur les charges réellement limitées par la latence et dégrade tout le reste en consommant un coeur pour rien.
Quand cela sera-t-il réellement disponible ?
Les correctifs sont dans la branche next de thunderbolt.git, là où les changements Thunderbolt et USB4 s'accumulent avant d'être envoyés à Linus pendant une fenêtre de fusion. La cible est Linux 7.3. En pratique, cela veut dire que le code est assez stabilisé pour que le mainteneur ait l'intention de le livrer, mais qu'il n'a pas encore atteint un noyau publié, et les réserves habituelles sur tout ce qui vit dans une branche next de sous-système s'appliquent. Après la sortie de la 7.3 vient la seconde attente, celle de votre distribution livrant un noyau assez récent pour l'inclure. Sur une distribution stable, cela se compte en mois plutôt qu'en semaines. Si vous compilez vos propres noyaux ou suivez une distribution en publication continue, vous l'aurez dès la sortie.