-
Notifications
You must be signed in to change notification settings - Fork 648
[sflow] Add Dropped Packet Notification (MOD) support. #3970
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
base: master
Are you sure you want to change the base?
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
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.
Pull Request Overview
This PR adds SFLOW drop monitor functionality to track and rate-limit dropped packets using TAM (Telemetry and Monitoring) infrastructure. The implementation enables drop monitoring only when SFLOW is enabled and provides configurable rate limiting through a policer.
- Introduces
SflowDropMonitorclass to manage TAM-based drop monitoring - Adds configuration support for
drop_monitor_limitparameter in SFLOW global settings - Implements comprehensive SAI object lifecycle management for TAM, policer, and hostif trap components
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| orchagent/sfloworch.h | Adds SflowDropMonitor class definition with TAM object management methods and member variable to SflowOrch |
| orchagent/sfloworch.cpp | Implements drop monitor enable/disable logic, TAM object creation/removal, and global config parsing with drop_monitor_limit |
| tests/mock_tests/portal.h | Adds accessor methods for testing drop monitor status and limit rate |
| tests/mock_tests/sfloworh_ut.cpp | Adds unit tests for drop monitor enable/disable and rate limit change scenarios |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <[email protected]>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Co-authored-by: Copilot <[email protected]>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Co-authored-by: Copilot <[email protected]>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| set_switch_capability(fvVector); | ||
| } | ||
|
|
||
| void SwitchOrch::querySwitchMirrorOnDropCapability() |
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.
It looks like some of the checks here are too specific to HOSTIF traps, but the capability being set is generic SWITCH_CAPABILITY_TABLE_MIRROR_ON_DROP_CAPABLE. Does it make sense to refactor this and add probably a capability specific to SFLOW/HOSTIF so that it can be reused for other MOD implementations ?
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.
The current capability check is based on the functions used by the sFlow drop monitor as described in the HLD. Other MOD implementations may have different requirements and fall outside the scope of this change.
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.
Since this is specific to sFlow, doesn't it make sense to name it as such by factoring out the non-sflow specific code from here ? Or are you thinking querySwitchMirrorOnDropCapability would evolve to add additional checks and return true if any form of MOD is supported ? Even if that is the case, I would recommend refactoring this to put sflow specific checks in another function say querySwitchSfloModCapability and use that in querySwitchMirrorOnDropCapability
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.
Just to confirm — your suggestion is to create a new function querySwitchSflowModCapability() that is called from querySwitchMirrorOnDropCapability(), and move the following HOSTIF-specific checks into it:
- SAI_HOSTIF_USER_DEFINED_TRAP_ATTR_TYPE (enum)
- SAI_HOSTIF_USER_DEFINED_TRAP_TYPE_TAM
- SAI_HOSTIF_USER_DEFINED_TRAP_ATTR_TRAP_GROUP
Then, querySwitchMirrorOnDropCapability() would call querySwitchSflowModCapability(), and if it returns true (along with all required TAM capabilities), it would set SWITCH_CAPABILITY_TABLE_MIRROR_ON_DROP_CAPABLE.
Please confirm if this matches your idea.
What I did
Added Dropped Packet Notification (MOD) support.
Why I did it
Enhancement.
How I verified it
Added mock tests.
HLD: sonic-net/SONiC#1786