[ovs-dev] 回复: 回复: 回复: one issue in vxlan functionality of the kernel-datapath type of ovs
Ben,
Thanks for your review.
1) Based on my understanding, there are two kinds of cases to age out the
datapath flow.
a) Timer.
b) revalidate. The flow will be deleted if there are some invalidated
conditions such as there is no output interface for this flow.
Even if the revalidate does not work, the timer mechanism will eventually
delete the flows.
2) Would you please help to elaborate what the impaction of this change imposes
to the case where the actions are changed from "drop" to anything else? I
couldn't understand this well.
Thanks in advance.
发件人: Ben Pfaff
发送时间: 2019年6月6日 3:58
收件人: pei Jikui
抄送: ovs-dev@openvswitch.org
主题: Re: 回复: [ovs-dev] 回复: one issue in vxlan functionality of the
kernel-datapath type of ovs
Thanks for working on the problem.
I agree that this will solve this particular problem. At the same time,
it will break OVS in every situation where a flow's actions need to
change from "drop" to anything else. We can't accept that regression,
which would be a correctness issue, not just a performance issue.
On Sun, Jun 02, 2019 at 01:52:56AM +, pei Jikui wrote:
> Attach the diff which I have verified locally.
> Thanks.
>
> [root@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, >stats,
> _actions,
> reval_seq, );
> +} else {
> +result = UKEY_KEEP;
> }
> ukey->dump_seq = dump_seq;
>
>
>
>
> 发件人: ovs-dev-boun...@openvswitch.org 代表 pei
> Jikui
> 发送时间: 2019年6月2日 9:42
> 收件人: Ben Pfaff
> 抄送: ovs-dev@openvswitch.org; ovs-disc...@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
> 发送时间: 2019年5月25日 7:31
> 收件人: Ben Pfaff
> 抄送: ovs-dev@openvswitch.org; ovs-disc...@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
> 发送时间: 2019年5月25日 2:36
> 收件人: pei Jikui
> 抄送: ovs-dev@openvswitch.org; ovs-disc...@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 +, 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 d
[ovs-dev] 回复: 回复: one issue in vxlan functionality of the kernel-datapath type of ovs
Attach the diff which I have verified locally.
Thanks.
[root@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, >stats, _actions,
reval_seq, );
+} else {
+result = UKEY_KEEP;
}
ukey->dump_seq = dump_seq;
发件人: ovs-dev-boun...@openvswitch.org 代表 pei
Jikui
发送时间: 2019年6月2日 9:42
收件人: Ben Pfaff
抄送: ovs-dev@openvswitch.org; ovs-disc...@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
发送时间: 2019年5月25日 7:31
收件人: Ben Pfaff
抄送: ovs-dev@openvswitch.org; ovs-disc...@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
发送时间: 2019年5月25日 2:36
收件人: pei Jikui
抄送: ovs-dev@openvswitch.org; ovs-disc...@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 +, 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
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[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 发送时间: 2019年5月25日 7:31 收件人: Ben Pfaff 抄送: ovs-dev@openvswitch.org; ovs-disc...@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 发送时间: 2019年5月25日 2:36 收件人: pei Jikui 抄送: ovs-dev@openvswitch.org; ovs-disc...@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 d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
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 发送时间: 2019年5月25日 2:36 收件人: pei Jikui 抄送: ovs-dev@openvswitch.org; ovs-disc...@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 d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] 回复: [ovs-discuss] An issue that the deleted flow tables in kernel based datapath couldn't be established again
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 发送时间: 2019年5月24日 0:57 收件人: pei Jikui 抄送: ovs-dev@openvswitch.org; ovs-disc...@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? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] one issue in vxlan functionality of the kernel-datapath type of ovs
hi, 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). Is this designed intentional or not? If not, should we do some optimization for this? Such as to push the vxlan configurations into datapath and drop the packets in datapath and does not deliver the unwanted packets to userspace? Thanks Jikui ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
