Support OTN alarm event notification (excluding SAI submodule update) - #1
Support OTN alarm event notification (excluding SAI submodule update)#1jjin62 wants to merge 6 commits into
Conversation
…et#1457) (sonic-net#1534) What I did Optimize the counter-polling performance in terms of polling interval accuracy Enable bulk counter-polling to run at a smaller chunk size There is one counter-polling thread for each counter group. All such threads can compete for the critical sections at the vendor SAI level, which means a counter-polling thread can wait for a critical section if another thread has been in it, which introduces latency for the waiting counter group. An example is the competition between the PFC watchdog and the port counter groups. The port counter group contains many counters and is polled in a bulk mode which takes a relatively longer time. The PFC watchdog counter group contains only a few counters but is polled at a short interval. Sometimes, PFC watchdog counters need to wait before polling, which makes the polling interval inaccurate and prevents the PFC storm from being detected in time. To resolve this issue, we can reduce the chunk size of the port counter group. The port counter group polls the counters of all ports in a single bulk operation by default. By using a smaller chunk size, it polls the counters in several bulk operations with each polling counter of a subset (whose size <= chunk size) of all ports. By doing so, the port counter group stays in the critical section for a shorter time and the PFC watchdog is more likely to be scheduled to poll counters and detect the PFC storm in time. Collect the time stamp immediately after vendor SAI API returns. Currently, many counter groups require a Lua plugin to execute based on polling interval, to calculate rates, detect certain events, etc. Eg. For PFC watchdog counter group to PFC storm. In this case, the polling interval is calculated based on the difference of time stamps between the current and last poll to avoid deviation due to scheduling latency. However, the timestamp is collected in the Lua plugin which is several steps after the SAI API returns and is executed in a different context (redis-server). Both introduce even larger deviations. To overcome this, we collect the timestamp immediately after the SAI API returns.
…onic-net#1457) …" (sonic-net#1570) Revert "Optimize counter polling interval by making it more accurate
…c_validation_create (sonic-net#1663) 1. SAI_HOSTIF_NAME_SIZE only applies to SAI_HOSTIF_ATTR_NAME 2. SAI_HOSTIF_GENETLINK_MCGRP_NAME_SIZE applies to SAI_HOSTIF_ATTR_GENETLINK_MCGRP_NAME 3. Others apply to chardata size. Signed-off-by: oplklum <lu.mao@molex.com>
1. Support OTN SAI interface 2. Support OTN flex counter 3. Update SAI submodule to 202411_otn branch Signed-off-by: oplklum <lu.mao@molex.com>
Made-with: Cursor
28fd8b3 to
10355ac
Compare
|
@jjin62 I'd suggest removing the alarm notification changes from this PR and handling alarms in a follow-up PR, since the merged SAI PR doesn't include alarm notifications yet. Also, can we keep the changes to syncd minimal? Do we really need to introduce new files like sai_serialize_otn.cpp and syncd/FlexCounterOtn.cpp? In SWSS, let's keep VOA and OA orchagent in one PR, and handling alarms and the other optical components in a follow-up PR. Any thoughts? We can discus the strategy in the next group meeting. |
|
this PR is not merged yet. I agree that our next PRs for SWSS and Syncd should only support OA and VOA to match The SAI PR merged. I will prepare the PRs. In terms of document, I think we can just refer to the SAI doc: https://github.com/opencomputeproject/SAI/blob/master/doc/OTN/sai_otn_proposal.md. There are sections for SWSS and Syncd. Please create otn_pr branch for sonic-swss-common, sonic-swss and sonic-sairedis. Having dedicated branches to avoid conflict to our internal development. |
|
The otn_pr branches based on the master source for swss, swss-common, and sairedis have been created. |
|
will submit later |
5 participants
This PR introduces support for OTN (Optical Transport Network) alarm event notifications within sonic-sairedis.
The changes enable the infrastructure to serialize, deserialize, and propagate OTN-specific alarm data (such as severity, action, and timestamps) through the Redis pipeline. This is a critical component for monitoring optical hardware states (e.g., LOS on Optical Amplifiers) in SONiC-OTN deployments.
This work is associated with sonic-buildimage issue #18.
Dependencies
SAI PR: This logic depends on the OTN experimental header definitions introduced in sonic-otn/SAI PR #5.
Key Changes
Metadata Support: Added meta_sai_on_otn_alarm_event and meta_sai_on_otn_alarm_event_single to meta/Meta.cpp to handle object reference tracking for OTN device types.
Serialization: Implemented JSON-based serialization and deserialization for sai_otn_alarm_event_data_t in meta/sai_serialize_otn.cpp.
Notification Handling: Created the NotificationOtnAlarmEvent class to manage the lifecycle of OTN notifications from syncd to the metadata services.
Component Integration: Updated syncd, proxylib, and saiplayer to recognize and forward the new SAI_SWITCH_NOTIFICATION_NAME_OTN_ALARM_EVENT.
Unit Testing: Added a comprehensive test suite in unittest/meta/TestNotificationOtnAlarmEvent.cpp to verify correct notification parsing.
Note on Submodule Changes
This commit intentionally excludes updates to the SAI submodule. To build this PR successfully, the local SAI directory must be manually updated to include the changes from SAI PR #5. This approach allows the code logic to be reviewed and merged without prematurely locking the global submodule pointer.