Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
OPX Porting Guide
Preliminary contents and work-in-progress
OPX code is developed to be portable to various hardware platforms. Except for the SAI and SDI components, only a very small amount of code is platform-specific — most platform-specific capabilities are defined in configuration files located at system initialization time.
The switch abstraction interface (SAI) and system device interface (SDI) components contain network processing unit (NPU) and system device-specific components. The SAI and SDI implementations are device and/or platform specific.
The code for network adaptation services (NAS) and the platform adaptation service (PAS) components are hardware-independent. Porting the NAS and PAS components to a new platform involves creating new configuration and initialization script files for that specific platform.
The configuration for the temperature control (TC) component (architecturally) is in the software layer above the PAS — it also needs to be adapted to the thermal characteristics of new platforms. Some platform may not require a temperature control component — in the case that an external micro-controller performs the cooling algorithm.
All platform configuration files are stored in
opx-platform-config. For each new platform, you must create two directories in the
Directory for the hardware device-dependent configuration files (mainly SAI, SDI, system startup and shutdown), such as
dell/s6000-hw. The directory name follows the convention
Directory for the hardware device-independent configuration files (NAS, PAS, temperature control), such as
dell/s6000/etc/opx. The directory name follows the convention
These scripts are called at platform initialization time and shutdown. The scripts can be adapted for new platforms and are optional depending on how developers decide to initialize or shutdown a given hardware platform.
Platform initialization script
The platform initialization script is executed once at startup — it must be included in the
systemd startup configuration. It can perform various tasks, such as CPLD initialization or SMBus controller initialization (depending on the platform). See
opx_platform_init.sh for a platform initialization script example. Add the platform initialization script to the
systemd platform initialization service (such as
Platform shutdown script
opx_platform_shutdown.sh for a platform shutdown script example.
SDI component portability information
Porting the SDI component to a new hardware platform requires:
- Implementing low-level device drivers for the new platform — these drivers must implement the SDI API.
- Creating SDI configuration files for the new platform, as needed — depends on the SDI implementation.
The SDI API defines:
- Entities — represent physical entities that can be replaced or represented as a single unit – power supply units (PSUs), fan trays, system board
- Resources — represent hardware devices that an entity aggregates
Note. Entities and resources are defined in the
sdi_entity.hfile SDI API
Examples of SDI implementations are:
- Mellanox SDI
- SDI-VM used for the OPX simulator
- Dell EMC SDI Implementation — made of three cooperating sub-components: SDI-Sys, SDI-Framework, SDI-Drivers
NPU porting information
OPX currently uses SAI API 0.9.4.
SAI portability — using a compatible Broadcom NPU
A Broadcom-compatible SAI binary (SAI API 0.9.4 compatible) is available in binary form. Its current version supports Trident-II, Maverick, and Tomahawk Broadcom chipsets.
You need to create an SAI initialization file (
init.xml) which is required by the OPX SAI BCM implementation. This file contains parameter definitions including:
- Port LED information
- Logical port description
- Number of lanes per port (correspond to logical ports in breakout modes)
- NPU traffic scheduler configuration
- Number of physical and logical ports for the NPU (logical ports corresponding to breakout modes)
init.xml for a SAI initialization file example.
Using a new NPU
You have these options when porting to a new NPU:
- Obtain or implement a SAI implementation compatible with the current API version (0.9.4) for the particular NPU (alternatively, SAI API 0.9.6 and SAI API 1.0 will be supported in the future)
- Develop a separate implementation of the NDI API (part of the NAS) to adapt a SAI implementation not compatible with the current SAI API version
NAS porting information
dell/s6000/etc/opx for an
NAS configuration example.
NAS configuration files
||Mapping of NPU ports to device front panel ports, and various characteristics of each front panel port including breakout mode, speed, default Linux interface name, HW NPU ports and so on. The mapping from front panel port to hardware ports is based on the hardware layout and front panel ports connectivity to the NPU's ports.|
||Quality of service (QoS) parameters for the platform including traffic class to queue mapping, QoS/TC scheduler configuration, WRR profiles, and so on|
||MAC address allocation scheme for the Management interface and front panel ports (assuming a unique system MAC address is used as the base value)|
||Transceivers supported including optical media|
||Switch (NPU) configuration — file defines default switch configuration such as L2 , L3 and ARP table size based on NPU's capability|
Platform supported statistics/counters configuration
NPU supported counters for a specific platform are defined in the
nas_ndi_plat_stat.c file. Per platform functions defined in this file return the list of counters supported including VLAN interfaces and physical interfaces/ports.
PAS porting information
Create a per-platform
config.xml file for each PAS configuration file. The PAS configuration file defines:
- PAS objects to register with the CPS framework
- LED groups
- Polling intervals
- Types of transceivers supported for a given platform
config.xml for a PAS configuration file example.
The TC configuration file is located in the
config.json file. The file contents are specific to a given platform — create a new file and modify the contents to the target platform.
1. Define the speed values (in RPMs) for the fans in the Fan Tray units, and fans in the PSUs (if any) at various system levels for both normal and reverse airflows.
Normal refers to blowing air from the exterior towards the switch hardware, and reverse airflow refers to drawing hot air from the system and exhausting it towards the exterior. A system level defines the type of airflow and fan speeds for the various system fans.
2. Define the temperature thresholds of the various sensors in the system which trigger the activation of a given system level.
env-tmpctl for a TC configuration file example.