[sfpshow/sfputil] Enhance sfpshow and sfputil to behavior correctly on RJ45 ports

[keboliu]

What I did

For RJ45 port, sfpshow and sfputil need to be enhanced to behavior correctly:

1. "show interface transceiver eeprom" and "sfputil show eeprom" will return "SFP EEPROM is not applicable for RJ45 port"

admin@sonic:~$ show interface transceiver eeprom Ethernet0
Ethernet0: SFP EEPROM is not applicable for RJ45 port

admin@sonic:~$ sudo sfputil show eeprom -p Ethernet0
Ethernet0: SFP EEPROM is not applicable for RJ45 port

2. "show interface transceiver error-status" will return with 'N/A'

admin@sonic:~$ show interface transceiver error-status Ethernet0
Port       Error Status
---------  --------------
Ethernet0  N/A

3. "show interface transceiver lpmode" and "sfputil show lpmode" will return with 'N/A'

admin@sonic:~$ show interface transceiver lpmode Ethernet0
Port       Low-power Mode
---------  ----------------
Ethernet0  N/A

admin@sonic:~$ sudo sfputil show lpmode -p Ethernet0
Port       Low-power Mode
---------  ----------------
Ethernet0  N/A

4. "sfputil lpmode set" will be rejected with error msg "{Disabling|Enabling} low-power mode is not applicable for RJ45 port Ethernet{x}"

admin@sonic:~$ sudo sfputil lpmode on Ethernet0
Enabling low-power mode is not applicable for RJ45 port Ethernet0.
admin@sonic:~$ sudo sfputil lpmode off Ethernet0
Disabling low-power mode is not applicable for RJ45 port Ethernet0.

5. "sfputil reset" will be rejected with error msg: "Reset is not applicable for RJ45 port Ethernet{x}"

admin@sonic:~$ sudo sfputil reset Ethernet0
Reset is not applicable for RJ45 port Ethernet0.

How I did it

check the port type, if it's RJ45 ports then handle it seperately.

How to verify it

run above command on platform with RJ45 ports

Previous command output (if the output of a command-line utility has changed)

New command output (if the output of a command-line utility has changed)

[lgtm-com]

This pull request introduces 1 alert when merging cc540ed into 61b1396 - view on LGTM.com

new alerts:

• 1 for Unused named argument in formatting call

[stephenxs]

The building errors are caused by dependent mock dbs in #2110 has not yet been merged.

[keboliu]

/azpw run

[mssonicbld]

/AzurePipelines run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[stephenxs]

platform API will detect whether RJ45 port is present or not, and push the result into TRANSCEIVER_STATUS table.

[stephenxs]

According to the current logic, an SFP's info will be removed from TRANSCEIVER_INFO table once the port is absent (unplugged). In that case, we will lost the "type" information of the port.

[stephenxs]

@prgeor
The solution is like this:

1. when the system starts, platform API reports present for all RJ45 ports
2. Xcvrd works as usual, fetch all the info for all the RJ45 ports and push them into TRANSCEIVER_INFO table
3. In case RJ45 ports enter not present state, an error status will be reported by platform API. This is not an error that blocks reading eeprom. So xcvrd will not remove port from TRANSCEIVER_INFO table
4. Platform API will never report remove to xcvrd, meaning RJ45 ports will never be removed from transceiver info
5. Cli needs to be updated, for RJ45 ports, if there is an error in TRANSCEIVER_STATUS table, it should display not present or unknown. Same as other apps that will represent the status

By doing so,

• Only CLI needs to be updated. xcvrd will not be touched.
• No new table is required
• It's possible to support unknown status for RJ45 ports

[liat-grozovik]

@prgeor any additional points to discuss in order to signoff this PR?

[stephenxs]

@prgeor For now, we will follow the current solution to fetch the port type of RJ45 - reading it from TRANSCEIVER_INFO table.
Can you check and approve it?

[stephenxs]

@prgeor The solution is like this:

1. when the system starts, platform API reports present for all RJ45 ports
2. Xcvrd works as usual, fetch all the info for all the RJ45 ports and push them into TRANSCEIVER_INFO table
3. In case RJ45 ports enter not present state, an error status will be reported by platform API. This is not an error that blocks reading eeprom. So xcvrd will not remove port from TRANSCEIVER_INFO table
4. Platform API will never report remove to xcvrd, meaning RJ45 ports will never be removed from transceiver info
5. Cli needs to be updated, for RJ45 ports, if there is an error in TRANSCEIVER_STATUS table, it should display not present or unknown. Same as other apps that will represent the status

By doing so,

• Only CLI needs to be updated. xcvrd will not be touched.
• No new table is required
• It's possible to support unknown status for RJ45 ports

This is not available anymore. it's the previous impelmetnation.

[prgeor]

@keboliu can put comments in the code why we need two different functions for getting the port type? Also when should one use each of them?

[keboliu]

@prgeor please check the latest commits for the comments on the usage of the functions.

[prgeor]

@keboliu as we discussed, lets have sfptuil always fetch the values by reading the eeprom and sfpshow utility use the DB to read the values. Hope this will be scoped and fixed in future PR.