[ovs-dev] [PATCH] tests/ofproto.at: Workaround some races

[Ben Pfaff]

On Thu, May 04, 2017 at 12:37:41PM +0200, Timothy M. Redaelli wrote:
> On 05/03/2017 10:28 PM, Ben Pfaff wrote:
> > On Thu, Apr 27, 2017 at 05:24:22PM +0200, Timothy Redaelli wrote:
> >> Port commit a6d1a2997db4:
> >>     ofproto.at: Workaround a race
> >>
> >>     While a barrier serializes requests from the same connection,
> >>     it doesn't wait for requests from other connections to the switch.
> >>     Replace the barrier with infamous "sleep 1" to workaround the problem.
> >>
> >> to the following tests:
> >>     "ofproto - asynchronous message control (OpenFlow 1.0)",
> >>     "ofproto - asynchronous message control (OpenFlow 1.3)",
> >>     "ofproto - asynchronous message control (OpenFlow 1.4)" and
> >>     "ofproto - asynchronous message control (OpenFlow 1.5)"
> >>
> >> Sometimes one of these tests fails because the OFPT_BARRIER_REPLY is
> >> printed before the other message we expect to have.
> >>
> >> Suggested-by: Lance Richardson <lrichard at redhat.com>
> >> Signed-off-by: Timothy Redaelli <tredaelli at redhat.com>
> > 
> > Thanks for working to make the tests more reliable.
> > 
> > Adding "sleep 1" makes tests slower, especially when it's in a loop as
> > it is here.
> > 
> > What if we instead make the test wait until monitor.log grows large
> > enough?  We already have OVS_WAIT_UNTIL, which waits only a short time
> > when it can.
> > 
> > What do you think of this?
> 
> The problem is not that the logfile is not large enough, the problem is
> that we have "reversed" output:
> 
> --- expout      2017-05-04 06:22:03.352044646 -0400
> +++ /root/ovs/tests/testsuite.dir/at-groups/944/stdout  2017-05-04
> 06:22:03.386044787 -0400
> @@ -5,5 +5,5 @@
>       state:      LIVE
>       speed: 0 Mbps now, 0 Mbps max
>  OFPT_FLOW_REMOVED (OF1.4):  reason=delete table_id=0
> -OFPT_FLOW_REMOVED (OF1.4):  reason=group_delete table_id=0
>  OFPT_BARRIER_REPLY (OF1.4):
> +OFPT_FLOW_REMOVED (OF1.4):  reason=group_delete table_id=0
> 

Right, and the patch I'm suggesting also drops the OFPT_BARRIER_REPLY.
The only difference from your patch is that mine generally waits less
time.