On Fri, May 31, 2019 at 6:37 PM Song Liu <songliubraving@xxxxxx> wrote: > > > > > On May 31, 2019, at 10:47 AM, Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > > > xdping allows us to get latency estimates from XDP. Output looks > > like this: > > > > ./xdping -I eth4 192.168.55.8 > > Setting up XDP for eth4, please wait... > > XDP setup disrupts network connectivity, hit Ctrl+C to quit > > > > Normal ping RTT data > > [Ignore final RTT; it is distorted by XDP using the reply] > > PING 192.168.55.8 (192.168.55.8) from 192.168.55.7 eth4: 56(84) bytes of data. > > 64 bytes from 192.168.55.8: icmp_seq=1 ttl=64 time=0.302 ms > > 64 bytes from 192.168.55.8: icmp_seq=2 ttl=64 time=0.208 ms > > 64 bytes from 192.168.55.8: icmp_seq=3 ttl=64 time=0.163 ms > > 64 bytes from 192.168.55.8: icmp_seq=8 ttl=64 time=0.275 ms > > > > 4 packets transmitted, 4 received, 0% packet loss, time 3079ms > > rtt min/avg/max/mdev = 0.163/0.237/0.302/0.054 ms > > > > XDP RTT data: > > 64 bytes from 192.168.55.8: icmp_seq=5 ttl=64 time=0.02808 ms > > 64 bytes from 192.168.55.8: icmp_seq=6 ttl=64 time=0.02804 ms > > 64 bytes from 192.168.55.8: icmp_seq=7 ttl=64 time=0.02815 ms > > 64 bytes from 192.168.55.8: icmp_seq=8 ttl=64 time=0.02805 ms > > > > The xdping program loads the associated xdping_kern.o BPF program > > and attaches it to the specified interface. If run in client > > mode (the default), it will add a map entry keyed by the > > target IP address; this map will store RTT measurements, current > > sequence number etc. Finally in client mode the ping command > > is executed, and the xdping BPF program will use the last ICMP > > reply, reformulate it as an ICMP request with the next sequence > > number and XDP_TX it. After the reply to that request is received > > we can measure RTT and repeat until the desired number of > > measurements is made. This is why the sequence numbers in the > > normal ping are 1, 2, 3 and 8. We XDP_TX a modified version > > of ICMP reply 4 and keep doing this until we get the 4 replies > > we need; hence the networking stack only sees reply 8, where > > we have XDP_PASSed it upstream since we are done. > > > > In server mode (-s), xdping simply takes ICMP requests and replies > > to them in XDP rather than passing the request up to the networking > > stack. No map entry is required. > > > > xdping can be run in native XDP mode (the default, or specified > > via -N) or in skb mode (-S). > > > > A test program test_xdping.sh exercises some of these options. > > > > Note that native XDP does not seem to XDP_TX for veths, hence -N > > is not tested. Looking at the code, it looks like XDP_TX is > > supported so I'm not sure if that's expected. Running xdping in > > native mode for ixgbe as both client and server works fine. > > > > Changes since v4 > > > > - close fds on cleanup (Song Liu) > > > > Changes since v3 > > > > - fixed seq to be __be16 (Song Liu) > > - fixed fd checks in xdping.c (Song Liu) > > > > Changes since v2 > > > > - updated commit message to explain why seq number of last > > ICMP reply is 8 not 4 (Song Liu) > > - updated types of seq number, raddr and eliminated csum variable > > in xdpclient/xdpserver functions as it was not needed (Song Liu) > > - added XDPING_DEFAULT_COUNT definition and usage specification of > > default/max counts (Song Liu) > > > > Changes since v1 > > - moved from RFC to PATCH > > - removed unused variable in ipv4_csum() (Song Liu) > > - refactored ICMP checks into icmp_check() function called by client > > and server programs and reworked client and server programs due > > to lack of shared code (Song Liu) > > - added checks to ensure that SKB and native mode are not requested > > together (Song Liu) > > > > Signed-off-by: Alan Maguire <alan.maguire@xxxxxxxxxx> > > Acked-by: Song Liu <songliubraving@xxxxxx> > > Note: I am Ack'ing it as a test. It needs more work, if we would > distribute it as a tool (maybe we really would). Agree. I think it works fine as a test. ./test_xdping.sh passed in my test setup. Applied to bpf-next. Thanks
