Gearbox ports have to be managed hierarchically from the Forwarding ASIC faceplate port index as per Gearbox HLD/design

[balanokia]

As per Gearbox design, gearbox ports have to be managed hierarchically from the Forwarding ASIC faceplate port index. setGearboxPortsAttr shall have to be managed/called internally by setPort* APIs when GB devices exist. #3529 has violated the design and introduced functional behavioral issue in handling FEC for Gearbox ports.

Severity: Critical

Component/subsystem impacted: orchagent gearsyncd PAI

Description:
When a port created with FEC or no FEC configuration for the interfaces, external PHY aka Gearbox has to follow as per the Forwarding ASIC to PHY lane configurations. FEC application has to follow a state machine between Forwarding ASIC MAC and PHY side and it needs to be triggered always from Forwarding ASIC in order to have a consistent configuration of PHY on System and Line side FEC configuration application.

Root Cause (Code):

1. [portsorch] add more attributes on port creation #3529 introduced the following code,
   if (pCfg.fec.is_set) { // do FEC application } else { setGearboxPortsAttr(p, SAI_PORT_ATTR_FEC_MODE, &pCfg.fec.value, pCfg.fec.override_fec); }
2. Its an error to handle gearbox ports in the else condition without handling admin-status properly for the forwarding MAC and PHY ports.
   The following else code from [portsorch] add more attributes on port creation #3529 have be removed.

Suggested Fix:
else { setGearboxPortsAttr(p, SAI_PORT_ATTR_FEC_MODE, &pCfg.fec.value, pCfg.fec.override_fec); }
How to avoid FEC related design error?

1. Fixes have to be validated using external PHYs (ex, BCM81356)
2. Complete OC must be run using any of topologies (T0, T1, T2) as these topologies tend to be deployed with very high-speed interfaces greater than 100G that would typically have complex lane configurations with atleast 50G PAM4 encoding of multiple serDes lane configurations