Strict priority QOS test.

[abhishek-nexthop]

Description of PR

Summary:
Add a new comprehensive rate limiting test for QoS validation in SONiC. The test validates CIR (Committed Information Rate) and PIR (Peak Information Rate) rate limiting functionality by generating traffic and validating drop behavior under different traffic conditions.]
Fixing #21052

Type of change

• 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?

Validate Strict priority scheduler

How did you do it?

• Created StrictPriorityRateLimitingDriver class to manage test flow
• Used Redis commands to configure scheduler policies with CIR/PIR rates
• Added direct PTF traffic generation with precise rate control
• Added counter-based validation using sonic-clear counters and interface statistics
• Implemented comprehensive cleanup with QoS reload
• Implemented three-phase testing: baseline (no limits), low traffic (within limits), high traffic (exceeding limits)

How did you verify/test it?

• Validates baseline traffic has minimal drops without rate limiting
• Confirms low traffic within CIR limits passes without drops
• Verifies high traffic exceeding PIR limits triggers appropriate packet drops
• Uses interface TX_DRP counters for drop validation with configurable thresholds

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: abhishek-nexthop / name: Abhishek (0797820, 2900294, c1145f4)
• ✅ login: abhishek-nexthop / name: abhishek-nexthop (f0d04c9)

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[pinky-nexthop]

@vmittal-msft
Kindly review this new test. Thanks.

[vmittal-msft]

@abhishek-nexthop Few things -

1. I see that interface counters is used to check drop counters. I believe we should use queue counters to check if higher priority traffic goes out at expense of low priority traffic. Please confirm if i am mistaken.
2. I see this is only supported for TH5 and not for Q3D. Can we add ? We can add github issue for extending this support later.
3. Does these changes support single asic as well as multi asic scenarios ?
4. I feel we may not be able to generate high enough traffic to test via PTF to test various load. Please add snappi test requirement/test gap for the same.

[abhishek-nexthop]

@vmittal-msft

1. I see that interface counters is used to check drop counters. I believe we should use queue counters to check if higher priority traffic goes out at expense of low priority traffic. Please confirm if i am mistaken.
   For this workflow, we are only validating whether PIR and CIR are working as expected. Therefore, we use a single queue, send traffic to that queue, and check for any packet drops. Since there is only one type of traffic, it is not necessary to identify which queue is experiencing the drop.
2. I see this is only supported for TH5 and not for Q3D. Can we add ? We can add github issue for extending this support later.
   Yes Q3D is in pipeline, we are working on it and will add the code soon.
3. Does these changes support single asic as well as multi asic scenarios ?
   Yes it only supports single asic configuration.
4. I feel we may not be able to generate high enough traffic to test via PTF to test various load. Please add snappi test requirement/test gap for the same.
   As we are testing functionality only, we used PTF and smaller limits (within MB). Do we also need to have a similar snappi test?

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[vmittal-msft]

@vmittal-msft

1. I see that interface counters is used to check drop counters. I believe we should use queue counters to check if higher priority traffic goes out at expense of low priority traffic. Please confirm if i am mistaken.
   For this workflow, we are only validating whether PIR and CIR are working as expected. Therefore, we use a single queue, send traffic to that queue, and check for any packet drops. Since there is only one type of traffic, it is not necessary to identify which queue is experiencing the drop.
2. I see this is only supported for TH5 and not for Q3D. Can we add ? We can add github issue for extending this support later.
   Yes Q3D is in pipeline, we are working on it and will add the code soon.
3. Does these changes support single asic as well as multi asic scenarios ?
   Yes it only supports single asic configuration.
4. I feel we may not be able to generate high enough traffic to test via PTF to test various load. Please add snappi test requirement/test gap for the same.
   As we are testing functionality only, we used PTF and smaller limits (within MB). Do we also need to have a similar snappi test?

@abhishek-nexthop

1. Yes i feel testing with ixia is better way to test this.
2. Please use this as base pr for strict priority scheduling support and add test for verifying strict priority scheudling across multiple TCs including lossy as well as lossless. please open a github issue and tag here.
3. please tag PR for Q3D support here
4. Is this extensible to multi asic support ?

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[abhishek-nexthop]

@vmittal-msft

1. I see that interface counters is used to check drop counters. I believe we should use queue counters to check if higher priority traffic goes out at expense of low priority traffic. Please confirm if i am mistaken.
   For this workflow, we are only validating whether PIR and CIR are working as expected. Therefore, we use a single queue, send traffic to that queue, and check for any packet drops. Since there is only one type of traffic, it is not necessary to identify which queue is experiencing the drop.
2. I see this is only supported for TH5 and not for Q3D. Can we add ? We can add github issue for extending this support later.
   Yes Q3D is in pipeline, we are working on it and will add the code soon.
3. Does these changes support single asic as well as multi asic scenarios ?
   Yes it only supports single asic configuration.
4. I feel we may not be able to generate high enough traffic to test via PTF to test various load. Please add snappi test requirement/test gap for the same.
   As we are testing functionality only, we used PTF and smaller limits (within MB). Do we also need to have a similar snappi test?

@abhishek-nexthop

1. Yes i feel testing with ixia is better way to test this.
2. Please use this as base pr for strict priority scheduling support and add test for verifying strict priority scheudling across multiple TCs including lossy as well as lossless. please open a github issue and tag here.
3. please tag PR for Q3D support here
4. Is this extensible to multi asic support ?

1. Yes, but we need something that can run continuously in sonic-mgmt, which is why we are working on a PTF-based test.
2. Here is issue for extending the testcase: Enhancement: Add new testcase to verify default strict priority #22405
3. The Q3D code is already included in this PR (it supports both TH5 and Q3D).
4. Yes, the code can be extended to support multi-ASIC setups.

[mssonicbld]

@abhishek-nexthop PR conflicts with 202511 branch

[YatishSVC]

Hi @abhishek-nexthop, looks like there are conflicts with the 202511 branch, can you please help with those?
Thanks.

[pinky-nexthop]

Hi @abhishek-nexthop, looks like there are conflicts with the 202511 branch, can you please help with those? Thanks.

@YatishSVC : Abhishek is working on it. Will share the PR link once it is raised.