Comment le Receive-Side Scaling répartit-il la charge réseau d'un serveur domestique ?

Le Receive-Side Scaling répartit la charge réseau du serveur domestique en hachant les flux entrants dans plusieurs files d'attente de réception NIC et en associant ces files d'attente à différents cœurs CPU. Au lieu qu'un seul cœur gère presque toutes les interruptions de réception et les tâches de protocole, plusieurs cœurs peuvent traiter des connexions indépendantes en parallèle.

Le RSS est particulièrement utile lorsque le serveur reçoit suffisamment de paquets pour qu'un cœur devienne la limite. Il n'accélère pas un disque unique, n'ajoute pas de capacité réseau, ni ne divise un flux TCP ordinaire de manière égale entre tous les cœurs. Sa fonction est de supprimer un goulot d'étranglement dans le traitement des paquets tout en préservant l'ordre des flux.

Le Mécanisme Central : Plusieurs Files d’Attente de Réception Alimentent Plusieurs Cœurs

Sans traitement multi-file d’attente, une NIC rapide peut fournir du travail à un chemin d’interruption plus vite qu’un cœur CPU ne peut le gérer. L’utilisation globale du CPU peut sembler modeste car les autres cœurs sont inactifs, mais le débit plafonne et la latence réseau augmente sur le cœur surchargé.

Le RSS utilise plusieurs files d’attente de réception pour que les flux entrants puissent être traités simultanément. Chaque file génère sa propre interruption et chemin de traitement, permettant au système d’exploitation d’utiliser davantage les ressources CPU déjà disponibles.

Cela est important sur un serveur domestique exécutant simultanément partage de fichiers, flux médias, sauvegardes et applications conteneurisées. Ces connexions indépendantes fournissent le travail parallèle dont le RSS a besoin ; un lien 1GbE peu utilisé ne génèrera peut-être jamais assez de pression de paquets pour que la différence soit visible.

Le Hachage des Flux Préserve l’Ordre Tout en Répartissant les Connexions

La NIC calcule un hachage à partir des champs d’en-tête du paquet tels que les adresses source et destination, les ports et le protocole. Une table d’indirection associe ce hachage à une file d’attente de réception. Les paquets d’un même flux atteignent normalement la même file, empêchant le traitement parallèle de réarranger ce flux.

La relation entre RSS, affinité IRQ et RPS détermine où le travail s’exécute réellement sous Linux. Le RSS matériel choisit une file de réception ; l’affinité d’interruption connecte cette file à un CPU ; le routage logiciel peut redistribuer le travail protocolaire ultérieur lorsque les files matérielles sont limitées.

Le hachage équilibre statistiquement de nombreux flux, mais pas parfaitement. Quelques flux lourds peuvent se heurter sur une même file, et un flux dominant unique peut rester lié à un seul cœur. C’est pourquoi les observations par cœur et par file sont plus utiles que de supposer qu’un CPU multi-cœur garantit une charge réseau uniforme.

Plus de Files Peuvent Échanger Soulagement du Goulot contre Surcharge CPU

Augmenter le nombre de files crée plus d’opportunités de parallélisme, mais génère aussi des interruptions, du travail de planification et des mouvements de cache. Le nombre optimal dépend des capacités de la NIC, de la topologie CPU, du débit de trafic et de la proximité des applications consommant les paquets par rapport au traitement de réception.

Une explication pratique de la saturation de réception sur un seul cœur montre pourquoi le pourcentage total de CPU peut masquer la vraie limite. Le test utile est de savoir si un cœur est saturé par les interruptions ou le travail softirq tandis que les autres cœurs ont encore de la marge.

Le RSS peut aussi augmenter la surcharge lorsque le trafic est trop faible pour en avoir besoin. La distribution parallèle des paquets améliore l’échelle, mais le placement des files et la localité flux-cœur affectent toujours l’efficacité. Activer toutes les files possibles n’est donc pas une optimisation universelle.

Comment le RSS Change un Goulot d’Étranglement sur un Serveur Domestique

Le RSS aide lorsque le chemin de réception est limité par le CPU : un cœur montre une charge élevée de traitement réseau, plusieurs clients sont actifs, et le stockage a encore de la marge. Il ne sera pas utile lorsque le lien Ethernet est saturé, que les disques ne peuvent pas suivre la charge, que le chiffrement domine le temps CPU, ou qu’une application sérialise toutes les requêtes.

Comparez les compteurs de files NIC, la charge d’interruption par cœur, le débit et la latence applicative avant et après un changement contrôlé. Un contrôle plus large des goulots d’étranglement du serveur domestique aide à éviter qu’un réglage réseau masque une contrainte de stockage, mémoire ou calcul.

Questions Fréquemment Posées

Le RSS divise-t-il une connexion TCP sur tous les cœurs ?

Normalement non. Le RSS maintient les paquets d’un même flux sur la même file pour préserver l’ordre. Son avantage de mise à l’échelle est le plus clair lorsque plusieurs flux indépendants peuvent être hachés sur plusieurs files.

Le RSS est-il utile sur un serveur domestique 1GbE ?

Il peut l’être, surtout avec de nombreux petits paquets ou un CPU peu puissant, mais beaucoup de systèmes peuvent traiter 1GbE sur un seul cœur. Mesurez la charge par cœur avant de considérer le RSS comme la fonctionnalité de performance manquante.

Le RSS et le RPS sont-ils identiques ?

Non. Le RSS oriente les paquets dans le matériel NIC vers les files de réception, tandis que le Receive Packet Steering effectue une étape de distribution liée en logiciel. Ils peuvent se compléter lorsque le nombre de files matérielles est limité.