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 <b...@ovn.org> 发送时间: 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
