Added 'Port breakout workFlow with CMIS enabled' section #1290
Conversation
|
@jaganbal-a @mihirpat1 @Junchao-Mellanox @keboliu please review |
| ['port breakout feature workflow with CMIS'.pdf](https://github.com/shyam77git/SONiC/files/11022820/port.breakout.feature.workflow.with.CMIS.pdf) | ||
|
|
||
|
|
||
| - Configure a unique channel # for each broken-down (logical) port in platform's port_config.ini |
There was a problem hiding this comment.
we should use 'hwsku.json' or 'platform.json' instead of 'port_config.ini', these two JSON files and introduced for the port breakout feature, and technically it's much easier to parser a JSON format file than an 'ini' file.
And not sure this 'channel' number shall be provided explicitly from some configuration, can it be deduced by some logic? It's shouldn't be too complicated.
There was a problem hiding this comment.
we should use 'hwsku.json' or 'platform.json' instead of 'port_config.ini', these two JSON files and introduced for the port breakout feature, and technically it's much easier to parser a JSON format file than an 'ini' file.
For following reasons, 'port_config.ini was used instead of 'platform.json', 'hwsku.json' :
[1] As mentioned as start of this section, its specifically added to take CMIS workflow/FSM into account for port breakout feature, which has been a GAP so far.
[2] MSFT use-case (for SONiC on MSFT purposes) is looking at port breakout configuration from the mini-graph standpoint. This involves dynamically update the mini-graph xml file by updating the interested port info via port_config.ini – lanes, speed, channel info etc. and then parser would take care of updating the PORT table of the interested port.
[3] Also, per @prgeor input, uniquely identifying channel via a separate column in port_config.ini provides clarity and a uniform approach to fill and fetch this info from one place for the MSFT use-case above ([2]) to use it
[4] There is a 'Note' at the end of this section:
At present, this utilizes the static method to configure port breakouts (i.e. port_config.ini or mini-graph).
And not sure this 'channel' number shall be provided explicitly from some configuration, can it be deduced by some logic? It's shouldn't be too complicated.
[a] Refer to [3] above
[b] Please refer to following 'Enhancement' note at the end of this section:
Enhancement: In near future, this would be enhanced to configure and handle the breakout (on an interface) in a dynamic fashion i.e.via sonic's #config interface breakout CLI.
This would be the one leveraging 'platform.json' per DPB HLD where channel number would be inferred
shyam77git
changed the title
|
In code "channel" was already substituted with "subport". Could you please update the HLD as well to have unified terminology ? |
Yes, per the discussion in the changeset PR, I'd update 'channel' terminology in this HLD to refer them as 'subport' |
|
|
||
|  | ||
|
|
||
| ['port breakout feature workflow with CMIS'.pdf](https://github.com/shyam77git/SONiC/files/11130409/port.breakout.feature.workflow.with.CMIS.pdf) |
There was a problem hiding this comment.
This link points to your personal github link shyam77git. Can we get a public link which is in the sonic repo?
Added a new section 'Port breakout workFlow modifications'
With CMIS enabled in xcvrd to handle QSFP-DD modules, this version adds the new design/workflow to 'port breakout' handling.
Addressed Review comments to this HLD section
Addressed the HLD (md) PR review comments for 'Port breakout Workflow updates considering CMIS' section
Addressed the HLD PR review comments from other reviewers (received later), to 'Port breakout Workflow updates considering CMIS' section
| A NxS breakout cable inserted implies following | ||
| - A physical port is broken down into N subports (logical ports) | ||
| - subports are numbered as 8/N i.e. | ||
| - For 4x100G breakout optical module inserted in physcial Ethernet port 1 (etp1), implies: Ethernet8, Ethernet10, Ethernet12, Ethernet14 |
| - subport# sequence may repeat for logical ports under another physcial port | ||
| - subport# as 0 (on a port) implies physical port itself (i.e. no port breakout on it) | ||
| - These subport#s are then parsed and updated in PORT_TABLE of CONFIG redisDB | ||
| - There would be a unique PORT_TABLE for each logical port |
There was a problem hiding this comment.
meant "unique entry for each logical port in PORT_TABLE" ?
| - xcvrd to determine Active Lanes (per subport) from the App Advertisement Table of CMIS Spec. | ||
| - xcvrd to read 'speed', 'subport' and lanes information (of a logical/sub-port) from the PORT_TABLE of CONFIG DB to perform look-up in appl_dict | ||
| - xcvrd to check Table 6.1 (of CMIS v5.2) to find the desired application (for the inserted optical module) via get_cmis_application_desired() subroutine | ||
| - get_application_advertisement() in xcvrd codebase (cmis.py), which eventually formualtes appl_dict |
Added the following new section to port breakout HLD https://github.com/sonic-net/SONiC/blob/master/doc/dynamic-port-breakout/sonic-dynamic-port-breakout-HLD.md
'Port breakout workFlow updates considering CMIS'
xcvrd (transceiver daemon) running as part of PMON docker container, runs CMIS FSM for QSFP-DD transceivers.
This section describes the design and depicts workflows for port breakout feature to work with CMIS enabled.
Repo PR Title State
sonic-platform-daemons breakout feature support with CMIS enabled Under review
sonic-platform-common Update get_host_lane_assignment_option based on application id Merged