Dual ToR QoS test case fixes

[vmittal-msft]

Signed-off-by: Vineet Mittal [email protected]

Description of PR

Summary: Dual ToR QoS test case fixes.
Fixes # (issue)
Thrift API calls were going to incorrect ToR due to rand_one_dut_hostname param. Fixed the duthost for dualtor to lower_tor to see consistence results for QoS test case.

Type of change

• Bug fix
• Testbed and Framework(new/improvement)
• Test case(new/improvement)

Back port request

• 201911
• 202012

Approach

What is the motivation for this PR?

To fix Dual ToR QoS test cases
Change on sonic image : sonic-net/sonic-buildimage#10694

How did you do it?

Fixed the duthost to lower tor for dual tor for QoS only test cases.

How did you verify/test it?

on dual tor HW platform

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

[lgtm-com]

This pull request introduces 2 alerts when merging 47062e9d8f4dfcedef0154a42cfc44e89b2785c0 into bd17176 - view on LGTM.com

new alerts:

• 2 for Variable defined multiple times

[stephenxs]

Now that there are different QoS mappings between downlink and uplink in leaf router and dual ToR, is there a way to cover the different mapping behaviors? This can be done by choosing different source ports and DSCPs.

Currently, the logic in many QoS tests are:

1. Choose a source port randomly or according to the qos.yml
2. Generate traffic and check corresponding counters (like drop, PFC) for DSCP 3 and 4.

To cover different mappings you may want to do it in this way:

1. Choose a source port from each of the following set
   • ports connected between dual-ToR and the leaf router
   • other ports
2. Generate traffic and check counters for corresponding DSCP
   • 2, 3, 4, 6 for ports between dual-ToR and leaf routers
   • 3, 4 for other ports

[vmittal-msft]

Now that there are different QoS mappings between downlink and uplink in leaf router and dual ToR, is there a way to cover the different mapping behaviors? This can be done by choosing different source ports and DSCPs.

Currently, the logic in many QoS tests are:

1. Choose a source port randomly or according to the qos.yml
2. Generate traffic and check corresponding counters (like drop, PFC) for DSCP 3 and 4.

To cover different mappings you may want to do it in this way:

1. Choose a source port from each of the following set

   • ports connected between dual-ToR and the leaf router
   • other ports

2. Generate traffic and check counters for corresponding DSCP

   • 2, 3, 4, 6 for ports between dual-ToR and leaf routers
   • 3, 4 for other ports

Different mapping feature is still work in progress. We can request this along with the feature PR.