SFP Management

SFP OIDs

Each SFP OID represents a small form factor pluggable module. When an SFP OID is present then a module is plugged in. When an SFP OID is absent then the port is empty.

SFP Information Structure

Information about the current module is queried using onlp_sfp_info_get to populate the onlp_sfp_info_t structure.

There are several useful fields in this structure:

SFP APIs

While calling onlp_sfp_info_get is sufficient to identify the inserted module there are several operational APIs provided to manage it.

SFP Bitmaps

SFPs can be numerous and processing their state changes on an individual level is unlikely to be performant for your NOS. As far as the hardware is concerned the state of each module’s presence and IO signals are usually communicated as aggregated bitfields in a few registers. This makes collecting information about multiple SFPs at the same time better than collecting them individually.

The onlp_sfp_bitmap_t is a bitmap indexed by SFP OID (typically the actual port number) whose value represents the value of a a given SFP state for that port. APIs are provided to return a bitmap for states which are typically asyncronous:

It would be possible to aggregate other SFP signals (for example, RESET_STATE, LP_MODE) but these are inputs, not outputs, and thus are controlled explicitly by your software.

Aggregating TX_FAULT might still be a useful but no bitmap API is currently specified for it.

SFP Documentation


Return to APIs