[article][packet drop] Fix subsection

content/packet_drop.mdown

@@ -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 :
 
@@ -71,7 +71,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.