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 opx-platform-config repository:

• 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 VENDOR_NAME/PLATFORM_NAME-hw (dell/s6000-hw).

• Directory for the hardware device-independent configuration files (NAS, PAS, temperature control), such as dell/s6000/etc/opx. The directory name follows the convention VENDOR_NAME/PLATFORM_NAME/etc/opx.

Platform scripts

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 opx-platform-init.service).

Platform shutdown script

See 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.h file 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)

See 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

See dell/s6000/etc/opx for an NAS configuration example.

NAS configuration files

Configuration file	Description
base_port_physical_mapping_table.xml	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.
base_qos_init.xml	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_alloc.xml	MAC address allocation scheme for the Management interface and front panel ports (assuming a unique system MAC address is used as the base value)
phy_media_default_npu_setting.xml	Transceivers supported including optical media
switch.xml	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

See config.xml for a PAS configuration file example.

Temperature control

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.

See env-tmpctl for a TC configuration file example.