[xcvrd] Implement to read sfp info from eeprom several times while de… #230
Conversation
…tected sfp inserted It is known that some sfp modules will need more time to power up its data path and sometimes it caused that the application takes the incorrect or uninitialized data to display. The original way is to read eeprom as soon as the sfp is inserted. And the latest modification in PR(sonic-net#201) is to add a 2 seconds delay after sfp is detected. Our modification is to keep the original way which will read eeprom as soon as the sfp is detected. It is expected that the eeprom data in some sfp modules which have shorter warm up time can be obtained immediately. For the other modules which has longer init time, xcvrd will have a second try to read eeprom when sfp is inserted for 2 seconds and the third try will be applied when sfp is inserted for 5 seconds. Record to syslog when the checksum of sfp info read from eeprom is different from the last try.
|
Please note, datapath init is different from management init. Management init can take at max 2 seconds for any QSFP28,QSFP+,QSFP-DD.
|
|
1.What is the motivation of this PR?
2.What issue are you facing? Which spec does your transceiver follow ?
|
What spec does these kind of QSFP follow? Who is the vendor of such QSFP?
What spec does these kind of QSFP follow? Who is the vendor of such QSFP?
From SFF-8679 QSFP28-hw spec the initialization time for i2c to be ready is 2000 msec MAX. Looks like the QSFP module in your case doesn't seem to be compliant with the spec, if so please check with the QSFP vendor. If the module i2c is ready before 2000 msec timeout, then Xcvrd will wait at max 2000 msec before it does the first i2c transaction. Why do you think 2 seconds wait time before reading and updating the DB is a concern? Which platform are you testing?
|
|
@dennis0113 are you still looking for this PR? |
|
Sorry... I will keep working on this PR and update the reply for the question you had mentioned. |
sonic-net#230) This release goes in sync with the following firmware version of Broadcom Y cable, which is consistent with release 7 { "version_nic_active": "D207.1.D103.1", "version_nic_inactive": "D207.1.D103.1", "version_nic_next": "D207.1.D103.1", "version_peer_active": "D307.1", "version_peer_inactive": "D307.1", "version_peer_next": "D307.1", "version_self_active": "D307.1", "version_self_inactive": "D307.1", "version_self_next": "D307.1" } Signed-off-by: vaibhav-dahiya vdahiya@microsoft.com Description Basically a vendor specific implementation of abstract YCableBase class . detailed design discussion can be found https://github.com/Azure/SONiC/pull/757/files Signed-off-by: vaibhav-dahiya <vdahiya@microsoft.com>
Description
It is known that some sfp modules will need more time to power up its
data path and sometimes it caused that the application takes the
incorrect or uninitialized data to display.
The original way is to read eeprom as soon as the sfp is inserted. And
the latest modification in PR(#201)
is to add a 2 seconds delay after sfp is detected.
Our modification is to keep the original way which will read eeprom as
soon as the sfp is detected. It is expected that the eeprom data in
some sfp modules which have shorter warm up time can be obtained
immediately. For the other modules which has longer init time, xcvrd
will have a second try to read eeprom when sfp is inserted for 2 seconds
and the third try will be applied when sfp is inserted for 5 seconds.
Record to syslog when the checksum of sfp info read from eeprom is
different from the last try.
Motivation and Context
How Has This Been Tested?
1.Build sonic_xcvrd python .whl
2.Install the python wheel on switch and insert sfp transceiver
Additional Information (Optional)