On Tue, Jul 26, 2011 at 10:55:00AM -0700, Ben Pfaff wrote: > 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.
As part of my testing I observed what seems to be O(n) behaviour, I'm glad that I wasn't imagining it. (Actually, perhaps I would be glad if I was imagining it, that would be an easier problem to solve. :) As you may have guessed from my recent posts relating to large(ish) number of flows, I am interesting in scaling to rather more than 1,000 flows. And O(n) portions are something that I would be rather happy to see weeded out, somehow. > 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. My current test is rather abusive - I'm using the kernel packet generator to send packets for many flows at roughly the same per-flow packet rate. In that scenario all flows are equal, so I think that classification would probably break down. Indeed, it plays havoc with the current eviction algorithm. However, I do agree that some kind of prioritisation algorithm could work well with less abusive (and more common?) workloads. > 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, I think that should be enough. I'll let you know if it turns out otherwise. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
