This question is related to: https://marc.info/?l=xdp-newbies&m=158462735008364&w=2
Is there a known (or maybe unknown) bug regarding the size of packets in the AF-XDP socket framework (+ libbpf)?
I am experiencing a strange packet loss for my application:
IPv4/UDP/RTP packet stream with all packets being the same size (1442 bytes): no packet loss
IPv4/UDP/RTP packet stream where pretty much all packets are the same size (1492 bytes) except a special "marker" packet (only 357 bytes but they are also IPv4/UDP-packets): all marker packets get lost
I added a bpf_printk statement in my XDP-Kernelprogram for further validation:
const int len = bpf_ntohs(iph->tot_len);
if(len < 400) {
bpf_printk("FOUND PACKET LEN < 400: %d.\n", len);
}
This output is never observed via *cat /sys/kernel/debug/tracing/trace_pipe*. So these small RTP-marker packets aren't even received by my kernel filter - no wonder why I don't receive them in userspace.
ethtool -S <if> shows me this number: rx_256_to_511_bytes_phy. This number is increasing in a similar rate as marker-packets should come in (about 30/s). So this means that my NIC does receive the packets (and so does a generic Linux socket), but my XDP-program doesn't - why?
I made further testing with *nping* which is able to generate packets with arbitrary sizes:
nping --udp -p <port> --dest-ip <ip> --data-length 372 -c 50000000 --rate 250 -N
Packets of size *372 bytes* are received but anything less is not received (ordinary linux socket does receive those packets as I said though).
The only idea that came to my mind was UMEM chunk size alignment related (option *XDP_UMEM_UNALIGNED_CHUNK_FLAG* with *MAP_HUGETLB*) - but this didn't change anything (I also don't know if changing UMEM-settings changes anything on the XDP-Kernelside).
Any idea what could be the cause of this problem?
|