the dumped WC and generated WC mismatch for ipv6

[gujun4990]

Hi, team
This is a issue that the revalidator will delete datapath flow when the dumped WC and generated WC mismatch.

Enviroment

• ovs: 3.4.2
• Not ovs-dpdk

Information

The following is the trace information:

[root@node-6 bpf]# ovs-appctl ofproto/trace 'recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(tap50cd3638-d9),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=fa:16:3e:74:74:32,dst=fa:16:3e:bf:01:a9),eth_type(0x86dd),ipv6(src=fd1f:8e62:3182:608c::c8,dst=fc00::/fe00::,label=0/0,proto=58,tclass=0/0,hlimit=64,frag=no),icmpv6(type=128/0xf8,code=0/0)'
Flow: icmp6,in_port=17,vlan_tci=0x0000,dl_src=fa:16:3e:74:74:32,dl_dst=fa:16:3e:bf:01:a9,ipv6_src=fd1f:8e62:3182:608c::c8,ipv6_dst=fc00::,ipv6_label=0x00000,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=128,icmp_code=0

bridge("br-int")
----------------
 0. in_port=17, priority 100, cookie 0xd67e3395
    set_field:0xc/0xffff->reg13
    set_field:0x9->reg11
    set_field:0xb->reg12
    set_field:0x4->metadata
    set_field:0x9->reg14
    set_field:0/0xffff0000->reg13
    resubmit(,8)
 8. metadata=0x4, priority 50, cookie 0x6d11c5b5
    set_field:0/0x1000->reg10
    resubmit(,73)
    73. ipv6,reg14=0x9,metadata=0x4,dl_src=fa:16:3e:74:74:32,ipv6_src=fd1f:8e62:3182:608c::c8, priority 90, cookie 0xd67e3395
            resubmit(,74)
        74. No match.
            drop
    move:NXM_NX_REG10[12]->NXM_NX_XXREG0[111]
     -> NXM_NX_XXREG0[111] is now 0
    resubmit(,9)
 9. metadata=0x4, priority 0, cookie 0x80a3e18f
    resubmit(,10)
10. metadata=0x4, priority 0, cookie 0x62b6d61e
    resubmit(,11)
11. metadata=0x4, priority 0, cookie 0x1c991896
    resubmit(,12)
12. ipv6,metadata=0x4, priority 100, cookie 0x5f20cefd
    set_field:0x1000000000000000000000000/0x1000000000000000000000000->xxreg0
    resubmit(,13)
13. metadata=0x4, priority 0, cookie 0x3987ecf1
    resubmit(,14)
14. ipv6,reg0=0x1/0x1,metadata=0x4, priority 100, cookie 0xd60f1d10
    ct(table=15,zone=NXM_NX_REG13[0..15])
    drop
     -> A clone of the packet is forked to recirculate. The forked pipeline will be resumed at table 15.
     -> Sets the packet to an untracked state, and clears all the conntrack fields.

Final flow: icmp6,reg0=0x1,reg11=0x9,reg12=0xb,reg13=0xc,reg14=0x9,metadata=0x4,in_port=17,vlan_tci=0x0000,dl_src=fa:16:3e:74:74:32,dl_dst=fa:16:3e:bf:01:a9,ipv6_src=fd1f:8e62:3182:608c::c8,ipv6_dst=fc00::,ipv6_label=0x00000,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=128,icmp_code=0
Megaflow: recirc_id=0,eth,icmp6,in_port=17,dl_src=fa:16:3e:74:74:32,dl_dst=fa:16:3e:bf:01:a9,ipv6_src=fd1f:8e62:3182:608c::c8,ipv6_dst=fc00::/7,nw_ttl=64,nw_frag=no,icmp_type=0x80/0xf8,nd_target=::,nd_tll=00:00:00:00:00:00
Datapath actions: ct(zone=12),recirc(0x2)

...

From above information, we can found that nd_target and nd_tll field are included by megaflow. The generated datapath flow is below:

ufid:3eb805ba-7576-4caf-8b08-93c7517e575d, recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(tap50cd3638-d9),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=fa:16:3e:74:74:32,dst=fa:16:3e:bf:01:a9),eth_type(0x86dd),ipv6(src=fd1f:8e62:3182:608c::c8,dst=fc00::/fe00::,label=0/0,proto=58,tclass=0/0,hlimit=64,frag=no),key32(00 00/00 00),icmpv6(type=128/0xf8,code=0/0), packets:44, bytes:5192, used:0.752s, dp:ovs, actions:ct(zone=12),recirc(0x4)

During the sweep stage, the revalidator will compare the dumped WC with a generated WC - these will mismatch because the generated WC will match on the Neighbor Discovery fields, while the datapath WC will not match on these fields. The revalidator will then invalidate the flow and as a side effect force an upcall.

Deeply, we found the patch openvswitch/ovs@489553b which adds masks on final stage causes this issue.
Simply, we can use below case to reproduce the issue.

AT_SETUP([flow classifier - ipv6 ND dependency from clone])
OVS_VSWITCHD_START
add_of_ports br0 1 2
AT_DATA([flows.txt], [dnl
 table=0,priority=100,ipv6,ipv6_src=1000::/10 actions=resubmit(,1)
 table=0,priority=0 actions=NORMAL
 table=1,priority=110,ipv6,ipv6_dst=1000::3 actions=resubmit(,2)
 table=1,priority=100,ipv6,ipv6_dst=1000::4 actions=resubmit(,2)
 table=1,priority=0 actions=NORMAL
 table=2,priority=120,icmp6,nw_ttl=255,icmp_type=136,icmp_code=0,nd_target=1000::1,nd_tll=fa:16:3e:74:74:32 actions=NORMAL
 table=2,priority=100,tcp actions=NORMAL
 table=2,priority=100,icmp6 actions=NORMAL
 table=2,priority=0 actions=NORMAL
])
AT_CHECK([ovs-ofctl add-flows br0 flows.txt])

# test ICMPv6 echo request (which should have no nd_target field)
AT_CHECK([ovs-appctl ofproto/trace br0 "in_port=1,eth_src=f6:d2:b0:19:5e:7b,eth_dst=d2:49:19:91:78:fe,dl_type=0x86dd,ipv6_src=1000::3,ipv6_dst=1000::4,nw_proto=58,nw_ttl=255,icmpv6_type=128,icmpv6_code=0"], [0], [stdout])
AT_CHECK([tail -2 stdout], [0],
  [Megaflow: recirc_id=0,eth,icmp6,in_port=1,dl_src=f6:d2:b0:19:5e:7b,dl_dst=d2:49:19:91:78:fe,ipv6_src=1000::/10,ipv6_dst=1000::4,nw_ttl=255,nw_frag=no,icmp_type=0x80/0xf8,nd_target=::,nd_tll=00:00:00:00:00:00
Datapath actions: 100,2
])
OVS_VSWITCHD_STOP
AT_CLEANUP

I wonder if the patch openvswitch/ovs@489553b need to be optimized. @igsilya