forked from sonic-net/sonic-buildimage
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Mellanox] Optimize SFP modules initialization #67
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
keboliu
reviewed
Apr 27, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please add more comments to describe the two new init flags
Done. |
Unit test added. |
keboliu
approved these changes
Apr 30, 2021
Originally, SFP modules were always accessed from platform daemons, and arbitrary SFP module can be accessed in the daemon. All SFP modules were initialized in one-shot once one of the following chassis APIs called - get_all_sfps - get_sfp_numbers - get_sfp Recently, we noticed that SFP modules can also be accessed from CLI, eg. the latest refactor of sfputil. In this case, only one SFP module is accessed in the chassis object's life cycle. To initialize all SFP modules in one-shot is waste of time. The new optimized flow is: - get_sfp called, only initialize the SFP module being accessed all other elements in _sfp_list are None - get_all_sfps and get_sfp_numbers called, initialize all SFP modules as usual Signed-off-by: Stephen Sun <stephens@nvidia.com>
Signed-off-by: Stephen Sun <stephens@nvidia.com>
Signed-off-by: Stephen Sun <stephens@nvidia.com>
871e452
to
f7c2565
Compare
stephenxs
pushed a commit
that referenced
this pull request
May 19, 2022
[sonic-linkmgrd][202012] submodule update 3d13ff2 Jing Zhang Wed May 4 10:07:14 2022 -0700 Add doc for default route related changes (#63) c703be4 Jing Zhang Mon May 2 13:27:54 2022 -0700 Reset WaitActiveUp count before switching to active (#70) 86eb727 Jing Zhang Wed Apr 27 10:35:05 2022 -0700 lower log level to warning (#69) e22c736 Jing Zhang Mon May 2 13:33:24 2022 -0700 [202012] Avoid proactively switching to active if default route is missing (#67) d4f282b Jing Zhang Thu Apr 28 18:35:11 2022 -0700 [202012] Add support to enable switchover time measurement (with link prober interval decreased to 10ms) feature (#66) sign-off: Jing Zhang [zhangjing@microsoft.com](mailto:zhangjing@microsoft.com)
stephenxs
pushed a commit
that referenced
this pull request
Jul 3, 2023
…utomatically (sonic-net#15548) #### Why I did it src/sonic-host-services ``` * 508d642 - (HEAD -> master, origin/master, origin/HEAD) [actions] Support Semgrep by Github Actions (#67) (31 hours ago) [Mai Bui] ``` #### How I did it #### How to verify it #### Description for the changelog
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why I did it
Originally, SFP modules were always accessed from platform daemons, and arbitrary SFP modules can be accessed in the daemon. So all SFP modules were initialized in one shot once one of the following chassis APIs called
Recently, we noticed that SFP modules can also be accessed from CLI, eg. the latest refactor of
sfputil
.In this case, only one SFP module is accessed in the chassis object's life cycle.
To initialize all SFP modules in one shot is waste of time and causes the CLI to take much more time to finish.
So we would like to optimize the initialization flow by introducing a two-phase initialization approach:
chassis._sfp_list
has been initialized with proper length and all elements beingNone
chassis._sfp_list
are createdIf the relevant function is called,
get_sfp
, only partial initialization will be done, and then the specific SFP module is initialized.get_all_sfps
orget_num_sfps
, full initialization will be done, which means all SFP modules are initialized.Signed-off-by: Stephen Sun stephens@nvidia.com
How I did it
How to verify it
Manually test. APIs are called in the following order:
get_sfp
and thenget_all_sfps
.get_all_sfps
get_num_sfps
Which release branch to backport (provide reason below if selected)
Description for the changelog
A picture of a cute animal (not mandatory but encouraged)