[ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

Joe Stringer joe at ovn.org
Tue Aug 8 22:43:39 UTC 2017


On 8 August 2017 at 09:26, Darrell Ball <dball at vmware.com> wrote:
>
>
>
>
> From: <ovs-discuss-bounces at openvswitch.org> on behalf of James Page
> <james.page at ubuntu.com>
> Date: Tuesday, August 8, 2017 at 2:49 AM
> To: "bugs at openvswitch.org" <bugs at openvswitch.org>
> Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213
> 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed
>
>
>
> Hi
>
>
>
> I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 release
> for Ubuntu; we build and test two sets of binaries - a vanilla one and one
> with dpdk enabled.
>
>
>
> I see test failures on all of the "ofproto-dpif - conntrack" tests with the
> DPDK build and with the ovn ACL test (see attached logs).  Vanilla build is
> fine.
>
>
>
> James
>
>
>
> These are generic tests and should not be run with-dpdk set.
>
> If you run these tests --with-dpdk, some tests will consider the packets
> coming an actual dpdk interface, which they are not.
>
> In this case, the packets will be marked with a bad checksum.
>
>
>
> Are you able to run these tests as we do without “–with-dpdk” ?

Hmm, this seems surprising to me - I thought that "--with-dpdk" mostly
just enables another netdevice implementation. Why would this affect
input/output with netdev-dummy devices?

For what it's worth, I tried a run of the testsuite with OVS built
"--with-dpdk" on branch-2.7 and it worked fine:
https://travis-ci.org/joestringer/openvswitch/jobs/262439494

The test failures for the first few are hard-failures (ie ovs uses
WAIT_UNTIL for something that never succeeds), examples below where
OVS was waiting to receive packets that never arrive:

../../tests/ofproto-dpif.at:9016: ovs-appctl netdev-dummy/receive p2
'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
../../tests/ofproto-dpif.at:9018: hard failure

---

Some of the later failures are a bit more interesting:

../../tests/ofproto-dpif.at:9161: ovs-appctl netdev-dummy/receive p2
'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
../../tests/ofproto-dpif.at:9164: cat ovs-vswitchd.log | strip_ufid |
filter_flow_install
--- - 2017-08-08 09:39:36.051525087 +0000
+++ /build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1214/stdout
2017-08-08 09:39:36.046218819 +0000
@@ -1,5 +1,4 @@
-ct_state(+new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
actions:drop
-ct_state(-new+est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
actions:1
+ct_state(-new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
actions:drop
 recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
actions:ct(commit),2
 recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
actions:ct,recirc(0x1)

---

../../tests/ofproto-dpif.at:9738: ovs-appctl netdev-dummy/receive p1
'50540000000950540000000a080045000028258e40004006ff3d0a0101020a01010100020001396bb55e8cadbf8a5010000a5ec10000'
../../tests/ofproto-dpif.at:9740: ovs-appctl revalidator/purge
../../tests/ofproto-dpif.at:9744: cat ofctl_monitor.log
--- /dev/null 2017-04-26 10:10:32.404961898 +0000
+++ /build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1225/stdout
2017-08-08 09:40:40.454215126 +0000
@@ -0,0 +1,22 @@
+NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54
ct_state=inv|trk,in_port=1 (via action) data_len=54 (unbuffered)
+tcp,vlan_tci=0x0000,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1,tcp_flags=ack
tcp_csum:629b
+NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=55
ct_state=inv|trk,in_port=1 (via action) data_len=55 (unbuffered)
+tcp,vlan_tci=0x0000,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1,tcp_flags=psh|ack
tcp_csum:5892
+NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54
ct_state=inv|trk,in_port=2 (via action) data_len=54 (unbuffered)

---

Perhaps the activation of DPDK code is somehow adding extra checks on
things like packet checksums, but the packet passing through are not
fully formed so they get marked as invalid?


More information about the discuss mailing list