-
Notifications
You must be signed in to change notification settings - Fork 531
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve the way of handling BUFFER_PG during PFC storm #1480
Merged
liat-grozovik
merged 4 commits into
sonic-net:master
from
stephenxs:fix-update-pg-under-pfcstorm
Dec 2, 2020
Merged
Improve the way of handling BUFFER_PG during PFC storm #1480
liat-grozovik
merged 4 commits into
sonic-net:master
from
stephenxs:fix-update-pg-under-pfcstorm
Dec 2, 2020
Conversation
This file contains 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
One action for the PFC storm is to set a zero buffer profile on the PG under PFC storm. The zero buffer won't be removed until the PFC storm has gone. If the user wants to modify the buffer profile for the PG, the bufferorch will return "task_need_retry". General speaking it doesn't matter unless that: - the system can't be warm rebooted until the PFC storm has gone. - the "task_need_retry" will block the update of the entire BUFFER_PG table from being programmed to ASIC. In this sense, we need a better solution. The new solution will: - record the new profile user wants to apply during PFC storm as the "pending profile" for that PG and return "task_success" if the PG is under PFC storm. - apply the pending profile once the PG is unlocked. - the latest pending profile will take effect in case user tries updating the profile for more than 1 times. Signed-off-by: Stephen Sun <stephens@nvidia.com>
Signed-off-by: Stephen Sun <stephens@nvidia.com>
Signed-off-by: Stephen Sun <stephens@nvidia.com>
stephenxs
changed the title
Imporve the way of handling BUFFER_PG during PFC storm
Improve the way of handling BUFFER_PG during PFC storm
Nov 11, 2020
neethajohn
previously approved these changes
Dec 1, 2020
neethajohn
approved these changes
Dec 1, 2020
liat-grozovik
approved these changes
Dec 2, 2020
3 tasks
daall
pushed a commit
to daall/sonic-swss
that referenced
this pull request
Dec 7, 2020
* Fix the issue: failed to updating BUFFER_PG during PFC storm One action for the PFC storm is to set a zero buffer profile on the PG under PFC storm. The zero buffer won't be removed until the PFC storm has gone. If the user wants to modify the buffer profile for the PG, the bufferorch will return "task_need_retry". General speaking it doesn't matter unless that: - the system can't be warm rebooted until the PFC storm has gone. - the "task_need_retry" will block the update of the entire BUFFER_PG table from being programmed to ASIC. In this sense, we need a better solution. The new solution will: - record the new profile user wants to apply during PFC storm as the "pending profile" for that PG and return "task_success" if the PG is under PFC storm. - apply the pending profile once the PG is unlocked. - the latest pending profile will take effect in case user tries updating the profile for more than 1 times. Signed-off-by: Stephen Sun <stephens@nvidia.com> * Address review comments: add a pair of brackets for the if-block Signed-off-by: Stephen Sun <stephens@nvidia.com> * Fix ut error Signed-off-by: Stephen Sun <stephens@nvidia.com> * Fix typo Signed-off-by: Stephen Sun <stephens@nvidia.com>
neethajohn
pushed a commit
that referenced
this pull request
Jun 24, 2022
…storm is detected (#2304) What I did Avoid dropping traffic that is ingressing the port/pg that is in storm. The code changes in this PR avoid creating the ingress zero pool and profile and does not attach any zero profile to the ingress pg when pfcwd is triggered Revert changes related to #1480 where the retry mechanism was added to BufferOrch which caches the task retries and while the PG is locked by PfcWdZeroBufferHandler. Revert changes related to #2164 in PfcWdZeroBufferHandler & ZeroBufferProfile & BufferOrch. Updated UT's accordingly How I verified it UT's. Ran the sonic-mgmt test with these changes sonic-net/sonic-mgmt#5665 and verified if they've passed. Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
yxieca
pushed a commit
that referenced
this pull request
Jun 25, 2022
…storm is detected (#2304) What I did Avoid dropping traffic that is ingressing the port/pg that is in storm. The code changes in this PR avoid creating the ingress zero pool and profile and does not attach any zero profile to the ingress pg when pfcwd is triggered Revert changes related to #1480 where the retry mechanism was added to BufferOrch which caches the task retries and while the PG is locked by PfcWdZeroBufferHandler. Revert changes related to #2164 in PfcWdZeroBufferHandler & ZeroBufferProfile & BufferOrch. Updated UT's accordingly How I verified it UT's. Ran the sonic-mgmt test with these changes sonic-net/sonic-mgmt#5665 and verified if they've passed. Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
vivekrnv
added a commit
to vivekrnv/sonic-swss
that referenced
this pull request
Aug 1, 2022
…storm is detected (sonic-net#2304) What I did Avoid dropping traffic that is ingressing the port/pg that is in storm. The code changes in this PR avoid creating the ingress zero pool and profile and does not attach any zero profile to the ingress pg when pfcwd is triggered Revert changes related to sonic-net#1480 where the retry mechanism was added to BufferOrch which caches the task retries and while the PG is locked by PfcWdZeroBufferHandler. Revert changes related to sonic-net#2164 in PfcWdZeroBufferHandler & ZeroBufferProfile & BufferOrch. Updated UT's accordingly How I verified it UT's. Ran the sonic-mgmt test with these changes sonic-net/sonic-mgmt#5665 and verified if they've passed. Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
preetham-singh
pushed a commit
to preetham-singh/sonic-swss
that referenced
this pull request
Aug 6, 2022
…storm is detected (sonic-net#2304) What I did Avoid dropping traffic that is ingressing the port/pg that is in storm. The code changes in this PR avoid creating the ingress zero pool and profile and does not attach any zero profile to the ingress pg when pfcwd is triggered Revert changes related to sonic-net#1480 where the retry mechanism was added to BufferOrch which caches the task retries and while the PG is locked by PfcWdZeroBufferHandler. Revert changes related to sonic-net#2164 in PfcWdZeroBufferHandler & ZeroBufferProfile & BufferOrch. Updated UT's accordingly How I verified it UT's. Ran the sonic-mgmt test with these changes sonic-net/sonic-mgmt#5665 and verified if they've passed. Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
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
One action for the PFC storm is to set a zero buffer profile on the PG under PFC storm.
The zero buffer won't be removed until the PFC storm has gone.
If the user wants to modify the buffer profile for the PG, the bufferorch will return "task_need_retry".
General speaking it doesn't matter unless that:
In this sense, we need a better solution.
In the new solution, it will:
Signed-off-by: Stephen Sun stephens@nvidia.com
Why I did it
How I verified it
It can be verified in the following steps:
Details if related