[ovs-discuss] An issue that the deleted flow tables in kernel based datapath couldn't be established again

[Ben Pfaff]

On Thu, May 23, 2019 at 11:57:05AM +0000, pei Jikui wrote:
> 1)    I found a case in the netlink based datapth, that if we delete the existing datapath flow tables via “ovs-dpctl del-flows”, the according datpath flow tables could not be created again and then  all the consecutive packets need to go through the user-space slow path.

OK.

One way to avoid this problem is to not run "ovs-dpctl del-flows".  Is
there a reason you want to run that command?

> 2)    I also found the potential root cause.  It is because when we delete the datapath flow tables, their according ufid keys stored in the userspace vswitchd are not deleted accordingly.  So, when the coming packets’ packet_missing upcall sent to vswitchd, they ufid key is still in the UKEY_OPERATIONAL status so that the DPIF_FP_CREATE message will not be sent to datapath anymore.

That does seem like a plausible root cause.

> 3)    That will be causing the above case.  The possible fixinges are,
> 
> a) Send the DPIF_FP_CREATE message to datapath regardless if the according ufid key exists or not. (I have verified this fix).

Do you mean, send the message on every packet that comes to userspace?
This could have performance implications, but I don't know how much.

> b) More fine-graind fix is when we execute “ovs-dpctl del-flows **”, we also should clean up the according ufid cach in vswitch.

How do you suggest that userspace should detect that the flows were
deleted?