Disable periodic polling of port in DomInfoUpdateTask thread during CMIS init

[mihirpat1]

Description

We currently need to disable periodic DOM polling of a port through DomInfoUpdateTask thread during CMIS initialization.

Motivation and Context

Disabling of DOM polling during CMIS initialization is primarily needed to disable sending CDB commands to read FW version from DomInfoUpdateTask thread during CMIS initialization.
For transceivers which do not support CDB background mode, any EEPROM access to the module can fail if a CDB command is executed at the same time.

In order to disable DOM polling during CMIS initialization, the cmis_state from CmisManagerTask thread is now being updated in the TRANSCEIVER_STATUS table of STATE_DB.
If the current cmis_state does not belong to CMIS_TERMINAL_STATES, DomInfoUpdateTask will disable DOM polling for the port to allow CmisManagerTask thread to complete CMIS initialization if required.
For platforms with CmisManagerTask disabled, the function is_port_in_cmis_initialization_process will always return False to allow DOM polling.
In case of device boot-up or transceiver insertion, the DomInfoUpdateTask thread will wait for the port to be in either of the CMIS_TERMINAL_STATES before proceeding with DOM polling. For non-CMIS transceivers, the expected cmis_state is CMIS_STATE_READY. Hence, once the corresponding port reaches CMIS_STATE_READY state, DOM polling will be enabled for such port.

Also, the cmis_state is not planned to be modified by DomInfoUpdateTask thread at any time to prevent race condition with CmisManagerTask.

How Has This Been Tested?

Following is the summary of tests performed

1 Ensure DOM thread polls for non-CMIS transceivers
2 Ensure DOM thread polls for platform with CMIS manager disabled
3 Ensure DOM thread waits during CMIS initialization
4 Ensure DOM polling is resumed after transceiver insertion
4.1 After removal
4.2 After insertion
5. Ensured `show interface transceiver status` CLI works with the current changes

Redis-db dump snippet to show `cmis_state` field in TRANSCEIVER_STATUS table
root@sonic:/home/admin# redis-cli -n 6 hgetall "TRANSCEIVER_STATUS|Ethernet0"
  1) "cmis_state"
  2) "READY"

Additional Information (Optional)

MSFT ADO - 26993372

[prgeor]

@keboliu @Junchao-Mellanox can you review this PR and see if it does not impact your paltform that skip's CMIS manager

[prgeor]

@mihirpat1 I am not sure if this is a must required because platform which skip cmis mgr will return CMIS_STATE_UNKNOWN which means is_port_in_cmis_initialization_process() will return False always (even though the fw could be initializing the CMIS module like in SN 2700)

[mihirpat1]

@prgeor The function is_port_in_cmis_initialization_process currently assumes that CMIS_STATE_UNKNOWN is a transient state and hence, returns True.
For platforms which have CMIS manager enabled, we assume that CMIS_STATE_UNKNOWN is the first state after starting CMIS state machine post xcvrd boot-up. Hence, the DomInfoUpdateTask thread holds off polling on the corresponding port to allow the port go through CMIS initialization if needed.

[mihirpat1]

/azpw run

[mssonicbld]

/AzurePipelines run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[prgeor]

@mihirpat1 do we need to take care of Xcvrd restart?

[mihirpat1]

We don't need to explicitly handle xcvrd restart case since the below code will set the cmis_state to CMIS_STATE_READY and prevent link flap if the module is already initialized.

sonic-platform-daemons/sonic-xcvrd/xcvrd/xcvrd.py

Line 1390 in d513eca

need_update = self.is_cmis_application_update_required(api, appl, host_lanes_mask)

Also, the current nightly behavior is to clear cmis_state after xcvrd restart. Hence, this should not cause additional change in behavior.