[Dynamic Buffer Calc][202012]Bug fix: Don't create lossless buffer profile for active ports without speed configured#1820
Merged
qiluo-msft merged 2 commits intosonic-net:202012from Jul 29, 2021
Conversation
… configured Root cause: - In handlePortTableUpdate, refreshPgsFromPort is called if admin status is updated even if the speed is not configured. This is reasonable because the port can be configured as headroom override and the profile should be applied in that case. - However, the port's state is set to PORT_READY in refreshPgsForPort regardless whether speed is configured, which is not correct. This is should be avoided and PORT_READY should be set by caller if necessary Fix: - Don't set port's state to READY in refreshPgsForPort. This has been done by all callers. Signed-off-by: Stephen Sun <[email protected]>
Signed-off-by: Stephen Sun <[email protected]>
neethajohn
approved these changes
Jul 23, 2021
liat-grozovik
approved these changes
Jul 29, 2021
5 tasks
5 tasks
qiluo-msft
pushed a commit
to sonic-net/sonic-buildimage
that referenced
this pull request
Jul 30, 2021
Update submodule for swss f54b7d0b [Dynamic Buffer Calc][202012]Bug fix: Don't create lossless buffer profile for active ports without speed configured (sonic-net/sonic-swss#1820) ac7f5cff Td2: Reclaim buffer from unused ports (sonic-net/sonic-swss#1830) 04105a4b [debugcounterorch] check if counter type is supported before querying (sonic-net/sonic-swss#1789) a67d8af6 [202012][portsorch] fix errors when moving port from one lag to another. (sonic-net/sonic-swss#1819)
lguohan
pushed a commit
to sonic-net/sonic-buildimage
that referenced
this pull request
Jul 31, 2021
This PR includes the following commits a67d8af [202012][portsorch] fix errors when moving port from one lag to another (sonic-net/sonic-swss#1819) 04105a4 [debugcounterorch] check if counter type is supported before querying (sonic-net/sonic-swss#1789) ac7f5cff Td2: Reclaim buffer from unused ports (sonic-net/sonic-swss#1830) f54b7d0 [Dynamic Buffer Calc][202012]Bug fix: Don't create lossless buffer profile for active ports without speed configured (sonic-net/sonic-swss#1820) Signed-off-by: Neetha John <[email protected]>
EdenGri
pushed a commit
to EdenGri/sonic-swss
that referenced
this pull request
Feb 28, 2022
…1820) #### What I did As discussed in this PR sonic-net/sonic-utilities#1814 (comment), only the stop.job should have job-mode set to replace irreversibly. Otherwise, simultaneous config reloads in the quick succession, can lead to the behavior. Although ,when the restart job (and all the other dependent jobs) are finished and is taken out of systemd's job queue, the next stop job will not be cancelled.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What I did
Bugfix: Don't create lossless buffer profiles for active ports without speed configured
This is to backport PR #1822 to 202012.
Root cause:
handlePortTableUpdate,refreshPgsFromPortis called if admin status is updated even if the speed is not configured.This is reasonable because the port can be configured as headroom override and the profile should be applied in that case.
PORT_READYinrefreshPgsForPortregardless of whether the speed is configured, which is not correct.This is should be avoided and
PORT_READYshould be set by the caller if necessaryFix:
PORT_READYinrefreshPgsForPortand check the port's state before calling it.Note:
Signed-off-by: Stephen Sun [email protected]
Why I did it
How I verified it
Regression test and vs test.
Details if related