[ovs-discuss] ovs route refresh problem
blp at ovn.org
Sat Mar 10 01:01:01 UTC 2018
On Thu, Mar 01, 2018 at 10:21:38AM -0800, Ben Pfaff wrote:
> On Fri, Feb 23, 2018 at 03:30:59AM +0000, Yinpeijun wrote:
> > >>On Sun, Feb 11, 2018 at 07:27:34AM +0000, Yinpeijun wrote:
> > >> Hi all
> > >> Recently , I run a test two VM commulication with
> > >> vxlan and ovs+dpdk networking(ovs2.7.2). when I add 200 virtual device
> > >> on the physical service of the commulicate vm then check the ping result, there is loss packet statistics. Then I use vlan and ovs+dpdk networking, do the same thing , there is no loss packets statistics.
> > >> I read the source code and add some log to confirm the
> > >> problem, the final problem I think is unreasonable routing refresh,
> > >> in route_table_rest function delete all items before readding, so in the middle of the interval ovs_router_lookup can not find the route then cause packet drop. So I think the implementation need to optimize, Any advice on how to optimize it?
> > >I don't fully understand your use case. However, if you're not using DPDK, then OVS isn't doing routing in userspace so this is probably not the problem.
> > Thank you for your replay, the test case just for reproduce the problem. The actual scene is to create or migrate virtual machines in openstack env. Correspondence will be created linux bridge
> > and other virtual device.
> > There is also have problem in netdev dataptah without dpdk. vxlan tunnel need route in userspace and ovs maintain the route table as follow:
> > ovs-appctl ovs/route/show
> > Route Table:
> > Cached: x.xx.1.10/32 dev eth0 SRC x.xx.1.10
> > Cached: 10.0.0.10/32 dev brcps SRC 10.0.0.10
> > Cached: 127.0.0.1/32 dev lo SRC 127.0.0.1
> > So when I create virtual device trigger ovs refresh the route then affect the already existing virtual machine communication.
> This is the same datapath, really, it's just that most people use it
> with DPDK, and so the solution would be the same.
> I think that the problem you're talking about can be fixed by holding
> the mutex in route_table_reset() across the entire update, instead of
> just for each individual operation on the routing table. Does that make
I sent a patch. Will you test it?
More information about the discuss