Performances weirdes avec eBPF pour network policy k8s

salut check d'abord ta version de kernel et de cilium les perfs eBPF sont hyper sensibles à ça surtout sur des vieilles versions. t'es en L7 policy ou juste L3/L4

kernel 5.4 avec cilium 1.9 c'est du L3/L4 de base pas de complexité. les drops sont pas constants mais quand le débit s'emballe ça se voit direct

5.4 c'est un peu ancien pour du eBPF haute perf le 5.10 ou 5.15 apporte des grosses optis surtout pour XDP t'as les cpu en mode irq ou softirq qui montent en flèche

les softirq ouais ça monte pas mal dans atop. j'ai regardé les logs du kernel mais rien d'explicite sur les drops ou des erreurs eBPF

ok si c'est les softirq c'est probablement le traitement des paquets. t'as configuré des maps ebpf avec des clés/valeurs complexes ou bcp de lookups

pas vraiment c'est des maps assez basiques pour les règles de sécurité. la complexité c'est la quantité de règles disons une centaine par node

cent règles c'est pas énorme. vérifie si tu n'as pas des `perf_event_open` leaks ou des traces qui s'accumulent. ça peut tuer le cpu sans le dire

comment je check ça les `perf_event_open` leaks t'as un outil spécifique

utilise `bpftool prog show` pour voir les programmes chargés et `bpftool map show` pour les maps. regarde aussi `cat /proc/kallsyms | grep bpf_prog_run` ou des outils comme `bcc/profile` pour identifier les hotspots cpu

j'ai lancé `bpftool` et j'ai vu que certains programmes avaient des durées d'exécution assez longues pour des opérations réseau censées être rapides. y'a un moyen de voir les jit logs du bpf verifier

pour les jit logs faut activer `echo 1 > /proc/sys/net/core/bpf_jit_enable` et `echo 1 > /proc/sys/net/core/bpf_jit_harden` et après tu regardes dans dmesg ou les logs du kernel mais ça peut être verbeux à mort

ouais et si c un souci de map access massif essaie de passer sur une structure plus optimisée si possible pour les lookups genre bpf hash map avec des clés pré-calculées ou des array maps si tes clés sont séquentielles

j'ai activé les logs du jit et j'ai vu des avertissements sur des boucles potentielles dans un de mes programmes qui est censé être simple. c'est ptete ça la source du souci quand il y a bcp de flux en parallèle

ah les boucles c'est le classique si le verifier est pas content ça ralentit ou ça rejette direct. réécris la partie critique pour éviter les boucles explicites utilise plutôt des helpers bpf_map_lookup_elem en batch si possible

on a identifié un pattern dans le code généré par cilium qui avait une petite boucle pour une inspection de header ça passait sur du faible trafic mais en charge ça partait en vrille. on a mis à jour cilium vers une version plus récente et ça a corrigé le programme bpf généré le cpu est redevenu normal et plus de drops. thx pour les pistes