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

[pei Jikui]

Ben,

Much thanks for your reply.
1) I know this command will be rarely used by customer.  For me, the reason why I used this command is trying to understand the full-cycle of packet traveling in OVS system.
   And I do not know if there are some cases for the customer in the real world to use this command.

3) a) Not for every packets to the userspace. Just for the packets generated the packet_miss upcall.
     b) The initial thinking
         i) for the case to delete all the flow tables, then cleanup all the ufid keys in userspace.
         ii) No much think for the case how to delete the according ufid for the deleting specific flow entries.

Thanks

Jikui


发送自 Outlook<http://aka.ms/weboutlook>

________________________________
发件人: Ben Pfaff <blp at ovn.org>
发送时间: 2019年5月24日 0:57
收件人: pei Jikui
抄送: ovs-dev at openvswitch.org; ovs-discuss at openvswitch.org
主题: Re: [ovs-discuss] An issue that the deleted flow tables in kernel based datapath couldn't be established again

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20190524/a655e896/attachment.html>