[Counters] Improve performance by polling only configured ports buffer queue/pg counters#2143
Merged
liat-grozovik merged 18 commits intosonic-net:masterfrom May 31, 2022
shlomibitton:shlomi_buffer_queues_pgs_counters_configurations_master
Merged
[Counters] Improve performance by polling only configured ports buffer queue/pg counters#2143liat-grozovik merged 18 commits intosonic-net:masterfrom shlomibitton:shlomi_buffer_queues_pgs_counters_configurations_master
liat-grozovik merged 18 commits intosonic-net:masterfrom
shlomibitton:shlomi_buffer_queues_pgs_counters_configurations_master
Conversation
Supported commands
See additional documentation. |
|
Commenter does not have sufficient privileges for PR 2143 in repo Azure/sonic-swss |
1 similar comment
|
Commenter does not have sufficient privileges for PR 2143 in repo Azure/sonic-swss |
… init. If no buffer configurations available, no counters will be created. Allow creating/removing counters on runtime if buffer PG/Queue is created or removed. New UT added to verify new flow. Signed-off-by: Shlomi Bitton <[email protected]>
Collaborator
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
…omi_buffer_queues_pgs_counters_configurations_master
Collaborator
|
/AzurePipelines run LGTM analysis: C/C++ |
|
No pipelines are associated with this pull request. |
Collaborator
|
/AzurePipelines run LGTM |
|
No pipelines are associated with this pull request. |
Collaborator
|
/AzurePipelines run Azure.sonic-swss (Test vstest) |
|
No pipelines are associated with this pull request. |
Contributor
Author
|
/azpw run Azure.sonic-swss |
Collaborator
|
/AzurePipelines run Azure.sonic-swss |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
|
@stepanblyschak could you please review this? |
Collaborator
|
/azp run Azure.sonic-swss |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Shlomi Bitton <[email protected]>
Contributor
Author
|
/azpw run Azure.sonic-swss |
Collaborator
|
/AzurePipelines run Azure.sonic-swss |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
|
@shlomibitton I tried again, still having PR test failures with: } |
Contributor
Author
|
@yxieca did you try it with the fix I provided for sonic-utilities? |
Contributor
Ah, I see, I jumped the gun. The utility PR is still open. |
This was referenced Jun 28, 2022
neethajohn
pushed a commit
to sonic-net/sonic-utilities
that referenced
this pull request
Jul 28, 2022
Signed-off-by: Nazarii Hnydyn [email protected] Propagating #2220 with resolved review comments What I did Since PG counters are created only if they are configured in the switch, it is not enough to relay only on the first entry in the DB when building the output table of watermarkstat script. We need to go over all configured counters, check what is the max configured, and build the table accordingly. How I did it Iterate all configured PG buffers for all ports and find the max index. Build the output table according to the max index. How to verify it Run test "iface_namingmode/test_iface_namingmode.py" including this PR: sonic-net/sonic-swss#2143 and observe it passes.
preetham-singh
pushed a commit
to preetham-singh/sonic-swss
that referenced
this pull request
Aug 6, 2022
…r queue/pg counters (sonic-net#2143) - What I did Currently in SONiC all ports queue and pg counters are created by default with the max possible amount of counters. This feature change this behavior to poll only configured counters provided by the config DB BUFFER_PG and BUFFER_QUEUE tables. If no tables are present in the DB, no counters will be created for ports. Filter the unwanted queues/pgs returned by SAI API calls and skip the creation of these queue/pg counters. Also allow creating/removing counters on runtime if buffer PG/Queue is configured or removed. - Why I did it Improve performance by filtering unconfigured queue/pg counters on init. - How I verified it Check after enabling the counters, if configured counters created in Counters DB according to the configurations. Add/Remove buffer PG/Queue configurations and observe the corresponding counters created/removed accordingly. New UT added to verify this flow. Signed-off-by: Shlomi Bitton <[email protected]>
preetham-singh
pushed a commit
to preetham-singh/sonic-swss
that referenced
this pull request
Aug 6, 2022
…ts buffer queue/pg counters (sonic-net#2143)" (sonic-net#2315) This reverts commit eba212d.
yxieca
pushed a commit
to sonic-net/sonic-utilities
that referenced
this pull request
Aug 8, 2022
Signed-off-by: Nazarii Hnydyn [email protected] Propagating #2220 with resolved review comments What I did Since PG counters are created only if they are configured in the switch, it is not enough to relay only on the first entry in the DB when building the output table of watermarkstat script. We need to go over all configured counters, check what is the max configured, and build the table accordingly. How I did it Iterate all configured PG buffers for all ports and find the max index. Build the output table according to the max index. How to verify it Run test "iface_namingmode/test_iface_namingmode.py" including this PR: sonic-net/sonic-swss#2143 and observe it passes.
liat-grozovik
pushed a commit
that referenced
this pull request
Aug 25, 2022
…r queue/pg counters (#2360) Propagating #2143 with resolved merge conflicts Depends on: sonic-net/sonic-utilities#2239 - What I did Currently in SONiC all ports queue and pg counters are created by default with the max possible amount of counters. This feature change this behavior to poll only configured counters provided by the config DB BUFFER_PG and BUFFER_QUEUE tables. If no tables are present in the DB, no counters will be created for ports. Filter the unwanted queues/pgs returned by SAI API calls and skip the creation of these queue/pg counters. Also allow creating/removing counters on runtime if buffer PG/Queue is configured or removed. - Why I did it Improve performance by filtering unconfigured queue/pg counters on init. - How I verified it Check after enabling the counters, if configured counters created in Counters DB according to the configurations. Add/Remove buffer PG/Queue configurations and observe the corresponding counters created/removed accordingly. New UT added to verify this flow. Signed-off-by: Nazarii Hnydyn <[email protected]>
preetham-singh
pushed a commit
to preetham-singh/sonic-utilities
that referenced
this pull request
Nov 21, 2022
…t#2239) Signed-off-by: Nazarii Hnydyn [email protected] Propagating sonic-net#2220 with resolved review comments What I did Since PG counters are created only if they are configured in the switch, it is not enough to relay only on the first entry in the DB when building the output table of watermarkstat script. We need to go over all configured counters, check what is the max configured, and build the table accordingly. How I did it Iterate all configured PG buffers for all ports and find the max index. Build the output table according to the max index. How to verify it Run test "iface_namingmode/test_iface_namingmode.py" including this PR: sonic-net/sonic-swss#2143 and observe it passes.
prabhataravind
added a commit
to prabhataravind/sonic-mgmt
that referenced
this pull request
Aug 2, 2023
* Check all queues for the test instead of just q0 * Remove check for q7 counters until regression due to sonic-net/sonic-swss#2143 is fixed * Perform interface queue counter checks only once when there are v4 and v6 neighbors over the same interface Signed-off-by: Prabhat Aravind <[email protected]>
malletvapid23
added a commit
to malletvapid23/Sonic-Utility
that referenced
this pull request
Aug 3, 2023
What I did Skip counters that are not enabled. How to verify it With change sonic-net/sonic-swss#2143, following commands will cause exception: admin@vlab-01:~$ show priority-group persistent-watermark headroom Traceback (most recent call last): File "/usr/local/bin/watermarkstat", line 315, in main() File "/usr/local/bin/watermarkstat", line 310, in main watermarkstat.print_all_stat(table_prefix, args.type) File "/usr/local/bin/watermarkstat", line 261, in print_all_stat data = self.get_counters(table_prefix, File "/usr/local/bin/watermarkstat", line 237, in get_counters elif fields[pos] != STATUS_NA: IndexError: list index out of range With the change: admin@vlab-01:~$ show priority-group persistent-watermark headroom Ingress headroom per PG: Port Ethernet0 Ethernet4 Ethernet8 Ethernet12 Ethernet16 ... ... Signed-off-by: Ying Xie [email protected]
malletvapid23
added a commit
to malletvapid23/Sonic-Utility
that referenced
this pull request
Aug 3, 2023
Signed-off-by: Nazarii Hnydyn [email protected] Propagating #2220 with resolved review comments What I did Since PG counters are created only if they are configured in the switch, it is not enough to relay only on the first entry in the DB when building the output table of watermarkstat script. We need to go over all configured counters, check what is the max configured, and build the table accordingly. How I did it Iterate all configured PG buffers for all ports and find the max index. Build the output table according to the max index. How to verify it Run test "iface_namingmode/test_iface_namingmode.py" including this PR: sonic-net/sonic-swss#2143 and observe it passes.
prabhataravind
added a commit
to sonic-net/sonic-mgmt
that referenced
this pull request
Aug 7, 2023
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <[email protected]>
mssonicbld
pushed a commit
to mssonicbld/sonic-mgmt
that referenced
this pull request
Sep 15, 2023
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <[email protected]>
mssonicbld
pushed a commit
to sonic-net/sonic-mgmt
that referenced
this pull request
Sep 16, 2023
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <[email protected]>
mssonicbld
pushed a commit
to mssonicbld/sonic-mgmt
that referenced
this pull request
Nov 6, 2023
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <[email protected]>
mssonicbld
pushed a commit
to mssonicbld/sonic-mgmt
that referenced
this pull request
Nov 6, 2023
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <[email protected]>
mssonicbld
pushed a commit
to sonic-net/sonic-mgmt
that referenced
this pull request
Nov 6, 2023
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <[email protected]>
mssonicbld
pushed a commit
to sonic-net/sonic-mgmt
that referenced
this pull request
Nov 10, 2023
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <[email protected]>
AharonMalkin
pushed a commit
to AharonMalkin/sonic-mgmt
that referenced
this pull request
Jan 25, 2024
* All control packets including BGP are expected to use Q7, separate from data packet queues * Check for q7 counters is not being done until regression due to sonic-net/sonic-swss#2143 is fixed Signed-off-by: Prabhat Aravind <[email protected]>
Janetxxx
pushed a commit
to Janetxxx/sonic-swss
that referenced
this pull request
Nov 10, 2025
…r queue/pg counters (sonic-net#2143) - What I did Currently in SONiC all ports queue and pg counters are created by default with the max possible amount of counters. This feature change this behavior to poll only configured counters provided by the config DB BUFFER_PG and BUFFER_QUEUE tables. If no tables are present in the DB, no counters will be created for ports. Filter the unwanted queues/pgs returned by SAI API calls and skip the creation of these queue/pg counters. Also allow creating/removing counters on runtime if buffer PG/Queue is configured or removed. - Why I did it Improve performance by filtering unconfigured queue/pg counters on init. - How I verified it Check after enabling the counters, if configured counters created in Counters DB according to the configurations. Add/Remove buffer PG/Queue configurations and observe the corresponding counters created/removed accordingly. New UT added to verify this flow. Signed-off-by: Shlomi Bitton <[email protected]>
Janetxxx
pushed a commit
to Janetxxx/sonic-swss
that referenced
this pull request
Nov 10, 2025
…ts buffer queue/pg counters (sonic-net#2143)" (sonic-net#2315) This reverts commit eba212d.
Janetxxx
pushed a commit
to Janetxxx/sonic-swss
that referenced
this pull request
Nov 10, 2025
…r queue/pg counters (sonic-net#2360) Propagating sonic-net#2143 with resolved merge conflicts Depends on: sonic-net/sonic-utilities#2239 - What I did Currently in SONiC all ports queue and pg counters are created by default with the max possible amount of counters. This feature change this behavior to poll only configured counters provided by the config DB BUFFER_PG and BUFFER_QUEUE tables. If no tables are present in the DB, no counters will be created for ports. Filter the unwanted queues/pgs returned by SAI API calls and skip the creation of these queue/pg counters. Also allow creating/removing counters on runtime if buffer PG/Queue is configured or removed. - Why I did it Improve performance by filtering unconfigured queue/pg counters on init. - How I verified it Check after enabling the counters, if configured counters created in Counters DB according to the configurations. Add/Remove buffer PG/Queue configurations and observe the corresponding counters created/removed accordingly. New UT added to verify this flow. Signed-off-by: Nazarii Hnydyn <[email protected]>
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
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
Currently in SONiC all ports queue and pg counters are created by default with the max possible amount of counters.
This feature change this behavior to poll only configured counters provided by the config DB BUFFER_PG and BUFFER_QUEUE tables.
If no tables are present in the DB, no counters will be created for ports.
Filter the unwanted queues/pgs returned by SAI API calls and skip the creation of these queue/pg counters.
Also allow creating/removing counters on runtime if buffer PG/Queue is configured or removed.
Why I did it
Improve performance by filtering unconfigured queue/pg counters on init.
How I verified it
Check after enabling the counters, if configured counters created in Counters DB according to the configurations.
Add/Remove buffer PG/Queue configurations and observe the corresponding counters created/removed accordingly.
New UT added to verify this flow.
Details if related