On Fri, May 16, 2014 at 10:16 PM, Ben Pfaff <b...@nicira.com> wrote: > On Fri, May 16, 2014 at 09:38:27PM +0400, Andrey Korolyov wrote: >> Can anyone please explain following performance impact: >> >> Taking following snippet of forward table (one-way traffic cleaner), I >> am observing very huge CPU impact on the ovs-vswitchd on the specific >> test for IP address violation, but it seemingly comes from nowhere - >> packets should be silently dropped by kernel module since there is a >> definitely 'drop' action for unicast IP flood from following: >> >> hping3 -1 --flood --rand-source 10.0.0.51 <-- active neighbour >> >> As one can see from counters, packets are dropping, but raising CPU >> consumption of the ovs-vswitchd up to four cores on E5 cpu, instead of >> being silently blackholed by kernel module. When no path to neighbor >> with certain address exists (for example, if one shut down interface >> 10.0.0.51), overhead disappears. Can anyone have a point on what can be >> fixed there to not heat up vswitchd process so much? I am using 2.1 >> series userspace tools. > > I think you need to turn on prefix tracking to get the best > performance out of this flow table. Try this: > > ovs-vsctl \ > -- set Bridge br0 flow_tables:2=@N2 \ > -- --id=@N2 create Flow_Table name=table2 prefixes=ip_dst,ip_src > > You'll need to replace br0 by the name of your bridge. > > We've had discussion of enabling prefix tracking by default. I > thought that we had concluded that it was a good idea, but it doesn't > seem to be on master yet. I'll follow up on that.
Thanks, but setting this had absolutely no difference in vswitchd consumption. I believe that there is a very simple knob of which I am unaware of, because of huge difference between flood overhead with reachable and unreachable (in same L2 area) target. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
