-
Notifications
You must be signed in to change notification settings - Fork 539
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Counters] Improve performance by polling only configured ports buffer queue/pg counters #2143
[Counters] Improve performance by polling only configured ports buffer queue/pg counters #2143
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 <shlomibi@nvidia.com>
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
…omi_buffer_queues_pgs_counters_configurations_master
/AzurePipelines run LGTM analysis: C/C++ |
No pipelines are associated with this pull request. |
/AzurePipelines run LGTM |
No pipelines are associated with this pull request. |
/AzurePipelines run Azure.sonic-swss (Test vstest) |
No pipelines are associated with this pull request. |
/azpw run Azure.sonic-swss |
/AzurePipelines run Azure.sonic-swss |
Azure Pipelines successfully started running 1 pipeline(s). |
@stepanblyschak could you please review this? |
/azp run Azure.sonic-swss |
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: Shlomi Bitton <shlomibi@nvidia.com>
/azpw run Azure.sonic-swss |
/AzurePipelines run Azure.sonic-swss |
Azure Pipelines successfully started running 1 pipeline(s). |
…r queue/pg counters (#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 <shlomibi@nvidia.com>
@shlomibitton I tried again, still having PR test failures with:
} |
@yxieca did you try it with the fix I provided for sonic-utilities? |
Ah, I see, I jumped the gun. The utility PR is still open. |
Signed-off-by: Nazarii Hnydyn nazariig@nvidia.com 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.
…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 <shlomibi@nvidia.com>
…ts buffer queue/pg counters (sonic-net#2143)" (sonic-net#2315) This reverts commit eba212d.
Signed-off-by: Nazarii Hnydyn nazariig@nvidia.com 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.
…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 <nazariig@nvidia.com>
…t#2239) Signed-off-by: Nazarii Hnydyn nazariig@nvidia.com 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.
* 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 <paravind@microsoft.com>
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 ying.xie@microsoft.com
Signed-off-by: Nazarii Hnydyn nazariig@nvidia.com 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.
* 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 <paravind@microsoft.com>
* 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 <paravind@microsoft.com>
* 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 <paravind@microsoft.com>
* 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 <paravind@microsoft.com>
* 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 <paravind@microsoft.com>
* 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 <paravind@microsoft.com>
* 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 <paravind@microsoft.com>
* 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 <paravind@microsoft.com>
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