On Tue, Jan 24, 2012 at 9:51 PM, Simon Horman <ho...@verge.net.au> wrote: > As the number of flows grows so does the length of time taken to update the > statistics of all facets. It has been obvserved that this becomes a > performance > problem. This patch mitiages this effect by only dumping a limited number of > facets at a time. > > Signed-off-by: Simon Horman <ho...@verge.net.au> > > --- > > Since the last time that I tested this code (changest > 279320b8276011df3667478de6750d5a40d0c6eb, "rhel: Add ability to enable bridge > compatibility mode in /etc/sysconfig/openvswitch") it seems that the cost of > dumping statistics has increased. I suspect that this relates to the > introducation of subfacet_find(). In any case I believe that a higher cost of > dumping stats makes a stronger case for the change introduced in this patch. > > The previously posted version of this patch used a limit of 100,000 facets per > statistics dump. This revision uses a limit of 20,000 subfacets per dump. > Empirically these two revisions appear to exhibit the same performance.
One other thing that has changed since the last time you posted this is that the kernel now periodically rehashes its flow table. Since the results of the dump are determined by hash order this means that it is possible to see entries twice or not at all if rehashing takes place during a dump. This isn't inherently a problem because most likely any missed flows will get updated the next time around. However, spreading out the dumping process both increases the probability that a rehashing will take place in that time and the time between runs so the impact is greater. I don't think it's that difficult to address this problem - such as by using a different data structure that doesn't change during rehashing, like a linked list - and probably makes sense to fix. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
