Port Breakout High Level Design

Port Breakout in SONiC

High Level Design Document

Rev 0.1

Table of Contents

• List of Tables

• Revision

• About this Manual

• Scope

• Definitions/Abbreviation

• 1 Sub-system Overview

  • 1.1 System Chart
  • 1.2 Modules description
    • 1.2.1 swssconfig
    • 1.2.2 App DB
    • 1.2.3 Orchestration Agent
    • 1.2.4 SAI Redis
    • 1.2.5 SAI DB
    • 1.2.6 syncd
    • 1.2.7 SAI (Redis and Switch)

• 2 Subsystem Requirements Overview

  • 2.1 Functional requirements

• 3 Modules Design

  • 3.1 Modules that needs to be updated
    • 3.1.1 Swssconfig
    • 3.1.2 App DB
    • 3.1.3 SWSS
      • 3.1.3.1 Port SyncD
        • 3.1.3.1.1 Example of port_config.ini
        • 3.1.3.1.2 Example of port_config.ini
      • 3.1.3.2 Orchestration Agent
    • 3.1.4 SAI Redis
    • 3.1.5 SAI DB
    • 3.1.6 Syncd
    • 3.1.7 SAI

• 4 Flows

  • 4.1 Port breakout

• 5 Open Questions

List of Tables

• Table 1: Revision
• Table 2: Abbreviations

Revision

Rev	Date	Author	Change Description
0.1		Volodymyr Samotiy	Initial version

About this Manual

This document provides general information about the Port Breakout feature implementation in SONiC.

Scope

This document describes the high level design of the Port Breakout feature.

Definitions/Abbreviation

Table 2: Abbreviations

Definitions/Abbreviation	Description
API	Application Programmable Interface
SAI	Swich Abstraction Interface
JSON	JavaScript Object Notation

1 Sub-system Overview

1.1 System Chart

Following diagram describes a top level overview of the SONiC Switch components:

1.2 Modules description

1.2.1 swssconfig

Reads prepared json-files with configuration and injects it into App DB.

1.2.2 App DB

Located in the Redis DB instance #0 running inside the container "database". Redis DB works with the data in format of key-value tuples, needs no predefined schema and can hold various types of data.

1.2.3 Orchestration Agent

This component is running in the "orchagent" docker container and is resdponsible for processing updates of the App DB and do corresponding changes in the SAI DB via SAI Redis.

1.2.4 SAI Redis

SAI Redis is an implementation of the SAI API which translates API calls into SAI objects which are stored in the SAI DB.

1.2.5 SAI DB

Redis DB instance #1. Holds serialized SAI objects.

1.2.6 syncd

Reads SAI DB data (SAI objects) and performs appropriate calls to Switch SAI.

1.2.7 SAI (Redis and Switch)

An unified API which represent the switch state as a set of objects. In SONiC represented in two implementations - SAI DB frontend and ASIC SDK wrapper.

2 Subsystem Requirements Overview

2.1 Functional requirements

Detailed description of the Port Breakout feature is here: Port Breakout and Speed.

Requirements are listed below.

• User needs to provide port_config.ini for different port breakout mode.
• Use the speed attribute in the minigraph to specify the speed of a port.
• Assume that the user needs to restart the SWSS when he needs to change the port breakout mode.
• Use create_port() and remove_port() SAI APIs, so SAI >= v1.0 is required.

3 Modules Design

3.1 Modules that needs to be updated

3.1.1 Swssconfig

No update is needed to support Port Breakout.

3.1.2 App DB

No update is needed to support Port Breakout.

3.1.3 SWSS

3.1.3.1 Port SyncD

No update is needed to support Port Breakout.

Current implementation parses port_config.ini file and creates new record in AppDB port table with the port_alias and hw_lanes info, which is enough to support port breakout.

3.1.3.1.1 Example of port_config.ini

# name          lanes
Ethernet0       0,1,2,3
Ethernet4       4,5,6,7
Ethernet8       8,9,10,11
Ethernet12      12,13,14,15
...

3.1.3.1.2 Example of port_config.ini with port breakout

# name          lanes
Ethernet0       0,1
Ethernet1       2,3
Ethernet4       4,5
Ethernet5       6
Ethernet6       7
Ethernet8       8
Ethernet9       9
Ethernet10      10
Ethernet11      11
Ethernet12      12,13,14,15
...

3.1.3.2 Orchestration Agent

PortsOrch receives notification from App DB when new port is added with the following info: (port_alias, hw_lanes). In Orchestration Agent in class PortsOrch the following logic should be implemented to handle port breakout:

• Check whether received port_alias or hw_lanes are already used.
• If port_alias and hw_lanes are already present then do nothing.
• If port_alias and hw_lanes are used, but with different mapping, then remove found port and create new port with the new hw_lanes.
• Else, just create port with the specified port_alias and hw_lanes.

Port speed SAI attribute is mandatory on port creation, so when create new port, minimal supported speed should be set as default. Default speed will be updated with the value retrieved from "Speed" attribute in minigraph.

3.1.4 SAI Redis

No update is needed to support Port Breakout.

Listed below SAI APIs should be used to create and delete ports.

• create_port()
• remove_port()

3.1.5 SAI DB

No update is needed to support Port Breakout.

3.1.6 Syncd

No changes required to support Port Breakout.

3.1.7 SAI

No changes required to support Port Breakout.

4 Flows

4.1 Port breakout

5 Open Questions

1. Port speed SAI attribute is mandatory on port creation, so what speed should be set by default, minimal supported?
2. Do we want to have different speeds on the split ports?
3. Minigraph generation procedure sets the same speed for all ports, how to handle in case of split ports?