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

Zoltán Balogh zoltan.balogh at ericsson.com
Mon Jul 10 14:37:14 UTC 2017


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_HwlzECADVds-
> 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_HwlzECADVds-
> 2P0uU&e=
> 
> 



More information about the dev mailing list