Expose the capability to config wred drop probability by wendani · Pull Request #571 · sonic-net/sonic-swss

wendani · 2018-08-09T21:52:10Z

Expose the capability to config wred drop probability of all packet colors (green, yellow, and red)

Signed-off-by: Wenda [email protected]

What I did

Why I did it

How I verified it
Tested on dut 3 cases:

drop probabilities all specified in qos.json
drop probabilities partly specified in qos.json
no drop probabilities specified in qos.json

Details if related

(green, yellow, and red) Signed-off-by: Wenda <[email protected]>

yxieca · 2018-08-10T01:04:06Z

orchagent/qosorch.cpp

-    attr.id = SAI_WRED_ATTR_YELLOW_DROP_PROBABILITY;
-    attr.value.s32 = 100;
-    attrs.push_back(attr);
-


This chunk of code looks like providing some default values for these settings. By removing them, you also removed the 'default' value.

I don't see other enforcement to make sure we pass down the configuration all the time. Maybe that belongs to a different PR?

If 'default' value is desirable, then you can create 2 attr objects for them, set the default value before going through the if - else lists. But don't add them until the whole if-else block is done. like following:

type attr_green_drop;
attr_green_drop.s32 = 100;

... ...
if ...
else if ...
...

attrs.push(attr_green_drops);

@lguohan do we need to do this?

I see your other review. But we don't apply qos.json unless we have buffer configuration. So maybe default value is still needed. If we have default value, then the other PR is no longer needed. right?

Hardware has a default value if you do not set. This is the case with RED_DROP_PROBABILITY, which is interestingly not set default here.

I agree with @yxieca , the pr can be modified as follows. if the user does not provide drop probability, we should set the default value in swss to be 100. In this case, your other pr is not needed.

specified in qos.json Signed-off-by: Wenda <[email protected]>

wendani · 2018-08-15T05:48:29Z

the vs check is broken. It used to succeed before retest.

wendani · 2018-08-16T03:21:54Z

retest this please

lguohan · 2018-08-16T08:03:28Z

retest this please

lguohan · 2018-08-16T08:49:57Z

retest this please

* Add the capability to set wred drop probability of all packet colors (green, yellow, and red) Signed-off-by: Wenda <[email protected]> * Ensure drop probability takes default value 100% if not explicitly specified in qos.json Signed-off-by: Wenda <[email protected]>

…a queue (#584) * Expose the capability to config wred drop probability (#571) * Add the capability to set wred drop probability of all packet colors (green, yellow, and red) Signed-off-by: Wenda <[email protected]> * Ensure drop probability takes default value 100% if not explicitly specified in qos.json Signed-off-by: Wenda <[email protected]> * Use "[WRED_PROFILE|]" as a CLI signal to unbind wred profile from a queue or a list of queues; Add the parsing and processing logic in qosorch to support such an operation Signed-off-by: Wenda <[email protected]> * Add print out for debugging purpose modified: orchagent/qosorch.cpp * Adjust log level Signed-off-by: Wenda <[email protected]> * Change to use "[]" as a signal to unbind wred profile from a queue or a list of queues Signed-off-by: Wenda <[email protected]> * Remove logs for debugging * Adjust code format * Address comments Signed-off-by: Wenda <[email protected]>

…n't exist (sonic-net#571)

…#2422) What I did Do not enforce drop probability for a color whose WRED is disabled. Signed-off-by: Stephen Sun [email protected] Why I did it Currently, there is a logic to enforce the drop probability if it is not explicitly designated for a color. However, the drop probability is not a mandatory attribute. It can incur vendor SAI complaints to set it when the color is disabled. The logic was introduced from the very beginning (by PR #571) because no drop probability was defined in the QoS template at the time, which is no longer true. So we will enforce drop probability only if it is not configured and the color is enabled. How I verified it Unit test and manual test

…sonic-net#2422) What I did Do not enforce drop probability for a color whose WRED is disabled. Signed-off-by: Stephen Sun [email protected] Why I did it Currently, there is a logic to enforce the drop probability if it is not explicitly designated for a color. However, the drop probability is not a mandatory attribute. It can incur vendor SAI complaints to set it when the color is disabled. The logic was introduced from the very beginning (by PR sonic-net#571) because no drop probability was defined in the QoS template at the time, which is no longer true. So we will enforce drop probability only if it is not configured and the color is enabled. How I verified it Unit test and manual test

…#2422) What I did Do not enforce drop probability for a color whose WRED is disabled. Signed-off-by: Stephen Sun [email protected] Why I did it Currently, there is a logic to enforce the drop probability if it is not explicitly designated for a color. However, the drop probability is not a mandatory attribute. It can incur vendor SAI complaints to set it when the color is disabled. The logic was introduced from the very beginning (by PR #571) because no drop probability was defined in the QoS template at the time, which is no longer true. So we will enforce drop probability only if it is not configured and the color is enabled. How I verified it Unit test and manual test

* Add the capability to set wred drop probability of all packet colors (green, yellow, and red) Signed-off-by: Wenda <[email protected]> * Ensure drop probability takes default value 100% if not explicitly specified in qos.json Signed-off-by: Wenda <[email protected]>

…sonic-net#2422) What I did Do not enforce drop probability for a color whose WRED is disabled. Signed-off-by: Stephen Sun [email protected] Why I did it Currently, there is a logic to enforce the drop probability if it is not explicitly designated for a color. However, the drop probability is not a mandatory attribute. It can incur vendor SAI complaints to set it when the color is disabled. The logic was introduced from the very beginning (by PR sonic-net#571) because no drop probability was defined in the QoS template at the time, which is no longer true. So we will enforce drop probability only if it is not configured and the color is enabled. How I verified it Unit test and manual test

Add the capability to set wred drop probability of all packet colors

af3ab01

(green, yellow, and red) Signed-off-by: Wenda <[email protected]>

wendani changed the title ~~Expose the capability to config wred drop probability of all packet colors~~ Expose the capability to config wred drop probability Aug 9, 2018

wendani changed the title ~~Expose the capability to config wred drop probability~~ Expose the capability to config wred drop probability of all packet colors Aug 9, 2018

wendani changed the title ~~Expose the capability to config wred drop probability of all packet colors~~ Expose the capability to config wred drop probability Aug 9, 2018

wendani requested review from lguohan and yxieca August 9, 2018 22:06

wendani mentioned this pull request Aug 9, 2018

Add drop probability configurability to ecnconfig sonic-net/sonic-utilities#297

Merged

yxieca reviewed Aug 10, 2018

View reviewed changes

wendani mentioned this pull request Aug 10, 2018

Add wred drop probability config in qos wred profile sonic-net/sonic-buildimage#1913

Closed

Ensure drop probability takes default value 100% if not explicitly

906e6dc

specified in qos.json Signed-off-by: Wenda <[email protected]>

stcheng added the Enhancement ➕ label Aug 15, 2018

lguohan approved these changes Aug 16, 2018

View reviewed changes

lguohan merged commit 367017a into sonic-net:master Aug 16, 2018

EdenGri pushed a commit to EdenGri/sonic-swss that referenced this pull request Feb 28, 2022

[show] Don't abort in InterfaceAliasConverter ctor if PORT table does…

c30e9ff

…n't exist (sonic-net#571)

stephenxs mentioned this pull request Aug 22, 2022

[QoS] Enforce drop probability only for colors whose WRED are enabled #2422

Merged

stephenxs mentioned this pull request Sep 19, 2022

[202205] [QoS] Enforce drop probability only for colors whose WRED are enabled (#2422) #2457

Closed

oleksandrivantsiv pushed a commit to oleksandrivantsiv/sonic-swss that referenced this pull request Mar 1, 2023

[syncd] Unlock vendor api lock if enabling diag shell (sonic-net#571)

59b0430

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Expose the capability to config wred drop probability#571

Expose the capability to config wred drop probability#571
lguohan merged 2 commits intosonic-net:masterfrom
wendani:wred_drop_prob

wendani commented Aug 9, 2018 •

edited

Loading

Uh oh!

yxieca Aug 10, 2018

Uh oh!

yxieca Aug 10, 2018

Uh oh!

wendani Aug 10, 2018 •

edited

Loading

Uh oh!

lguohan Aug 10, 2018

Uh oh!

wendani commented Aug 15, 2018

Uh oh!

wendani commented Aug 16, 2018

Uh oh!

lguohan commented Aug 16, 2018

Uh oh!

lguohan commented Aug 16, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

wendani commented Aug 9, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yxieca Aug 10, 2018

Choose a reason for hiding this comment

Uh oh!

yxieca Aug 10, 2018

Choose a reason for hiding this comment

Uh oh!

wendani Aug 10, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lguohan Aug 10, 2018

Choose a reason for hiding this comment

Uh oh!

wendani commented Aug 15, 2018

Uh oh!

wendani commented Aug 16, 2018

Uh oh!

lguohan commented Aug 16, 2018

Uh oh!

lguohan commented Aug 16, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

wendani commented Aug 9, 2018 •

edited

Loading

wendani Aug 10, 2018 •

edited

Loading