Hi, I've created a new patch, that does check the OpenFlow statistics of integration bridges instead of the statistics of datapath flows. I sent the patch to the dev list: https://patchwork.ozlabs.org/patch/786669/
Best regards, Zoltan > -----Original Message----- > From: Jan Scheurich > Sent: Tuesday, July 11, 2017 10:26 AM > To: Zoltán Balogh <zoltan.bal...@ericsson.com>; Darrell Ball > <db...@vmware.com>; Yang, Yi Y <yi.y.y...@intel.com>; > Eric Garver <e...@erig.me> > Cc: 'd...@openvswitch.org' <d...@openvswitch.org>; > simon.hor...@netronome.com; Jiri Benc <jb...@redhat.com> > Subject: RE: [ovs-dev] [PATCH v4 0/7] Packet type aware pipeline > > 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-boun...@openvswitch.org > > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh > > Sent: Monday, 10 July, 2017 16:37 > > To: Darrell Ball <db...@vmware.com>; Yang, Yi Y <yi.y.y...@intel.com>; Eric > > Garver <e...@erig.me> > > Cc: 'd...@openvswitch.org' <d...@openvswitch.org>; > > simon.hor...@netronome.com; Jiri Benc <jb...@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:db...@vmware.com] > > > Sent: Friday, July 07, 2017 6:56 PM > > > To: Zoltán Balogh <zoltan.bal...@ericsson.com>; Yang, Yi Y > > > <yi.y.y...@intel.com>; Eric Garver <e...@erig.me> > > > Cc: 'd...@openvswitch.org' <d...@openvswitch.org>; > > > simon.hor...@netronome.com; Jiri Benc <jb...@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.bal...@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-boun...@openvswitch.org > > > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Yang, Yi Y > > > > > > > Sent: Friday, July 07, 2017 3:36 AM > > > > > > > To: Darrell Ball <db...@vmware.com>; Eric Garver <e...@erig.me> > > > > > > > Cc: 'd...@openvswitch.org' <d...@openvswitch.org>; > > > simon.hor...@netronome.com; Jiri Benc <jb...@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-boun...@openvswitch.org > > > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Darrell Ball > > > > > > > Sent: Friday, July 7, 2017 5:06 AM > > > > > > > To: Eric Garver <e...@erig.me> > > > > > > > Cc: 'd...@openvswitch.org' <d...@openvswitch.org>; > > > simon.hor...@netronome.com; Jiri Benc <jb...@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" <db...@vmware.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 7/6/17, 1:22 PM, "Eric Garver" <e...@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: <b...@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-boun...@openvswitch.org on > > > behalf of Ben Pfaff" <ovs-dev- > > > > > > > boun...@openvswitch.org on behalf of b...@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 > > > > > > > > d...@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 > > > > > > > > d...@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 > > > > > > > d...@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 > > > > > > > d...@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 > > d...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
