Fix SNMP dropping some of the queue counter when create_only_config_d… #1
Conversation
This file contains 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
DavidZagury
force-pushed
the
master_fix_snmp_counters_with_create_only_config
branch
from
b15b022 to
a0ce63d
Compare
stephenxs
reviewed
Dec 15, 2023
| # Otherwise the first half of queue id is for ucast, and second half is for mcast | ||
| # In that case to simulate vendor OID, we wrap queues by half distance | ||
| div = 1 if create_only_config_db_buffers == 'true' else 2 | ||
| pq_count = math.ceil((max(if_queues) + 1) / div) |
There was a problem hiding this comment.
It assumed
- the number of counters equals the number of queues
- the number of UC queues equals the number of MC queues
After the change, assumption 2 is still true but assumption 1 can be false.
I do not suggest calculating pq_count by dividing max(if_queues) by 2 by default or 1 when create_only_config_db_buffers is configured. It can still break the logic in case a user configures a buffer on an MC queue.
I suggest the following ways to maintain backward compatibility after create_only_config_db_buffers
- leveraging the mapping
COUNTERS_QUEUE_TYPE_MAP - fetching the number of queues from
STATE_DB.BUFFER_MAX_PARAM_TABLE|<port>.max_queues
However, I have to say, this is still not 100% correct especially if a vendor doesn't have MC queues
DavidZagury
force-pushed
the
master_fix_snmp_counters_with_create_only_config
branch
6 times, most recently
from
a709fcc to
79a5b82
Compare
…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
DavidZagury
force-pushed
the
master_fix_snmp_counters_with_create_only_config
branch
from
79a5b82 to
71f9e81
Compare
stephenxs
approved these changes
Dec 18, 2023
stephenxs
approved these changes
Dec 20, 2023
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.
…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
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