[action] [PR:3952] [buffermgrd] Optimize fast-reboot startup #4018
+381
−3
Conversation
This file contains hidden or 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
This commit fixes a 10-second startup delay during fast-reboot in dynamic buffer mode. <!-- Please make sure you have read and understood the contribution guildlines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md 1. Make sure your commit includes a signature generted with `git commit -s` 2. Make sure your commit title follows the correct format: [component]: description 3. Make sure your commit message contains enough details about the change and related tests 4. Make sure your pull request adds related reviewers, asignees, labels Please also provide the following information in this pull request: --> **What I did** Add check for fast-reboot done flag m_bufferCompletelyInitialized in checkSharedBufferPoolSize() to avoid early calculation. This can save about 7s. But still keep one calculation, because buffer pool need to be ready before buffer profile creation. Also skip headroom validate in startup phase. This can save about 2s. **Why I did it** There is a 10-second startup delay during fast-reboot. Because in fast-reboot, m_mmuSize is immediately available from STATE_DB (persisted from previous boot), causing checkSharedBufferPoolSize() to execute expensive Redis operations before buffer system init completes. **How I verified it** Test with fast reboot, and check timing duration between key logs: Before fix: 2025 Jun 6 13:53:03.918106 sonic NOTICE swss#orchagent: :- main: Created underlay router interface ID 600000000000a 2025 Jun 6 13:53:14.411721 sonic NOTICE swss#orchagent: :- initBufferConstants: Got maximum memory size 20799, exposing to BUFFER_MAX_PARAM_TABLE|global After fix: 2025 Sep 15 12:12:55.319951 r-bison-12 NOTICE swss#orchagent: :- main: Created underlay router interface ID 600000000000a 2025 Sep 15 12:12:55.617816 r-bison-12 NOTICE swss#orchagent: :- initBufferConstants: Got maximum memory size 20799, exposing to BUFFER_MAX_PARAM_TABLE|global
Collaborator
Author
|
Original PR: #3952 |
Collaborator
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This commit fixes a 10-second startup delay during fast-reboot in dynamic buffer mode.
What I did
Add check for fast-reboot done flag m_bufferCompletelyInitialized in checkSharedBufferPoolSize() to avoid early calculation. This can save about 7s.
But still keep one calculation, because buffer pool need to be ready before buffer profile creation.
Also skip headroom validate in startup phase. This can save about 2s.
Why I did it
There is a 10-second startup delay during fast-reboot.
Because in fast-reboot, m_mmuSize is immediately available from STATE_DB (persisted from previous boot), causing checkSharedBufferPoolSize() to execute expensive Redis operations before buffer system init completes.
How I verified it
Test with fast reboot, and check timing duration between key logs:
Before fix:
2025 Jun 6 13:53:03.918106 sonic NOTICE swss#orchagent: :- main: Created underlay router interface ID 600000000000a
2025 Jun 6 13:53:14.411721 sonic NOTICE swss#orchagent: :- initBufferConstants: Got maximum memory size 20799, exposing to BUFFER_MAX_PARAM_TABLE|global
After fix:
2025 Sep 15 12:12:55.319951 r-bison-12 NOTICE swss#orchagent: :- main: Created underlay router interface ID 600000000000a
2025 Sep 15 12:12:55.617816 r-bison-12 NOTICE swss#orchagent: :- initBufferConstants: Got maximum memory size 20799, exposing to BUFFER_MAX_PARAM_TABLE|global