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
Rev | Date | Author | Change Description |
---|---|---|---|
0.1 | 07/12/2023 | Longyin Huang | Initial 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
Term | Definition |
---|---|
pmon | Platform Monitoring Service |
xcvr | Transceiver |
xcvrd | Transceiver Daemon |
gbsyncd | Gearbox (External PHY) docker container |
References
Table 2 References
Document | Location |
---|---|
Deterministic Approach for Interface Link bring-up sequence for CMIS and SFF modules | Interface-Link-bring-up-sequence.md |
Problem Definition
According to parent HLD, as already discussed with sonic-chassis workgroup and OCP community:
-
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.
-
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:
-
Initialize and enable NPU Tx and Rx path
-
For system with 'External' PHY: Initialize and enable PHY Tx and Rx on both line and host sides; ensure host side link is up
-
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
isTrue
, it means Tx is disabed -
when
tx_disable value/status
isFalse
, 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