[ovs-discuss] ovs route refresh problem

Yinpeijun yinpeijun at huawei.com
Sat Mar 10 07:22:47 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 sense?
>
>I sent a patch.  Will you test it?
>        https://patchwork.ozlabs.org/patch/884064/
>
>Thanks

ok, I am glad to. I will do this test as soon as possible and tell you the test result later.


More information about the discuss mailing list