[ovs-dev] [PATCH] tests: Add gre test that doesn't requiring Linux gre module

Yifeng Sun pkusunyifeng at gmail.com
Fri Jul 13 04:41:33 UTC 2018


Hi Darrell,

Thanks. There are really lots of things to consider. I will come up with v2.

Best,
Yifeng

On Thu, Jul 12, 2018 at 7:14 PM, Darrell Ball <dlu998 at gmail.com> wrote:

>
>
> On Wed, Jul 11, 2018 at 2:49 PM, Yifeng Sun <pkusunyifeng at gmail.com>
> wrote:
>
>> Hi Darrell,
>>
>> Thanks for the test. It shouldn't be that slow. For the same
>> 'nsh -forward' test, it is pretty fast on my test machine.
>>
>> ## ------------------------------ ##
>> ## openvswitch 2.9.90 test suite. ##
>> ## ------------------------------ ##
>> 111: nsh - forward                                   ok
>>
>> ## ------------- ##
>> ## Test results. ##
>> ## ------------- ##
>>
>> 1 test was successful.
>> make[1]: Leaving directory '/home/yfs/disk2/ovs'
>>
>> real    0m14.501s
>> user    0m7.121s
>> sys     0m1.873s
>>
>> What testing environment are you using?
>>
>> Best,
>> Yifeng
>>
>
>
> Hio Yifeng
>
> sorry, missed this response
>
> 1/ As discussed, I am using several common Ubuntu (and other) distros in
> Fusion on MAC and you are now seeing the same
> vert long timing in this environment. Since this is a very common
> environment, probably it needs support.
>
> Maybe you can avoid the sendpkt script, as discussed; the running time is
> too slow on common systems.
>
> 2/ As discussed, why you see a pass on the kmod test and William and I see
> fail is obviously a problem.
>
> 3/ More strange is the failure both you and I see with userspace datapath
> is different than the kernel failure I see.
>
> Thanks Darrell
>
>
>
>
>>
>> On Tue, Jul 10, 2018 at 7:08 PM, Darrell Ball <dlu998 at gmail.com> wrote:
>>
>>> Thanks for the patch Yifeng
>>>
>>> I gave the patch a spin.
>>>
>>> Few datapoints:
>>>
>>> 1/ The new test fails for both userspace and kernel; at different points
>>> in the test, lines 377 and 395
>>>     respectively; I later tried increasing the sleep time to 5 seconds,
>>> but it did not seem to help.
>>>
>>> 2/ The test runs pretty slow for an arp/ICMP test.
>>>      It takes about 35 seconds for the test to fail at line 377 and 140
>>> seconds to fail at line 395.
>>>
>>>
>>> ## openvswitch 2.9.90 test suite. ##
>>> ## ------------------------------ ##
>>>  12: datapath - ping over gre tunnel by simulated packets FAILED (
>>> system-traffic.at:395)
>>>
>>> ## ------------- ##
>>> ## Test results. ##
>>> ## ------------- ##
>>>
>>> ERROR: 1 test was run,
>>> 1 failed unexpectedly.
>>> ## -------------------------------------- ##
>>> ## system-kmod-testsuite.log was created. ##
>>> ## -------------------------------------- ##
>>>
>>> Please send `tests/system-kmod-testsuite.log' and all information you
>>> think might help:
>>>
>>>    To: <bugs at openvswitch.org>
>>>    Subject: [openvswitch 2.9.90] system-kmod-testsuite: 12 failed
>>>
>>> You may investigate any problem if you feel able to do so, in which
>>> case the test suite provides a good starting point.  Its output may
>>> be found below `tests/system-kmod-testsuite.dir'.
>>>
>>> make[1]: *** [check-kernel] Error 1
>>> make[1]: Leaving directory `/home/dball/openvswitch/ovs/_gcc'
>>> make: *** [check-kmod] Error 2
>>> make: Leaving directory `/home/dball/openvswitch/ovs/_gcc'
>>>
>>> real 2m17.951s
>>> user 0m7.528s
>>> sys 0m0.944s
>>>
>>>
>>>      In the same environment, test 1 takes about 5 seconds to complete
>>>
>>> ## ------------------------------ ##
>>> ## openvswitch 2.9.90 test suite. ##
>>> ## ------------------------------ ##
>>>   1: datapath - ping between two ports               ok
>>>
>>> ## ------------- ##
>>> ## Test results. ##
>>> ## ------------- ##
>>>
>>> 1 test was successful.
>>> make: Leaving directory `/home/dball/openvswitch/ovs/_gcc'
>>>
>>> real 0m4.937s
>>> user 0m1.440s
>>> sys 0m0.304s
>>>
>>>
>>> 3/ I noticed the 4 other sendpkt tests, which are simple crafted packet
>>> injection tests, also run slow - 1.5 to 4 minutes per test
>>>     for a successful run.
>>>
>>>  ## ------------------------------ ##
>>> ## openvswitch 2.9.90 test suite. ##
>>> ## ------------------------------ ##
>>> 111: nsh - forward                                   ok
>>>
>>> ## ------------- ##
>>> ## Test results. ##
>>> ## ------------- ##
>>>
>>> 1 test was successful.
>>> make: Leaving directory `/home/dball/openvswitch/ovs/_gcc'
>>>
>>> real 4m10.855s
>>> user 0m1.664s
>>> sys 0m0.304s
>>>
>>>
>>> Darrell
>>>
>>> On Tue, Jul 10, 2018 at 12:24 PM, Yifeng Sun <pkusunyifeng at gmail.com>
>>> wrote:
>>>
>>>> Currently check-kmod's gre test is broken on certain kernel
>>>> versions where ovs's gre module conflits with kernel's gre
>>>> module. But at the same time, present gre test depends on
>>>> Linux gre module to setup gre port.
>>>>
>>>> This patch repairs the gre test by completely removing the
>>>> dependancy of kernel's gre module and emulating a virtual
>>>> Linux gre port that sends out arp and icmp packets.
>>>>
>>>> Suggested-by: William Tu <u9012063 at gmail.com>
>>>> Signed-off-by: Yifeng Sun <pkusunyifeng at gmail.com>
>>>> ---
>>>>  tests/system-common-macros.at | 13 +++++++++
>>>>  tests/system-traffic.at       | 67 ++++++++++++++++++++++++++++++
>>>> +++++++++++++
>>>>  2 files changed, 80 insertions(+)
>>>>
>>>> diff --git a/tests/system-common-macros.at b/tests/
>>>> system-common-macros.at
>>>> index 64bf5ec63ab4..7b841250c383 100644
>>>> --- a/tests/system-common-macros.at
>>>> +++ b/tests/system-common-macros.at
>>>> @@ -329,3 +329,16 @@ m4_define([OVS_CHECK_IPROUTE_ENCAP],
>>>>  # OVS_CHECK_CT_CLEAR()
>>>>  m4_define([OVS_CHECK_CT_CLEAR],
>>>>      [AT_SKIP_IF([! grep -q "Datapath supports ct_clear action"
>>>> ovs-vswitchd.log])])
>>>> +
>>>> +# GEN_ICMP_DATA([start], [len])
>>>> +#
>>>> +# Generate space-separated ICMP data that is acceptable to
>>>> tests/sendpkt.py.
>>>> +m4_define([GEN_ICMP_DATA],
>>>> +    [[
>>>> +      ICMP_DATA=""
>>>> +      for (( n=0; n<$2; n++ )); do
>>>> +          ICMP_DATA="${ICMP_DATA} $(printf %x $((($1+n) % 256)))"
>>>> +      done
>>>> +      echo "$ICMP_DATA"
>>>> +    ]]
>>>> +)
>>>> diff --git a/tests/system-traffic.at b/tests/system-traffic.at
>>>> index 519b234bb16b..37421ed1e78a 100644
>>>> --- a/tests/system-traffic.at
>>>> +++ b/tests/system-traffic.at
>>>> @@ -339,6 +339,73 @@ NS_CHECK_EXEC([at_ns0], [ping -s 3200 -q -c 3 -i
>>>> 0.3 -w 2 10.1.1.100 | FORMAT_PI
>>>>  OVS_TRAFFIC_VSWITCHD_STOP
>>>>  AT_CLEANUP
>>>>
>>>> +AT_SETUP([datapath - ping over gre tunnel by simulated packets])
>>>> +OVS_CHECK_GRE()
>>>> +
>>>> +OVS_TRAFFIC_VSWITCHD_START()
>>>> +AT_CHECK([ovs-vsctl -- set bridge br0 other-config:hwaddr=\"f2:ff:00
>>>> :00:00:01\"])
>>>> +ADD_BR([br-underlay], [set bridge br-underlay
>>>> other-config:hwaddr=\"f2:ff:00:00:00:02\"])
>>>> +
>>>> +AT_CHECK([ovs-ofctl add-flow br0 "actions=normal"])
>>>> +AT_CHECK([ovs-ofctl add-flow br-underlay "actions=normal"])
>>>> +
>>>> +ADD_NAMESPACES(at_ns0)
>>>> +
>>>> +dnl Set up underlay link from host into the namespace using veth pair.
>>>> +ADD_VETH(p0, at_ns0, br-underlay, "172.31.1.1/24", f2:ff:00:00:00:03)
>>>> +AT_CHECK([ip addr add dev br-underlay "172.31.1.100/24"])
>>>> +AT_CHECK([ip link set dev br-underlay up])
>>>> +
>>>> +dnl Set up tunnel endpoints on OVS outside the namespace.
>>>> +ADD_OVS_TUNNEL([gre], [br0], [at_gre0], [172.31.1.1], [10.1.1.100/24])
>>>> +
>>>> +ip netns exec at_ns0 tcpdump -U -i p0 -w p0.pcap &
>>>> +
>>>> +dnl First, check the underlay.
>>>> +NS_CHECK_EXEC([at_ns0], [ping -q -c 3 -i 0.3 -w 2 172.31.1.100 |
>>>> FORMAT_PING], [0], [dnl
>>>> +3 packets transmitted, 3 received, 0% packet loss, time 0ms
>>>> +])
>>>> +
>>>> +dnl Okay, now we don't actually add the port as below, instead, we
>>>> +dnl emulate it. Suppose its mac address is f2:ff:00:00:00:04.
>>>> +dnl ADD_NATIVE_TUNNEL([gretap], [ns_gre0], [at_ns0], [172.31.1.100], [
>>>> 10.1.1.1/24])
>>>> +
>>>> +dnl Okay, now send out an arp request from 10.1.1.1 for 10.1.1.100 in
>>>> gre.
>>>> +NS_CHECK_EXEC([at_ns0], [$PYTHON $srcdir/sendpkt.py p0 f2 ff 00 00 00
>>>> 02 f2 ff 00 00 00 03 08 00 45 00 00 42 ec 2c 40 00 40 2f f3 bc ac 1f 01 01
>>>> ac 1f 01 64 00 00 65 58 ff ff ff ff ff ff f2 ff 00 00 00 04 08 06 00 01 08
>>>> 00 06 04 00 01 f2 ff 00 00 00 04 0a 01 01 01 00 00 00 00 00 00 0a 01 01 64
>>>> > /dev/null])
>>>> +
>>>> +sleep 1
>>>> +AT_CHECK([tcpdump -xx -r p0.pcap 2>&1 | egrep "IP 172.31.1.100 >
>>>> 172.31.1.1: GREv0, length 46: ARP, Reply 10.1.1.100 is-at
>>>> f2:ff:00:00:00:01 .* length 28" 2>&1 1>/dev/null])
>>>> +
>>>> +dnl Oaky, now check the overlay by sending out raw icmp packets of
>>>> +dnl different sizes in gre protocol.
>>>> +
>>>> +dnl First, send the packet that emulates
>>>> +dnl `ip netns exec at_ns0 ping 10.1.1.100`
>>>> +NS_CHECK_EXEC([at_ns0], [$PYTHON $srcdir/sendpkt.py p0 f2 ff 00 00 00
>>>> 02 f2 ff 00 00 00 03 08 00 45 00 00 7a ec 8e 40 00 40 2f f3 22 ac 1f 01 01
>>>> ac 1f 01 64 00 00 65 58 f2 ff 00 00 00 01 f2 ff 00 00 00 04 08 00 45 00 00
>>>> 54 54 8f 40 00 40 01 cf b3 0a 01 01 01 0a 01 01 64 08 00 e6 e8 29 27 00 03
>>>> e1 a3 43 5b 00 00 00 00 ff 1a 05 00 00 00 00 00 $(GEN_ICMP_DATA(16, 40)) >
>>>> /dev/null])
>>>> +
>>>> +sleep 1
>>>> +AT_CHECK([tcpdump -xx -r p0.pcap 2>&1 | egrep "IP 172.31.1.100 >
>>>> 172.31.1.1: GREv0, length 102: IP 10.1.1.100 > 10.1.1.1: ICMP echo
>>>> reply, .* length 64$" 2>&1 1>/dev/null])
>>>> +
>>>> +dnl Second, send the packet that emulates
>>>> +dnl `ip netns exec at_ns0 ping -s 1600 10.1.1.100`
>>>> +NS_CHECK_EXEC([at_ns0], [$PYTHON $srcdir/sendpkt.py p0 f2 ff 00 00 00
>>>> 02 f2 ff 00 00 00 03 08 00 45 00 05 ca 9a 7b 40 00 40 2f 3f e6 ac 1f 01 01
>>>> ac 1f 01 64 00 00 65 58 f2 ff 00 00 00 01 f2 ff 00 00 00 04 08 00 45 00 05
>>>> a4 6d 4d 20 00 40 01 d1 a5 0a 01 01 01 0a 01 01 64 08 00 11 cc 13 ed 00 01
>>>> 82 c6 43 5b 00 00 00 00 d2 e1 0c 00 00 00 00 00 $(GEN_ICMP_DATA(16, 1400))
>>>> > /dev/null])
>>>> +NS_CHECK_EXEC([at_ns0], [$PYTHON $srcdir/sendpkt.py p0 f2 ff 00 00 00
>>>> 02 f2 ff 00 00 00 03 08 00 45 00 00 f2 9a 7c 40 00 40 2f 44 bd ac 1f 01 01
>>>> ac 1f 01 64 00 00 65 58 f2 ff 00 00 00 01 f2 ff 00 00 00 04 08 00 45 00 00
>>>> cc 6d 4d 00 b2 40 01 f5 cb 0a 01 01 01 0a 01 01 64 $(GEN_ICMP_DATA(136,
>>>> 184)) > /dev/null])
>>>> +
>>>> +sleep 1
>>>> +AT_CHECK([tcpdump -xx -r p0.pcap 2>&1 | egrep "IP 172.31.1.100 >
>>>> 172.31.1.1: GREv0, length 222: IP 10.1.1.100 > 10.1.1.1: icmp" 2>&1
>>>> 1>/dev/null])
>>>> +
>>>> +dnl Lastly, send the packet that emulates
>>>> +dnl `ip netns exec at_ns0 ping -s 3200 10.1.1.100`
>>>> +NS_CHECK_EXEC([at_ns0], [$PYTHON $srcdir/sendpkt.py p0 f2 ff 00 00 00
>>>> 02 f2 ff 00 00 00 03 08 00 45 00 05 ca 9b 5e 40 00 40 2f 3f 03 ac 1f 01 01
>>>> ac 1f 01 64 00 00 65 58 f2 ff 00 00 00 01 f2 ff 00 00 00 04 08 00 45 00 05
>>>> a4 6d af 20 00 40 01 d1 43 0a 01 01 01 0a 01 01 64 08 00 55 ce 13 f4 00 03
>>>> 84 c6 43 5b 00 00 00 00 29 4c 02 00 00 00 00 00 $(GEN_ICMP_DATA(16, 1400))
>>>> > /dev/null])
>>>> +NS_CHECK_EXEC([at_ns0], [$PYTHON $srcdir/sendpkt.py p0 f2 ff 00 00 00
>>>> 02 f2 ff 00 00 00 03 08 00 45 00 05 ca 9b 5f 40 00 40 2f 3f 02 ac 1f 01 01
>>>> ac 1f 01 64 00 00 65 58 f2 ff 00 00 00 01 f2 ff 00 00 00 04 08 00 45 00 05
>>>> a4 6d af 20 b2 40 01 d0 91 0a 01 01 01 0a 01 01 64 $(GEN_ICMP_DATA(136,
>>>> 1424)) > /dev/null])
>>>> +NS_CHECK_EXEC([at_ns0], [$PYTHON $srcdir/sendpkt.py p0 f2 ff 00 00 00
>>>> 02 f2 ff 00 00 00 03 08 00 45 00 01 a2 9b 60 40 00 40 2f 43 29 ac 1f 01 01
>>>> ac 1f 01 64 00 00 65 58 f2 ff 00 00 00 01 f2 ff 00 00 00 04 08 00 45 00 01
>>>> 7c 6d af 01 64 40 01 f4 07 0a 01 01 01 0a 01 01 64 $(GEN_ICMP_DATA(24,
>>>> 360)) > /dev/null])
>>>> +
>>>> +sleep 1
>>>> +AT_CHECK([tcpdump -xx -r p0.pcap 2>&1 | egrep "IP 172.31.1.100 >
>>>> 172.31.1.1: GREv0, length 398: IP 10.1.1.100 > 10.1.1.1: icmp" 2>&1
>>>> 1>/dev/null])
>>>> +
>>>> +OVS_TRAFFIC_VSWITCHD_STOP
>>>> +AT_CLEANUP
>>>> +
>>>>  AT_SETUP([datapath - ping over erspan v1 tunnel])
>>>>  OVS_CHECK_GRE()
>>>>  OVS_CHECK_ERSPAN()
>>>> --
>>>> 2.7.4
>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev at openvswitch.org
>>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>>>
>>>
>>>
>>
>


More information about the dev mailing list