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