On Wed, Jul 27, 2011 at 12:17 PM, Jesse Gross <[email protected]> wrote: > On Wed, Jul 27, 2011 at 11:14 AM, Ethan Jackson <[email protected]> wrote: >>> One strategy that I have considered is to be able to ask only for flows >>> that have a non-zero packet count. That would help with the common case >>> where, when there is a large number of flows, they are caused by a port >>> scan or some other activity with 1-packet flows. It wouldn't help at >>> all in your case. >> >> You could also have the kernel pass down to userspace what logically >> amounts to a list of the flows which have had their statistics change >> in the past 10 seconds. A bloom filter would be a sensible approach. >> Again, probably won't help at all in Simon's case, and may or may-not >> be a useful optimization above simply not pushing down statistics for >> flows which have a zero packet count. > > I don't think that you could implement a Bloom filter like this in a > manner that wouldn't cause cache contention. Probably you would still > need to iterate over every flow in the kernel, you would just be > comparing last used time to current time - 10 instead of packet count > not equal to zero. > cpu cache contention can be fixed by partitioning all flow by something (e.g. port no) and assigning cache replacement processing to a cpu. replacement algo could simple as active and inactive LRU list. this is how kernel page cache replacement looks like from high level.
Thanks, Pravin. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
