[Snappi][MultiDUT-PFC] Combining multiple priorities in a single test flow leads to incorrect behavior on IXIA

[amitpawar12]

Issue Description

Affected testcases: tests/snappi_tests/multidut/pfc/test_lossless_response_to_throttling_pause_storms.py tests/snappi_tests/multidut/pfc/files/lossless_response_to_external_pause_storms_helper.py tests/snappi_tests/multidut/pfc/files/m2o_oversubscribe_lossless_helper.py

Code:

            for fp in flow_prio:
                for val in prio_dscp_map[fp]:
                    flow_prio_dscp_list.append(val)
            ipv4.priority.dscp.phb.values = flow_prio_dscp_list

What does the code do: The following code combines multiple lossless priorities and adds them as single test-flow. In IXIA for given test-flow, priorities are shown as list [3,4].

Problem: On IXIA chassis esp with 4 queues, there is a mapping of priority <-> queue. Priorities 0-3 are mapped to queues 0-3, leaving priority 4, 5 and 6 unmapped.

This was fixed by dynamically assigning queues to priorities. Priorities 0, 1, 2, 5 and 6 are assigned queues 0 and 1. Priority 3 and 4 are assigned queue 3 and 2 respectively.

By combining priority 3 and 4 in a single test flow, we can assign ONLY single queue to the flow (in this case 3). Due to this, IXIA sends limited number of PFCs to the DUT and DUT in turn sends very small number of PFCs for priority 4 (as compared to priority 3).

Results you see

Incorrect assignment of the queue to the priority, especially for priority 4, leading to smaller number of PFCs being generated.

Results you expected to see

Equal number of PFCs being generated.

Good idea would be to split the test-flows into two sub-test-flows of priority 3 and 4 individually and assign them the right queues.

Is it platform specific

generic

Relevant log output

No response

Output of show version

No response

Attach files (if any)

No response

[yxieca]

@selldinesh is this issue fully addressed by your change #13546?

[sdszhang]

@selldinesh will work on this one. Thanks.

[sdszhang]

@selldinesh is this issue fully addressed by your change #13546? PR #13546 doesn't have the fix for this issue. This issue is one of the two remaining task after merging #13546.

[sdszhang]

@amitpawar12 I believe this issue is fixed in #14153 ?

[amitpawar12]

This issue was addressed via PR #13546 . Hence closing this issue.

Thanks,