Enhance orchagent and buffer manager in error handling #2414
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
|
/azpw run |
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
stephenxs
changed the title
|
/azpw run |
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Stephen Sun <stephens@nvidia.com>
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
force-pushed
the
enhance-buffer-mgr-oa
branch
from
4004910
to
bf1f4de
Compare
|
@neethajohn , @prsunny kindly reminder as this is a bug fixc for 202205 appreciate if you can prioritize it. |
|
@neethajohn , can you please review/sign-off? |
prsunny
approved these changes
Sep 9, 2022
neethajohn
approved these changes
Sep 9, 2022
stephenxs
added a commit
to stephenxs/sonic-swss
that referenced
this pull request
Sep 14, 2022
What I did Enhance orchagent and buffer manager Buffer manager: do not insert buffer queue into cache if the profile is illegal, which prevents an empty string from being inserted into APPL_DB during initialization. orchagent: handle the case that a field referencing other objects is an empty string. There had been such logic that was broken by a PR last year. Signed-off-by: Stephen Sun stephens@nvidia.com Why I did it Enhance the error handling logic. In most cases, a user will not encounter such scenarios in a production environment because it's the front-ends' (eg. CLI) responsibility to identify the wrong configuration and prevent them from being inserted to CONFIG_DB. However, in some cases, like a wrong config_db.json composed and copied to the switch, front-ends can not prevent that. How I verified it Manual and mock tests. Details if related For the improvement in buffer manager: previously, the logic was: declare a reference portQueue to m_portQueueLookup[port][queues] and then assign fvValue(i) to portQueue.running_profile_name But [] operation on C++ map has a side-effect -- it will insert a new element into the map if there wasn't one. In case the validation check in checkBufferProfileDirection failed and there was not one in the map, the portQueue.running_profile_name will keep empty. This is not what we want. In case there was an item configured in the map, we should not remove it on failure because we want to prevent the user from being affected by misconfiguration and alert user to correct the error. There is log in checkBufferProfileDirection Now it is improved in this way: Avoid using reference and initialize m_portQueueLookup[port][queues] only if there is a valid egress profile configured
7 tasks
liat-grozovik
pushed a commit
that referenced
this pull request
Sep 19, 2022
… (#2449) Cherry-pick #2414 - Why I did it Enhance the error handling logic. In most cases, a user will not encounter such scenarios in a production environment because it's the front-ends' (eg. CLI) responsibility to identify the wrong configuration and prevent them from being inserted to CONFIG_DB. However, in some cases, like a wrong config_db.json composed and copied to the switch, front-ends can not prevent that. - How I verified it Manual and mock tests. - Details if related For the improvement in buffer manager: previously, the logic was: declare a reference portQueue to m_portQueueLookup[port][queues] and then assign fvValue(i) to portQueue.running_profile_name But [] operation on C++ map has a side-effect -- it will insert a new element into the map if there wasn't one. In case the validation check in checkBufferProfileDirection failed and there was not one in the map, the portQueue.running_profile_name will keep empty. This is not what we want. In case there was an item configured in the map, we should not remove it on failure because we want to prevent the user from being affected by misconfiguration and alert user to correct the error. There is log in checkBufferProfileDirection Now it is improved in this way: Avoid using reference and initialize m_portQueueLookup[port][queues] only if there is a valid egress profile configured Signed-off-by: Stephen Sun stephens@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
Enhance orchagent and buffer manager
APPL_DBduring initialization.There had been such logic that was broken by a PR last year.
Signed-off-by: Stephen Sun stephens@nvidia.com
Why I did it
Enhance the error handling logic.
In most cases, a user will not encounter such scenarios in a production environment because it's the front-ends' (eg. CLI) responsibility to identify the wrong configuration and prevent them from being inserted to
CONFIG_DB.However, in some cases, like a wrong
config_db.jsoncomposed and copied to the switch, front-ends can not prevent that.How I verified it
Manual and mock tests.
Details if related
For the improvement in buffer manager:
portQueuetom_portQueueLookup[port][queues]and then assignfvValue(i)toportQueue.running_profile_name[]operation on C++ map has a side-effect -- it will insert a new element into the map if there wasn't one. In case the validation check incheckBufferProfileDirectionfailed and there was not one in the map, theportQueue.running_profile_namewill keep empty. This is not what we want.checkBufferProfileDirectionm_portQueueLookup[port][queues]only if there is a valid egress profile configured