Skip to content
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
merged 16 commits into from
Jul 7, 2022

Conversation

Junchao-Mellanox
Copy link
Collaborator

HLD: sonic-net/SONiC#985

What I did

  1. portsyncd no longer handle port configuration change and put it to APP DB
  2. Implement incremental configuration change in portmgr
  3. Adjust portsorch to meet incremental configuration change requirement

Why I did it

  1. portsyncd and portmgrd both handles port configuration change, this causes unnecessary handling in ports orch
I set the mtu to 1500 and search the log:
 
admin@sonic:~$ sudo config interface mtu Ethernet0 1500                                                                                                                                                                            
admin@sonic:~$ sudo cat /var/log/syslog | grep portsyncd
 
 
Log shows:
 
May 31 07:41:25.275792 sonic NOTICE swss#portsyncd: :- handlePortConfig: Configure port Ethernet0 attribute admin_status value to up                                                                                               
May 31 07:41:25.275792 sonic NOTICE swss#portsyncd: :- handlePortConfig: Configure port Ethernet0 attribute alias value to etp1                                                                                                    
May 31 07:41:25.275792 sonic NOTICE swss#portsyncd: :- handlePortConfig: Configure port Ethernet0 attribute index value to 1                                                                                                       
May 31 07:41:25.275792 sonic NOTICE swss#portsyncd: :- handlePortConfig: Configure port Ethernet0 attribute lanes value to 0                                                                                                       
May 31 07:41:25.275792 sonic NOTICE swss#portsyncd: :- handlePortConfig: Configure port Ethernet0 attribute mtu value to 1500                                                                                                      
May 31 07:41:25.275792 sonic NOTICE swss#portsyncd: :- handlePortConfig: Configure port Ethernet0 attribute speed value to 25000
  1. portmgrd shall do increment configuration update

How I verified it

  1. manual test
  2. regression test
  3. added new unit test case

Details if related

@Junchao-Mellanox
Copy link
Collaborator Author

/azpw run Azure.sonic-swss

@mssonicbld
Copy link
Collaborator

/AzurePipelines run Azure.sonic-swss

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@liushilongbuaa
Copy link
Contributor

/azp run Azure.sonic-swss

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@Junchao-Mellanox
Copy link
Collaborator Author

/azpw run Azure.sonic-swss

@mssonicbld
Copy link
Collaborator

/AzurePipelines run Azure.sonic-swss

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@Junchao-Mellanox
Copy link
Collaborator Author

/azpw run Azure.sonic-swss

@mssonicbld
Copy link
Collaborator

/AzurePipelines run Azure.sonic-swss

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

* We should not call any ip command if portOk=false. However, it is
* valid to put port configuration to APP DB which will trigger port creation in kernel.
*/
bool portOk = isPortStateOk(alias);
Copy link
Collaborator

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.

Copy link
Collaborator Author

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?

Copy link
Collaborator

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yes

Copy link
Collaborator

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

Copy link
Collaborator

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.

for (auto &entry : field_values)
            {
                writeConfigToAppDb(alias, fvField(entry), fvValue(entry));

Copy link
Collaborator Author

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:

if (!isPortStateOk(alias))
{
    SWSS_LOG_INFO("Port %s is not ready, pending...", alias.c_str());
    for (auto& i : kfvFieldsValues(t))
    {
        writeConfigToAppDb(alias, fvField(i), fvValue(i));
    }
    it++;
    continue;
}

// rest of the code keeps as original one

This solution makes code much clear and simple. But It will repeatedly put the configuration to APP DB until the port state turns "ok".

Copy link
Collaborator

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?

Copy link
Collaborator Author

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:

  1. port turns ok, mtu / admin_status will be configured into kernel, other fields will not be put into APP DB again
  2. port is still not ok and mtu/admin_status were changed by user, it will only put the new mtu / admin_status to APP DB
  3. port is still not ok and mtu / admin_status were not changed, nothing will be put into APP DB

Copy link
Collaborator

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.

Copy link
Collaborator

@prsunny prsunny left a comment

Choose a reason for hiding this comment

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

changes lgtm, one comment to address

for (auto &entry : field_values)
{
writeConfigToAppDb(alias, fvField(entry), fvValue(entry));
SWSS_LOG_NOTICE("Configure %s %s to %s", alias.c_str(), fvField(entry).c_str(), fvValue(entry).c_str());
Copy link
Collaborator

Choose a reason for hiding this comment

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

i'm confused by this. It seems like we are anyways writing all the fields to APP DB, so why individual writes above like mtu, tpid?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I will fix this

Copy link
Collaborator

Choose a reason for hiding this comment

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

Left a comment above to move this section to top. Also please have this as INFO logs as we don't want to keep logging during retries.

* We should not call any ip command if portOk=false. However, it is
* valid to put port configuration to APP DB which will trigger port creation in kernel.
*/
bool portOk = isPortStateOk(alias);
Copy link
Collaborator

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

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@Junchao-Mellanox
Copy link
Collaborator Author

/azpw run Azure.sonic-swss

@mssonicbld
Copy link
Collaborator

/AzurePipelines run Azure.sonic-swss

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@Junchao-Mellanox
Copy link
Collaborator Author

/azpw run Azure.sonic-swss

@mssonicbld
Copy link
Collaborator

/AzurePipelines run Azure.sonic-swss

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@Junchao-Mellanox
Copy link
Collaborator Author

/azpw run Azure.sonic-swss

@mssonicbld
Copy link
Collaborator

/AzurePipelines run Azure.sonic-swss

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@Junchao-Mellanox
Copy link
Collaborator Author

/azpw run Azure.sonic-swss

@mssonicbld
Copy link
Collaborator

/AzurePipelines run Azure.sonic-swss

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Collaborator

@prsunny prsunny left a comment

Choose a reason for hiding this comment

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

lgtm

@prsunny
Copy link
Collaborator

prsunny commented Jul 1, 2022

@Junchao-Mellanox , the VS test failure is tracke by #2365. Please retry once this is fixed.

@prsunny
Copy link
Collaborator

prsunny commented Jul 7, 2022

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@prsunny prsunny merged commit 7126857 into sonic-net:master Jul 7, 2022
dprital added a commit to dprital/sonic-buildimage that referenced this pull request Jul 7, 2022
Update sonic-swss submodule pointer to include the following:
* Port configuration incremental update support ([sonic-net#2305](sonic-net/sonic-swss#2305))
* [VS Test] Skip failing subport tests ([sonic-net#2370](sonic-net/sonic-swss#2370))
* [teammgr]: Waiting MACsec ready before doLagMemberTask ([sonic-net#2286](sonic-net/sonic-swss#2286))
* [vnetorch] [vxlanorch] fix a set of memory usage issues ([sonic-net#2352](sonic-net/sonic-swss#2352))
* [tests] [asan] add graceful stop flag ([sonic-net#2347](sonic-net/sonic-swss#2347))
* [asan] suppress the static variable leaks ([sonic-net#2354](sonic-net/sonic-swss#2354))
* Add support for IP interface loopback action ([sonic-net#2307](sonic-net/sonic-swss#2307))
* [orchagent]: srv6orch support for uSID ([sonic-net#2335](sonic-net/sonic-swss#2335))

Signed-off-by: dprital <drorp@nvidia.com>
liat-grozovik pushed a commit to sonic-net/sonic-buildimage that referenced this pull request Jul 14, 2022
Update sonic-swss submodule pointer to include the following:
* Port configuration incremental update support ([#2305](sonic-net/sonic-swss#2305))
* [VS Test] Skip failing subport tests ([#2370](sonic-net/sonic-swss#2370))
* [teammgr]: Waiting MACsec ready before doLagMemberTask ([#2286](sonic-net/sonic-swss#2286))
* [vnetorch] [vxlanorch] fix a set of memory usage issues ([#2352](sonic-net/sonic-swss#2352))
* [tests] [asan] add graceful stop flag ([#2347](sonic-net/sonic-swss#2347))
* [asan] suppress the static variable leaks ([#2354](sonic-net/sonic-swss#2354))
* Add support for IP interface loopback action ([#2307](sonic-net/sonic-swss#2307))
* [orchagent]: srv6orch support for uSID ([#2335](sonic-net/sonic-swss#2335))

Signed-off-by: dprital <drorp@nvidia.com>
preetham-singh pushed a commit to preetham-singh/sonic-swss that referenced this pull request Aug 6, 2022
*portsyncd no longer handle port configuration change and put it to APP DB
*Implement incremental configuration change in portmgr
*Adjust portsorch to meet incremental configuration change requirement
yxieca pushed a commit that referenced this pull request Aug 11, 2022
*portsyncd no longer handle port configuration change and put it to APP DB
*Implement incremental configuration change in portmgr
*Adjust portsorch to meet incremental configuration change requirement
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.

6 participants