[2405][BRCM-DNX]: 'sonic-clear queuecounter' CLI does not clear the queue counters. #20913
Labels
Chassis 🤖
Modular chassis support
Comments
|
@rlhui for viz |
|
This should be addressed by sonic-net/sonic-utilities#3635 which merged to 202405 a fews days ago. However, I haven't yet had a chance to test the latest upstream image to confirm. |
|
Logs for 'sonic-clear queuecounter': |
|
I confirmed that the cherry-picked PR (sonic-net/sonic-utilities#3635) addresses this issue. The issue now is that we need to bump up |
|
@kenneth-arista , @vmittal-msft, @saksarav-nokia Sakthi helped to patch the queue counter changes. We tested the patch and found that 'Ethernet0' egress stats are not cleared with 'sonic-clear queuecounters' CLI. Output with patch: As seen above, Ethernet0 stats are not cleared, while the other interfaces have their counters cleared. It is possible that maybe if there are multiple priority entries for a given interface, the CLI is unable to clear it. Will test and update. Thanks, |
rlhui
pushed a commit
to sonic-net/sonic-utilities
that referenced
this issue
Dec 12, 2024
…oq (#3671) Fixed the sonic-clear queuecounter issues reported in sonic-net/sonic-buildimage#20913 For the egress queue counters, after the queue counter is cleared and show is issued with --nonzero option, the code takes the elif path at line 323 (old code) even if the diff between cached counter and current counter is 0, prints the current counter values from counter_db . This issue was for both egress queue counter and voq counter. When the sonic-clear queuecounter is issued , the queuestat is called first without --voq option and this gets the port names and queue ids for each port in each asic , reads the egress queue counters and cache the values in /tmp/cache/queuestat/. Then queuestat is called with --voq option and this gets all the system ports names and voq id's for each asic , reads the voq counters and cache the values in /tmp/cache/queuestat. Since each asic has the all the system ports and all the voqs, and since the cache file name is queuestat+system_port_name with out asic namespace, caching asic1's voq counters overwrites the asic0's voq counters . How I did it 1)Corrected the logic mistake for issue 1. Since cnstat_diff_print is called only if cache file is present and this should print only if non-zero & valid diff or (not non-zero ) 2) Added asic namespace with the cache file name for vow counters. Signed-off-by: saksarav <[email protected]>
mssonicbld
pushed a commit
to mssonicbld/sonic-utilities
that referenced
this issue
Dec 24, 2024
…oq (sonic-net#3671) Fixed the sonic-clear queuecounter issues reported in sonic-net/sonic-buildimage#20913 For the egress queue counters, after the queue counter is cleared and show is issued with --nonzero option, the code takes the elif path at line 323 (old code) even if the diff between cached counter and current counter is 0, prints the current counter values from counter_db . This issue was for both egress queue counter and voq counter. When the sonic-clear queuecounter is issued , the queuestat is called first without --voq option and this gets the port names and queue ids for each port in each asic , reads the egress queue counters and cache the values in /tmp/cache/queuestat/. Then queuestat is called with --voq option and this gets all the system ports names and voq id's for each asic , reads the voq counters and cache the values in /tmp/cache/queuestat. Since each asic has the all the system ports and all the voqs, and since the cache file name is queuestat+system_port_name with out asic namespace, caching asic1's voq counters overwrites the asic0's voq counters . How I did it 1)Corrected the logic mistake for issue 1. Since cnstat_diff_print is called only if cache file is present and this should print only if non-zero & valid diff or (not non-zero ) 2) Added asic namespace with the cache file name for vow counters. Signed-off-by: saksarav <[email protected]>
mssonicbld
pushed a commit
to sonic-net/sonic-utilities
that referenced
this issue
Dec 24, 2024
…oq (#3671) Fixed the sonic-clear queuecounter issues reported in sonic-net/sonic-buildimage#20913 For the egress queue counters, after the queue counter is cleared and show is issued with --nonzero option, the code takes the elif path at line 323 (old code) even if the diff between cached counter and current counter is 0, prints the current counter values from counter_db . This issue was for both egress queue counter and voq counter. When the sonic-clear queuecounter is issued , the queuestat is called first without --voq option and this gets the port names and queue ids for each port in each asic , reads the egress queue counters and cache the values in /tmp/cache/queuestat/. Then queuestat is called with --voq option and this gets all the system ports names and voq id's for each asic , reads the voq counters and cache the values in /tmp/cache/queuestat. Since each asic has the all the system ports and all the voqs, and since the cache file name is queuestat+system_port_name with out asic namespace, caching asic1's voq counters overwrites the asic0's voq counters . How I did it 1)Corrected the logic mistake for issue 1. Since cnstat_diff_print is called only if cache file is present and this should print only if non-zero & valid diff or (not non-zero ) 2) Added asic namespace with the cache file name for vow counters. Signed-off-by: saksarav <[email protected]>
|
Verification logs:
Closing this issue. Thanks, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
This is regression in 2405 as compared to release 2205.
We are using CLI - 'sudo ip netns exec asic<0/1> sonic-clear queuecounter' to clear the queue counter. The same CLI was used in 2205 to clear the counters.
However, in 2405, this CLI does not clear the counter.
Note - there is an on-going discussion about 'show ...' CLIs involved in multi-asic environment. However, the clear commands should also be addressed. This issue is a placeholder to ensure that we address this issue.
@saksarav-nokia.
Steps to reproduce the issue:
Describe the results you received:
In 2405 release, these counters are not reset to zero.
Describe the results you expected:
The counters should reset to zero.
Output of
show version:Output of
show techsupport:Additional information you deem important (e.g. issue happens only occasionally):
The text was updated successfully, but these errors were encountered: