> The one thing I wonder about is: do we expect a bunch of CFM states to > change in a "clustered" way, almost at the same time? If that > happens, then we could update the first one in the database and then > have to wait a second before updating the rest in the database. Do > you think that is likely to happen? If it is, then we should consider > a different rate-limiting strategy. One way would be to use a > back-off timer, e.g. start with a 100ms interval and then increase the > update delay each time until it reaches 1s. Another way would be to > have a separate rate limit for each CFM, instead of a global rate > limit. (In the latter case it might be better to integrate the rate > limit into the CFM object itself.)
Summary of an offline discussion reproduced here: There is no hard requirement that cfm updates are reported immediately. The main purpose of this patch is to be more responsive in the average case. If asked for it, we could increase the responsiveness further by introducing a per CFM rate limiter, or backing off as suggested. But for now, I think it's unnecessary. Ethan _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
