Skip to content

Conversation

@yehjunying
Copy link
Contributor

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

@yehjunying yehjunying requested a review from prsunny as a code owner November 3, 2025 08:08
Copilot AI review requested due to automatic review settings November 3, 2025 08:08
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Nov 3, 2025

CLA Signed

The committers listed above are authorized under a signed CLA.

  • ✅ login: yehjunying / name: junying_yeh (9513bd6, d65bf61)
  • ✅ login: yehjunying / name: yehjunying (12fbb5f)

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link

Copilot AI left a 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 SflowDropMonitor class to manage TAM-based drop monitoring
  • Adds configuration support for drop_monitor_limit parameter 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.

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

set_switch_capability(fvVector);
}

void SwitchOrch::querySwitchMirrorOnDropCapability()

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 ?

Copy link
Contributor Author

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.

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

Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants