> This is clever! I think that this kind of approach is the right one. > > I don't yet understand why this should be moved from xlate_wc_finish() > to revalidate_ukey__(). Can you help me understand that?
Hi Ben, Thanks for reviewing the patch. When I use the same fix in xlate_wc_finish() I get several unit test failures: 0738 0756 0763 0768 2247 2251 2255 2256. 0738: -Megaflow: recirc_id=0,eth,ip,tun_id=0,tun_src=1.1.1.1,tun_dst=2.2.2.2,tun_tos=3,tun_fl ags=-df-csum-key,in_port=1,nw_ecn=3,nw_frag=no +Megaflow: recirc_id=0,eth,ip,tun_src=1.1.1.1,tun_dst=2.2.2.2,tun_tos=3,tun_flags=-df-c sum-key,in_port=1,nw_ecn=3,nw_frag=no 0756: -Megaflow: recirc_id=0,eth,ip,tun_id=0,tun_src=1.1.1.1,tun_dst=1.1.1.2,tun_tos=0,tun_fl ags=+df-csum+key,tun_metadata0,tun_metadata1=NP,tun_metadata2=NP,in_port=1,n w_frag=no +Megaflow: recirc_id=0,eth,ip,tun_id=0,tun_src=1.1.1.1,tun_dst=1.1.1.2,tun_tos=0,tun_fl ags=+df-csum+key,tun_metadata0,in_port=1,nw_frag=no 0763: +2020-01-23T06:05:58.695Z|00002|odp_util(revalidator9)|WARN|unexpected L3 matching with masked Ethertype 0x800/0 +2020-01-23T06:05:58.695Z|00003|odp_util(revalidator9)|WARN|the flow mask in error is: skb_priority(0),tunnel(tun_id=0xffffffffffffffff,src=255.255.255.255,dst=255 .255.255.255,tos=0xff,ttl=0,flags(df|csum|key)),skb_mark(0),ct_state(0),ct_z one(0),ct_mark(0),ct_label(0),recirc_id(0xffffffff),dp_hash(0),in_port(42949 67295),packet_type(ns=65535,id=0xffff),eth_type(0x0000),ipv4(src=0.0.0.0,dst =0.0.0.0,proto=0,tos=0x3,ttl=0,frag=<error>),icmp(type=0,code=0), for the following flow key: packet_type=(1,0x800),tun_id=0x1c8,tun_src=1.1.2.92,tun_dst=1.1.2.88,tun_ipv 6_src=::,tun_ipv6_dst=::,tun_gbp_id=0,tun_gbp_flags=0,tun_tos=3,tun_ttl=64,t un_erspan_ver=0,tun_flags=key,in_port=3,nw_src=30.0.0.1,nw_dst=30.0.0.2,nw_p roto=1,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=0,icmp_code=0 And likewise. Any idea why these failures? It looks to me that the patch wild-carded more mask bits then expected. Regards, Vishal _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
