[ovs-dev] 回复: 回复: one issue in vxlan functionality of the kernel-datapath type of ovs

pei Jikui jkpei at hotmail.com
Sun Jun 2 01:52:56 UTC 2019


Attach the diff which I have verified locally.
Thanks.

[root at localhost ovs]# git diff
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index dc30824..c5a7de6 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -2678,9 +2678,12 @@ revalidate(struct revalidator *revalidator)
             }
             if (kill_them_all || (used && used < now - max_idle)) {
                 result = UKEY_DELETE;
-            } else {
+            /*Only validate the ukey if the flow's action is not drop.Since for the drop flows, there might be not validated.*/
+            } else if (f->actions_len > 0) {
                 result = revalidate_ukey(udpif, ukey, &f->stats, &odp_actions,
                                          reval_seq, &recircs);
+            } else {
+                result = UKEY_KEEP;
             }
             ukey->dump_seq = dump_seq;



________________________________
发件人: ovs-dev-bounces at openvswitch.org <ovs-dev-bounces at openvswitch.org> 代表 pei Jikui <jkpei at hotmail.com>
发送时间: 2019年6月2日 9:42
收件人: Ben Pfaff
抄送: ovs-dev at openvswitch.org; ovs-discuss at openvswitch.org
主题: [ovs-dev] 回复: one issue in vxlan functionality of the kernel-datapath type of ovs

hi,

I looked into this further and found the root cause.

1) for the unwanted packets(no vxlan tunnel configured for this case), the receiver will install the drop-action flow to the datapath.
2) when the revalidator thread is trying to age-out/clean-up the flows installed in step 1), they are considered as invalidated by revalidator thread since the revalidator thread could not find the xport for them. Hence the revalidator thread delete the them very soon.
3) that is causing all the upcoming packets are sending to userspace again.   And repeat the steps that  a) send to userspace, b) install drop-action flow table c) the revalidator thread delete them.
4) A proposed fix is if the flow's action is drop, we only bank on the time age-out mechanism to clean them up and don't enforce the revalidate_ukey action for them.

Thanks.

Jikui

________________________________
发件人: pei Jikui <jkpei at hotmail.com>
发送时间: 2019年5月25日 7:31
收件人: Ben Pfaff
抄送: ovs-dev at openvswitch.org; ovs-discuss at openvswitch.org
主题: Re: [ovs-dev] one issue in vxlan functionality of the kernel-datapath type of ovs

In my test bed there is no any dropping flow entry generated in the datapath, which causes all the unwanted vxlan packets will go to the slow path.  That’s a little time-consuming for this case.



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

________________________________
发件人: Ben Pfaff <blp at ovn.org>
发送时间: 2019年5月25日 2:36
收件人: pei Jikui
抄送: ovs-dev at openvswitch.org; ovs-discuss at openvswitch.org
主题: Re: [ovs-dev] one issue in vxlan functionality of the kernel-datapath type of ovs

On Sat, May 18, 2019 at 10:23:50AM +0000, pei Jikui wrote:
> I found one issue in the vxlan functionality in kernel-datapath type of ovs which could be potentially optimize?
>
>
> For example, there is a machine (A) running ovs with one configured one vxlan interface with tunnel value 123,  then all the vxlan traffics destinate to this machine(A) will be dealt with the ovs.
>
>
> Although the ovs in machine A only configured with one vxlan tunnel (123), all the vxlan traffics regardless the tunnel value is 123 or not, will be delivered to the vswitchd to do the slow path if there is no flow tables found in the datapath.
>
> This is due to the vxlan configuration such as the configured vxlan tunnel valuse does not exist in the datapath. (There is only one vxlan tunnel with vni value 0 exist in the datapath’s vxlan configuration).

It's true, but does it matter?  It would be unusual for a host to
receive much VXLAN traffic that it is only going to drop.
_______________________________________________
dev mailing list
dev at openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


More information about the dev mailing list