Fixed set mtu for deleted subintf due to late notification #2571
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Commenter does not have sufficient privileges for PR 2571 in repo sonic-net/sonic-swss |
|
/azpw run Asure.sonic-buildimage |
|
/AzurePipelines run Asure.sonic-buildimage |
|
No pipelines are associated with this pull request. |
|
/azpw run Azure.sonic-swss |
|
/AzurePipelines run Azure.sonic-swss |
|
/azpw run Azure.sonic-swss |
|
/AzurePipelines run Azure.sonic-swss |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw run Azure.sonic-swss |
|
/AzurePipelines run Azure.sonic-swss |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
|
||
| return subifMtu; | ||
| if (ret && !isIntfStateOk(alias)) |
There was a problem hiding this comment.
This is already checked in the doIntfGeneralTask under SET operation. So why check again here? is there a race condition?
There was a problem hiding this comment.
We are not visiting the "doIntfGeneralTask" function in this flow.
The flow is:
- changing the "mtu" field in the PORT_TABLE in state DB
doTaskdoPortTableTaskupdateSubIntfMtusetHostSubIntfMtu
There was a problem hiding this comment.
ok, does this happen in the updateSubIntfAdminStatus flow as well? Or why only mtu change is handled?
There was a problem hiding this comment.
It is happen in the updateSubIntfAdminStatus flow as well
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw run Asure.sonic-buildimage |
|
/AzurePipelines run Asure.sonic-buildimage |
|
No pipelines are associated with this pull request. |
|
/azpw run Azure.sonic-swss |
|
/AzurePipelines run Azure.sonic-swss |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw run Azure.sonic-swss |
|
/AzurePipelines run Azure.sonic-swss |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azpw run Azure.sonic-swss |
|
/AzurePipelines run Azure.sonic-swss |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@prsunny - Can you please approve this PR ? |
Update sonic-swss submodule pointer to include the following: * bdedf69 Modify coppmgr mergeConfig to support preserving copp tables through reboot. ([sonic-net#2548](sonic-net/sonic-swss#2548)) * 7891e78 Fixed set mtu for deleted subintf due to late notification ([sonic-net#2571](sonic-net/sonic-swss#2571)) * a443945 Updated handling of VRF_VNI mapping and VLAN_VNI mapping for same VNI ID ([sonic-net#2538](sonic-net/sonic-swss#2538)) Signed-off-by: dprital <[email protected]>
Update sonic-swss submodule pointer to include the following: * bdedf69 Modify coppmgr mergeConfig to support preserving copp tables through reboot. ([#2548](sonic-net/sonic-swss#2548)) * 7891e78 Fixed set mtu for deleted subintf due to late notification ([#2571](sonic-net/sonic-swss#2571)) * a443945 Updated handling of VRF_VNI mapping and VLAN_VNI mapping for same VNI ID ([#2538](sonic-net/sonic-swss#2538)) Signed-off-by: dprital <[email protected]>
…2595) PR against 202205 based on the following PR: #2571 - What I did Ignores errors on the set MTU command for subinterface when the subinterface state is not OK. - Why I did it A race condition between the portmgrd and the intfmgrd sometimes causes running a set MTU command on a deleted subinterface. The logs and the error: INFO swss#supervisord: intfmgrd Cannot find device "Ethernet32.58" ERR swss#intfmgrd: :- main: Runtime error: /sbin/ip link set "Ethernet32.58" mtu "9100" : INFO swss#supervisord 2022-11-08 05:53:33,057 INFO exited: intfmgrd (exit status 255; not expected) - How I verified it Run the test_loopback_action_reload test and saw no errors in the logs.
* Fixed set mtu for deleted subintf due to late notification
What I did
Ignores errors on the set MTU command for subinterface when the subinterface state is not OK.
Why I did it
A race condition between the portmgrd and the intfmgrd sometimes causes running a set MTU command on a deleted subinterface.
The logs and the error:
How I verified it
Run the test_loopback_action_reload test and saw no errors in the logs.
Details if related