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

Ben Pfaff blp at ovn.org
Fri May 24 16:22:15 UTC 2019


On Fri, May 24, 2019 at 03:23:26AM +0000, pei Jikui wrote:
> 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.

But how would userspace find out?  "ovs-dpctl del-flows" goes directly
to the kernel.  It doesn't go through ovs-vswitchd at all.

>          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?


More information about the discuss mailing list