On Tue, Jul 26, 2011 at 04:00:28PM +0900, Simon Horman wrote: > I have been doing some performance measurements when > sending lots of flows through Open vSwitch and one bottleneck > that I have observed is the 1,000 flow point at which facet_max_idle() > causes flows to start being evicted from the datapath. > > While I understand the motivation for some sort of limit it strikes > me that there are real-world situations where 1,000 is far too low. > > Also, by my calculations the entries consume a little over 300 bytes each > and thus it seems quite conceivable that there are real-world situations > where significantly more than 1,000 can be cached in the kernel without > resulting in significant memory pressure. > > So I set about trying to add a knob to Open vSwitch to allow > this parameter to be tuned, but I must confess that after drawing > a few blanks am a little uncertain about where the best place to add > the knob is. And advice would be greatly appreciated.
Memory consumption is of course one motivation for limiting the number of kernel flows. Another, which may be more important, is that some of ovs-vswitchd's algorithms are O(n) in the number of kernel flows. In the long run, my goal is to devise heuristics to figure out whether a given kernel flow is likely to be worthwhile. One friend of mine suggests that a "naive Bayesian classifier" would be an approach worth pursuing. That's more of a research project than a plan, so until then, I agree that your idea of making it tunable is a good one. I would suggest adding a setting to the Bridge other-config column. ovs-vswitchd would pass that down to ofproto and ofproto-dpif when it is present. (Do you need more pointers on how to do this?) Thanks, Ben. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
