Optimize counter polling interval by making it more accurate#1457
Merged
kcudnik merged 6 commits intosonic-net:masterfrom Feb 7, 2025
Merged
Optimize counter polling interval by making it more accurate#1457kcudnik merged 6 commits intosonic-net:masterfrom
kcudnik merged 6 commits intosonic-net:masterfrom
Conversation
Contributor
Author
|
This PR requires swss to be updated correspondingly. The swss PR will be opened soon. |
Contributor
Author
|
Depends on sonic-net/sonic-swss-common#950 |
stephenxs
force-pushed
the
counter-optimization-all-in-one
branch
from
c14fd22 to
6b362f6
Compare
stephenxs
force-pushed
the
counter-optimization-all-in-one
branch
from
6b362f6 to
b82e233
Compare
Contributor
Author
stephenxs
force-pushed
the
counter-optimization-all-in-one
branch
from
b82e233 to
5442b37
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
stephenxs
force-pushed
the
counter-optimization-all-in-one
branch
from
5442b37 to
6c1086a
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
stephenxs
force-pushed
the
counter-optimization-all-in-one
branch
from
9624365 to
677bfc2
Compare
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Contributor
|
hi @kperumalbfn and @dgsudharsan , do we need this change in 202411? One of the dependency is only added to 202412, not sure if this is expected. |
kcudnik
pushed a commit
that referenced
this pull request
Feb 26, 2025
…1534) What I did Optimize the counter-polling performance in terms of polling interval accuracy Enable bulk counter-polling to run at a smaller chunk size There is one counter-polling thread for each counter group. All such threads can compete for the critical sections at the vendor SAI level, which means a counter-polling thread can wait for a critical section if another thread has been in it, which introduces latency for the waiting counter group. An example is the competition between the PFC watchdog and the port counter groups. The port counter group contains many counters and is polled in a bulk mode which takes a relatively longer time. The PFC watchdog counter group contains only a few counters but is polled at a short interval. Sometimes, PFC watchdog counters need to wait before polling, which makes the polling interval inaccurate and prevents the PFC storm from being detected in time. To resolve this issue, we can reduce the chunk size of the port counter group. The port counter group polls the counters of all ports in a single bulk operation by default. By using a smaller chunk size, it polls the counters in several bulk operations with each polling counter of a subset (whose size <= chunk size) of all ports. By doing so, the port counter group stays in the critical section for a shorter time and the PFC watchdog is more likely to be scheduled to poll counters and detect the PFC storm in time. Collect the time stamp immediately after vendor SAI API returns. Currently, many counter groups require a Lua plugin to execute based on polling interval, to calculate rates, detect certain events, etc. Eg. For PFC watchdog counter group to PFC storm. In this case, the polling interval is calculated based on the difference of time stamps between the current and last poll to avoid deviation due to scheduling latency. However, the timestamp is collected in the Lua plugin which is several steps after the SAI API returns and is executed in a different context (redis-server). Both introduce even larger deviations. To overcome this, we collect the timestamp immediately after the SAI API returns.
stephenxs
pushed a commit
to stephenxs/sonic-sairedis
that referenced
this pull request
Feb 27, 2025
…#24) ```<br>* f83634d9 - (HEAD -> 202412) Merge branch '202411' of https://github.com/sonic-net/sonic-sairedis into 202412 (2025-02-27) [Sonic Automation] * 8c17d4b - (origin/202411) Revert "Do not enter vendor SAI critical section for counter polling/clearing operations (sonic-net#1450)" (sonic-net#1541) (2025-02-27) [mssonicbld] * 3df03e1 - Optimize counter polling interval by making it more accurate (sonic-net#1457) (sonic-net#1534) (2025-02-26) [Stephen Sun] * d884ff9 - [syncd] Move logSet logGet under mutex to prevent race condition (sonic-net#1520) (sonic-net#1538) (2025-02-20) [Kamil Cudnik] * ec8b3c3 - Fix pipeline errors related to rsyslogd and libswsscommon installation (sonic-net#1535) (2025-02-19) [mssonicbld] * 6b263b8 - [FC] Support Policer Counter (sonic-net#1533) (2025-02-19) [mssonicbld] * e53489e - [syncd] Update log level for bulk api (sonic-net#1532) (2025-02-18) [Jianyue Wu] * 7ae00e5 - Define bulk chunk size and bulk chunk size per counter ID (sonic-net#1528) (2025-02-11) [mssonicbld] * f35e743 - [nvidia] Skip SAI discovery on ports (sonic-net#1524) (2025-02-07) [mssonicbld] * bf049ed - Use sonictest pool instead of sonic-common and fix arm64 issue. (sonic-net#1516) (2025-02-05) [mssonicbld] * ffe371d - [syncd] Support bulk set in INIT_VIEW mode (sonic-net#1517) (2025-02-05) [mssonicbld]<br>```
Contributor
|
hi @stephenxs , you have taking this PR into 202411 (#1534) without taking WRED PR (#1234) is causing the WRED PR failing to be merged into 202412. The reason is because CounterContext in WRED PR is still taking 4 parameters while after this PR, it starts to take 5 parameters:
This causes code failing to build in CI as below, hence even doing manual cherry pick here, I cannot get the PR merged into 202412 anymore: Azure/sonic-sairedis.msft#28. So we are stuck on this PR.
Please note that all the changes to 202411 will be automatically merged into 202412, so while taking the changes into 202411, please take the dependency into the consideration in the future.
|
Contributor
Author
thanks for reminding @r12f |
Contributor
|
yea, WRED is not going to 202411, but if it lands on 202412 first, this conflict should not happen. I will get the access and do a force merge tomorrow to get this solved. And also thanks a lot for the quick response! |
Contributor
|
this is already in 202411 and merged into 202412. fixing label. |
Pterosaur
pushed a commit
to Pterosaur/sonic-sairedis
that referenced
this pull request
Apr 6, 2025
…onic-net#1457) …" (sonic-net#1570) Revert "Optimize counter polling interval by making it more accurate
DavidZagury
pushed a commit
to DavidZagury/sonic-sairedis
that referenced
this pull request
Apr 28, 2025
* [syncd] Support bulk set in INIT_VIEW mode (sonic-net#1517) Support bulk set in INIT_VIEW mode. * Use sonictest pool instead of sonic-common and fix arm64 issue. (sonic-net#1516) 1. Use sonictest pool instead of sonic-common 2. Fix arm64 build error. * [nvidia] Skip SAI discovery on ports (sonic-net#1524) Given that modern systems have lots of ports, performing SAI discovery takes very long time, e.g. (8 sec) for 256 port system. This has a big impact of fast-boot downtime and the discovery itself is not required for Nvidia platform fast-boot. Same applies to Nvidia fastfast-boot (aka warm-boot), yet needs to be tested separately. * Define bulk chunk size and bulk chunk size per counter ID (sonic-net#1528) Define bulk chunk size and bulk chunk size per counter ID. This is to resolve the VS test failure in sonic-net#1457, which is caused by loop dependency. In PR sonic-net#1457, new fields `bulk_chunk_size` and `bulk_chunk_size_per_prefix` have been introduced to `sai_redis_flex_counter_group_parameter_t` whose instances are initialized by orchagent. However, the orchagent is still compiled with the old sairedis header, which prevents both new fields from being uninitialized which in turn fails vs test. We have to split this PR into two: 1. sonic-net#1519 which updates the header sairedis.h only. the motivation is to compile swss(orchagent) with both new fields initiated. 2. sonic-net#1457 contains all the rest of code The order to merge: 1. sonic-net#1519 2. sonic-net/sonic-swss#3391 3. sonic-net#1457 * [syncd] Update log level for bulk api (sonic-net#1532) [syncd] Update log level for bulk api * [FC] Support Policer Counter (sonic-net#1533) Added the implantation for policer counter - Support in POLICER group and sai_serialize functions Unit Tests: Included unit tests to add and remove policer counter. * Fix pipeline errors related to rsyslogd and libswsscommon installation (sonic-net#1535) On arm64 (and maybe sometimes amd64), rsyslogd appears to need a second or two to actually fully exit. The current code expects it to exit practically instantly. Add a sleep of 2 seconds to give it some time. Also enable some logging so that the commands being run can be seen. Also, fix an error related to libswsscommon not getting installed due to new dependencies being added. Solve this by using apt install to install the package, which brings in any necessary dependencies. * [syncd] Move logSet logGet under mutex to prevent race condition (sonic-net#1520) (sonic-net#1538) [syncd] Move logSet logGet under mutex to prevent race condition * Optimize counter polling interval by making it more accurate (sonic-net#1457) (sonic-net#1534) What I did Optimize the counter-polling performance in terms of polling interval accuracy Enable bulk counter-polling to run at a smaller chunk size There is one counter-polling thread for each counter group. All such threads can compete for the critical sections at the vendor SAI level, which means a counter-polling thread can wait for a critical section if another thread has been in it, which introduces latency for the waiting counter group. An example is the competition between the PFC watchdog and the port counter groups. The port counter group contains many counters and is polled in a bulk mode which takes a relatively longer time. The PFC watchdog counter group contains only a few counters but is polled at a short interval. Sometimes, PFC watchdog counters need to wait before polling, which makes the polling interval inaccurate and prevents the PFC storm from being detected in time. To resolve this issue, we can reduce the chunk size of the port counter group. The port counter group polls the counters of all ports in a single bulk operation by default. By using a smaller chunk size, it polls the counters in several bulk operations with each polling counter of a subset (whose size <= chunk size) of all ports. By doing so, the port counter group stays in the critical section for a shorter time and the PFC watchdog is more likely to be scheduled to poll counters and detect the PFC storm in time. Collect the time stamp immediately after vendor SAI API returns. Currently, many counter groups require a Lua plugin to execute based on polling interval, to calculate rates, detect certain events, etc. Eg. For PFC watchdog counter group to PFC storm. In this case, the polling interval is calculated based on the difference of time stamps between the current and last poll to avoid deviation due to scheduling latency. However, the timestamp is collected in the Lua plugin which is several steps after the SAI API returns and is executed in a different context (redis-server). Both introduce even larger deviations. To overcome this, we collect the timestamp immediately after the SAI API returns. * Revert "Do not enter vendor SAI critical section for counter polling/clearing operations (sonic-net#1450)" (sonic-net#1541) Revert "Do not enter vendor SAI critical section for counter polling/clearing operations (sonic-net#1450)" This reverts commit 0317b16. * [vslib] SAI_KEY_VS_OPER_SPEED_IS_CONFIGURED_SPEED, SAI_PORT_ATTR_HOST_TX_READY_STATUS support (sonic-net#1553) This PR adds two features to `vslib`. - `SAI_KEY_VS_OPER_SPEED_IS_CONFIGURED_SPEED`: when `true`, `SAI_PORT_ATTR_SPEED` returns the configured speed instead of the value retrieved via [`/sys/class/net/<name>/speed`](https://github.com/sonic-net/sonic-sairedis/blob/master/vslib/SwitchStateBaseHostif.cpp#L892-L893). - fixes sonic-net/sonic-buildimage#19735 - `SAI_PORT_ATTR_HOST_TX_READY_STATUS`: always returns `true`. Required to support running `xcvrd` in the VS env. - ref: https://github.com/sonic-net/SONiC/pull/1849/files#diff-6f3e95e6c57a3edc2e30e1f13edb9fd9a32a0db44e1035ac1f0b1b9a191762a5R46 * Update build_and_install_module.sh to match newer Linux kernel version (sonic-net#1561) sonic-sairedis will checkout sonic-swss to do vstest but using local build_and_install_module.sh to setup test environment, which is out of date with newer Linux kernel version. The build_and_install_module.sh in sonic-swss is up to date with latest Ubuntu 20.04, so we need to update the build sh file with the file in sonic-swss. In a long term, we may need to do some automatically sync, but now we have some azure agent security issue need to fix immediately, so just update the build_and_install_module.sh manually. * Revert "Optimize counter polling interval by making it more accurate (sonic-net#1457) …" (sonic-net#1570) Revert "Optimize counter polling interval by making it more accurate --------- Co-authored-by: mssonicbld <[email protected]> Co-authored-by: Jianyue Wu <[email protected]> Co-authored-by: Kamil Cudnik <[email protected]> Co-authored-by: Stephen Sun <[email protected]> Co-authored-by: Kumaresh Perumal <[email protected]>
DavidZagury
pushed a commit
to DavidZagury/sonic-sairedis
that referenced
this pull request
Apr 28, 2025
Code sync sonic-net/sonic-sairedis:202411 => 202412 ``` * 0fcc968 (HEAD -> code-sync-202412, origin/code-sync-202412) r12f 250417:0536 - Merge remote-tracking branch 'base/202411' into code-sync-202412 |\ | * 4048483 (base/202411) Kumaresh Perumal 250403:0905 - Revert "Optimize counter polling interval by making it more accurate (sonic-net#1457) …" (sonic-net#1570) | * 420d92f (user/riffjiang/last-202411) mssonicbld 250319:1302 - Update build_and_install_module.sh to match newer Linux kernel version (sonic-net#1561) | * e2d2ca6 mssonicbld 250312:1602 - [vslib] SAI_KEY_VS_OPER_SPEED_IS_CONFIGURED_SPEED, SAI_PORT_ATTR_HOST_TX_READY_STATUS support (sonic-net#1553) | * 8c17d4b mssonicbld 250227:0702 - Revert "Do not enter vendor SAI critical section for counter polling/clearing operations (sonic-net#1450)" (sonic-net#1541) | * 3df03e1 Stephen Sun 250226:1737 - Optimize counter polling interval by making it more accurate (sonic-net#1457) (sonic-net#1534) | * d884ff9 Kamil Cudnik 250221:0109 - [syncd] Move logSet logGet under mutex to prevent race condition (sonic-net#1520) (sonic-net#1538) | * ec8b3c3 mssonicbld 250219:1902 - Fix pipeline errors related to rsyslogd and libswsscommon installation (sonic-net#1535) | * 6b263b8 mssonicbld 250219:0702 - [FC] Support Policer Counter (sonic-net#1533) | * e53489e Jianyue Wu 250219:0217 - [syncd] Update log level for bulk api (sonic-net#1532) | * 7ae00e5 mssonicbld 250211:0703 - Define bulk chunk size and bulk chunk size per counter ID (sonic-net#1528) | * f35e743 mssonicbld 250207:1005 - [nvidia] Skip SAI discovery on ports (sonic-net#1524) | * bf049ed mssonicbld 250205:1328 - Use sonictest pool instead of sonic-common and fix arm64 issue. (sonic-net#1516) | * ffe371d mssonicbld 250205:1327 - [syncd] Support bulk set in INIT_VIEW mode (sonic-net#1517) ```
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
6 participants
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
Optimize the counter-polling performance in terms of polling interval accuracy
Enable bulk counter-polling to run at a smaller chunk size
There is one counter-polling thread for each counter group. All such threads can compete for the critical sections at the vendor SAI level, which means a counter-polling thread can wait for a critical section if another thread has been in it, which introduces latency for the waiting counter group.
An example is the competition between the PFC watchdog and the port counter groups.
The port counter group contains many counters and is polled in a bulk mode which takes a relatively longer time. The PFC watchdog counter group contains only a few counters but is polled at a short interval. Sometimes, PFC watchdog counters need to wait before polling, which makes the polling interval inaccurate and prevents the PFC storm from being detected in time.
To resolve this issue, we can reduce the chunk size of the port counter group. The port counter group polls the counters of all ports in a single bulk operation by default. By using a smaller chunk size, it polls the counters in several bulk operations with each polling counter of a subset (whose size <=
chunk size) of all ports.By doing so, the port counter group stays in the critical section for a shorter time and the PFC watchdog is more likely to be scheduled to poll counters and detect the PFC storm in time.
Collect the time stamp immediately after vendor SAI API returns.
Currently, many counter groups require a Lua plugin to execute based on polling interval, to calculate rates, detect certain events, etc.
Eg. For PFC watchdog counter group to PFC storm. In this case, the polling interval is calculated based on the difference of time stamps between the
currentandlastpoll to avoid deviation due to scheduling latency. However, the timestamp is collected in the Lua plugin which is several steps after the SAI API returns and is executed in a different context (redis-server). Both introduce even larger deviations. To overcome this, we collect the timestamp immediately after the SAI API returns.Depends on
Why I did it
How I verified it
Run regression test and observe counter-polling performance.
A comparison test shows very good results if we put any/or all of the above optimizations.
Details if related
For 2, each counter group contains more than one counter context based on the type of objects. counter context is mapped from (group, object type). But the counters fetched from different counter groups will be pushed into the same entry for the same objects.
eg. PFC_WD group contains counters of ports and queues. PORT group contains counters of ports. QUEUE_STAT group contains counters of queues.
Both PFC_WD and PORT groups will push counter data into an item representing a port. but each counter has its own polling interval, which means counter IDs polled from different counter groups can be polled with different time stamps.
We use the name of a counter group to identify the time stamp of the counter group.
Eg. In port counter entry, PORT_timestamp represents last time when the port counter group polls the counters. PFC_WD_timestamp represents the last time when the PFC watchdog counter group polls the counters