Feature Name

Deterministic Approach for Interface Link bring-up sequence on SFF compliant modules

High Level Design Document

Rev 0.1

Table of Contents

List of Tables

Revision

RevDateAuthorChange Description
0.107/12/2023Longyin HuangInitial version

About this Manual

This is a high-level design document describing the need to have determinstic approach on SFF compliant modules for Interface link bring-up sequence and workflows for use-cases around it

Parent HLD Interface-Link-bring-up-sequence.md focuses on generic high level background/idea and details for CMIS modules, while this HLD focuses on SFF modules with details.

Abbreviation

Table 1: Definitions

TermDefinition
pmonPlatform Monitoring Service
xcvrTransceiver
xcvrdTransceiver Daemon
gbsyncdGearbox (External PHY) docker container

References

Table 2 References

DocumentLocation
Deterministic Approach for Interface Link bring-up sequence for CMIS and SFF modulesInterface-Link-bring-up-sequence.md

Problem Definition

According to parent HLD, as already discussed with sonic-chassis workgroup and OCP community:

  1. Presently in SONiC, for SFF compliant modules (100G/40G), there is no synchronization between enabling Tx of optical module and enabling ASIC (NPU/PHY) Tx which may cause link instability during administrative interface enable “config interface startup Ethernet” configuration and bootup scenarios.

  2. During administrative interface disable “config interface shutdown Ethernet”, only the ASIC(NPU) Tx is disabled and not the optical module Tx/laser. This will lead to power wastage, un-necessary fan power consumption to keep the module temperature in operating range, and potential lab hazard when the port is shut off but the laser is still on.

Background

Refer to parent HLD

Objective

According to parent HLD, have a determistic approach for Interface link bring-up sequence for SFF compliant modules (100G/40G) i.e. below sequence to be followed:

  1. Initialize and enable NPU Tx and Rx path

  2. For system with 'External' PHY: Initialize and enable PHY Tx and Rx on both line and host sides; ensure host side link is up

  3. Then perform optics Tx enable

Plan

Plan is to follow this high-level work-flow sequence to accomplish the Objective:

  • Add a new thread SFF task manager (called sff_mgr) inside xcvrd to subscribe to existing field “host_tx_ready” in port table state-DB

  • “host_tx_ready” is set to true only when admin_status is up and setting admin_status to syncd/gbsyncd is successful. (As part of setting admin_status to syncd/gbsyncd successfully, the NPU/PHY Tx is enabled/disabled)

  • sff_mgr processes the “host_tx_ready” value change event and do optics Tx enable/disable using tx_disable API

Breakout Handling

Refer to parent HLD

Feature enablement

This feature (optics Interface Link bring-up sequence) would be enabled on per platform basis. There could be cases where vendor(s)/platform(s) may take time to shift from existing codebase to the model (work-flows) described in this document.

  • By default, sff_mgr feature is disabled.

  • In order to enable sff_mgr feature, the platform would set ‘enable_xcvrd_sff_mgr’ to ‘true’ in their respective pmon_daemon_control.json. Xcvrd would parse ‘enable_xcvrd_sff_mgr’ and if found 'true', it would launch SFF task manager (sff_mgr).

Pre-requisite

In addition to parent HLD's pre-requisite,

Pre-requisite for enabling sff_mgr:​ Platform needs to leave the transceiver (if capable of disabling Tx) in Tx disabled state when an module inserted or during boot-up. This is to make sure the transceiver is not transmitting with Tx enabled before host_tx_ready is True.

Proposed Work-Flows

  • Flow of pre-requisite for platform in insertion/bootup cases

  • Feature enablement flow -- how xcvrd spawns sff_mgr thread based on enable_sff_mgr flag

  • Flow of calculating target tx_disable value:

    • When tx_disable value/status is True, it means Tx is disabed

    • when tx_disable value/status is False, it means Tx is enabled

  • Main flow of sff_mgr, covering below cases:

    • system bootup

    • transceiver insertion

    • admin enable/disable configurations

Out of Scope

Refer to parent HLD