[vlanmgr][202106]Fix for STATE_DB port check logic#1981
Closed
dgsudharsan wants to merge 2 commits intosonic-net:202106from
Closed
[vlanmgr][202106]Fix for STATE_DB port check logic#1981dgsudharsan wants to merge 2 commits intosonic-net:202106from
dgsudharsan wants to merge 2 commits intosonic-net:202106from
Conversation
Signed-off-by: Sudharsan Dhamal Gopalarathnam <sudharsand@nvidia.com>
Signed-off-by: Sudharsan Dhamal Gopalarathnam <sudharsand@nvidia.com>
Collaborator
Author
|
/azpw run |
Collaborator
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
Author
|
/azpw run |
Collaborator
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
Author
|
/azpw run |
Collaborator
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
Author
|
/azpw run |
Collaborator
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
Author
|
/azpw run |
Collaborator
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
Author
|
/azpw run |
Collaborator
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
Author
|
/azpw run |
Collaborator
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Collaborator
Author
|
/azpw run |
Collaborator
|
/AzurePipelines run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
EdenGri
pushed a commit
to EdenGri/sonic-swss
that referenced
this pull request
Feb 28, 2022
#### What I did
Loading sonic-yang models only once, and re-using them. This makes the sorting a lot faster.
How to verify `loadYangModel` took a lot of time?
Add the following snippet to `TestPatchSorter`
```python
from pstats import Stats
import cProfile
class TestPatchSorter(...):
def setUp(self):
"""init each test"""
self.pr = cProfile.Profile()
self.pr.enable()
print("\n<<<---")
def tearDown(self):
"""finish any test"""
p = Stats (self.pr)
p.strip_dirs()
p.sort_stats ('cumtime')
p.print_stats ()
print("\n--->>>")
.
.
.
# Also update verify(self, cc_ops=[], tc_ops=[]) by commenting out changes validation to avoid extra calls to loadYangModels
def verify(self, cc_ops=[], tc_ops=[]):
# Arrange
config_wrapper=ConfigWrapper()
target_config=jsonpatch.JsonPatch(tc_ops).apply(Files.CROPPED_CONFIG_DB_AS_JSON)
current_config=jsonpatch.JsonPatch(cc_ops).apply(Files.CROPPED_CONFIG_DB_AS_JSON)
patch=jsonpatch.make_patch(current_config, target_config)
# Act
actual = self.create_patch_sorter(current_config).sort(patch)
# Assert
# simulated_config = current_config
# for move in actual:
# simulated_config = move.apply(simulated_config)
# self.assertTrue(config_wrapper.validate_config_db_config(simulated_config))
# self.assertEqual(target_config, simulated_config)
```
Run
```
> python3 -m unittest patch_sorter_test.TestPatchSorter.test_sort__dpb_1_to_4__success
.
.
.
48986582 function calls (48933431 primitive calls) in 104.530 seconds
Ordered by: cumulative time
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 104.530 104.530 case.py:549(_callTestMethod)
1 0.000 0.000 104.530 104.530 patch_sorter_test.py:1889(test_sort__dpb_1_to_4__success)
1 0.000 0.000 104.529 104.529 patch_sorter_test.py:1933(verify)
1 0.005 0.005 104.527 104.527 patch_sorter.py:1332(sort)
32/1 0.006 0.000 104.077 104.077 patch_sorter.py:955(sort)
334 0.012 0.000 99.498 0.298 patch_sorter.py:310(validate)
492 2.140 0.004 95.810 0.195 sonic_yang_ext.py:30(loadYangModel) <=========
```
From the above we can see profiling data about test_sort__dpb_1_to_4__success:
- Took 104.53s to complete
- loadYangModel was called 492 times
- loadYangModel took 95.810s.
loadYangModel is the method that loads the yang models from memory into SonicYang object. The loading of the YANG models should only happen once.
#### How I did it
Moved all calls to create sonic_yang object to ConfigWrapper, and each call to create a new instance just fills in the data for the yang models.
#### How to verify it
unit-test
Running profiling after the update:
```
> python3 -m unittest patch_sorter_test.TestPatchSorter.test_sort__dpb_1_to_4__success
.
.
.
702096 function calls (648951 primitive calls) in 2.882 seconds
Ordered by: cumulative time
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 2.882 2.882 case.py:549(_callTestMethod)
1 0.000 0.000 2.882 2.882 patch_sorter_test.py:1890(test_sort__dpb_1_to_4__success)
1 0.002 0.002 2.881 2.881 patch_sorter_test.py:1934(verify)
1 0.000 0.000 2.874 2.874 patch_sorter.py:1332(sort)
32/1 0.004 0.000 2.705 2.705 patch_sorter.py:955(sort)
334 0.008 0.000 2.242 0.007 patch_sorter.py:310(validate)
490 0.080 0.000 1.791 0.004 sonic_yang_ext.py:1043(loadData)
332 0.043 0.000 1.655 0.005 patch_sorter.py:345(validate)
332 0.018 0.000 1.509 0.005 gu_common.py:112(validate_config_db_config)
.
.
.
1 0.002 0.002 0.164 0.164 sonic_yang_ext.py:30(loadYangModel)
```
From the above we can see profiling data about test_sort__dpb_1_to_4__success:
- Took 2.882s to complete
- loadYangModel was called 1time
- loadYangModel took 0.164s.
[profiling-after.txt](https://github.com/Azure/sonic-utilities/files/7757252/profiling-after.txt)
#### Previous command output (if the output of a command-line utility has changed)
#### New command output (if the output of a command-line utility has changed)
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
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.
Same as #1980 for 202106
What I did
Updated checks for PORT entry in STATE_DB in vlanmgrd additionally check for presence of "state" attribute.. This is to add Vlanmgrd check similar to #1936
Why I did it
Prior to recent commits for PORT auto-negotiation, 3 daemons in cfgmgr (portmgrd, teammgrd, and intfmgrd) would not allow configuration to proceed for a specific PORT until portsyncd detected the presence of the kernel device (EthernetN) associated with the PORT and created the associated entry for the PORT in the STATE_DB with attribute "state" and value "ok".
With recent commits for PORT auto-negotiation, this logic is now broken due to creation of PORT entry in the STATE_DB by PortsOrch with only "supported_speed" attribute.
This leads to the issue where vlanmgrd might try to access the port even without it created
Oct 21 07:51:42.121276 arc-switch1025 ERR swss#vlanmgrd: :- main: Runtime error: /bin/bash -c "/sbin/ip link set "Ethernet10" master Bridge && /sbin/bridge vlan del vid 1 dev "Ethernet10" && /sbin/bridge vlan add vid 1000 dev "Ethernet10" pvid untagged" :
Oct 21 07:51:42.122339 arc-switch1025 INFO swss#/supervisord: vlanmgrd Cannot find device "Ethernet10"
How I verified it
Details if related