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

Dynamic port configuration - add port buffer cfg to the port ref counter #2194

Merged
merged 6 commits into from
Aug 29, 2022

Conversation

dprital
Copy link
Collaborator

@dprital dprital commented Mar 23, 2022

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

@dprital
Copy link
Collaborator Author

dprital commented Mar 23, 2022

/azpw run

@mssonicbld
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@pytest.mark.usefixtures('dvs_port_manager')
class TestPortAddRemove(object):

def test_remove_port_with_buffer_cfg(self, dvs, testlog):
Copy link
Collaborator

@zhenggen-xu zhenggen-xu Mar 24, 2022

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" ?

Copy link
Collaborator

@stephenxs stephenxs Mar 29, 2022

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?

Copy link
Collaborator

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.

Copy link
Collaborator

@stephenxs stephenxs Mar 30, 2022

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?

Copy link
Collaborator

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.

orchagent/bufferorch.cpp Outdated Show resolved Hide resolved
@dprital
Copy link
Collaborator Author

dprital commented Mar 24, 2022

/azpw run

@liat-grozovik
Copy link
Collaborator

/azp run Azure.sonic-swss

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@dprital
Copy link
Collaborator Author

dprital commented Mar 24, 2022

/azp run Azure.sonic-swss

@azure-pipelines
Copy link

Commenter does not have sufficient privileges for PR 2194 in repo Azure/sonic-swss

@dprital
Copy link
Collaborator Author

dprital commented Mar 27, 2022

/azpw run

@mssonicbld
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@dprital
Copy link
Collaborator Author

dprital commented Mar 27, 2022

/azpw run

@mssonicbld
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@dprital
Copy link
Collaborator Author

dprital commented Mar 28, 2022

/azpw run

@mssonicbld
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@dprital
Copy link
Collaborator Author

dprital commented Mar 28, 2022

/azpw run

@mssonicbld
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@dprital
Copy link
Collaborator Author

dprital commented Mar 30, 2022

/azpw run

@mssonicbld
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@dprital
Copy link
Collaborator Author

dprital commented Mar 31, 2022

/azpw run

@mssonicbld
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@mssonicbld
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@dprital dprital force-pushed the dynamic_port_config_buffers branch from a35cbfa to 5d262e4 Compare May 16, 2022 22:28
@liat-grozovik
Copy link
Collaborator

/azp run Azure.sonic-swss

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@liat-grozovik
Copy link
Collaborator

@dprital what is the status of this PR? do you have an ETA to fix the tests

@dprital
Copy link
Collaborator Author

dprital commented Aug 23, 2022

@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!

Copy link
Collaborator

@stephenxs stephenxs left a comment

Choose a reason for hiding this comment

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

LGTM

@liat-grozovik liat-grozovik merged commit a26b26a into sonic-net:master Aug 29, 2022
@liat-grozovik
Copy link
Collaborator

Note: approved and merged following prev approval and only tests updates.
@dprital is it needed for 202205? if so please ensure it can be cherry picked and passing. if not creale new PR against 202205

@dprital
Copy link
Collaborator Author

dprital commented Aug 29, 2022

Note: approved and merged following prev approval and only tests updates. @dprital is it needed for 202205? if so please ensure it can be cherry picked and passing. if not creale new PR against 202205

Needed for 202205 and can be taken.

dprital added a commit to dprital/sonic-buildimage that referenced this pull request Aug 29, 2022
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>
yxieca pushed a commit that referenced this pull request Sep 1, 2022
…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.
dprital added a commit to dprital/sonic-buildimage that referenced this pull request Sep 1, 2022
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>
@dprital dprital deleted the dynamic_port_config_buffers branch January 18, 2023 22:18
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.

7 participants