Enhance qos tests to support single-asic, multi-asic, and multi-dut testing#8149
Conversation
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
2479b30 to
ff90873
Compare
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
|
202205 PR - #8213 |
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
17b6cd9 to
c5d4bb9
Compare
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
|
The pre-commit check is a mandatory check, please fix detected issues |
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
777924a to
c9dccc6
Compare
|
The pre-commit check detected issues in the files touched by this pull request. Detailed pre-commit check results: To run the pre-commit checks locally, you can follow below steps:
|
|
The pre-commit check is a mandatory check, please fix. |
|
@vmittal-msft did you run qos test on single box device? and can you resolve conflict? |
* Fix dscp remapping cases 1. fix the lag support logic for dscp remapping test 2. fix a bug introduced by community PR #8149
In #8149 the multi-asic and multi-dut variants were added to test_qos_sai.py. This required updating calls to dynamically_compensate_leakout to specify either the src_client or dst_clientbut a couple calls inPGSharedWatermarkTest` passed the wrong client. For more details on the failure this causes see #16167 Summary: Fixes #16167
…net#16169) In sonic-net#8149 the multi-asic and multi-dut variants were added to test_qos_sai.py. This required updating calls to dynamically_compensate_leakout to specify either the src_client or dst_clientbut a couple calls inPGSharedWatermarkTest` passed the wrong client. For more details on the failure this causes see sonic-net#16167 Summary: Fixes sonic-net#16167
…net#16169) In sonic-net#8149 the multi-asic and multi-dut variants were added to test_qos_sai.py. This required updating calls to dynamically_compensate_leakout to specify either the src_client or dst_clientbut a couple calls inPGSharedWatermarkTest` passed the wrong client. For more details on the failure this causes see sonic-net#16167 Summary: Fixes sonic-net#16167
In sonic-net#8149 the multi-asic and multi-dut variants were added to test_qos_sai.py. This required updating calls to dynamically_compensate_leakout to specify either the src_client or dst_clientbut a couple calls inPGSharedWatermarkTest` passed the wrong client. For more details on the failure this causes see sonic-net#16167 Summary: Fixes sonic-net#16167 Correcting client arguments to dynamically_compensate_leakout (sonic-net#16169) co-authorized by: jianquanye@microsoft.com
…net#16169) In sonic-net#8149 the multi-asic and multi-dut variants were added to test_qos_sai.py. This required updating calls to dynamically_compensate_leakout to specify either the src_client or dst_clientbut a couple calls inPGSharedWatermarkTest` passed the wrong client. For more details on the failure this causes see sonic-net#16167 Summary: Fixes sonic-net#16167
…net#16169) In sonic-net#8149 the multi-asic and multi-dut variants were added to test_qos_sai.py. This required updating calls to dynamically_compensate_leakout to specify either the src_client or dst_clientbut a couple calls inPGSharedWatermarkTest` passed the wrong client. For more details on the failure this causes see sonic-net#16167 Summary: Fixes sonic-net#16167
…GSharedWatermarkTest` In sonic-net/sonic-mgmt#8149 the `multi-asic` and `multi-dut` variants were added to `test_qos_sai.py`. This required updating calls to `dynamically_compensate_leakout` to specify either the `src_client` or dst_client` but a couple calls in `PGSharedWatermarkTest` passed the wrong client. For more details on the failure this causes see sonic-net/sonic-mgmt#16167 Summary: Fixes #16167 ### Type of change - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] Test case(new/improvement) ### Back port request - [ ] 202012 - [ ] 202205 - [ ] 202305 - [ ] 202311 - [x] 202405
…nsate_leakout` in `PGSharedWatermarkTest` (#407) In sonic-net/sonic-mgmt#8149 the `multi-asic` and `multi-dut` variants were added to `test_qos_sai.py`. This required updating calls to `dynamically_compensate_leakout` to specify either the `src_client` or dst_client` but a couple calls in `PGSharedWatermarkTest` passed the wrong client. For more details on the failure this causes see sonic-net/sonic-mgmt#16167 Summary: Fixes #16167 ### Type of change - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] Test case(new/improvement) ### Back port request - [ ] 202012 - [ ] 202205 - [ ] 202305 - [ ] 202311 - [x] 202405
Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: #8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. signed-off-by: jianquanye@microsoft.com
<!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: sonic-net/sonic-mgmt#8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. Summary: Fixes # (issue) ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 ### Approach #### What is the motivation for this PR? #### How did you do it? #### How did you verify/test it? #### Any platform specific information? #### Supported testbed topology if it's a new test case? ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? -->
…ith soft_reset (#697) <!-- Please make sure you've read and understood our contributing guidelines; https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md Please provide following information to help code review process a bit easier: --> ### Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: sonic-net/sonic-mgmt#8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. Summary: Fixes # (issue) ### Type of change <!-- - Fill x for your type of change. - e.g. - [x] Bug fix --> - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 ### Approach #### What is the motivation for this PR? #### How did you do it? #### How did you verify/test it? #### Any platform specific information? #### Supported testbed topology if it's a new test case? ### Documentation <!-- (If it's a new feature, new test case) Did you update documentation/Wiki relevant to your implementation? Link to the wiki page? -->
Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: sonic-net#8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. signed-off-by: jianquanye@microsoft.com
Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: sonic-net#8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. signed-off-by: jianquanye@microsoft.com
Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: sonic-net#8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. signed-off-by: jianquanye@microsoft.com
Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: sonic-net#8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. signed-off-by: jianquanye@microsoft.com Signed-off-by: opcoder0 <110003254+opcoder0@users.noreply.github.com>
Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: sonic-net#8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. signed-off-by: jianquanye@microsoft.com Signed-off-by: Guy Shemesh <gshemesh@nvidia.com>
Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: sonic-net#8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. signed-off-by: jianquanye@microsoft.com Signed-off-by: Aharon Malkin <amalkin@nvidia.com>
Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: sonic-net#8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. signed-off-by: jianquanye@microsoft.com Signed-off-by: Guy Shemesh <gshemesh@nvidia.com>
Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: sonic-net#8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. signed-off-by: jianquanye@microsoft.com
Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: sonic-net#8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. signed-off-by: jianquanye@microsoft.com Signed-off-by: Guy Shemesh <gshemesh@nvidia.com>
Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: sonic-net#8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. signed-off-by: jianquanye@microsoft.com Signed-off-by: Lakshmi Yarramaneni <lakshmi@nexthop.ai>
Description of PR Recently, a new QoS test case was added, which triggered an issue: https://migsonic.atlassian.net/browse/MIGSMSFT-1203 The root cause is that during the test case, the system MAC address is changed after a soft reset. The script that changes the MAC address was introduced in the following upstream PR: sonic-net#8149 After debugging and discussion, it is confirmed that the script was added to fix a TD2-specific issue and is not applicable to Cisco devices. Following the discussions, we implemented a fix to skip the MAC address setting for Cisco platforms. signed-off-by: jianquanye@microsoft.com Signed-off-by: Yael Tzur <ytzur@nvidia.com>
set() does not support index assignment (portIds[idx] = ...) which replaceNonExistentPortId() uses internally. This is a pre-existing bug from PR sonic-net#8149 (test_qos_sai.py L345), moved here during refactoring. The set() was likely intended for deduplication but breaks item assignment. In practice it rarely triggered because most testbeds have all valid ports, so the index assignment path was never reached. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Xu Chen <xuchen3@microsoft.com>
set() does not support index assignment (portIds[idx] = ...) which replaceNonExistentPortId() uses internally. This is a pre-existing bug from PR sonic-net#8149 (test_qos_sai.py L345), moved here during refactoring. The set() was likely intended for deduplication but breaks item assignment. In practice it rarely triggered because most testbeds have all valid ports, so the index assignment path was never reached. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Xu Chen <xuchen3@microsoft.com>
Description of PR
Summary:
Fixes # (issue)
The existing QoS (test_qos_sai.py) is written to accomodata a single asic on a single Dut. But, we require the same tests to be executed against a T2 chassis (with single/multi-asic linecards) and multi-asic pizza boxes.
Type of change
Back port request
Approach
What is the motivation for this PR?
All the test cases create a list of src and dst ports. For the different modes, here is the distribution of the src and dst ports:
How did you do it?
Approach to accomplish this is the following:
All the tests have to parameterized for the 3 modes defined above.
dutConfig is modified such that testPortIds and testPortIps are collecting from all the duts and asics involved and stored in a dictionary with key being the dutIndex and value being a dictionary per asic index.
All the other fixtures and tests, we use 'get_src_dst_asci_and_duts' fixture instead of enum_rand_one_frontend_hostname and enum_frontend_index.
Similarly, changes to saitests involved dealing with multiple DUTs (and thus multiple sai clients) and modifying other data structure like 'interface_to_front_mapping' in sai_base_test.py and port_list, sai_port_list, front_port_list in switch.py to deal with multiple duts (modified to be dictionary with keys being 'src' and 'dst')
Assumptions:
How did you verify/test it?
Ran the tests against T2 J2C+ chassis.
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation