[fdb] More strict checking of FDB entry count#1126
Merged
prsunny merged 2 commits intosonic-net:masterfrom Oct 8, 2019
wangxin:fdb-strict-check
Merged
[fdb] More strict checking of FDB entry count#1126prsunny merged 2 commits intosonic-net:masterfrom wangxin:fdb-strict-check
prsunny merged 2 commits intosonic-net:masterfrom
wangxin:fdb-strict-check
Conversation
In the FdbConfigReloadTest, we observed that the SDK FDB count and number of MACs in "show mac" output may be 0. And the test still passed because of "0 == 0". This fix is to have more strict checking of the FDB entry number. If any of the FDB count is 0, fail the test. What's more, the reason of 0 FDB count is that config reloading takes longer than before. The PTF script has stopped running when FDB was cleared during config reloading. The fix is to increase the PTF script running time from 200 seconds to 300 seconds. The third change is to replace raw config reloading command with calling common_tasks/reload_config.yml Signed-off-by: Xin Wang <xinw@mellanox.com>
prsunny
reviewed
Sep 25, 2019
| when: sdk_fdb_count.stdout == show_mac_output.stdout | ||
|
|
||
| - fail: msg="No FDB is learned, something wrong with the switch" | ||
| when: sdk_fdb_count.stdout | int == 0 or show_mac_output.stdout | int == 0 |
Contributor
There was a problem hiding this comment.
Just thinking, after fdb clear, the count would be 0 until it learns next right? I don't see a sleep in between. This I believe can break the test intermittently.
Collaborator
Author
There was a problem hiding this comment.
Yes, config reloading would clear FDB. And then new FDB entries would be learned if the PTF script is still running. Currently the PTF script runs 300 seconds. After the PTF script is started, the config reload command is executed immediately. There is no need to sleep in between. If config reloading takes more than 300s to complete, the test will fail because of 0 FDB learned. In this case, the config reloading takes too long and is a problem that need to be fixed.
stepanblyschak
requested changes
Sep 25, 2019
stepanblyschak
approved these changes
Sep 26, 2019
prsunny
approved these changes
Oct 8, 2019
kazinator-arista
pushed a commit
to kazinator-arista/sonic-mgmt
that referenced
this pull request
Mar 4, 2026
Update sonic-sairedis submodule pointer to include the following: * 1d3720e Added Flex Counters support for tunnel counters (sonic-net#886) ([sonic-net#1120](sonic-net/sonic-sairedis#1120)) * 6469456 [lgtm] Add uuid library (sonic-net#1119) ([sonic-net#1126](sonic-net/sonic-sairedis#1126))
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
3 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.
Description of PR
Summary:
Fixes # (issue)
In the FdbConfigReloadTest, we observed that the SDK
FDB count and number of MACs in "show mac" output
may be 0. And the test still passed because of "0 == 0".
This fix is to have more strict checking of the FDB entry
number. If any of the FDB count is 0, fail the test.
What's more, the reason of 0 FDB count is that config
reloading takes longer than before. The PTF script has
stopped running when FDB was cleared during config
reloading. The fix is to increase the PTF script running
time from 200 seconds to 300 seconds.
The third change is to replace raw config reloading
command with calling common_tasks/reload_config.yml
Type of change
Approach
How did you do it?
How did you verify/test it?
Tested on Mellanox platform
Any platform specific information?
Supported testbed topology if it's a new test case?
Documentation