Open vkjammala-arista opened 5 days ago
The pre-commit check detected issues in the files touched by this pull request. The pre-commit check is a mandatory check, please fix detected issues.
Detailed pre-commit check results:
trim trailing whitespace.................................................PassedTo run the pre-commit checks locally, you can follow below steps:
pre-commit
package is installed:
sudo pip install pre-commit
pre-commit install
pre-commit
pre-commit run --from-ref <commit_id> --to-ref <commit_id>
The pre-commit check detected issues in the files touched by this pull request. The pre-commit check is a mandatory check, please fix detected issues.
Detailed pre-commit check results:
trim trailing whitespace.................................................PassedTo run the pre-commit checks locally, you can follow below steps:
pre-commit
package is installed:
sudo pip install pre-commit
pre-commit install
pre-commit
pre-commit run --from-ref <commit_id> --to-ref <commit_id>
The pre-commit check detected issues in the files touched by this pull request. The pre-commit check is a mandatory check, please fix detected issues.
Detailed pre-commit check results:
trim trailing whitespace.................................................PassedTo run the pre-commit checks locally, you can follow below steps:
pre-commit
package is installed:
sudo pip install pre-commit
pre-commit install
pre-commit
pre-commit run --from-ref <commit_id> --to-ref <commit_id>
Do we need this PR in 2024 or 202311 branch?
@XuChen-MSFT FYI
Do we need this PR in 2024 or 202311 branch?
Yes, we need this PR in 202405 and 202311 branches.
I am ok with this change.
Description of PR
Summary: Fix flakiness of qos/test_qos_dscp_mapping.py::TestQoSSaiDSCPQueueMapping_IPIP_Base::test_dscp_to_queue_mapping_uniform_mode
Fixes # aristanetworks/sonic-qual.msft#172
Type of change
Back port request
Approach
What is the motivation for this PR?
In some of the cases, after sending packets (2000) the queue counter value is not reflecting correct value (counter value is less than expected) and thus lead to test failure. In the issue state, reading the counter value (in breakpoint) again shows the correct value.
Sample output in failure case:
How did you do it?
1) Updated the test to wait for atleast 10s (which is hardware counter polling time) before reading the queue counters.
2) Updated the logic to re-poll the counters if the egress packet count is not as expected.
How did you verify/test it?
Stressed the test with fix on
Arista-7260CX3-D108C8
. Test is passing consistently with the fix.Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation