diff mbox series

[ovs-dev,v11,10/11] tests: Fix reading of OpenFlow byte counters in GRE test cases.

Message ID 167577884295.1166983.17250724968371889141.stgit@ebuild.local
State Accepted
Commit 594d1fee5b04c0a219cc87488507b021820020a1
Headers show
Series tests: Add system-traffic.at tests to check-offloads. | expand

Checks

Context Check Description
ovsrobot/apply-robot success apply and check: success
ovsrobot/github-robot-_Build_and_Test success github build: passed
ovsrobot/intel-ovs-compilation success test: success

Commit Message

Eelco Chaudron Feb. 7, 2023, 2:07 p.m. UTC
With some datapaths, read TC, it takes a bit longer to update the
OpenFlow statistics. Rather than adding an additional delay, try
to read the counters multiple times until we get the desired value.

Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Roi Dayan <roid@nvidia.com>
---
 tests/system-traffic.at |   18 +++++++-----------
 1 file changed, 7 insertions(+), 11 deletions(-)

Comments

Simon Horman Feb. 8, 2023, 4:50 p.m. UTC | #1
On Tue, Feb 07, 2023 at 03:07:24PM +0100, Eelco Chaudron wrote:
> With some datapaths, read TC, it takes a bit longer to update the
> OpenFlow statistics. Rather than adding an additional delay, try
> to read the counters multiple times until we get the desired value.
> 
> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> Acked-by: Roi Dayan <roid@nvidia.com>

Hi Eelco,

I'm not sure how much this buys us.
I notice that in the following patch the tests are disabled
(maybe I am reading that wrong) as they are not reliable.
And, FWIIW, in my environment, I couldn't get these tests to pass
at all (17 iterations).

I'd be happy to set up a Fedora, or other environment, to verify
this patch if you think it's worthwhile.

Lastly, just to clarify my response to other patches.
The tests were for the SW TC datapath.
Eelco Chaudron Feb. 9, 2023, 8:42 a.m. UTC | #2
On 8 Feb 2023, at 17:50, Simon Horman wrote:

> On Tue, Feb 07, 2023 at 03:07:24PM +0100, Eelco Chaudron wrote:
>> With some datapaths, read TC, it takes a bit longer to update the
>> OpenFlow statistics. Rather than adding an additional delay, try
>> to read the counters multiple times until we get the desired value.
>>
>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
>> Acked-by: Roi Dayan <roid@nvidia.com>
>
> Hi Eelco,
>
> I'm not sure how much this buys us.
> I notice that in the following patch the tests are disabled
> (maybe I am reading that wrong) as they are not reliable.
> And, FWIIW, in my environment, I couldn't get these tests to pass
> at all (17 iterations).
>
> I'd be happy to set up a Fedora, or other environment, to verify
> this patch if you think it's worthwhile.

I think it’s fine for now. For me, it failed every now and then on 50 runs. I decided to keep them out in the final patch to avoid re-run errors. As I’ve seen that, if it fails in the first run, the changes are high it will fail in the re-run. But I did not find any clue yet why.

I have some revalidator patches pending upstreanm, and my plan is to revisit these two errors once those changes are in.

> Lastly, just to clarify my response to other patches.
> The tests were for the SW TC datapath.

Thanks for doing this!

Cheers,

Eelco
Simon Horman Feb. 9, 2023, 9:09 a.m. UTC | #3
On Thu, Feb 09, 2023 at 09:42:03AM +0100, Eelco Chaudron wrote:
> 
> 
> On 8 Feb 2023, at 17:50, Simon Horman wrote:
> 
> > On Tue, Feb 07, 2023 at 03:07:24PM +0100, Eelco Chaudron wrote:
> >> With some datapaths, read TC, it takes a bit longer to update the
> >> OpenFlow statistics. Rather than adding an additional delay, try
> >> to read the counters multiple times until we get the desired value.
> >>
> >> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> >> Acked-by: Roi Dayan <roid@nvidia.com>
> >
> > Hi Eelco,
> >
> > I'm not sure how much this buys us.
> > I notice that in the following patch the tests are disabled
> > (maybe I am reading that wrong) as they are not reliable.
> > And, FWIIW, in my environment, I couldn't get these tests to pass
> > at all (17 iterations).
> >
> > I'd be happy to set up a Fedora, or other environment, to verify
> > this patch if you think it's worthwhile.
> 
> I think it’s fine for now. For me, it failed every now and then on 50 runs. I decided to keep them out in the final patch to avoid re-run errors. As I’ve seen that, if it fails in the first run, the changes are high it will fail in the re-run. But I did not find any clue yet why.
> 
> I have some revalidator patches pending upstreanm, and my plan is to revisit these two errors once those changes are in.

Thanks, in that case, feel free to add:

Reviewed-by: Simon Horman <simon.horman@corigine.com>

> > Lastly, just to clarify my response to other patches.
> > The tests were for the SW TC datapath.
> 
> Thanks for doing this!
> 
> Cheers,
> 
> Eelco
>
diff mbox series

Patch

diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index 76f1f39a2..2d46e0639 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -1638,7 +1638,6 @@  dnl   br-underlay: with IP: 172.31.1.100
 dnl   ns0: connect to br-underlay, with IP: 10.1.1.1
 AT_SETUP([datapath - truncate and output to gre tunnel by simulated packets])
 OVS_CHECK_MIN_KERNEL(3, 10)
-CHECK_NO_TC_OFFLOAD()
 AT_SKIP_IF([test $HAVE_NC = no])
 OVS_TRAFFIC_VSWITCHD_START()
 
@@ -1709,9 +1708,8 @@  AT_CHECK([ovs-ofctl dump-flows br0 | grep "in_port=2" | sed -n 's/.*\(n\_bytes=[
 n_bytes=242
 ])
 dnl After truncation = outer ETH(14) + outer IP(20) + GRE(4) + 100 = 138B
-AT_CHECK([ovs-ofctl dump-flows br-underlay | grep "in_port=LOCAL" | sed -n 's/.*\(n\_bytes=[[0-9]]*\).*/\1/p'], [0], [dnl
-n_bytes=138
-])
+OVS_WAIT_UNTIL_EQUAL([ovs-ofctl dump-flows br-underlay | grep "in_port=LOCAL" | sed -n 's/.*\(n\_bytes=[[0-9]]*\).*/\1/p'], [dnl
+n_bytes=138])
 
 dnl check tunnel pop path, from at_ns0 to at_ns1
 dnl This 200-byte packet is simulated on behalf of ns_gre0
@@ -1719,9 +1717,9 @@  ovs-ofctl -O OpenFlow13 packet-out br-underlay "in_port=1 packet=02908ca8a149faa
 
 dnl After truncation = 100 byte at loopback device p2(4)
 AT_CHECK([ovs-appctl revalidator/purge], [0])
-AT_CHECK([ovs-ofctl dump-flows br0 | grep "in_port=4" | ofctl_strip], [0], [dnl
- n_packets=1, n_bytes=100, priority=1,ip,in_port=4 actions=drop
-])
+OVS_WAIT_UNTIL_EQUAL([ovs-ofctl dump-flows br0 | grep "in_port=4" | ofctl_strip], [dnl
+ n_packets=1, n_bytes=100, priority=1,ip,in_port=4 actions=drop])
+
 
 dnl SLOW_ACTION: disable datapath truncate support
 dnl Repeat the test above, but exercise the SLOW_ACTION code path
@@ -1746,9 +1744,8 @@  AT_CHECK([ovs-ofctl dump-flows br0 | grep "in_port=2" | sed -n 's/.*\(n\_bytes=[
 n_bytes=242
 ])
 dnl After truncation = outer ETH(14) + outer IP(20) + GRE(4) + 100 = 138B
-AT_CHECK([ovs-ofctl dump-flows br-underlay | grep "in_port=LOCAL" | sed -n 's/.*\(n\_bytes=[[0-9]]*\).*/\1/p'], [0], [dnl
-n_bytes=138
-])
+OVS_WAIT_UNTIL_EQUAL([ovs-ofctl dump-flows br-underlay | grep "in_port=LOCAL" | sed -n 's/.*\(n\_bytes=[[0-9]]*\).*/\1/p'], [dnl
+n_bytes=138])
 
 dnl check tunnel pop path, from at_ns0 to at_ns1
 dnl This 200-byte packet is simulated on behalf of ns_gre0
@@ -1773,7 +1770,6 @@  AT_SETUP([datapath - truncate and output to gre tunnel])
 AT_SKIP_IF([test $HAVE_NC = no])
 OVS_CHECK_KERNEL_EXCL(3, 10, 4, 15)
 OVS_CHECK_GRE()
-CHECK_NO_TC_OFFLOAD()
 OVS_TRAFFIC_VSWITCHD_START()
 
 ADD_BR([br-underlay])