-
Notifications
You must be signed in to change notification settings - Fork 529
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
Dynamic port configuration - add port buffer cfg to the port ref counter #2194
Dynamic port configuration - add port buffer cfg to the port ref counter #2194
Conversation
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
tests/test_port_add_remove.py
Outdated
@pytest.mark.usefixtures('dvs_port_manager') | ||
class TestPortAddRemove(object): | ||
|
||
def test_remove_port_with_buffer_cfg(self, dvs, testlog): |
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.
we should remove_port, add_port, then remove_port (port will with buffer_cfg, when remove you will remove buffer cfg first, and when you add, you will add buffer cfg after) to see if things are as expected. This is to explicitly excise the ref counters during those operations. maybe we can have a test case like "test_remove_add_remove_port_with_buffer_cfg" ?
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.
@zhenggen-xu
to me, this is a negative test that verifies a port will not be removed if there is a buffer configuration on it. We should keep this test.
So i would like to have the test test_remove_add_remove_port_with_buffer_cfg
like this:
- when removing the port for the first time, remove port first and then the buffer configuration. verify the port will not be removed without buffer configuration cleared.
- when adding the port, add the port first and then the buffer configuration, as you suggested.
- when removing the port for the second time, remove the buffer configuration and then the port, as you suggested.
By doing so, we are able to verify both orders.
How 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.
@stephenxs sounds good to me.
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.
Updated test case. It's a bit different compared with what I suggested yesterday.
What I suggested:
- for the first removing, remove the port and then buffer configuration
- for the second removing, remove the buffer configuration and then port
What I implemented:
- for the first removing, remove the buffer configuration and then the port
- for the second removing, remove the port and then buffer configuration
Compared with the original approach, we do not need to check whether the buffer configuration has been successfully re-added after it was added back when the port was recreated: if it is not successfully added, the following port removing can succeed without removing buffer configuration, which will fail the test. Neither do we lose coverage.
@zhenggen-xu can you please review it?
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.
Sure, looks good to me.
/azpw run |
/azp run Azure.sonic-swss |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run Azure.sonic-swss |
Commenter does not have sufficient privileges for PR 2194 in repo Azure/sonic-swss |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
a35cbfa
to
5d262e4
Compare
Signed-off-by: Stephen Sun <stephens@nvidia.com>
5d262e4
to
39aa90a
Compare
/azp run Azure.sonic-swss |
Azure Pipelines successfully started running 1 pipeline(s). |
@dprital what is the status of this PR? do you have an ETA to fix the tests |
@neethajohn , @zhenggen-xu - This is an old PR which was approved by you, as the checkers failed for some time, i fixed the test and now it pass. Would l ike to ask you to look at it (the code was not changed, only the test itself) and I would like you to approve so it will be able to be merged. Thanks in advance! |
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.
LGTM
Note: approved and merged following prev approval and only tests updates. |
Needed for 202205 and can be taken. |
Update sonic-swss submodule pointer to include the following: * Dynamic port configuration - add port buffer cfg to the port ref counter ([sonic-net#2194](sonic-net/sonic-swss#2194)) * tlm_teamd: Filter portchannel subinterface events from STATE_DB LAG_TABLE ([sonic-net#2408](sonic-net/sonic-swss#2408)) * [counters] Improve performance by polling only configured ports buffer queue/pg counters ([sonic-net#2360](sonic-net/sonic-swss#2360)) * added support for Xsight platform ([sonic-net#2426](sonic-net/sonic-swss#2426)) * [ci][asan] add DVS tests run with ASAN ([sonic-net#2363](sonic-net/sonic-swss#2363)) * Handle dual ToR neighbor miss scenario ([sonic-net#2151](sonic-net/sonic-swss#2151)) * Upstream new development on p4orch ([sonic-net#2237](sonic-net/sonic-swss#2237)) * [lgtm] Fix dependency ([sonic-net#2419](sonic-net/sonic-swss#2419)) * [muxorch] Returning true if nbr in skip_neighbor_ in isNeighborActive() ([sonic-net#2415](sonic-net/sonic-swss#2415)) * [macsec]: Set MTU for MACsec ([sonic-net#2398](sonic-net/sonic-swss#2398)) * Delete Invalid if condition in intfsorch.cpp ([sonic-net#2411](sonic-net/sonic-swss#2411)) Signed-off-by: dprital <drorp@nvidia.com>
…ter (#2194) - What I did This PR replace PR #2022 Added increasing/decreasing to the port ref counter each time a port buffer configuration is added or removed Implemented according to the - sonic-net/SONiC#900 - Why I did it In order to avoid cases where a port is removed before the buffer configuration on this port were removed also - How I verified it VS Test was added in order to test it. we remove a port with buffer configuration and the port is not removed. only after all buffer configurations on this port were removed - this port will be removed.
Update sonic-swss submodule pointer to include the following: * [BFD]Clean up state_db BFD entries on swss restart ([sonic-net#2434](sonic-net/sonic-swss#2434)) * Fix the Fec Mode Setting of gbsyncd ([sonic-net#2430](sonic-net/sonic-swss#2430)) * [neighsyncd] Enabling ipv4 link local entries for non-dualtor ([sonic-net#2427](sonic-net/sonic-swss#2427)) * tlm_teamd: Filter portchannel subinterface events from STATE_DB LAG_TABLE ([sonic-net#2408](sonic-net/sonic-swss#2408)) * PFCWD recovery changes using DLR_INIT ([sonic-net#2316](sonic-net/sonic-swss#2316)) * Dynamic port configuration - add port buffer cfg to the port ref counter ([sonic-net#2194](sonic-net/sonic-swss#2194)) Signed-off-by: dprital <drorp@nvidia.com>
What I did
This PR replace PR #2022
Added increasing/decreasing to the port ref counter each time a port buffer configuration is added or removed
Implemented according to the - sonic-net/SONiC#900
Why I did it
In order to avoid cases where a port is removed before the buffer configuration on this port were removed also
How I verified it
VS Test was added in order to test it.
we remove a port with buffer configuration and the port is not removed. only after all buffer configurations on this port were
removed - this port will be removed.
Details if related