On 11/9/18 3:20 AM, Paweł Staszewski wrote: > > I just catch some weird behavior :) > All was working fine for about 20k packets > > Then after xdp start to forward every 10 packets
Interesting. Any counter showing drops? > ping 172.16.0.2 -i 0.1 > PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data. > 64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=5.12 ms > 64 bytes from 172.16.0.2: icmp_seq=9 ttl=64 time=5.20 ms > 64 bytes from 172.16.0.2: icmp_seq=19 ttl=64 time=4.85 ms > 64 bytes from 172.16.0.2: icmp_seq=29 ttl=64 time=4.91 ms > 64 bytes from 172.16.0.2: icmp_seq=38 ttl=64 time=4.85 ms > 64 bytes from 172.16.0.2: icmp_seq=48 ttl=64 time=5.00 ms > ^C > --- 172.16.0.2 ping statistics --- > 55 packets transmitted, 6 received, 89% packet loss, time 5655ms > rtt min/avg/max/mdev = 4.850/4.992/5.203/0.145 ms > > > And again after some time back to normal > > ping 172.16.0.2 -i 0.1 > PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data. > 64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=5.02 ms > 64 bytes from 172.16.0.2: icmp_seq=2 ttl=64 time=5.06 ms > 64 bytes from 172.16.0.2: icmp_seq=3 ttl=64 time=5.19 ms > 64 bytes from 172.16.0.2: icmp_seq=4 ttl=64 time=5.07 ms > 64 bytes from 172.16.0.2: icmp_seq=5 ttl=64 time=5.08 ms > 64 bytes from 172.16.0.2: icmp_seq=6 ttl=64 time=5.14 ms > 64 bytes from 172.16.0.2: icmp_seq=7 ttl=64 time=5.08 ms > 64 bytes from 172.16.0.2: icmp_seq=8 ttl=64 time=5.17 ms > 64 bytes from 172.16.0.2: icmp_seq=9 ttl=64 time=5.04 ms > 64 bytes from 172.16.0.2: icmp_seq=10 ttl=64 time=5.10 ms > 64 bytes from 172.16.0.2: icmp_seq=11 ttl=64 time=5.11 ms > 64 bytes from 172.16.0.2: icmp_seq=12 ttl=64 time=5.13 ms > 64 bytes from 172.16.0.2: icmp_seq=13 ttl=64 time=5.12 ms > 64 bytes from 172.16.0.2: icmp_seq=14 ttl=64 time=5.15 ms > 64 bytes from 172.16.0.2: icmp_seq=15 ttl=64 time=5.13 ms > 64 bytes from 172.16.0.2: icmp_seq=16 ttl=64 time=5.04 ms > 64 bytes from 172.16.0.2: icmp_seq=17 ttl=64 time=5.12 ms > 64 bytes from 172.16.0.2: icmp_seq=18 ttl=64 time=5.07 ms > 64 bytes from 172.16.0.2: icmp_seq=19 ttl=64 time=5.06 ms > 64 bytes from 172.16.0.2: icmp_seq=20 ttl=64 time=5.12 ms > 64 bytes from 172.16.0.2: icmp_seq=21 ttl=64 time=5.21 ms > 64 bytes from 172.16.0.2: icmp_seq=22 ttl=64 time=4.98 ms > ^C > --- 172.16.0.2 ping statistics --- > 22 packets transmitted, 22 received, 0% packet loss, time 2105ms > rtt min/avg/max/mdev = 4.988/5.104/5.210/0.089 ms > > > I will try to catch this with debug enabled > > > > > > Wondering also - cause xdp will bypass now vlan counters and other stuff > like tcpdump yes, xdp is before tcpdump based sockets. And the counters (vlan just being the current example) is another problem to be solved. The vlan net_device never sees the packet and you can not arbitrarily bump the counters just because the device lookups reference them. > > Is there possible to add only counters from xdp for vlans ? > This will help me in testing. I will take a look today at adding counters that you can dump using bpftool. It will be a temporary solution for this xdp program only. > > > And also - for non lab scenario there should be possible to sniff > sometimes on interface :) Yes, sampling is another problem. > Soo wondering if need to attack another xdp program to interface or all > this can be done by one > > I think this is time where i will need to learn more about xdp :) > >
