[ovs-dev] [PATCH] system-traffic: Remove datapath specific tests and macro.

Joe Stringer joe at ovn.org
Fri Jul 15 00:55:25 UTC 2016


Thanks, applied to master.

By the way, the "tested-at" with travis doesn't run system-traffic
tests so it wasn't really tested there. I tried it on a local system
though and it was fine.

On 13 July 2016 at 17:30, William Tu <u9012063 at gmail.com> wrote:
> Hi Joe,
>
> I agree that this check is kind of redundant. Please remove this line.
> Thank you~
>
> William
>
>
> On Wed, Jul 13, 2016 at 4:57 PM, Joe Stringer <joe at ovn.org> wrote:
>> On 1 July 2016 at 09:45, William Tu <u9012063 at gmail.com> wrote:
>>> We generally try to keep the testsuite independent of the underlying
>>> datapath. This patch removes the datapath-specific tests and macros.
>>>
>>> Tested-at: https://travis-ci.org/williamtu/ovs-travis/builds/141642065
>>> Signed-off-by: William Tu <u9012063 at gmail.com>
>>
>> Thanks for sending this out.
>>
>>> ---
>>>  tests/system-kmod-macros.at      |  7 -------
>>>  tests/system-traffic.at          | 13 ++-----------
>>>  tests/system-userspace-macros.at |  7 -------
>>>  3 files changed, 2 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/tests/system-kmod-macros.at b/tests/system-kmod-macros.at
>>> index a3e4dd7..cee0510 100644
>>> --- a/tests/system-kmod-macros.at
>>> +++ b/tests/system-kmod-macros.at
>>> @@ -66,10 +66,3 @@ m4_define([CHECK_CONNTRACK],
>>>       on_exit 'ovstest test-netlink-conntrack flush'
>>>      ]
>>>  )
>>> -
>>> -# CHECK_KERNEL_DP, CHECK_USER_DP
>>> -#
>>> -# Ignore the CHECK_USER_DP and execute the CHECK_KERNEL_DP
>>> -#
>>> -m4_define([CHECK_KERNEL_DP], [$1])
>>> -m4_define([CHECK_USER_DP], [])
>>> diff --git a/tests/system-traffic.at b/tests/system-traffic.at
>>> index 252ed20..f8e7279 100644
>>> --- a/tests/system-traffic.at
>>> +++ b/tests/system-traffic.at
>>> @@ -334,14 +334,12 @@ dnl SLOW_ACTION test1: check datapatch actions
>>>  AT_CHECK([ovs-ofctl del-flows br0])
>>>  AT_CHECK([ovs-ofctl add-flows br0 flows.txt])
>>>
>>> -CHECK_KERNEL_DP(
>>> -AT_CHECK([ovs-appctl ofproto/trace system 'in_port(2),eth(src=e6:66:c1:11:11:11,dst=e6:66:c1:22:22:22),eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=6,tos=4,ttl=128,frag=no),tcp(src=8,dst=9)'], [0], [stdout])
>>> +AT_CHECK([ovs-appctl ofproto/trace br0 "in_port=1,dl_type=0x800,dl_src=e6:66:c1:11:11:11,dl_dst=e6:66:c1:22:22:22,nw_src=192.168.0.1,nw_dst=192.168.0.2,nw_proto=6,tp_src=8,tp_dst=9"], [0], [stdout])
>>>  AT_CHECK([tail -3 stdout], [0],
>>>  [Datapath actions: trunc(100),3,5,trunc(100),3,trunc(100),5,3,trunc(200),5,trunc(65535),3
>>>  This flow is handled by the userspace slow path because it:
>>>         - Uses action(s) not supported by datapath.
>>>  ])
>>> -)
>>>
>>>  dnl SLOW_ACTION test2: check actual packet truncate
>>>  AT_CHECK([ovs-ofctl del-flows br0])
>>> @@ -458,14 +456,7 @@ dnl SLOW_ACTION test1: check datapatch actions
>>>  AT_CHECK([ovs-ofctl del-flows br0])
>>>  AT_CHECK([ovs-ofctl add-flows br0 flows.txt])
>>>
>>> -CHECK_KERNEL_DP(
>>> -AT_CHECK([ovs-appctl ofproto/trace system 'in_port(5),eth(src=e6:66:c1:11:11:11,dst=e6:66:c1:22:22:22),eth_type(0x0800),ipv4(src=192.168.0.1,dst=192.168.0.2,proto=17,tos=4,ttl=128,frag=no),udp(src=8,dst=9)'], [0], [stdout])
>>> -AT_CHECK([tail -3 stdout], [0],
>>> -[Datapath actions: trunc(100),set(tunnel(dst=172.31.1.1,ttl=64,flags(df))),4
>>> -This flow is handled by the userspace slow path because it:
>>> -       - Uses action(s) not supported by datapath.
>>> -])
>>> -)
>>> +AT_CHECK([ovs-appctl ofproto/trace br0 "in_port=2,dl_type=0x800,dl_src=e6:66:c1:11:11:11,dl_dst=e6:66:c1:22:22:22,nw_src=192.168.0.1,nw_dst=192.168.0.2,nw_proto=17,udp_src=8,udp_dst=9"], [0], [stdout])
>>
>> I don't see any benefit to re-adding this check just to see if
>> ovs-appctl ofproto/trace returns a zero exit code. We already test
>> that the actual truncation occurs to the correct length later in the
>> test, so I see no benefit to checking the specific translation here
>> (although it was good that you verified that this was sane during your
>> own testing). With your OK, I'll remove this line and apply the patch
>> to master. Does that make sense?
>>
>> Thanks,
>> Joe



More information about the dev mailing list