On 1 February 2016 at 22:51, Dimitri John Ledkov <x...@ubuntu.com> wrote: > Build log for powerpc platform: > > https://launchpadlibrarian.net/235964133/buildlog_ubuntu-xenial-powerpc.openvswitch_2.5.0~git20160129.46a88d9-0ubuntu2.1_BUILDING.txt.gz > > Ctrl-F for "testsuite: command line was:" to jump to the "cat > tests/testuite.log" output. > > There are now 22 failures: > > Subject: [openvswitch 2.5.0] testsuite: 94 95 632 643 644 645 646 809 > 810 811 813 816 821 827 833 838 851 860 878 889 949 951 failed > > note this is with 29th of january snapshort, with these two patches > applied on top. Looks like there are more things like the first patch. > E.g.: > > -Megaflow: recirc_id=0,tcp,in_port=2,nw_dst=192.168.0.0/16,nw_frag=no > +Megaflow: recirc_id=0,tcp,in_port=131072,nw_dst=192.168.0.0/16,nw_frag=no > > in_port going from small to huge. Also in_port ANY doesn't seem to be > handled correctly: >
FYI, in_port ANY broke on any architecture. (testsuite: 860 failed) e.g. x86_64 build log https://launchpadlibrarian.net/235964138/buildlog_ubuntu-xenial-amd64.openvswitch_2.5.0~git20160129.46a88d9-0ubuntu2.1_BUILDING.txt.gz I shall pull latest repository and rebuild/retest it. Regards, Dimitri. > -arp,in_port=ANY,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.0.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=00:00:00:00:00:00 > -arp,in_port=ANY,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.128.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=00:00:00:00:00:00 > -arp,in_port=ANY,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.128.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=40:44:44:44:44:41 > -arp,in_port=ANY,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.0.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=00:00:00:00:00:00 > -arp,in_port=ANY,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.128.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=00:00:00:00:00:00 > -arp,in_port=ANY,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.128.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=40:44:44:44:44:41 > -arp,in_port=ANY,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.0.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=00:00:00:00:00:00 > -arp,in_port=ANY,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.128.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=00:00:00:00:00:00 > -arp,in_port=ANY,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.128.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=40:44:44:44:44:41 > +arp,in_port=4294967295,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.0.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=00:00:00:00:00:00 > +arp,in_port=4294967295,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.128.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=00:00:00:00:00:00 > +arp,in_port=4294967295,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.128.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=40:44:44:44:44:41 > +arp,in_port=4294967295,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.0.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=00:00:00:00:00:00 > +arp,in_port=4294967295,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.128.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=00:00:00:00:00:00 > +arp,in_port=4294967295,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.128.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=40:44:44:44:44:41 > +arp,in_port=4294967295,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.0.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=00:00:00:00:00:00 > +arp,in_port=4294967295,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.128.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=00:00:00:00:00:00 > +arp,in_port=4294967295,vlan_tci=0x0000,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.128.1,arp_tpa=192.168.0.2,arp_op=2,arp_sha=50:54:00:00:00:05,arp_tha=40:44:44:44:44:41 > > > ipv4, gre, key: > -Datapath actions: > tnl_push(tnl_port(3),header(size=42,type=3,eth(dst=f8:bc:12:44:34:b6,src=aa:55:aa:55:00:00,dl_type=0x0800),ipv4(src=1.1.2.88,dst=1.1.2.92,proto=47,tos=0,ttl=64,frag=0x4000),gre((flags=0x2000,proto=0x6558),key=0x1c8)),out_port(100)) > +Datapath actions: > tnl_push(tnl_port(3),header(size=42,type=3,eth(dst=f8:bc:12:44:34:b6,src=aa:55:aa:55:00:00,dl_type=0x0800),ipv4(src=1.1.2.88,dst=1.1.2.92,proto=47,tos=0,ttl=64,frag=0x4000),gre((flags=0x2000,proto=0x6558),key=0x0)),out_port(100)) > > Thanks a lot for looking into these issues! I'll build the git master > (with patches) on a bare metal machine (rather than a PPA) to extract > test suite files directly. > > Regards, > > Dimitri. > > > > > On 1 February 2016 at 22:19, Dimitri John Ledkov <x...@ubuntu.com> wrote: >> Hello, >> >> The reasoning sounds good, but i wouldn't understand this just by >> looking at the patch. >> >> Let me test build these both patches, and I'll let you know the results soon. >> >> Regards, >> >> Dimitri. >> >> On 1 February 2016 at 21:55, Ben Pfaff <b...@ovn.org> wrote: >>> struct flow has a union for the in_port field, and the two different >>> members of the union have different sizes: ofp_port_t is 16 bits, >>> odp_port_t is 32 bits. On little-endian machines this doesn't matter much, >>> but on big-endian machines it's important to distinguish between them >>> because a small number in odp_port_t will show up as zero when viewed >>> through ofp_port_t. >>> >>> There are in fact few parts of OVS that can handle a struct flow that >>> has either formats; most parts of OVS work with one or the other but not >>> both. match_format(), however, does need to handle both cases, and it did >>> not: it displayed small odp_port_t values as zero on big-endian platforms. >>> This commit fixes the problem by checking the mask, which indicates which >>> format is in use, and displaying the appropriate field from the union. >>> >>> Reported-by: Dimitri John Ledkov <x...@ubuntu.com> >>> Reported-at: >>> http://openvswitch.org/pipermail/discuss/2016-January/020072.html >>> Signed-off-by: Ben Pfaff <b...@ovn.org> >>> --- >>> lib/match.c | 6 ++++-- >>> 1 file changed, 4 insertions(+), 2 deletions(-) >>> >>> diff --git a/lib/match.c b/lib/match.c >>> index 95d34bc..5d4a9dc 100644 >>> --- a/lib/match.c >>> +++ b/lib/match.c >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015 Nicira, Inc. >>> + * Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016 Nicira, >>> Inc. >>> * >>> * Licensed under the Apache License, Version 2.0 (the "License"); >>> * you may not use this file except in compliance with the License. >>> @@ -1162,7 +1162,9 @@ match_format(const struct match *match, struct ds *s, >>> int priority) >>> >>> format_be64_masked(s, "metadata", f->metadata, wc->masks.metadata); >>> >>> - if (wc->masks.in_port.ofp_port) { >>> + if (wc->masks.in_port.odp_port == UINT32_MAX) { >>> + ds_put_format(s, "in_port=%"PRIu32",", f->in_port.odp_port); >>> + } else if (wc->masks.in_port.ofp_port) { >>> ds_put_cstr(s, "in_port="); >>> ofputil_format_port(f->in_port.ofp_port, s); >>> ds_put_char(s, ','); >>> -- >>> 2.1.3 >>> >> >> >> >> -- >> Regards, >> >> Dimitri. > > > > -- > Regards, > > Dimitri. -- Regards, Dimitri. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
