On 1 Oct 2021, at 11:35, Eelco Chaudron wrote:
> Hi Chris, > > I just started to review this patchset, but as some of the v14 discussions > have not finished, I’ll copy them over to v15. This way, all the open items > are contained in a single thread/revision. I would suggest clear up the open > items before you send a new revision. > > This is only a visual review, as I did not test the code, assuming we need a > new revision anyway with the test cases integrated. > > Cheers, > > Eelco Forgot about this issue (see below), was this fixed in v15? I did not see any reply to the email chain? > Here is some debug info, it seems related to an update to an existing handle, > which does not update the tc part: > > Here the flow gets added: > > 2021-09-09T14:01:12.278Z|00001|netdev_offload_tc(handler1)|ERR|EC_DBG: Enter > b13915aa-c7a8-4574-8dcf-439f03929b8e. > > 2021-09-09T14:01:12.278Z|00002|netdev_offload_tc(handler1)|ERR|EC_DEBUG: > port -2147483646 > > 2021-09-09T14:01:12.285Z|00003|netdev_offload_tc(handler1)|ERR|EC_DBG: EXIT > ok b13915aa-c7a8-4574-8dcf-439f03929b8e. > > Here the revalidator updates it with new port information: > > 2021-09-09T14:01:12.537Z|00001|netdev_offload_tc(revalidator13)|ERR|EC_DBG: > Enter b13915aa-c7a8-4574-8dcf-439f03929b8e. > > > 2021-09-09T14:01:12.537Z|00002|netdev_offload_tc(revalidator13)|ERR|EC_DEBUG: > port 3 > > 2021-09-09T14:01:12.537Z|00004|netdev_offload_tc(revalidator13)|DBG|updating > old handle: 1 prio: 2 > > 2021-09-09T14:01:12.553Z|00005|netdev_offload_tc(revalidator13)|ERR|EC_DBG: > EXIT ok b13915aa-c7a8-4574-8dcf-439f03929b8e. > > Here is a dp dump showing the wrong/old port: > > $ ovs-appctl dpctl/dump-flows -m system@ovs-system type=tc > > ufid:b13915aa-c7a8-4574-8dcf-439f03929b8e, > skb_priority(0/0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(vnet4),packet_type(ns=0/0,id=0/0),eth(src=52:54:00:88:51:38,dst=04:f4:bc:28:57:01),eth_type(0x0800),ipv4(src=0.0.0.0/0.0.0.0,dst=0.0.0.0/0.0.0.0,proto=0/0,tos=0/0,ttl=0/0,frag=no), > packets:180, bytes:15120, used:0.230s, dp:tc, > actions:sample(sample=10.0%,actions(userspace(pid=2771969963,sFlow(vid=0,pcp=0,output=2147483650),actions))),enp5s0f0 > > Guess this is the area you need to look at del_filter_and_ufid_mapping(): > > 2389 if (get_ufid_tc_mapping(ufid, &id) == 0) { > > 2390 VLOG_DBG_RL(&rl, "updating old handle: %d prio: %d", > > 2391 id.handle, id.prio); > > 2392 info->tc_modify_flow_deleted = > !del_filter_and_ufid_mapping(&id, ufid); > > 2393 } > > There might also be a problem in the sgid mapping as it’s also using the > uuid as the hash, and there could be a collision during the update phase. > > I’m working on some escalations so, please take a look and see if you can > fix this. > > I need to restart OVS, and then send a ping, and I see the problem once, I > need to restart OVS each time to see it. > > I’ll wait for v15 to see how you fixed it ;) _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev