Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions inc/saiport.h
Original file line number Diff line number Diff line change
Expand Up @@ -3481,6 +3481,17 @@ typedef enum _sai_port_attr_t
*/
SAI_PORT_ATTR_APSU_ISL_READY,

/** @brief Link down debounce time in microseconds
*
* 0 means no delay time so link down events are immediately delivered as usual
* This attribute overrides the switch level debounce configuration

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we slightly reword as: A non-zero value of this port attribute overrides the switch level debounce timeout.
The reason being that the default value of this port attr is 0 and can cause confusion.

@JaiOCP JaiOCP May 7, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have kept the wording consistent with the port up debounce. If you feel strongly then probably would be a good idea to change there as well.

I feel the wording is ok: if port is not configured then default of 0 is a no op as an override.

*
* @type sai_uint32_t
* @flags CREATE_AND_SET
* @default 0
*/
SAI_PORT_ATTR_LINK_DOWN_DEBOUNCE_TIMEOUT,

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the DOWN DEBOUNCE mechanism only delays the NOS-level notification, upper-layer applications and protocols may continue to assume the port is operationally UP, but packets could start experiencing drops in the data path.
This introduces a challenge from the application perspective - the port remains up, but traffic loss is occurring. In such scenarios, is there any explicit drop reason, error indication, debug counters or any new operational state visibility exposed to help applications distinguish this condition ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked various implementation documentation across vendors and looks like there debug counters maintain for link flaps. If there is a link flap observed NOS knows that there is a traffic loss during debounce.

I will introduce debug counters for link flags during debounce.


/**
* @brief End of attributes
*/
Expand Down
10 changes: 10 additions & 0 deletions inc/saiswitch.h
Original file line number Diff line number Diff line change
Expand Up @@ -3652,6 +3652,16 @@ typedef enum _sai_switch_attr_t
*/
SAI_SWITCH_ATTR_TAM_EVENT_LEARN_NOTIFY,

/** @brief Link down debounce time in microseconds
*
* 0 means no delay time so link down events are immediately delivered as usual
*
* @type sai_uint32_t
* @flags CREATE_AND_SET
* @default 0
*/
SAI_SWITCH_ATTR_LINK_DOWN_DEBOUNCE_TIMEOUT,

/**
* @brief End of attributes
*/
Expand Down
Loading