Transceiver monitoring HLD #202

keboliu · 2018-06-01T11:13:35Z

Transceiver monitoring HLD

This reverts commit 3a60b65.

andriymoroz · 2018-06-01T12:04:21Z

doc/transceiver-monitor-hld.md

+                             header.wd, header.mask, header.cookie, header.len, type_names,
+                             watch_path.decode('utf-8'), filename.decode('utf-8'))
+    finally:
+        i.remove_watch(b'/tmp')


I understand this is just an example but looks like remove_watch does not match the add_watch
also /bsp/ is not available in pmon (it will run in pmon, right?) so it is better to use /sys/bus...

yes, we should mount /sys/bus to pmon, will revise the example.

andriymoroz · 2018-06-01T12:07:49Z

doc/transceiver-monitor-hld.md

+
+Transceiver plug in/out status can be derived from the content of sysfs file like `"/sys/bus/i2c/devices/2-0048/hwmon/hwmon7/qsfp10_status"`, if the content of the file is "good" represent SFP is present, conent change to "not_connected" means SFP plug out.
+
+To monitor the file change, can introduce python lib [inotify](https://pypi.org/project/inotify/), which can raise notification when target file change. Below is a sample for how to use inotify lib to monitor file change:


here some details are missing. Who will generate events? where it will run? Is it part of Xcvrd or a separate daemon? If not part of Xcvrd - how event will be passed?

I agree with Andriy. This is the most tricky part. Need more details.
How should we get the list of path to watch for different vendor? and what are the ""good" and "not_connected" value different vendors? How to retrieve them in the platform monitor container.

Sorry for the delay. I think I sent the comment back. I forget to hit the review button.

I think each vendor have to implement their own API to fetch the watching path list and also the API to judge the status of the transceiver according to the file content. I'll define some API here. maybe the current CLI to show SFP presence is a good example here.

Thanks! Sounds good to me.

liatgrozovik · 2018-06-01T12:22:41Z

Arent the events generated by inotofy and should be in xcvrd? Best regards, Liat Grozovik Sent from my Samsung Galaxy smartphone. Typo is expected, sorry in advance.

-------- Original message -------- From: andriymoroz <notifications@github.com> Date: 6/1/18 15:07 (GMT+02:00) To: Azure/SONiC <SONiC@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [Azure/SONiC] Transceiver monitoring HLD (#202) @andriymoroz commented on this pull request.

________________________________ In doc/transceiver-monitor-hld.md<#202 (comment)>:

+### 1.2 Access eeprom from platform container ###

+ +Transceiver information eeprom can be accessed via read files(e.g. /sys/bus/i2c/devices/2-0048/hwmon/hwmon4/qsfp9_eeprom), different vendors may have these files under different folders, these folder need to be mounted to platform container so Xcvrd can access them. + +Another potential enhancement to the eeprom reading is to only read the needed parameters out instead of read all of them, this can be achieved by add new API to `SfpUtilBase` which can read desired bytes starting from give offset and parse the bytes to readable format accordingly. + +For the convenience of implementation and reduce the time consuming, need to enhance the `SfpUtilBase` class to provide functions to get `eeprom_if_dict` and `eeprom_dom_dict` separately, the intrested values are defined in section 1.1.1 and 1.1.2, we can pick up these values from eeprom by calling the above new API with proper offset and number of bytes. + + +### 1.3 Transceiver plug in/out event ### + +Xcvrd need to be triggered by transceiver plug in/out event to refresh the transceiver info table. + +Transceiver plug in/out status can be derived from the content of sysfs file like `"/sys/bus/i2c/devices/2-0048/hwmon/hwmon7/qsfp10_status"`, if the content of the file is "good" represent SFP is present, conent change to "not_connected" means SFP plug out. + +To monitor the file change, can introduce python lib [inotify](https://pypi.org/project/inotify/), which can raise notification when target file change. Below is a sample for how to use inotify lib to monitor file change: here some details are missing. Who will generate events? where it will run? Is it part of Xcvrd or a separate daemon? If not part of Xcvrd - how event will be passed? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#202 (review)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AQ8YX0e8XxO8eL3-abI3cDcZL8AyRU1qks5t4S6bgaJpZM4UWhUY>.

hui-ma · 2018-06-02T00:20:59Z

doc/transceiver-monitor-hld.md

+
+### 2.2 New connection to STATE_DB ###
+
+To get the transceiver and dom sensor status, SNMP agent need to connect to STATE\_DB and fetch information from TRNASCEIVER_TABLE which will be updated by Xcvrd when this is status change.


Could you please add more details about how SNMP agent should connect to DB? Could it subscribe to the change of Transceiver tables?

hui-ma · 2018-06-02T00:27:34Z

doc/transceiver-monitor-hld.md

+
+Transceiver plug in/out status can be derived from the content of sysfs file like `"/sys/bus/i2c/devices/2-0048/hwmon/hwmon7/qsfp10_status"`, if the content of the file is "good" represent SFP is present, conent change to "not_connected" means SFP plug out.
+
+To monitor the file change, can introduce python lib [inotify](https://pypi.org/project/inotify/), which can raise notification when target file change. Below is a sample for how to use inotify lib to monitor file change:


I agree with Andriy. This is the most tricky part. Need more details.
How should we get the list of path to watch for different vendor? and what are the ""good" and "not_connected" value different vendors? How to retrieve them in the platform monitor container.

hui-ma · 2018-06-27T00:44:23Z

doc/transceiver-monitor-hld.md

+| --- | --- | --- | --- |
+| 1.3.6.1.2.1.47.1.1.1 | entPhysicalTable |   |   |
+| 1.3.6.1.2.1.47.1.1.1.1 | entPhysicalEntry |   |   |
+| 1.3.6.1.2.1.47.1.1.1.1.2. ifindex | entPhysicalDescr | Show interfaces alias | Xcvr for Ethernet29 |


The ifindex should be replaced with index, which is Ifindex * 1000, as changed in requirement

yongcanwang00 · 2018-06-27T04:01:51Z

doc/transceiver-monitor-hld.md

+	tx2bias                 = FLOAT                                      ; tx2 bias in mA
+	tx3bias                 = FLOAT                                      ; tx3 bias in mA
+	tx4bias                 = FLOAT                                      ; tx4 bias in mA
+


Is it possible to add TX power? Or TX bias is enough?

@yongcanwang00 this is defined in the requirement doc, I would like to ask the requirement author @hui-ma to comment on this.

TX bias is from the output of "show interfaces transceiver eeprom" command, It is also the output of some other vendors' snmp output. I think they can be translated into TX power. I need to look for its equation. Do you prefer TX power in the output directly?

ChannelMonitorValues: RX1Power: -1.1936dBm RX2Power: -1.1793dBm RX3Power: -0.9388dBm RX4Power: -1.0729dBm TX1Bias: 4.0140mA TX2Bias: 4.0140mA TX3Bias: 4.0140mA TX4Bias: 4.0140mA ModuleMonitorValues : Temperature : 1.1111C Vcc : 0.0000Volts

Yes, TX power is useful. It's helpful to have them both.

reinight · 2018-07-06T06:29:39Z

If the transceiver is damaged, what will SfpUtil return when Xcrvd pull the info? Is it depends on the vendor's implementation and we don't care about it?

keboliu added 8 commits May 18, 2018 13:03

add transceiver monitoring hld design

6d32d74

Update transceiver-monitor-hld.md

a31f352

Update transceiver-monitor-hld.md

13d422d

Update transceiver-monitor-hld.md

97d7bed

add flow chart

3a60b65

Revert "add flow chart"

71de3e5

This reverts commit 3a60b65.

add flow chart

f55fd28

add hld design

77da04d

andriymoroz reviewed Jun 1, 2018

View reviewed changes

hui-ma reviewed Jun 4, 2018

View reviewed changes

keboliu added 3 commits June 8, 2018 13:10

update hld with comments fix

dca0f27

Add files via upload

411f168

Add files via upload

c6302fd

hui-ma reviewed Jun 27, 2018

View reviewed changes

update API definition and mib definition.

8c3150d

yongcanwang00 reviewed Jun 27, 2018

View reviewed changes

keboliu added 3 commits July 6, 2018 06:34

handle comments

a26ace7

update pic link

76858e4

resolve conflict

cd1761b

keboliu merged commit adccef4 into sonic-net:gh-pages Jul 6, 2018

arkadiyshapiro mentioned this pull request Dec 4, 2018

[device/arista]: Update sonic-net/sonic-buildimage#2336

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Transceiver monitoring HLD #202

Transceiver monitoring HLD #202

keboliu commented Jun 1, 2018

andriymoroz Jun 1, 2018

keboliu Jun 7, 2018

andriymoroz Jun 1, 2018

hui-ma Jun 2, 2018

hui-ma Jun 4, 2018

keboliu Jun 7, 2018

hui-ma Jun 8, 2018

liatgrozovik commented Jun 1, 2018 via email

hui-ma Jun 2, 2018

keboliu Jun 7, 2018

hui-ma Jun 2, 2018

hui-ma Jun 27, 2018

yongcanwang00 Jun 27, 2018

keboliu Jun 27, 2018

hui-ma Jun 27, 2018

yongcanwang00 Jun 27, 2018

reinight commented Jul 6, 2018


		Transceiver plug in/out status can be derived from the content of sysfs file like `"/sys/bus/i2c/devices/2-0048/hwmon/hwmon7/qsfp10_status"`, if the content of the file is "good" represent SFP is present, conent change to "not_connected" means SFP plug out.

		To monitor the file change, can introduce python lib [inotify](https://pypi.org/project/inotify/), which can raise notification when target file change. Below is a sample for how to use inotify lib to monitor file change:


		### 2.2 New connection to STATE_DB ###

		To get the transceiver and dom sensor status, SNMP agent need to connect to STATE\_DB and fetch information from TRNASCEIVER_TABLE which will be updated by Xcvrd when this is status change.

Transceiver monitoring HLD #202

Transceiver monitoring HLD #202

Conversation

keboliu commented Jun 1, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

liatgrozovik commented Jun 1, 2018 via email

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

reinight commented Jul 6, 2018