On Mon, Aug 25, 2014 at 04:07:40PM +1200, Joe Stringer wrote: > On 23 August 2014 10:47, Ben Pfaff <b...@nicira.com> wrote: > > > OpenFlow packet and byte counters have always been something of an > > approximation in Open vSwitch. First, they are updated only periodically. > > Second, they can be misattributed because statistics collection does a > > retranslation and gives the statistics to whichever OpenFlow flow or flows > > they happen to hit, which could be different from the original set of > > flows because the OpenFlow flow table may have changed. > > > > This commit is intended to somewhat improve on the second point, by always > > attributing statistics to the set of flows that were cached at the datapath > > flow's initial translation by the revalidator. This reduces the race in > > which the flow table could have changed to the interval between the initial > > installation and the first translation by the revalidator. We plan to > > start having the thread that does the initial installation also create the > > ukey, which would eliminate that interval entirely. At that point, packets > > could get lost from OpenFlow statistics because of the periodic collection > > of datapath statistics, but they should no longer be misattributed. > > > > Signed-off-by: Ben Pfaff <b...@nicira.com> > > > > We previously merged a similar patch: > http://openvswitch.org/pipermail/dev/2014-June/041120.html > > ..which caused issues with xlate side-effects for mac-learning, so we > reverted it: > http://openvswitch.org/pipermail/dev/2014-June/041868.html > > Around that time, I also proposed an alternative, which failed to gain > traction: > http://openvswitch.org/pipermail/dev/2014-June/041718.html > > > In summary, I agree with the reasoning around statistics. The trouble is > that xlate_push_stats() also performs various side-effects that > xlate_push_stats(). If this xlate_cache is out of date, and refers to rules > that cause learning, then OVS may learn rules when it is not supposed to. > These may cause unexpected behaviour, and the incorrect rules can hang > around for an extended period. > > I think that the decision from the third patch above was that the current > behaviour was "good enough", and we didn't have a good solution short of > tracking flowtable transitions to implement retroactive side-effects > (Excerpt from thread below) > > > I think that the correct solution is to perform "retroactive > side-effects", > > that is, perform side effects as though they had happened at the time that > > the flow was hit. Anything that may hide these effects (like mac table > > flush) would need to be taken into account. However, such information is > > unavailable, and would be non-trivial to collect and maintain. > > Happy to revisit this discussion if you'd like.
Thanks for all the reminders. I had forgotten the previous attempt. Let's defer this one for now. In the long term, I'd like to try to get more accurate stats. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
