Skip to content

xcvrd: fix SFP monitor without get_transceiver_change_event() support#31

Closed
ds952811 wants to merge 2 commits intosonic-net:masterfrom
ds952811:SONIC-749-XCVRD
Closed

xcvrd: fix SFP monitor without get_transceiver_change_event() support#31
ds952811 wants to merge 2 commits intosonic-net:masterfrom
ds952811:SONIC-749-XCVRD

Conversation

@ds952811
Copy link
Copy Markdown
Contributor

@ds952811 ds952811 commented Jul 2, 2019

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

  • 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

  • Revise xcvrd to periodically poll SFP module states for the SFP insertion/removal and the database updates
  • How to verify it
  1. Bring up the DUT, and wait until SONIC CLI is ready
  2. Please insert/remove SFP modules for multiple times
  3. Issue the following command to check if SFP module insertion/removal is detected correctly
    show logging pmon -l 100

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>
@msftclas
Copy link
Copy Markdown

msftclas commented Jul 2, 2019

CLA assistant check
All CLA requirements met.

@ds952811
Copy link
Copy Markdown
Contributor Author

ds952811 commented Jul 2, 2019

Please note the following change is also necessary for this commit, and it's for sonic-platform-common.

sonic-net/sonic-platform-common#37

@jleveque
Copy link
Copy Markdown
Contributor

jleveque commented Jul 2, 2019

I have merged sonic-net/sonic-platform-common#37. Thanks for the fix!

Please resolve conflicts.

@jleveque
Copy link
Copy Markdown
Contributor

jleveque commented Jul 5, 2019

@keboliu: Please review.

Copy link
Copy Markdown
Collaborator

@keboliu keboliu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jleveque @ds952811

  1. 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.

  2. 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.

  3. 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.

@jleveque
Copy link
Copy Markdown
Contributor

Closing this PR as per comment above:

  1. 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.

  2. 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.

  3. 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.

@jleveque jleveque closed this Feb 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants