netdev - Re: [PATCH bpf-next v5] selftests/bpf: measure RTT from xdp using xdping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 31 May 2019 19:58:22 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Song Liu <songliubraving@...com>
Cc:     Alan Maguire <alan.maguire@...cle.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        "hawk@...nel.org" <hawk@...nel.org>,
        John Fastabend <john.fastabend@...il.com>,
        Networking <netdev@...r.kernel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "xdp-newbies@...r.kernel.org" <xdp-newbies@...r.kernel.org>,
        Shuah Khan <shuah@...nel.org>, Martin Lau <kafai@...com>,
        Yonghong Song <yhs@...com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>
Subject: Re: [PATCH bpf-next v5] selftests/bpf: measure RTT from xdp using xdping

On Fri, May 31, 2019 at 6:37 PM Song Liu <songliubraving@...com> wrote:
>
>
>
> > On May 31, 2019, at 10:47 AM, Alan Maguire <alan.maguire@...cle.com> 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@...cle.com>
>
> Acked-by: Song Liu <songliubraving@...com>
>
> 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