[Dynamic Buffer Calc] Stabilize the vs test #1679
Merged
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
Signed-off-by: Stephen Sun <stephens@nvidia.com>
neethajohn
approved these changes
Mar 22, 2021
4 tasks
daall
pushed a commit
that referenced
this pull request
Apr 1, 2021
- What I did Stabilize the vs test. - Why I did it Stabilize the vs test. - How I verified it Run the vs test. - Details if related One logic in the vs test is to check consistency between APPL_DB and ASIC_DB for buffer profiles. However, the mapping between are stored in the orchagent and can't be accessed from outside. The way we fetch that mapping is: Get the SAI OID of all the buffer profiles in ASIC_DB at the beginning of the test, and store it to set P1 Get the SAI OID of all the buffer profiles in ASIC_DB after a new buffer profile has been created, and stored it to P2 The newly created buffer profile in ASIC_DB should be P2 - P1. However, sometimes there can be more than one OIDs in P2 - P1. This is because the old profile hasn't been removed from the ASIC, which typically caused by timing issues, which fails the test. To make the test case stable, we will retry for 5 seconds to make sure the old profile is removed and the OID of the new profile can be fetched. Signed-off-by: Stephen Sun <stephens@nvidia.com>
raphaelt-nvidia
pushed a commit
to raphaelt-nvidia/sonic-swss
that referenced
this pull request
Oct 5, 2021
- What I did Stabilize the vs test. - Why I did it Stabilize the vs test. - How I verified it Run the vs test. - Details if related One logic in the vs test is to check consistency between APPL_DB and ASIC_DB for buffer profiles. However, the mapping between are stored in the orchagent and can't be accessed from outside. The way we fetch that mapping is: Get the SAI OID of all the buffer profiles in ASIC_DB at the beginning of the test, and store it to set P1 Get the SAI OID of all the buffer profiles in ASIC_DB after a new buffer profile has been created, and stored it to P2 The newly created buffer profile in ASIC_DB should be P2 - P1. However, sometimes there can be more than one OIDs in P2 - P1. This is because the old profile hasn't been removed from the ASIC, which typically caused by timing issues, which fails the test. To make the test case stable, we will retry for 5 seconds to make sure the old profile is removed and the OID of the new profile can be fetched. Signed-off-by: Stephen Sun <stephens@nvidia.com>
EdenGri
pushed a commit
to EdenGri/sonic-swss
that referenced
this pull request
Feb 28, 2022
… counters after 'config reload' (sonic-net#1679) - What I did Explanation how show/clear counters works: Suppose we got from SDK some count of dropped packets for priority group (№3) per interface (Ehernet4). (for example Ethernet4 PG-3 123 packets) Stats can be shown via show priority-group drop counters Then we run sonic-clear priority-group drop counters. This command will save data "Ethernet4 PG-3 123 packets" to backup. It saved in /tmp/dropstat-{user_id} folder When we run show priority-group drop counters again, script will take data from SDK and data saved from backup. In backup it will find 123. In SDK it may still be number 123 for Ethernet4 (like in backup) or bigger (for example 126.) Our sonic-clear priority-group drop counters command does not change anything in SDK. It just show difference beetwen SDK data and last saved data. So if in SDK data is 123, show priority-group drop counters will show 0 (123 minus 123) - data is cleared If in SDK data is bigger than saved 124, or higher show priority-group drop counters will show 1 (124 minus 123) FIX After config reload all counters drop counters data retrieved from SDK become cleared. All counters become zeros. In this case show priority-group drop counters will show -123 ( 0 (from SDK) minus 123 (saved backup)) So we don't need backup after config reload - How I did it remove /tmp/dropstat-{user_id} folders with counters backup Signed-off-by: Andriy Yurkiv <ayurkiv@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
Stabilize the vs test.
Signed-off-by: Stephen Sun stephens@nvidia.com
Why I did it
Stabilize the vs test.
How I verified it
Run the vs test.
Details if related
One logic in the vs test is to check consistency between APPL_DB and ASIC_DB for buffer profiles. However, the mapping between are stored in the orchagent and can't be accessed from outside. The way we fetch that mapping is:
P1P2P2 - P1.However, sometimes there can be more than one OIDs in
P2 - P1. This is because the old profile hasn't been removed from the ASIC, which typically caused by timing issues, which fails the test.To make the test case stable, we will retry for 5 seconds to make sure the old profile is removed and the OID of the new profile can be fetched.