Das Laden eines eBPF-Programms führt zu einer Änderung der IRQ-Affinitäten - (ixgbe-Treiber)

Das Laden eines eBPF-Programms führt zu einer Änderung der IRQ-Affinitäten - (ixgbe-Treiber)

Ich arbeite an einer eBPF/XDP-Anwendung, die auf einem Server mit Intel 10G X550T-Netzwerkkarten läuft und den ixgbe-Treiber verwendet.

Ich brauche eine genaue Kontrolle darüber, wie die Arbeit zwischen den Kernen verteilt wird, also deaktiviere ich irqbalance und stelle die IRQ-Affinität manuell ein. Ich habe ein kurzes Python-Skript geschrieben, um /proc/interrupts und /proc/irq/X/smp_affinity zu lesen und anzuzeigen, welche CPU-Kerne den Interrupt für jede Warteschlange verarbeiten sollen:

Die int0-Netzwerkkarte ist mit 40 Warteschlangen konfiguriert und die Maschine verfügt über 40 Kerne. Nach dem Ausführen meiner manuellen Konfiguration sieht die Zuordnung Warteschlange->Kern folgendermaßen aus:

# python3 show_ints.py
int0       : [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39]

Wenn ich jedoch auch nur das trivialste eBPF-Programm auf dieses Gerät lade, geschieht Folgendes:

int xdp_sock_prog(struct xdp_md *ctx)
{
    return( XDP_PASS );
}
# xdp-loader load -m native int0 test.o

die IRQ-Affinität scheint geändert zu sein:

# python3 show_ints.py
int0       : [0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, 25, 27, 29, 31, 33, 35, 37, 39]

Dies wäre an sich kein Problem – es würde lediglich eine Neuanordnung der Kerne darstellen –, aber dieser Computer verfügt über mehrere Netzwerkkarten, und jedes Mal, wenn ich versuche, bestimmte Kerne direkt der Handhabung bestimmter Warteschlangen auf bestimmten Netzwerkkarten zuzuweisen, bringt die eBPF-Last alles durcheinander, sodass immer mehrere Netzwerkkarten dieselben Kerne beanspruchen (was ich nicht will!).

Ist das das erwartete Verhalten? Gibt es eine Möglichkeit, es zu deaktivieren?

Bearbeiten (zusätzliche Informationen):

Die IRQs selbst ändern sich nicht...

Vor:

int0       IRQs : [79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181]
int0       CPUs : [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39]

Nach:

int0       IRQs : [79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181]
int0       CPUs : [0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, 25, 27, 29, 31, 33, 35, 37, 39]

Es wird also nur die smp_affinity optimiert.

Entschuldigen Sie, dass ich keine Versionsinformationen angegeben habe – dies ist die generische Version 5.15.0-79 unter Ubuntu 22.04.

Weitere Bearbeitung:

Hmmm ... wenn das eBPF-Programm geladen ist, zeigt dmesg:

[66216.150088] ixgbe 0000:3b:00.0: removed PHC on int0
[66216.927782] ixgbe 0000:3b:00.0: registered PHC device on int0
[66221.735857] ixgbe 0000:3b:00.0 int0: NIC Link is Up 10 Gbps, Flow Control: None

verwandte Informationen