> On Aug 25, 2015, at 6:01 PM, Alan Deikman <[email protected]> wrote: > > Can someone familiar with tester.py advise me as to a next step to take?
I think I can explain the anomalies I reported in my prior e-mail. The problem is that OVS when installed with the kernel datapath (DKMS) it effective has a cache in the kernel for the flow table. The cached flow entries have a hard timeout of 5 seconds. The problem is that tester.py attempts to confirm its flow modifications with a barrier request, but OVS sends a barrier request reply back when its non-cached table is stable but it does not take note of the state of the cached entries in the kernel module. So as a result tester.py in some cases is throwing test packets at a switch that is actually executing different flows than tester.py thinks it is. As a work around I entered a time.sleep(10) statement right after the point at which tester.py issues the clear command. With this modification running with OVS 2.4.90 as both the test switch and the DUT I was able to obtain a final score count of OK: 684 and ERROR: 307. This is 90 more tests that pass without the mod and is a higher score than what is currently posted for OVS on the Ryu certification page. At this point I am not sure if this should be considered an OVS bug or a tester.py bug, but regardless anyone using tester.py against OVS as a test switch should be aware of it. If someone would like to know more about my test results please feel free to contact me. ---------------------------- Alan Deikman ZNYX Networks, Inc.
------------------------------------------------------------------------------
_______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
