Hi William/Ben,

I am working on how to reproduce it, but not yet have clue.

Some finding when the memory usage is large:

1) Usually the flow once reached the limit, example as below
#  ovs-appctl upcall/show
        flows         : (current 100) (avg 104) (max 206205) (limit 199000)
        dump duration : 1ms
        ufid enabled : true

        12: (keys 100)
2) There are attacks from VM port, like syn flood with different source TCP 

3) There are lots of detailed flow in data path. Like including detailed TCP 
src and dst port, even I do not specify TCP info in my openflow rule. I can not 
understand this. Any idea?
ovs-appctl dpif/dump-flows br0

If there is no memory leak, and caused by memory fragment, I believe we can use 
dpdk memory pool instead alloc()/free() here and there.

Zhike Wang
-----Original Message-----
From: William Tu [mailto:u9012...@gmail.com] 
Sent: Saturday, February 03, 2018 1:46 AM
To: Ben Pfaff
Cc: 王志克; ovs-dev@openvswitch.org
Subject: Re: [ovs-dev][PATCH] memory: kill ovs-vswitchd under super

Hi Zhike,

On Fri, Feb 2, 2018 at 7:48 AM, Ben Pfaff <b...@ovn.org> wrote:
> On Fri, Feb 02, 2018 at 12:37:58PM +0000, 王志克 wrote:
>> I also found that if once theres are lots of flows, the memory (RSS) usage 
>> of OVS process would be quite high, 2~3GB. Even then the flows disappear 
>> later, the memory still keeps.

Are you able to reproduce the issue?
There might be a memory leak around cls_rule, miniflow/minimatch allocation.
Can you share more information about your setup?


>> I am not sure how many people notices this, but if indeed OVS has such 
>> defect, I guess this should be critical blocker.
> This is normal behavior of the C library malloc implementation.
dev mailing list

Reply via email to