Adjust select timeouts during port update handling to allow for faster transceiver DOM polling

[aditya-nexthop]

Description

This PR optimizes the DOM (Digital Optical Monitoring) polling loop in xcvrd by improving port update event handling and reducing unnecessary wait times. The changes include:

1. Refactored port update handling - Extracted port update event processing into a dedicated check_port_update() method for better code organization and reusability
2. Optimized timeout strategy - Introduced two-tier timeout mechanism:
   • 1000ms timeout when waiting for port updates before DOM polling begins and after when it completes until the next polling cycle
   • 100ms timeout during DOM polling to minimize delays while still handling port events
3. Improved loop structure - Restructured the main loop to handle port updates before entering the DOM polling phase, preventing unnecessary blocking
4. Added comprehensive unit tests - Created tests covering various scenarios including multiple ports, timing edge cases, and stop event handling

fixes #759 and builds on #757

Motivation and Context

Before the change, the DOM monitoring loop would wait up to 1 second (SELECT_TIMEOUT_MSECS) for port update events during each iteration of the physical port loop. This caused significant delays in DOM data collection, especially on systems with many ports.

Problem: With the 1-second timeout being called for every physical port, the DOM polling could take an excessive amount of time to complete, delaying DOM polling updates.

Solution: By separating port update handling from DOM polling and using a shorter 100ms timeout during the polling phase, the loop can complete much faster while still being responsive to port change events. The 1-second timeout is only used when explicitly waiting for port updates before starting the next DOM polling cycle.

How Has This Been Tested?

1. Unit Tests Added - Comprehensive test coverage for the new check_port_update() method including:

   • Scenario with no link change affected ports
   • Link change affected port with past timestamp (should trigger immediate update)
   • Link change affected port with future timestamp (should defer update)
   • Multiple ports with mixed ready/not-ready states
   • Stop event handling during processing

2. CPU usage profiling: Measured for 10 minutes after restarting xcvrd on a switch fully populated with optical transceivers.

• Before the change (includes changes from Set DOM polling interval based on the time at the start of the loop instead of the end #757)

- After the change

The CPU usage is slightly higher during active polling as it spends less time waiting (100ms) between interfaces and then the loop spends time waiting for port change updates in 1s chunks.

3. Measuring actual DOM update times

• Before change: We are not able to poll every 60 seconds (takes 90 sec+) on a switch fully populated with optical transceivers

$ while true; do sonic-db-dump -n STATE_DB -y -k "TRANSCEIVER_DOM_SENSOR|Ethernet112" | grep last_update_time; sleep 10; done | uniq
      "last_update_time": "Tue Feb 24 19:25:57 2026",
      "last_update_time": "Tue Feb 24 19:27:32 2026",
      "last_update_time": "Tue Feb 24 19:29:06 2026",
      "last_update_time": "Tue Feb 24 19:30:40 2026",
      "last_update_time": "Tue Feb 24 19:32:13 2026",
      "last_update_time": "Tue Feb 24 19:33:47 2026",

• After change: Updates happen every 60 seconds for a specified interface

$ while true; do sonic-db-dump -n STATE_DB -y -k "TRANSCEIVER_DOM_SENSOR|Ethernet112" | grep last_update_time; sleep 10; done | uniq
      "last_update_time": "Tue Feb 24 19:17:09 2026",
      "last_update_time": "Tue Feb 24 19:18:10 2026",
      "last_update_time": "Tue Feb 24 19:19:10 2026",
      "last_update_time": "Tue Feb 24 19:20:10 2026",
      "last_update_time": "Tue Feb 24 19:21:11 2026",
      "last_update_time": "Tue Feb 24 19:22:11 2026",

Additional Information (Optional)

Key Technical Changes:

• New constants: PORT_UPDATE_EVENT_SELECT_TIMEOUT_MSECS (1000ms) and PORT_UPDATE_EVENT_SELECT_TIMEOUT_FAST_MSECS (100ms)
• Modified PortChangeObserver.handle_port_update_event() to accept a configurable timeout parameter
• The periodic update interval calculation now uses dom_loop_start_time to maintain consistent intervals regardless of loop execution time

Backward Compatibility: This change is fully backward compatible and does not affect the external API or configuration.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This PR improves xcvrd DOM polling responsiveness by reducing time spent blocking on port-update events, so full-port DOM polling can complete closer to the intended periodic interval.

Changes:

• Add a configurable select timeout to PortChangeObserver.handle_port_update_event() so callers can use shorter waits during DOM polling.
• Refactor DOM loop port-update handling into a reusable check_port_update() helper and introduce a two-tier timeout strategy (slow/fast).
• Add unit tests for the new check_port_update() behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
sonic-xcvrd/xcvrd/xcvrd_utilities/port_event_helper.py	Makes port-update event selection timeout configurable (enables fast/slow modes).
sonic-xcvrd/xcvrd/dom/dom_mgr.py	Restructures the DOM update loop and introduces two timeout constants plus check_port_update().
sonic-xcvrd/tests/test_xcvrd.py	Adds unit coverage for DomInfoUpdateTask.check_port_update().

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mihirpat1]

fixes sonic-net/sonic-buildimage#22625

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).