[daiwei1983]

Problem
Comparing port state before and after warmboot misses a transient UP→DOWN→UP transition. While the network operating system (NOS) and its adapter are detached, software may not receive or process link-state notifications. Some hardware or adapter implementations can retain an indication that a port changed state, but SAI does not provide a standard attribute for reading the current operational state together with this latched change indication.

Solution
The existing sai_latch_status_t type can represent the port changed result. Add a read-only port attribute, SAI_PORT_ATTR_OPER_STATUS_LATCH with the sai_latch_status_t type in this pull request.

Example use case: FRR
In an Fast ReRoute (FRR) deployment, the primary-to-backup switchover is expected to complete within time SLA. In callback-driven designs, the NOS may use a link-down notification to program the SDK to initiate the switchover; once programmed, hardware performs the fast-path switch. During warmboot, which can last tens of seconds, the NOS may be unavailable to process that notification. For a port that was UP at the start of the interval, the proposed latch can indicate whether it went down at least once, flagging a potential missed FRR trigger. This Boolean indication does not count repeated flaps or prove that FRR failed or missed its target, but it helps assess FRR exposure during warmboot

NOS warmboot flow
FRR is just one example use case of port status latch. A more generic workflow to use latch data and tell whether link flaps across NOS warmboot is summarized below.

1. When saving warmboot state, read the attribute once per port and persist the returned status as the baseline. This read establishes the start of the measured interval.
2. After warmboot, read the attribute at the chosen checkpoint for the warmboot metric. Each read clears changed; the NOS may also read the attribute for telemetry or notifications and retain or aggregate returned changed indications as appropriate.
3. For each port, record a down transition when its saved current_status was UP and the changed indication for the measured interval is true. If the NOS reads the attribute between the baseline and checkpoint, it can aggregate changed across those reads.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[kcudnik]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).