[article][packet drop] Fix subsection

content/packet_drop.md

@@ -11,16 +11,16 @@ Summary: Augmentation du budget alloué au traitement des paquets réseau et de
 
 [TOC]
 
-## Pourquoi ? Description du besoin
+# Pourquoi ? Description du besoin
 
 Au boulot, on nous reportait quelques echecs de CI, dus à des connexion qui échouaient vers des ressources internes, et en particulier vers les proyxs sortants. Notre CI étant hébergé sur un cluster DC/OS, il a fallu analyser ce qu'il se passait directement au niveau des machines en elles mêmes.
 
-## Critères de choix & solutions envisagées
+# Critères de choix & solutions envisagées
 
 On a constaté des drops de paquets et des "overruns" sur les interfaces réseau des agents, d'abord p1, puis finalement les autres aussi.
 
 ```console
-$ ifconfig eth4
+$ ifconfig eth3
 eth3: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
         ether 00:d0:e6:00:22:5a  txqueuelen 1000  (Ethernet)
         RX packets 552848402  bytes 758129279695 (706.0 GiB)
@@ -30,7 +30,7 @@ eth3: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
         device interrupt 18  memory 0x96800000-96ffffff
 ```
 
-(`ip -s link show dev eth3` pour ne pas utiliser `ifconfig`, qui est obsolète, mais j'ai trouvé la sortie plus difficile à lire sur le moment)
+(`ip -s link show dev eth3` pour ne pas utiliser `ifconfig`, qui est déprécié, mais j'ai trouvé la sortie plus difficile à lire sur le moment)
 
 Un autre constat des drops en regardant les statistiques de la carte réseau et de ses files de traitement :
 
@@ -49,7 +49,7 @@ $ ethtool -S eth3 | grep rx_discard
 
 Au passage, on constate que les cartes réseau de ces machines ont 8 files de traitement des paquets. `ethtool -l` nous indique que l'ont pourrait passer à 30 files, combinées, c'est à dire qu'il faut toujours un nombre pair et que deux files sont liées, l'une pour la réception (RX) et l'autre pour la trasmission (TX).
 
-### rx buffer
+# rx buffer
 
 Après quelques recherches, en particulier à l'aide de cet article, [Monitoring and Tuning the Linux Networking Stack: Receiving Data](https://blog.packagecloud.io/eng/2016/06/22/monitoring-tuning-linux-networking-stack-receiving-data/), il a été constaté que la taille du ring buffer du driver réseau était configurée à une valeur assez basse par défaut :
 
@@ -70,8 +70,7 @@ TX:             4078
 
 Mon analyse est que les CPU de ces machines, servant au CI, sont soumis à des pics de charge, assez longs lors des builds et que le noyau n'a pas le temps de dépiler tous les paquets réseau arrivant dans le ring buffer entre la carte et le noyau. Ainsi, les anciens paquets non traités sont droppés.
 
-
-### /proc/net/softnet_stat
+# /proc/net/softnet_stat
 
 Un autre extrait de l'article traitant cette fois de la gestion des interruptions réseau. Le traitement se fait à l'aide de la couche NAPI, qui est une optimisation du traitement des interruptions réseau, pour ne pas générer une interruption par paquet réseau, comme c'était le cas à l'origine, et ainsi pouvoir traiter de fortes charges réseau, sans monopoliser le CPU.
 Ce mécanisme désactive les interruptions matérielles et ce sont les interruptions logicielles qui sont en charge de venir traiter régulièrement le contenu du buffer de la carte réseau.
@@ -107,22 +106,18 @@ Un extrait de la doc pour lire ça : (TL;DR, la deuxième indique les paquets dr
 > The second value, sd->dropped, is the number of network frames dropped because there was no room on the processing queue. More on this later.
 > The third value, sd->time_squeeze, is (as we saw) the number of times the net_rx_action loop terminated because the budget was consumed or the time limit was reached, but more work could have been. Increasing the budget as explained earlier can help reduce this.
 
-
 Finalement, et contrairement à ce que je pensais au début, dans l'exemple collecté, ça ne serait peut-être pas tant la place dans le buffer qui manquerait, mais le temps pour le traiter.
 
-
-## Actions envisagées
+# Actions envisagées
 
 - allouer plus de `budget` pour traiter le contenu de ce buffer - action à chaud : `sysctl -w net.core.netdev_budget=600` (l'unité étant le paquet traité, le temps étant plafonné à 2 jiffies, il y a un effet de seuil dans l'augmentation de la valeur. Par défaut le budget est de 300)
 - augmenter la taille du ring buffer, à 1024 voir au max à 4096 - ⚠️ fait un down/up sur la carte réseau donc drop toutes les connexions en cours ⚠️ - `ethtool -G ethX rx 1024`
 
-
-## Next steps
+# Next steps
 
 Si cela ne suffit pas, d'autres pistes peuvent être explorées :
 
-- irqbalance et le fait de répartir les gestionnaires d'interruptions sur tous plusieurs cœurs et de ne surtout pas en avoir plusieurs sur le même coeur. Le budget étant assigné à un coeur, si plusieurs gestionnaires d'interruptions sont assignés au même coeur, ils partageront le même budget.
-À noter qu'un équilibrage automatique est réalisé sur les systèmes "modernes", nos centos 7 ont un process irqbalance qui tourne. Je ne m'attends donc pas à des progrès de ce côté là, mais je n'ai pas creusé.
+- irqbalance et le fait de répartir les gestionnaires d'interruptions sur tous plusieurs cœurs et de ne surtout pas en avoir plusieurs sur le même coeur. Le budget étant assigné à un coeur, si plusieurs gestionnaires d'interruptions sont assignés au même coeur, ils partageront le même budget. A noter qu'un équilibrage automatique est réalisé sur les systèmes "modernes", nos centos 7 ont un process irqbalance qui tourne. Je ne m'attends donc pas de progrès de ce côté là, mais je n'ai pas creusé.
 
 ## Quelques ressources documentaires