On Wed, Nov 30, 2011 at 09:40:28PM +0800, Herbert Xu wrote: > On Wed, Nov 30, 2011 at 08:14:51AM -0500, jamal wrote: > > On Wed, 2011-11-30 at 15:00 +0800, Herbert Xu wrote: > > > > > > > The other factor I considered is scalability. The OVS code as is > > > is not really friendly to SMP/NUMA scalability (but as Eric pointed, > > > neither is the classifier/action layer). > > > > Did you mean the qdisc funnel-to-interface part which Eric is hopefully > > going to work on now that bql is in? classifier/action happens way > > before that. > > I actually meant the scalability with adding/deleting flows, > or in the case with qdiscs, filters. > > OVS is quite scalable on the fast-path, but when it comes to > new flows, you have a bottleneck.
Having done some testing of OVS in relation to both the number of flows I can stuff into the system and how fast I can do so, I agree. As it stands I don't believe that there has been a whole lot of work so far on optimising for high rates of new flows. I say this based on a low-hang optimisations I have found (and discussed on the OVS dev list). Obviously at some point the low-hanging fruit can all be picked and making things faster becomes more difficult. And it seems to me that the user-space controller is only single threaded and that is a significant bottle-neck to scaling flow creation beyond some point. But I also suspect there are lot of use-cases for OVS where the current code scales sufficiently. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
