[ovs-discuss] ovs route refresh problem

Ben Pfaff blp at ovn.org
Thu Mar 1 18:21:38 UTC 2018


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


More information about the discuss mailing list