xcvrd: fix SFP monitor without get_transceiver_change_event() support#31
xcvrd: fix SFP monitor without get_transceiver_change_event() support#31ds952811 wants to merge 2 commits intosonic-net:masterfrom ds952811:SONIC-749-XCVRD
Conversation
This is a common approach for platforms without get_transceiver_change_event() support, it will poll SFP module states with 1 second interval, and updates the database accordingly Otherwise, the xcvrd will crash right after initialization, as a result, all the related services will fail. e.g. * SFP modules attached to the system after SONIC start-up, will not be detected * SFP module information will never be updated upon removals Signed-off-by: Dante (Kuo-Jung) Su <dante.su@broadcom.com>
|
Please note the following change is also necessary for this commit, and it's for sonic-platform-common. |
|
I have merged sonic-net/sonic-platform-common#37. Thanks for the fix! Please resolve conflicts. |
|
@keboliu: Please review. |
There was a problem hiding this comment.
-
Vendors shall implement all the methods of plugins, this is by design. In this particular case, even platform not support SFP plug in/out event reporting, a dummy implementation shall be there to prevent xcvrd from crash.
-
If there is no event/interrupt for SFP on some certain platform, in this case the polling should be implemented inside the platform plugin, instead of polling SFP inside xcvrd, this is not something should be done by xcvrd.
-
In current xcvrd implementation, a new inserted SFP, if no event reported, eventually it's information will be added to DB by periodically running functions "post_port_dom_info_to_db" and "recover_missing_sfp_table_entries". It's true that SFP info will not be deleted if there is no event reported, but this is expected.
|
Closing this PR as per comment above:
|
This is a common approach for platforms without get_transceiver_change_event()
support, it will poll SFP module states with 1 second interval, and updates
the database accordingly
Otherwise, the xcvrd will crash right after initialization, as a result,
all the related services will fail.
e.g.
Signed-off-by: Dante (Kuo-Jung) Su dante.su@broadcom.com
What I did
For platforms without get_transceiver_change_event() support, fall back to periodically poll SFP module states for the SFP insertion/removal and the database updates
How I did it
show logging pmon -l 100