-----Original Message-----
From: Joe Stringer <[email protected]>
Date: Tuesday, August 8, 2017 at 3:43 PM
To: Darrell Ball <[email protected]>
Cc: James Page <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213
1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed
On 8 August 2017 at 09:26, Darrell Ball <[email protected]> wrote:
>
>
>
>
> From: <[email protected]> on behalf of James Page
> <[email protected]>
> Date: Tuesday, August 8, 2017 at 2:49 AM
> To: "[email protected]" <[email protected]>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_joestringer_openvswitch_jobs_262439494&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=2rYtIAwBngD_iZxhgs9_RxL9aNIlVqYJNRfdSppMEKw&s=j1JxZ5I8Yj0xapAPLtfpPqwTHiqQEUmUf2ZBdqdJkOo&e=
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)
[Darrell]
Thanks
2.7 will work fine.
I have already traced the errors and know why they are occurred; the new HWOL
bad checksum flags are not initialized.
I sent a patch this morning
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/337042.html
---
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?
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
