kleph/blog
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

[article][packet drop] Fix subsection
All checks were successful
continuous-integration/drone/push Build is passing
Details

Browse source
This commit is contained in:
kleph 2020-10-27 19:48:36 +01:00
parent 22158e3371
commit 16a8ad21d7
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
content/packet_drop.mdown
View file

@ -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). 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 : 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. 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. 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. 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.