When attaching an XDP program in native (driver) mode and returning XDP_PASS for all received packets, the NIC’s RX ring buffers eventually fills up from just a simple ICMP ping from another computer (5 packets/second max).
Kernel version: Linux 6.14.0
Driver: igb
NIC: enp4s0 (Intel i211AT )
XDP mode: Native (driver) mode
Program behavior: Returns XDP_PASS for all packets
cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
lo: 17280 240 0 0 0 0 0 0 17280 240 0 0 0 0 0 0
enp1s0: 2218389 26845 0 4964 0 0 0 4175 946204 7574 0 0 0 0 0 0
enp2s0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
enp3s0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
enp4s0: 75154 613 0 9980 9980 0 0 2 53154 555 0 0 0 0 0 0
ethtool -S enp4s0
NIC statistics:
rx_packets: 839
tx_packets: 553
rx_bytes: 106556
tx_bytes: 55496
rx_broadcast: 104
tx_broadcast: 0
rx_multicast: 2
tx_multicast: 17
multicast: 2
collisions: 0
rx_crc_errors: 0
rx_no_buffer_count: 1
rx_missed_errors: 9980 <-------------------------
ethtool -i enp4s0
driver: igb
version: 6.14.0-33-generic
firmware-version: 0. 6-1
expansion-rom-version:
bus-info: 0000:04:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
CPU: Intel Embedded Atom series E3845, 1.91 GHz quad core with 64 bit and AES-NI support, 24K 6-way L1 data + 32K 8-way L1 instruction cache per core, 512KB L2 cache per core (Total 2MB).
DRAM: SODIMM DDR3-1333 DRAM
Connectivity: 4 Gigabit Ethernet channels (Intel i211AT )
Linux kernel 6.17.2
PCIe controller
Can't see how a simple ICMP ping can fill the RX ring buffer so quickly that the kernel can't catch up
