On 09.09.2011 19:54, Ben Pfaff wrote:
On Fri, Sep 09, 2011 at 07:47:52PM +0200, S?bastien Riccio wrote:
That's expected behavior. When new flows constantly pop up, it takes
CPU time to decide what to do with them, and eventually you run out of
CPU time. This will be true of any kind of smart software bridge,
including the Linux kernel bridge, but it's more obviously visible
with Open vSwitch because the CPU cost gets credited to a specific
process instead of to just a vague "system time" percentage, and
because the cost of a kernel/user transition is higher than when
everything happens exclusively in the kernel
(That's why I've been paying more attention to the memory usage
report. ovs-vswitchd shouldn't grow without bound.)
Okay thanks it's clear. I'm trying to find a way to be nearly sure that
on a xen host if
a customer vm gets hacked and starts flooding the network like hell, it
doesn't
render the whole host unreachable (That's what happened the first time I
tried
this test.)
The first step for me was to know what was the expected behavior of
openvswitch
when this happens and then find a way to prevent it.
Kind regards,
Sébastien
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
