On Wed, Nov 30, 2011 at 03:02:19PM +0800, Herbert Xu wrote: > On Tue, Nov 29, 2011 at 10:21:32PM -0800, Jesse Gross wrote: > > > > It's userspace which is managing the entries in the kernel hash table > > and it has some intelligence about aging out entries (and specifically > > about doing it more aggressively as the number of entries increases), > > so it's not really unbounded. In practice, userspace actually keeps > > the number of entries much smaller than the maximum size of the table. > > Right, I thought you would have something like this. > > But I think you still need to rehash the table periodically, as > otherwise even with a limited number of entries and attacker could > construct long chains in a hash bucket, given enough time.
I have done some work on both testing and improving the performance of Open vSwitch with large number of flows (for some definition of large). My current opinion is that expanding the hash table beyond its current maximum size does not seem to yield a performance benefit. This is primarily because there are other performance issues that come into play first - in particular the rate at which a dump of statistics for all flows is made (I intend to fix this, its a user-space problem). So while I agree that optimizing the hash is a good idea. I don't believe it is a bottle-neck at this point. Though I could be convinced otherwise if long collision chains could be constructed with relatively few flows. Something I had not considered until I rad your email just now. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
