Do not enter vendor SAI critical section for counter polling/clearing operations #1450
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 <[email protected]>
Signed-off-by: Stephen Sun <[email protected]>
This reverts commit 32ed1c2.
This reverts commit 8d2aa54.
… community maintainer Signed-off-by: Stephen Sun <[email protected]>
Junchao-Mellanox
approved these changes
Nov 4, 2024
kcudnik
approved these changes
Nov 4, 2024
shiraez
pushed a commit
to Marvell-switching/sonic-sairedis
that referenced
this pull request
Dec 12, 2024
… operations (sonic-net#1450) There are two types of threads in syncd: The syncd main thread in which the create/destroy/set/get SAI APIs are called Flex counter threads in which counter-polling/-clearing APIs are called The critical section in vendor SAI was introduced to protect vendors' SAI from being re-entered, which prevents the flex counter threads from running concurrently, and introduces latency for one flex counter thread when it's waiting for the critical section. It is not necessary to enter a section in counter-polling/clearing operations since the objects' state won't be changed in that API.
shiraez
pushed a commit
to Marvell-switching/sonic-sairedis
that referenced
this pull request
Dec 12, 2024
… operations (sonic-net#1450) There are two types of threads in syncd: The syncd main thread in which the create/destroy/set/get SAI APIs are called Flex counter threads in which counter-polling/-clearing APIs are called The critical section in vendor SAI was introduced to protect vendors' SAI from being re-entered, which prevents the flex counter threads from running concurrently, and introduces latency for one flex counter thread when it's waiting for the critical section. It is not necessary to enter a section in counter-polling/clearing operations since the objects' state won't be changed in that API.
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
Do not enter the vendor SAI critical section for counter-polling/-clearing operations.
Why I did it
There are two types of threads in syncd:
The critical section in vendor SAI was introduced to protect vendors' SAI from being re-entered, which prevents the flex counter threads from running concurrently, and introduces latency for one flex counter thread when it's waiting for the critical section.
It is not necessary to enter a section in counter-polling/clearing operations since the objects' state won't be changed in that API.
How I verified it
Run regression test and observe counter-polling performance.
Details if related