-
Notifications
You must be signed in to change notification settings - Fork 116
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
Fix SNMP dropping some of the queue counter when create_only_config_d… #303
Fix SNMP dropping some of the queue counter when create_only_config_d… #303
Conversation
…b_buffers is set to true This happened because the MIB assumed that half the queues configured are for mcast. To remove this assumpetion we will check the max number of queues from STATE_DB.BUFFER_MAX_PARAM_TABLE|<port>.max_queues
…8 and not (16 + 1 ) % 2 = 9
@qiluo-msft , Can you please review ? |
I see a bug inside Refers to: src/sonic_ax_impl/mibs/vendor/cisco/ciscoSwitchQosMIB.py:92 in 3d13de4. [](commit_id = 3d13de4, deletion_comment = False) |
…plete UC and incomplete MC.
@qiluo-msft , Can you please set the label of : "Request for 202311 branch" ? |
Add UT for multi asic
Hi @qiluo-msft - I don't see what is the issue you are seeing here. And I don't know how could we get the port index only by using these tables withouth COUNTERS_QUEUE_NAME_MAP or at lest COUNTERS_PORT_NAME_MAP. |
@qiluo-msft @StormLiangMS Can you please add label for 202305? |
@qiluo-msft , can you please review and approve ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, please check with other active reviewers.
@dgsudharsan @DavidZagury could you address comment from Suvarna? |
@DavidZagury @dgsudharsan pls test this PR with 202305 image. |
…b_buffers is set to true (sonic-net#303) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue
Cherry-pick PR to 202205: #305 |
…b_buffers is set to true (#303) (#305) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue Co-authored-by: DavidZagury <[email protected]>
… when create_only_config_db_buffers is set to true (#303)"
…b_buffers is set to true (sonic-net#303) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue
Cherry-pick PR to 202305: #309 |
…b_buffers is set to true (#303) (#309) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue Co-authored-by: DavidZagury <[email protected]>
@yxieca can we merge this to 202311? |
…b_buffers is set to true (sonic-net#303) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue
Cherry-pick PR to 202311: #310 |
…b_buffers is set to true (#303) This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case **- What I did** The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast. This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters. This wrong assumption caused issue sonic-net/sonic-buildimage#17448 To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues **- How I did it** **- How to verify it** Inside the SNMP docker run snmp walk: $ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1 Check that the results is not missing counters from any queue
## Description of PR This test is checking that buffer queue counters inside snmp docker are inline when using create_only_config_db_counters optimization. Summary: Accompanies "Fix SNMP dropping some of the queue counter when create_only_config_db_buffers is set to true" (sonic-net/sonic-snmpagent#303) which fixes the issue: "The feature "polling only configured ports buffer queue" will break SNMP" (sonic-net/sonic-buildimage#17448). ### Type of change - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [x] Test case(new/improvement) ## Approach #### What is the motivation for this PR? To enhance the bug fix mentioned above, solving an issue with buffer queue counters optimization. #### How did you do it? - Set "create_only_config_db_buffers" to true in config db, to create only relevant counters - Remove one of the buffer queues, Ethernet0|3-4 is chosen arbitrary - Using snmpwalk compare number of queue counters on Ethernet0, assuming there will be 8 less after removing the buffer. (Assuming unicast only, 4 counters for each queue in this case) #### How did you verify/test it? Run the test multiple times on various setups. Run the test while reverting the fix mentioned above to see the different result. ### Supported testbed topology if it's a new test case? Any
…b_buffers is set to true
This happened because the MIB assumed that half the queues configured are for mcast. When create_only_config_db_buffers is set to true this is not the case
- What I did
The ciscoSwitchQosMIB MIB assumed that all the counter are configured and that half of the configured queues are for mcast.
This is no longer true, the feature "polling only configured ports buffer queue" make it possible for port to not have MC counters.
This wrong assumption caused issue sonic-net/sonic-buildimage#17448
To fix this, I instead used the BUFFER_MAX_PARAM_TABLE to find the max possible queues
- How I did it
- How to verify it
Inside the SNMP docker run snmp walk:
$ snmpwalk -v2c -c msft 10.64.247.240 1.3.6.1.4.1.9.9.580.1.5.5.1.4.1
Check that the results is not missing counters from any queue
- Description for the changelog