[ovs-dev] [PATCH v4 0/7] Packet type aware pipeline

Jan Scheurich jan.scheurich at ericsson.com
Tue Jul 11 08:26:01 UTC 2017


I think the dropped packets are indeed noise generated by the host kernel when bringing up interfaces and are dependent on system configuration and timing. Dumping datapath flows seems pretty vulnerable to such noise in system tests and it may be hard to create filters that work reliably on all systems.

Since we are checking DP flows in the normal PTAP unit tests already, perhaps we can remove the check here and instead check on something more predictable, e.g. tunnel port or stats or OpenFlow stats.

BR, Jan

> -----Original Message-----
> From: ovs-dev-bounces at openvswitch.org [mailto:ovs-dev-bounces at openvswitch.org] On Behalf Of Zoltán Balogh
> Sent: Monday, 10 July, 2017 16:37
> To: Darrell Ball <dball at vmware.com>; Yang, Yi Y <yi.y.yang at intel.com>; Eric Garver <e at erig.me>
> Cc: 'dev at openvswitch.org' <dev at openvswitch.org>; simon.horman at netronome.com; Jiri Benc <jbenc at redhat.com>
> Subject: Re: [ovs-dev] [PATCH v4 0/7] Packet type aware pipeline
> 
> Hi Darrell,
> 
> Thank you for the log and the investigation. Unfortunately, I wasn't able to reproduce the fault.
> I used two systems:
>  - Ubuntu 17.04
>    Linux host1 4.10.0-26-generic #30-Ubuntu SMP Tue Jun 27 09:30:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> 
>  - Ubuntu 14.04.5 LTS
>    Linux host2 3.16.0-70-generic #90~14.04.1-Ubuntu SMP Wed Apr 6 22:56:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> 
> The dp ports 8-13 below are veth ports. Maybe, there is a system configuration, that affects behavior of the veth ports.
> 
> +recirc_id(0),in_port(10),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(dst=255.255.255.255/128.0.0.0,frag=no), packets:2, bytes:684,
> used:0.0s, actions:drop
> +recirc_id(0),in_port(11),packet_type(ns=0,id=0),eth(dst=ff:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(frag=no), packets:2, bytes:684, used:0.0s,
> actions:drop
> +recirc_id(0),in_port(12),packet_type(ns=0,id=0),eth(dst=ff:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(frag=no), packets:2, bytes:684, used:0.0s,
> actions:drop
> +recirc_id(0),in_port(13),packet_type(ns=0,id=0),eth(dst=ff:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(frag=no), packets:2, bytes:684, used:0.0s,
> actions:drop
> +recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(dst=255.255.255.255/128.0.0.0,frag=no), packets:2, bytes:684,
> used:0.0s, actions:drop
> +recirc_id(0),in_port(9),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(dst=255.255.255.255/128.0.0.0,frag=no), packets:3, bytes:1026,
> used:0.0s, actions:drop
> 
> 
> However there are other veth ports (dp ports: 15-17) used in the unit test setup, they connect namespaces to bridges. If it's about a system
> level configuration that causes veth ports 8-13 to behave differently, I guess we should see broadcast packets from the ports connecting
> namespaces and bridges too. But we do not. Those ports connect a namespace to a bridge, and there is an m4 macro in the system-
> common-macros.at file to do this:
> 
> # ADD_VETH([port], [namespace], [ovs-br], [ip_addr] [mac_addr [gateway]])
> #
> # Add a pair of veth ports. 'port' will be added to name space 'namespace',
> # and "ovs-'port'" will be added to ovs bridge 'ovs-br'.
> #
> # The 'port' in 'namespace' will be brought up with static IP address
> # with 'ip_addr' in CIDR notation.
> #
> # Optionally, one can specify the 'mac_addr' for 'port' and the default
> # 'gateway'.
> #
> # The existing 'port' or 'ovs-port' will be removed before new ones are added.
> #
> m4_define([ADD_VETH],
>     [ AT_CHECK([ip link add $1 type veth peer name ovs-$1 || return 77])
>       CONFIGURE_VETH_OFFLOADS([$1])
>       AT_CHECK([ip link set $1 netns $2])
>       AT_CHECK([ip link set dev ovs-$1 up])
>       AT_CHECK([ovs-vsctl add-port $3 ovs-$1 -- \
>                 set interface ovs-$1 external-ids:iface-id="$1"])
>       NS_CHECK_EXEC([$2], [ip addr add $4 dev $1])
>       NS_CHECK_EXEC([$2], [ip link set dev $1 up])
>       if test -n "$5"; then
>         NS_CHECK_EXEC([$2], [ip link set dev $1 address $5])
>       fi
>       if test -n "$6"; then
>         NS_CHECK_EXEC([$2], [ip route add default via $6])
>       fi
>       on_exit 'ip link del ovs-$1'
>     ]
> )
> 
> I have not found any m4 macro to create veth port pairs for the unit test, so I used individual commands to create the dp ports 8-13, for
> instance:
> 
> AT_CHECK([ip link add p1-0 type veth peer name p0-1])
> AT_CHECK([ip link set p1-0 up])
> AT_CHECK([ip link set p0-1 up])
> AT_CHECK([ip link set dev p1-0 mtu 3300])
> AT_CHECK([ip link set dev p0-1 mtu 3300])
> on_exit 'ip link del p0-1'
> 
> Well, there is a difference compared to the VETH_ADD macro. The ADD_VETH macro disables Tx offloading for the veth port in the
> namespace. I don't know if this really matters. We could try to diable Tx offloading for ports 8-13.
> 
> diff --git a/tests/system-userspace-packet-type-aware.at b/tests/system-userspace-packet-type-aware.at
> index 65d81ce8e..1ec6fa7f6 100644
> --- a/tests/system-userspace-packet-type-aware.at
> +++ b/tests/system-userspace-packet-type-aware.at
> @@ -51,6 +51,8 @@ AT_CHECK([ip link set p1-0 up])
>  AT_CHECK([ip link set p0-1 up])
>  AT_CHECK([ip link set dev p1-0 mtu 3300])
>  AT_CHECK([ip link set dev p0-1 mtu 3300])
> +CONFIGURE_VETH_OFFLOADS([p1-0])
> +CONFIGURE_VETH_OFFLOADS([p0-1])
>  on_exit 'ip link del p0-1'
> 
>  AT_CHECK([ip link add p2-0 type veth peer name p0-2])
> @@ -58,6 +60,8 @@ AT_CHECK([ip link set p2-0 up])
>  AT_CHECK([ip link set p0-2 up])
>  AT_CHECK([ip link set dev p2-0 mtu 3300])
>  AT_CHECK([ip link set dev p0-2 mtu 3300])
> +CONFIGURE_VETH_OFFLOADS([p2-0])
> +CONFIGURE_VETH_OFFLOADS([p0-2])
>  on_exit 'ip link del p0-2'
> 
>  AT_CHECK([ip link add p3-0 type veth peer name p0-3])
> @@ -65,6 +69,8 @@ AT_CHECK([ip link set p3-0 up])
>  AT_CHECK([ip link set p0-3 up])
>  AT_CHECK([ip link set dev p3-0 mtu 3300])
>  AT_CHECK([ip link set dev p0-3 mtu 3300])
> +CONFIGURE_VETH_OFFLOADS([p3-0])
> +CONFIGURE_VETH_OFFLOADS([p0-3])
>  on_exit 'ip link del p0-3'
> 
>  # Setup bridge infrastructure
> ---
> 
> If this does not solve the problem, we can still filter dp flow entries with 'drop' action out.
> 
> diff --git a/tests/system-userspace-packet-type-aware.at b/tests/system-userspace-packet-type-aware.at
> index 1ec6fa7f6..9b0ace0fd 100644
> --- a/tests/system-userspace-packet-type-aware.at
> +++ b/tests/system-userspace-packet-type-aware.at
> @@ -348,7 +348,7 @@ NS_CHECK_EXEC([ns1], [ping -q -c 3 -i 0.3 -w 2 $N3_IP | FORMAT_PING], [0], [dnl
>  sleep 1
> 
>  AT_CHECK([
> -    ovs-appctl dpctl/dump-flows | strip_used | grep -v ipv6 | grep -v arp |sort
> +    ovs-appctl dpctl/dump-flows | strip_used | grep -v ipv6 | grep -v arp | grep -v drop| sort
>  ], [0], [flow-dump from non-dpdk interfaces:
> 
> recirc_id(0),in_port(10),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:03),eth_type(0x0800),ipv4(src=10.0.0.1,dst=10.0.0.3,proto=47,frag
> =no), packets:2, bytes:272, used:0.0s, actions:set(ipv4(src=30.0.0.1,dst=30.0.0.3)),tnl_pop(14)
>  recirc_id(0),in_port(11),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:03),eth_type(0x0800),ipv4(frag=no), packets:2, bytes:272,
> used:0.0s, actions:13
> @@ -377,7 +377,7 @@ NS_CHECK_EXEC([ns1], [ping -q -c 3 -i 0.3 -w 2 $N2_IP | FORMAT_PING], [0], [dnl
>  sleep 1
> 
>  AT_CHECK([
> -    ovs-appctl dpctl/dump-flows | strip_used | grep -v ipv6 | grep -v arp | sort
> +    ovs-appctl dpctl/dump-flows | strip_used | grep -v ipv6 | grep -v arp | grep -v drop | sort
>  ], [0], [flow-dump from non-dpdk interfaces:
>  recirc_id(0),in_port(11),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:02),eth_type(0x0800),ipv4(frag=no), packets:2, bytes:272,
> used:0.0s, actions:12
>  recirc_id(0),in_port(12),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:01),eth_type(0x0800),ipv4(frag=no), packets:2, bytes:272,
> used:0.0s, actions:11
> @@ -402,7 +402,7 @@ NS_CHECK_EXEC([ns3], [ping -q -c 3 -i 0.3 -w 2 $N1_IP | FORMAT_PING], [0], [dnl
>  sleep 1
> 
>  AT_CHECK([
> -    ovs-appctl dpctl/dump-flows | strip_used | grep -v ipv6 | grep -v arp | sort
> +    ovs-appctl dpctl/dump-flows | strip_used | grep -v ipv6 | grep -v arp | grep -v drop | sort
>  ], [0], [flow-dump from non-dpdk interfaces:
> 
> recirc_id(0),in_port(10),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:03),eth_type(0x0800),ipv4(src=10.0.0.1,dst=10.0.0.3,proto=47,frag
> =no), packets:2, bytes:272, used:0.0s, actions:set(ipv4(src=30.0.0.1,dst=30.0.0.3)),tnl_pop(14)
>  recirc_id(0),in_port(11),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:03),eth_type(0x0800),ipv4(frag=no), packets:2, bytes:272,
> used:0.0s, actions:13
> ---
> 
> Could you verify if any of the patches solves the problem?
> 
> Otherwise we could simply remove the verification of dp flows.
> 
> Best regards,
> Zoltan
> 
> 
> 
> > -----Original Message-----
> > From: Darrell Ball [mailto:dball at vmware.com]
> > Sent: Friday, July 07, 2017 6:56 PM
> > To: Zoltán Balogh <zoltan.balogh at ericsson.com>; Yang, Yi Y <yi.y.yang at intel.com>; Eric Garver <e at erig.me>
> > Cc: 'dev at openvswitch.org' <dev at openvswitch.org>; simon.horman at netronome.com; Jiri Benc <jbenc at redhat.com>
> > Subject: Re: [ovs-dev] [PATCH v4 0/7] Packet type aware pipeline
> >
> > A few points worth noting:
> >
> > 1/ This test only uses the ping application and there are no advanced options, so my first guess is
> >      distro should not matter, but I could be wrong.
> >
> > 2/ This will not be fixed by increasing the sleep time before the check below; there are extra
> >      drops for broadcast packets.
> > There are 6 extra lines of them for this failure – see the below o/p.
> > The trailing checks in the test may fail of course.
> >              If these are noise, then they can be filtered. But an explanation would be needed.
> >
> >             I assume you added sleep because you want to make sure datapath flows are established and stats are as
> > expected
> >             Again, adding more sleep for this part will not help here.
> >
> >            3/ Your group needs to be able to reproduce the issue in house.
> >                 We used standard Ubuntu 14.04 and 16.04 and also Ubuntu with upgraded kernel.
> >
> >            4/ The system tests should pass the far majority of the time.
> >
> >
> > Portion of test:
> >
> >  # Ping between N1 and N3, via the L2 GRE tunnel between br-in1 and br-in3
> > NS_CHECK_EXEC([ns1], [ping -q -c 3 -i 0.3 -w 2 $N3_IP | FORMAT_PING], [0], [dnl
> > 3 packets transmitted, 3 received, 0% packet loss, time 0ms
> > ])
> >
> > sleep 1
> >
> > AT_CHECK([
> >     ovs-appctl dpctl/dump-flows | strip_used | grep -v ipv6 | grep -v arp |sort
> > ], [0], [flow-dump from non-dpdk interfaces:
> > recirc_id(0),in_port(10),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:03),eth_type(0x0800),ipv4(src=10.0.0.1,dst=10
> > .0.0.3,proto=47,frag=no), packets:2, bytes:272, used:0.0s, actions:set(ipv4(src=30.0.0.1,dst=30.0.0.3)),tnl_pop(14)
> > recirc_id(0),in_port(11),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:03),eth_type(0x0800),ipv4(frag=no),
> > packets:2, bytes:272, used:0.0s, actions:13
> > recirc_id(0),in_port(12),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:01),eth_type(0x0800),ipv4(frag=no),
> > packets:2, bytes:244, used:0.0s, actions:11
> > recirc_id(0),in_port(13),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:02),eth_type(0x0800),ipv4(frag=no),
> > packets:2, bytes:244, used:0.0s, actions:12
> >
> >
> > relevant error output lines
> >
> > recirc_id(0),in_port(10),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:03),eth_type(0x0800),ipv4(src=10.0.0.1,dst=10
> > .0.0.3,proto=47,frag=no), packets:2, bytes:272, used:0.0s, actions:set(ipv4(src=30.0.0.1,dst=30.0.0.3)),tnl_pop(14)
> > +recirc_id(0),in_port(10),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(dst=255.255.255.255/128.0.0.0,frag=no),
> > packets:2, bytes:684, used:0.0s, actions:drop
> >  recirc_id(0),in_port(11),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:03),eth_type(0x0800),ipv4(frag=no),
> > packets:2, bytes:272, used:0.0s, actions:13
> > +recirc_id(0),in_port(11),packet_type(ns=0,id=0),eth(dst=ff:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(frag=no),
> > packets:2, bytes:684, used:0.0s, actions:drop
> >  recirc_id(0),in_port(12),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:01),eth_type(0x0800),ipv4(frag=no),
> > packets:2, bytes:244, used:0.0s, actions:11
> > +recirc_id(0),in_port(12),packet_type(ns=0,id=0),eth(dst=ff:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(frag=no),
> > packets:2, bytes:684, used:0.0s, actions:drop
> >  recirc_id(0),in_port(13),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:02),eth_type(0x0800),ipv4(frag=no),
> > packets:2, bytes:244, used:0.0s, actions:12
> > +recirc_id(0),in_port(13),packet_type(ns=0,id=0),eth(dst=ff:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(frag=no),
> > packets:2, bytes:684, used:0.0s, actions:drop
> >  recirc_id(0),in_port(15),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(dst=192.168.10.30,tos=0/0x3,frag=no),
> > packets:2, bytes:196, used:0.0s,
> > actions:tnl_push(tnl_port(14),header(size=38,type=3,eth(dst=aa:55:00:00:00:03,src=aa:55:00:00:00:01,dl_type=0x0800),
> > ipv4(src=10.0.0.1,dst=10.0.0.3,proto=47,tos=0,ttl=64,frag=0x4000),gre((flags=0x0,proto=0x6558))),out_port(5))
> >  recirc_id(0),in_port(17),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(dst=192.168.10.10,tos=0/0x3,frag=no),
> > packets:2, bytes:196, used:0.0s,
> > actions:pop_eth,tnl_push(tnl_port(14),header(size=38,type=3,eth(dst=aa:55:00:00:00:02,src=aa:55:00:00:00:03,dl_type=
> > 0x0800),ipv4(src=30.0.0.3,dst=30.0.0.2,proto=47,tos=0,ttl=64,frag=0x4000),gre((flags=0x0,proto=0x800))),out_port(7))
> >  recirc_id(0),in_port(5),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), packets:2, bytes:272, used:0.0s,
> > actions:8
> >  recirc_id(0),in_port(6),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), packets:2, bytes:244, used:0.0s,
> > actions:9
> >  recirc_id(0),in_port(7),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), packets:2, bytes:244, used:0.0s,
> > actions:10
> >
> > recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:01),eth_type(0x0800),ipv4(src=20.0.0.2,dst=20.
> > 0.0.1,proto=47,frag=no), packets:2, bytes:244, used:0.0s, actions:set(ipv4(src=10.0.0.2,dst=10.0.0.1)),tnl_pop(14)
> > +recirc_id(0),in_port(8),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(dst=255.255.255.255/128.0.0.0,frag=no),
> > packets:2, bytes:684, used:0.0s, actions:drop
> >
> > recirc_id(0),in_port(9),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:02),eth_type(0x0800),ipv4(src=30.0.0.3,dst=30.
> > 0.0.2,proto=47,frag=no), packets:2, bytes:244, used:0.0s, actions:set(ipv4(src=20.0.0.3,dst=20.0.0.2)),tnl_pop(14)
> > +recirc_id(0),in_port(9),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(dst=255.255.255.255/128.0.0.0,frag=no),
> > packets:3, bytes:1026, used:0.0s, actions:drop
> >  tunnel(src=10.0.0.2,dst=10.0.0.1,flags(-df-
> > csum)),recirc_id(0),in_port(14),packet_type(ns=1,id=0x800),ipv4(dst=192.168.10.10,frag=no), packets:2, bytes:168,
> > used:0.0s, actions:push_eth(src=00:00:00:00:00:00,dst=aa:55:aa:55:00:01),15
> >  tunnel(src=20.0.0.3,dst=20.0.0.2,flags(-df-
> > csum)),recirc_id(0),in_port(14),packet_type(ns=1,id=0x800),ipv4(dst=192.168.10.10,tos=0/0x3,frag=no), packets:2,
> > bytes:168, used:0.0s,
> > actions:tnl_push(tnl_port(14),header(size=38,type=3,eth(dst=aa:55:00:00:00:01,src=aa:55:00:00:00:02,dl_type=0x0800),
> > ipv4(src=20.0.0.2,dst=20.0.0.1,proto=47,tos=0,ttl=64,frag=0x4000),gre((flags=0x0,proto=0x800))),out_port(6))
> >  tunnel(src=30.0.0.1,dst=30.0.0.3,flags(-df-
> > csum)),recirc_id(0),in_port(14),packet_type(ns=0,id=0),eth(dst=aa:55:aa:55:00:03),eth_type(0x0800),ipv4(dst=192.168.
> > 10.30,frag=no), packets:2, bytes:196, used:0.0s, actions:17
> >
> >
> > On 7/7/17, 12:23 AM, "Zoltán Balogh" <zoltan.balogh at ericsson.com> wrote:
> >
> >     Hi,
> >
> >
> >
> >     The script seems to be stopped at line 344 in system-userspace-packet-type-aware.at. Checking root privilege
> > happens before that. There is a "sleep 1" command before line 344. Maybe it's too short on some systems.
> >
> >
> >
> >     Darell, could you share the log file of this test case, please? It should be :
> >
> >     tests/system-userspace-testsuite.dir/94/system-userspace-testsuite.log
> >
> >
> >
> >     If the log file too large, then you could try to grep for the relevant part:
> >
> >      grep -A 40 "\--- " tests/system-userspace-testsuite.dir/94/system-userspace-testsuite.log
> >
> >
> >
> >
> >
> >
> >     Thank you,
> >
> >     Zoltan
> >
> >
> >
> >     > -----Original Message-----
> >
> >     > From: ovs-dev-bounces at openvswitch.org [mailto:ovs-dev-bounces at openvswitch.org] On Behalf Of Yang, Yi Y
> >
> >     > Sent: Friday, July 07, 2017 3:36 AM
> >
> >     > To: Darrell Ball <dball at vmware.com>; Eric Garver <e at erig.me>
> >
> >     > Cc: 'dev at openvswitch.org' <dev at openvswitch.org>; simon.horman at netronome.com; Jiri Benc <jbenc at redhat.com>
> >
> >     > Subject: Re: [ovs-dev] [PATCH v4 0/7] Packet type aware pipeline
> >
> >     >
> >
> >     > I think it needs root privilege to run.
> >
> >     >
> >
> >     > -----Original Message-----
> >
> >     > From: ovs-dev-bounces at openvswitch.org [mailto:ovs-dev-bounces at openvswitch.org] On Behalf Of Darrell Ball
> >
> >     > Sent: Friday, July 7, 2017 5:06 AM
> >
> >     > To: Eric Garver <e at erig.me>
> >
> >     > Cc: 'dev at openvswitch.org' <dev at openvswitch.org>; simon.horman at netronome.com; Jiri Benc <jbenc at redhat.com>
> >
> >     > Subject: Re: [ovs-dev] [PATCH v4 0/7] Packet type aware pipeline
> >
> >     >
> >
> >     > btw, I asked Andy to check on his Trusty system and he observes the same failure.
> >
> >     >
> >
> >     > On 7/6/17, 1:39 PM, "Darrell Ball" <dball at vmware.com> wrote:
> >
> >     >
> >
> >     >
> >
> >     >
> >
> >     >     On 7/6/17, 1:22 PM, "Eric Garver" <e at erig.me> wrote:
> >
> >     >
> >
> >     >         On Thu, Jul 06, 2017 at 03:59:51PM +0000, Darrell Ball wrote:
> >
> >     >         > Patch 4 added unit tests
> >
> >     >         > One test was added to system userspace.
> >
> >     >         > I ran it many times and it has never passed.
> >
> >     >         > Is something missing in the test or supporting code ?
> >
> >     >
> >
> >     >         Works for me. Maybe there is a timing problem?
> >
> >     >
> >
> >     >     Thanks
> >
> >     >     There are races in the system tests, but those tests will pass on a second attempt.
> >
> >     >     This is 100% failure.
> >
> >     >
> >
> >     >         OVS: current master (fb16fec66498)
> >
> >     >
> >
> >     >     Tip of master - same for me
> >
> >     >
> >
> >     >         Kernel: 4.12.0-rc7+
> >
> >     >
> >
> >     >     I tried 2 kernels 4.2.0 and 3.19 – always fails in both.
> >
> >     >
> >
> >     >         OS: RHEL 7.4-ish
> >
> >     >
> >
> >     >     I really hope the distro is not relevant here
> >
> >     >     If you have reason to think so, pls speak up
> >
> >     >
> >
> >     >
> >
> >     >         >
> >
> >     >         > ## ------------------------------ ##
> >
> >     >         > ## openvswitch 2.7.90 test suite. ##
> >
> >     >         > ## ------------------------------ ##
> >
> >     >         >  94: ptap - triangle bridge setup with L2 and L3 GRE tunnels FAILED (system-userspace-packet-type-
> >
> >     > aware.at:344)
> >
> >     >         >
> >
> >     >         > ## ------------- ##
> >
> >     >         > ## Test results. ##
> >
> >     >         > ## ------------- ##
> >
> >     >         >
> >
> >     >         > ERROR: 1 test was run,
> >
> >     >         > 1 failed unexpectedly.
> >
> >     >         > ## ------------------------------------------- ##
> >
> >     >         > ## system-userspace-testsuite.log was created. ##
> >
> >     >         > ## ------------------------------------------- ##
> >
> >     >         >
> >
> >     >         > Please send `tests/system-userspace-testsuite.log' and all information you think might help:
> >
> >     >         >
> >
> >     >         >    To: <bugs at openvswitch.org>
> >
> >     >         >    Subject: [openvswitch 2.7.90] system-userspace-testsuite: 94 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-userspace-testsuite.dir'.
> >
> >     >         >
> >
> >     >         > make: *** [check-system-userspace] Error 1
> >
> >     >         > make: Leaving directory `/home/dball/openvswitch/ovs/_gcc'
> >
> >     >         >
> >
> >     >         >
> >
> >     >         >
> >
> >     >         >
> >
> >     >         > On 6/27/17, 2:29 PM, "ovs-dev-bounces at openvswitch.org on behalf of Ben Pfaff" <ovs-dev-
> >
> >     > bounces at openvswitch.org on behalf of blp at ovn.org> wrote:
> >
> >     >         >
> >
> >     >         >     On Fri, Jun 23, 2017 at 04:47:48PM +0000, Zoltán Balogh wrote:
> >
> >     >         >     >
> >
> >     >         >     > This series was started by Ben Pfaff, v3 can be found here:
> >
> >     >         >     > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> >     > 3A__patchwork.ozlabs.org_patch_778070_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=01fMZLg-sq_Rf_2X9TcxmtDN0Vx2hS2v4BABA77en0w&e=
> >
> >     >         >     > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> >     > 3A__patchwork.ozlabs.org_patch_778071_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=5fpQZh33OQ_0AGjRuJNQqvS-1E6yhFoD5TxUoLayzwM&e=
> >
> >     >         >     > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> >     > 3A__patchwork.ozlabs.org_patch_778076_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=rqnhEoIuJ9rECQaXZafZGrAW9us8y184GCexqK8VUxQ&e=
> >
> >     >         >     > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> >     > 3A__patchwork.ozlabs.org_patch_778072_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=p5Fnh2SQ8fUrNF0V8ChNRQyQLmbjiuvKRd1UUwE93s8&e=
> >
> >     >         >     > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> >     > 3A__patchwork.ozlabs.org_patch_778074_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=02CPoSKkiGGsFX4neL8TpGa75VUPaaeNYWz_2WbqBsQ&e=
> >
> >     >         >     > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> >     > 3A__patchwork.ozlabs.org_patch_778073_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=eMl7m4NpJSD07nXTN_oOdQFvysmJnclSRw39GgGg9BQ&e=
> >
> >     >         >     > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> >     > 3A__patchwork.ozlabs.org_patch_778075_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=71zSrD_kcUjZwuKvjfeqam_rdCpeXuxtm4TW_SsZ_3w&e=
> >
> >     >         >     >
> >
> >     >         >     > Ben's series is based on this one:
> >
> >     >         >     > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> >     > 3A__patchwork.ozlabs.org_patch_770490_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=W1AcbVTr4qKOBEfQuMSmVH-Illfhs0R3TYJs1s9HtfU&e=
> >
> >     >         >     > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> >     > 3A__patchwork.ozlabs.org_patch_770487_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=EHhVEHj-Pvdl0I609BkK_Z44CV-641MVWlLy7rZH6Qo&e=
> >
> >     >         >     > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> >     > 3A__patchwork.ozlabs.org_patch_770495_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=izZUroix8O9Bcg5XNCmvsEseCctZfho3ovxvZRz0rwI&e=
> >
> >     >         >     > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> >     > 3A__patchwork.ozlabs.org_patch_770498_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=VFf2BDMVyA1OU5h0hCBJFboZtp_U2NlqmPYkLDGnWnE&e=
> >
> >     >         >     > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> >     > 3A__patchwork.ozlabs.org_patch_770488_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=3_rtktraZwXdr6VkYz8ujpi_eV9MDKc8EwCDk43nnLg&e=
> >
> >     >         >     > https://urldefense.proofpoint.com/v2/url?u=https-
> >
> >     > 3A__patchwork.ozlabs.org_patch_770489_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=1OhDZfiGpq3GF4Vie9KKwKudHEAHpG8nj8qTMqlmKV8&e=
> >
> >     >         >     >
> >
> >     >         >     > v1->v2:
> >
> >     >         >     >   - Squash fixup patches.
> >
> >     >         >     >   - Apply changes agreed with Jan.
> >
> >     >         >     >   - Not yet done: Figure out whether to really show packet_type in (some)
> >
> >     >         >     >     match_format() output.
> >
> >     >         >     >   - New patch at the end unsuccessfully tries to re-enable packet-aware
> >
> >     >         >     >     test.  Either I don't have enough insight yet, or it just reveals a
> >
> >     >         >     >     bug or two.
> >
> >     >         >     >   - 4 new patches at beginning.  First one is trivial.  Next 3 are intended
> >
> >     >         >     >     to make it easier to debug the packet aware test that is still failing.
> >
> >     >         >     >     Jan, you don't have to feel obligated to review these if you feel they
> >
> >     >         >     >     are off-topic; I will get separate reviews.
> >
> >     >         >     >
> >
> >     >         >     > v2->v3:
> >
> >     >         >     >   - Drop first two patches, which have been applied to master.
> >
> >     >         >     >   - Drop patches 3 and 4, which have been moved to a new series.
> >
> >     >         >     >   - Drop last patch, which was incomplete.  I'll hope that Jan or Zoltan
> >
> >     >         >     >     can pick it back up.
> >
> >     >         >     >   - Apply Jan's and Zoltan's comments on a few other patches.
> >
> >     >         >     >
> >
> >     >         >     > v3->v4:
> >
> >     >         >     >   - Rebase to recent origin/master (0722f3410).
> >
> >     >         >     >   - Re-introduce packet-type aware unit tests.
> >
> >     >         >     >   - Unwildcard dl_type only for packet_type=PT_ETH.
> >
> >     >         >     >   - Apply comments.
> >
> >     >         >
> >
> >     >         >     Thanks.  I applied this series to master.
> >
> >     >         >     _______________________________________________
> >
> >     >         >     dev mailing list
> >
> >     >         >     dev at openvswitch.org
> >
> >     >         >     https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-
> >
> >     > 2Ddev&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=eFnoeVgPHfExQ3X4kGuiRhqxnn-iw7rq2RoY9fvwj4I&e=
> >
> >     >         >
> >
> >     >         >
> >
> >     >         > _______________________________________________
> >
> >     >         > dev mailing list
> >
> >     >         > dev at openvswitch.org
> >
> >     >         > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-
> >
> >     > 2Ddev&d=DwIDAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-
> >
> >     > uZnsw&m=msEftCAccuIB4BWrvoXOXgDDsp7LUK5CHuIscL6JtsY&s=wbZ8iJo4O-gC9UmULTSz6NABL3Dmz-9d-Pg_28JNlmE&e=
> >
> >     >
> >
> >     >
> >
> >     >
> >
> >     >
> >
> >     > _______________________________________________
> >
> >     > dev mailing list
> >
> >     > dev at openvswitch.org
> >
> >     > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-
> > 2Ddev&d=DwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-
> >
> uEs&r=dGZmbKhBG9tJHY4odedsGA&m=L7nAsK74d2EKUrXtQVIVX1ExwBLsoe6W3XwyyU6lvi0&s=lEqDjzoYGuE8UKddAndoqJC_x_HwlzECAD
> Vds-
> > 2P0uU&e=
> >
> >     > _______________________________________________
> >
> >     > dev mailing list
> >
> >     > dev at openvswitch.org
> >
> >     > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-
> > 2Ddev&d=DwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-
> >
> uEs&r=dGZmbKhBG9tJHY4odedsGA&m=L7nAsK74d2EKUrXtQVIVX1ExwBLsoe6W3XwyyU6lvi0&s=lEqDjzoYGuE8UKddAndoqJC_x_HwlzECAD
> Vds-
> > 2P0uU&e=
> >
> >
> 
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev


More information about the dev mailing list