HW Port Profile ID

Summary

A per port SAI_PORT_ATTR_HW_PROFILE_ID allows applications ('host-adapters') to request the SAI implementation to set vendor specific in a 'transparent' manner.

To this purpose, the SAI implementation should define a vendor specific configuration file, which maps a "HW Port profile IDs" to a set of HW specific parameters. The name of the configuration file can be specified using the SAI_KEY_HW_PORT_PROFILE_ID_CONFIG_FILE (as a key/value pair, see saiswitch.h)

The contents of the configuration file is vendor and hardware specific, but it is assumed that it can map HW Port Profiles IDs to specific hardware parameters.

For readability, consider the following format : HWPortProfileID:ParameterName=Value,ParameterName=Value,...

For instance: 1: Pre-emphasis=valuePreEmphasis1,SerDesPolarity=valueSerDesPolarity1 2: Pre-emphasis=valuePreEmphasis2,SerDesPolarity=valueSerDesPolarity2 3: Pre-emphasis=valuePreEmphasis3,SerDesPolarity=valueSerDesPolarity3 ...

Other formats can be used (e.g. XML). The file format is not standardized by the SAI API; rather, it is considered a part of the implementation.

Theory of Operation

When the application (host adapter) sets the SAI_PORT_ATTR_HW_PROFILE_ID (say, SAI_PORT_ATTR_HW_PROFILE_ID=2), the SAI implementation uses the values corresponding to the HW Port Profile ID from the mapping table and sets the appropriate vendor specific register values. Typically, those values correspond to a specific transceiver type (SFP, QSPF). The advantage of this approach is that there is no need to specify transceiver types in the SAI API (and new port profile ID's can be added to the configuration file as new SFP's are supported).

Advantages:

• there is no need to inform the SAI explicitly what is the type of transceiver (only a generic port profile ID is provided) associated to a given port.
• given that the profile ID to NPU HW register mapping is contained in a configuration file, the SAI code does not need to be modified to add new transceiver types
• the information in the configuration file can be vendor specific, but this is transparent to the SAI API
• the SAI user application ('host-adapter') does not need to "hard-code" the mappings of transceiver types to "HW Port Profile IDs" either. These mappings can be provided as a separate configuration file as well (although this is outside the scope of the SAI API). It should be noted that the same HW port profile ID may correspond to multiple transceiver types.

For instance: QSFP_TypeA: 1 QSFP_TypeB: 1 SFP_TypeC: 2 SFP_TypeD: 2 ...

When a transceiver is plugged in into a port, the host adapter determines the SAI_PORT_ATTR_HW_PROFILE_ID value that corresponds to the transceiver, and calls the appropriate SAI API for the port.

As new transceiver types are supported, the host-adapter transceiver to HW Port Profile configuration file can be updated.

In summary:

• the SAI does not need to be aware of transceiver types
• the SAI API is NPU agnostic/independent, yet specific NPU registers can be supported (inside an NPU specific SAI implementation)
• both the 'host-adapter' and SAI implementation can be configuration/data driven (no hard-coded mappings)