CPO SW Control Vmodule Statistics platform changes

[Natgerbi]

Description

Motivation and Context

How Has This Been Tested?

Additional Information (Optional)

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

Hi, there are workflow run(s) waiting for approval, you may be first-time contributor. I will notify maintainers to help approve once PR is approved. Thanks!

_{---Powered by SONiC BuildBot}

[bgallagher-nexthop]

There seems to be some unrelated changes possibly in this PR (e.g cmis page changes, c-cmis changes), i assume these might be old changes

[bgallagher-nexthop]

There already exists an ElsfpApi. It does not contain some of the aggregate methods like get_transceiver_dom_real_value or have CDB support, but is designed to be easily extended to contain that type of functionality.

Could you extend that class so we have one ElsfpApi defined in the platform layer?

[bgallagher-nexthop]

I was initially thinking this approach is the best strategy for aggregating/combining OE and ELSFP data, but I think it might be simpler to just do that work in xcvrd code as opposed to the platform API layer.

The xcvr API lifecycle is complicated in this approach. The aggregate CpoApi and ELSFP API both need to be destroyed and re-built upon an ELSFP plug-in and plug-out event in order to ensure they are not stale. That means CpoBase needs its own xcvr lifecycle events with a correct implementation that destroys the ELSFP API and CpoApi in remove_xcvr_api and re-creates both in the refresh_xcvr_api functions.

Since we've already committed in xcvrd to directly use the new CPO API objects, I think we can just do the aggregation in xcvrd code.

CpoBase can provide the OE API to xcvrd by default -- this ensures backwards compatibility in CMIS state machine logic and other places:

class CpoBase(device_base.DeviceBase):
    def __init__(self, hardware_id: CpoHardwareInfo, oe: "OeBase", elsfp: "ElsfpBase"):
        self.hardware_id = hardware_id
        self.oe = oe
        self.elsfp = elsfp

    def refresh_xcvr_api(self):
        self.oe.refresh_api()
        self.elsfp.refresh_api()

    def get_xcvr_api(self):
        # We always default to the OE API for CPO. If the ELSFP API is required,
        # then that can be accessed via self.elsfp.get_api() directly.
        return self.oe.get_api()

    def remove_xcvr_api(self):
        self.oe.remove_api()
        self.elsfp.remove_api()

Then, in the CPO-specific areas of xcvrd, we can just directly interact with the OE and ELSFP APIs (and perform aggregation optionally if needed):

    def post_cpo_port_dom_sensor_info_to_db(self, logical_port_name, db_cache=None):
        asic_index = self.port_mapping.get_asic_id_for_logical_port(logical_port_name)
        if asic_index is None:
            self.logger.log_error(f"CPO: Post port dom sensor info to db failed for {logical_port_name} "
                                  "as no asic index found")
            return

        oe_result = self.post_diagnostic_values_to_db(logical_port_name,
                                                 self.xcvr_table_helper.get_dom_tbl(asic_index),
                                                 self.cpo_dom_utils.get_oe_transceiver_dom_sensor_real_value,
                                                 db_cache=db_cache,
                                                 beautify_func=self._beautify_dom_info_dict)
        elsfp_result = self.post_diagnostic_values_to_db(logical_port_name,
                                                 self.xcvr_table_helper.get_dom_tbl(asic_index),
                                                 self.cpo_dom_utils.get_elsfp_transceiver_dom_sensor_real_value,
                                                 db_cache=db_cache,
                                                 beautify_func=self._beautify_dom_info_dict)
        return oe_result and elsfp_result

This also eliminates the problem of merging the results and having to care about key collisions and such.

[bgallagher-nexthop]

This would probably be better housed in some elsfp specific file, since it is not necessarily related to the regular CmisApi

[bgallagher-nexthop]

There exists an ELSFP-specific codes class that already contains these: https://github.com/sonic-net/sonic-platform-common/blob/master/sonic_platform_base/sonic_xcvr/codes/public/elsfp.py