On 9/21/21 14:51, Amber, Kumar wrote:
> Hi Ilya,
> 
> The Test-case failure is not related to AVX512 or any patches we are directly 
> failing on "master" latest of OVS with no patches on top of it.
> I am still trying to figure out or root cause the issue, we tested the master 
> on 4 different servers, and all fails on the same test-case.

This sounds very weird.  How do you build it?

> 
> Regards
> Amber
> 
>> -----Original Message-----
>> From: Ilya Maximets <[email protected]>
>> Sent: Monday, September 20, 2021 5:05 PM
>> To: Amber, Kumar <[email protected]>; [email protected];
>> [email protected]; [email protected]
>> Cc: Stokes, Ian <[email protected]>; Van Haaren, Harry
>> <[email protected]>
>> Subject: Re: Unit Test Failure Report to OVS ML
>>
>> On 9/20/21 12:35, Amber, Kumar wrote:
>>> Hi all,
>>>
>>> The following commit ID with the following description added a test case for
>> "tunnel-push-pop" test-suit by the name: "tunnel_push_pop - packet_out
>> debug_slow" has been found to be failing on the latest master branch.
>>>
>>> ## ------------------------------- ##
>>> ## openvswitch 2.16.90 test suite. ##
>>> ## ------------------------------- ##
>>> 779: tunnel_push_pop - packet_out debug_slow         FAILED
>>> (ovs-macros.at:242)
>>>
>>> ## ------------- ##
>>> ## Test results. ##
>>> ## ------------- ##
>>>
>>> ERROR: 1 test was run,
>>> 1 failed unexpectedly.
>>>
>>> We did some investigation, and the matching is the cause of the failure.
>>>
>>> ./ovs-macros.at:242: hard failure
>>>
>>> 779. tunnel-push-pop.at:598: 779. tunnel_push_pop - packet_out
>>> debug_slow (tunnel-push-pop.at:598): FAILED (ovs-macros.at:242)
>>>
>>> Commit patch: 7e6b41ac8d9d183655be96795b529adeb33aeb47
>>>
>>> dpif-netdev: Fix crash when PACKET_OUT is metered.
>>>
>>> When a PACKET_OUT has output port of OFPP_TABLE, and the rule table
>>> includes a meter and this causes the packet to be deleted, execute
>>> with a clone of the packet, restoring the original packet if it is
>>> changed by the execution.
>>>
>>> Add tests to verify the original issue is fixed, and that the fix
>>> doesn't break tunnel processing.
>>>
>>> Would the authors of the patch investigate why the test is failing?
>>>
>>> Regards
>>> Amber
>>
>> Hi.
>>
>> I can't reproduce the issue.  I re-run the test 10 times on 2 of my
>> systems and it works 10/10 without any issues.   And none of our CI
>> systems has issues with this test.
>>
>> The patch that added the test should not affect packet matching as it only
>> changes the execution of actions, just to avoid the crash under certain
>> conditions, and it tries to do that with least amount of side effects 
>> possible.  So,
>> this patch should not be a root cause.  Maybe the new test case just 
>> uncovered a
>> different issue in packet matching?
>>
>> The test itself was carefully crafted to catch a particular issue where 
>> packet is
>> not encapsulated, while it should be.  And the test itself seems solid.
>>
>> Does it still fail for you, if you revert code changes from the patch but 
>> keep the
>> aforementioned unit test (this test is not for the crash itself, so it 
>> should pass
>> without the change in the patch)?
>>
>> Anyway, what does "the matching is the cause of the failure" mean?
>> Are you testing with avx512 enabled?  If so, doesn't autovalidator tell you 
>> what
>> the issue is?
>>
>> Best regards, Ilya Maximets.

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to