-
Notifications
You must be signed in to change notification settings - Fork 531
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
Port configuration incremental update support #2305
Merged
prsunny
merged 16 commits into
sonic-net:master
from
Junchao-Mellanox:incre-port-update-1
Jul 7, 2022
Merged
Changes from all commits
Commits
Show all changes
16 commits
Select commit
Hold shift + click to select a range
0273978
Implement incremental port configuration update
Junchao-Mellanox 623b64a
Improve unit test coverage
Junchao-Mellanox 400ee4b
Merge remote-tracking branch 'origin/master' into incre-port-update
Junchao-Mellanox 24697b2
Merge remote-tracking branch 'origin/master' into incre-port-update
Junchao-Mellanox c104b77
Fix vs test failure
Junchao-Mellanox 1cca0aa
Merge remote-tracking branch 'origin/master' into incre-port-update
Junchao-Mellanox 97fae06
Do not check configuration value since there could be case that someo…
Junchao-Mellanox 9dce0ca
Merge branch 'master' into incre-port-update
Junchao-Mellanox 9c5990d
Merge commit '910bfd4' into incre-port-update
Junchao-Mellanox 0b9b2e1
Port incremental configuration support
Junchao-Mellanox 0b18221
Merge remote-tracking branch 'origin/master' into incre-port-update-1
Junchao-Mellanox bbaadc5
Remove unused code
Junchao-Mellanox 55a18d9
Fix review comment
Junchao-Mellanox ebeb091
Fix review comment
Junchao-Mellanox 5b99253
Fix review comment
Junchao-Mellanox 25cb579
Merge remote-tracking branch 'origin/master' into incre-port-update-1
Junchao-Mellanox File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
#include <string> | ||
#include <vector> | ||
|
||
int mockCmdReturn = 0; | ||
std::string mockCmdStdcout = ""; | ||
std::vector<std::string> mockCallArgs; | ||
|
||
namespace swss { | ||
int exec(const std::string &cmd, std::string &stdout) | ||
{ | ||
mockCallArgs.push_back(cmd); | ||
stdout = mockCmdStdcout; | ||
return mockCmdReturn; | ||
} | ||
} |
Oops, something went wrong.
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.
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.
I dont think we need to change this? portsyncd does the
handlePortConfigFromConfigDB
. So portmgrd can still wait and keep the current flow.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.
Hi @prsunny ,
handlePortConfigFromConfigDB
is only called once at init stage. It cannot handle case like dynamic port breakout. So, I suppose we need keep this change. What do you think?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.
ok. so the logic here retries for some part of the configuration (kernel), but write to app_db in the first place.
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.
yes
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.
My concern is, developer has to make sure kernel writes cannot be attempted if portOk is false which is different from the previous logic. Secondly, it keeps re-writing app_db during the wait period. We need to revisit this logic
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.
how about doing this in the
if case
and keep the original logic.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.
First let me confirm your solution:
This solution makes code much clear and simple. But It will repeatedly put the configuration to APP DB until the port state turns "ok".
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.
But its the same with your current implementation as well, as you are looping through all retry attributes and writing to app_db, correct?
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.
no, for the retry process there are 3 cases:
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.
How about this? You can use similar to 'configured' below. Apply it to APP_DB only first time in this
else
part. I would like to simplify the code. I dont think we need to worry the 2nd case (port is still not ok and mtu/admin_status changed). The new values get anyways applied once the port is ready.