Closed sdszhang closed 6 days ago
@rraghav-cisco @amitpawar12 can you help to review?
All oversubscribed cases passed except 2 different failures which are still under investigation, not related to this change.
snappi_tests/multidut/pfc/test_m2o_oversubscribe_lossless_lossy.py::test_m2o_oversubscribe_lossless_lossy[multidut_port_info0] PASSED [100%]
snappi_tests/multidut/pfc/test_m2o_oversubscribe_lossless_lossy.py::test_m2o_oversubscribe_lossless_lossy[multidut_port_info0] PASSED [100%]
snappi_tests/multidut/pfc/test_m2o_fluctuating_lossless.py::test_m2o_fluctuating_lossless[multidut_port_info0] FAILED [100%]
snappi_tests/multidut/pfc/test_lossless_response_to_throttling_pause_storms.py::test_lossless_response_to_throttling_pause_storms[multidut_port_info0] PASSED [100%]
Cherry-pick PR to 202405: https://github.com/sonic-net/sonic-mgmt/pull/15730
Description of PR
Summary: Fixing dut port mapping when retrieving counter. Otherwise, ingress duthost maybe used to retrieve egress counters.
In Snappi ports, the ingress dut and port maybe different for each port. In current code, it uses same ingress dut for both ports.
which results in the counter was retrieved on incorrect dut, and get the following error:
Type of change
Back port request
Approach
What is the motivation for this PR?
Fixing dut port mapping when retrieving counter.
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