Add support for LPO in media_settings_parser

[longhuan-cisco]

dependency: sonic-net/sonic-platform-common#599

Description

LPO (Linear Pluggable Optics) is a new type of optical module without DSP, in which case the role of DSP (retiming/etc) is offloaded to host/NPU side, which generally might require different NPU SI settings to achieve good signal quality compared to today's DSP-based optics.

1. Today's medium_lane_speed_key in media_settings.json only supports two media_types OPTICAL and COPPER, additionally LPO as (extended) media_type is needed.
2. To achieve backward compatibility on platforms which don't want to distinguish between DSP-based optics and LPO, have optional flag ENABLE_EXTENDED_MEDIA_TYPE_MATCHING in media_settings.json: only distinguish between DSP-based optics and LPO in the case of this flag being set.
3. This infra is extensible: in the future, new media_types (in addition to OPTICAL, COPPER, OPTICAL_LPO) can be easily added and enabled optionally in ENABLE_EXTENDED_MEDIA_TYPE_MATCHING.

Example media_settings.json:

{
    "ENABLE_EXTENDED_MEDIA_TYPE_MATCHING": [
        “OPTICAL_LPO”
    ],
    "GLOBAL_MEDIA_SETTINGS": {
        "0-15,48-63": {
            “OPTICAL100": {
...
            “OPTICAL_LPO100": {
...
            "COPPER100": {
...

Motivation and Context

How Has This Been Tested?

Additional Information (Optional)

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[prgeor]

@longhuan-cisco How about the TRO vs LPO?

[prgeor]

@bobby-nexthop can you review?

[prgeor]

@longhuan-cisco I don' t think "ENABLE_EXTENDED_MEDIA_TYPE_MATCHING" is necessary

[longhuan-cisco]

@longhuan-cisco I don' t think "ENABLE_EXTENDED_MEDIA_TYPE_MATCHING" is necessary

The reason of adding this ENABLE_EXTENDED_MEDIA_TYPE_MATCHING is to provide backward compatibility on platforms which don't (or hasn't) distinguish between DSP-based optics and LPO. Without this, the behavior will change when matching today's media_settings.json which contains OPTICALXX keys but doesn't have LPOXX keys.

e.g, Arista today already has a few media_settings.json files using medium_lane_speed_key
https://github.com/sonic-net/sonic-buildimage/blob/master/device/arista/x86_64-arista_7280dr3a_36/media_settings.json
Let's take this file as example, and assuming we have LPO DR optics inserted on port 1 with lane_speed 50G:

• The behavior of today's code: this port's medium_lane_speed_key will be OPTICAL50, which ends up matching these SI settings in the media_settings.json
• The behavior after adding LPO media_type but without the protection of is_extended_media_type_enabled(LPO): this port's medium_lane_speed_key will be LPO50, which ends up not matching any SI settings in media_settings.json

https://github.com/longhuan-cisco/sonic-platform-daemons/blob/6f19de4f8434c2180756f34d2e40268649ccb486/sonic-xcvrd/xcvrd/xcvrd_utilities/media_settings_parser.py#L108-L125

def get_media_type(physical_port):
    """
    Get the media type of the transceiver


    Args:
        physical_port: physical port number


    Returns:
        'COPPER', 'OPTICAL' or extended media types included in
        ENABLE_EXTENDED_MEDIA_TYPE_MATCHING of media_settings.json
    """
    if get_is_copper(physical_port):
        return MEDIA_COPPER


    # For optical transceivers:
    if is_extended_media_type_enabled(EXTENDED_MEDIA_OPTICAL_LPO) and get_is_lpo(physical_port):
        return EXTENDED_MEDIA_OPTICAL_LPO
    return MEDIA_OPTICAL

[longhuan-cisco]

@longhuan-cisco How about the TRO vs LPO?

I'm not sure if we need to support TRO at this point. Haven't heard of immediate requirement. And I could't find related info on sff8024 spec, even LPO related codes were just recently introduced/finalized on sff8024, not sure if there's a way to differentiate TRO from other optics based on standard codes.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[bobby-nexthop]

One way I can think of to not remove the need ENABLE_EXTENDED_MEDIA_TYPE_MATCHING and keep backwards compatibility is to use a fallback instead:

if get_is_lpo(physical_port):
    return MEDIA_LPO
return MEDIA_OPTICAL

Then add some form of fallback logic when looking up settings:

def get_media_settings_value(port_config, medium_lane_speed_key):
    # Try exact match first
    if medium_lane_speed_key in port_config:
        return port_config[medium_lane_speed_key]
    
    # If LPO key not found, automatically fallback to OPTICAL and log
    

@prgeor @longhuan-cisco any thoughts ?