[portsorch]: Bring the physical ports up are only after buffer configuration was applied #515
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
pavel-shirshov
changed the title
qiluo-msft
reviewed
Jun 7, 2018
orchagent/bufferorch.cpp
Outdated
| bool result = true; | ||
| for (const auto& key: list_of_keys) | ||
| { | ||
| result &= m_ready_list.at(key); |
There was a problem hiding this comment.
&= [](start = 15, length = 2)
Better not use bitwise operator on bool. #Closed
qiluo-msft
reviewed
Jun 7, 2018
|
|
||
| if (m_ready_list.find(key) != m_ready_list.end()) | ||
| { | ||
| m_ready_list[key] = true; |
There was a problem hiding this comment.
m_ready_list [](start = 8, length = 12)
search the key twice
There was a problem hiding this comment.
can you please elaborate on it?
There was a problem hiding this comment.
There was a problem hiding this comment.
if (m_ready_list.find(key) != m_ready_list.end())
{
m_ready_list[key] = true;
vs
auto ready_list_it = m_ready_list.find(key);
if (ready_list_it != m_ready_list.end())
{
*ready_list_it = true;
I think first case is more readable, although it might be slightly slower in case the compiler will not optimize it.
That code is not on he hot path, so I preferred to use better readability here.
qiluo-msft
reviewed
Jun 7, 2018
|
|
||
| if (m_ready_list.find(key) != m_ready_list.end()) | ||
| { | ||
| m_ready_list[key] = true; |
There was a problem hiding this comment.
m_ready_list [](start = 8, length = 12)
the same
lguohan
approved these changes
Jun 8, 2018
lguohan
pushed a commit
that referenced
this pull request
Jun 25, 2018
…uration was applied (#515) * Don't up ports, until buffer configuration is applied * Set MTU first, then set port state to UP * Introduce the test * Use logical operator && for boolean values
EdenGri
pushed a commit
to EdenGri/sonic-swss
that referenced
this pull request
Feb 28, 2022
…onic-net#515) * If fast-reboot-dump gives an error, don't continue with fast-reboot
oleksandrivantsiv
pushed a commit
to oleksandrivantsiv/sonic-swss
that referenced
this pull request
Mar 1, 2023
* Add warm boot support with removed/created port * Fix aspell * Update sai_warmboot.bin location to local folder
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.
What I did
I created an extra logic to bring the ports UP only after the buffer configuration was applied. If there is no any buffer configuration on the device, orchagent brings the ports UP immediately. This change suppose all buffer configuration on the disk before SONiC starts orch agent.
As a side change I put changing MTU operation before changing MTU state operation.
Why I did it
It's possible to create a deadlock in ASIC pipeline when we change buffer configurations with ports which are active
How I verified it
Build and run on DUT. Ensure that /var/log/swss/sairedis.rec contains ADMIN_STATE = true attribute after BUFFER_PROFILE application to the ports.
Details if related
The test is not comprehensive. vs docker already has buffer configuration, so it's impossible to test the container without any buffers.