[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