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 #2022

Conversation

tomer-israel
Copy link
Contributor

@tomer-israel tomer-israel commented Nov 10, 2021

What I did
I added increasing/decreasing to the port ref counter each time a port buffer configuration is added or removed

Implemented according to the - Dynamic Port Cfg HLD

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
I added a vs test that 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

@liat-grozovik
Copy link
Collaborator

@praveen-li I am unable to assign code review to you. Could you please add yourself as the reviewer?

@dprital
Copy link
Collaborator

dprital commented Nov 21, 2021

@prsunny - Can you please add @praveen-li as a reviewer ?

@praveen-li
Copy link

praveen-li commented Nov 22, 2021 via email

@zhenggen-xu
Copy link
Collaborator

Do we really need this PR since if buffer cfg is on the port, it should fail when remove port with SAI_STATUS_OBJECT_IN_USE and retry?

See: https://github.com/Azure/sonic-swss/blob/master/orchagent/portsorch.cpp#L3312

@tomer-israel
Copy link
Contributor Author

Do we really need this PR since if buffer cfg is on the port, it should fail when remove port with SAI_STATUS_OBJECT_IN_USE and retry?

See: https://github.com/Azure/sonic-swss/blob/master/orchagent/portsorch.cpp#L3312

in this way we will receive endless orchagent/SAI error messages:

...
Nov 30 11:05:38.892675 r-bulldog-04 NOTICE swss#orchagent: :- doPortTask: Deleting Port Ethernet0
Nov 30 11:05:38.895147 r-bulldog-04 ERR swss#orchagent: :- meta_is_object_in_default_state: object oid:0x1a000000000005 has non default state on SAI_INGRESS_PRIORITY_GROUP_ATTR_BUFFER_PROFILE: oid:0x190000000004c8, expected NULL
Nov 30 11:05:38.895147 r-bulldog-04 ERR swss#orchagent: :- meta_port_remove_validation: port related object oid:0x1a000000000005 is not in default state, can't remove
Nov 30 11:05:38.895195 r-bulldog-04 WARNING swss#orchagent: :- doPortTask: Failed to remove port 1000000000170, as the object is in use
Nov 30 11:05:38.895230 r-bulldog-04 NOTICE swss#orchagent: :- doPortTask: Deleting Port Ethernet0
Nov 30 11:05:38.897932 r-bulldog-04 ERR swss#orchagent: :- meta_is_object_in_default_state: object oid:0x1a000000000005 has non default state on SAI_INGRESS_PRIORITY_GROUP_ATTR_BUFFER_PROFILE: oid:0x190000000004c8, expected NULL
Nov 30 11:05:38.897932 r-bulldog-04 ERR swss#orchagent: :- meta_port_remove_validation: port related object oid:0x1a000000000005 is not in default state, can't remove
Nov 30 11:05:38.897932 r-bulldog-04 WARNING swss#orchagent: :- doPortTask: Failed to remove port 1000000000170, as the object is in use
Nov 30 11:05:38.897932 r-bulldog-04 NOTICE swss#orchagent: :- doPortTask: Deleting Port Ethernet0
Nov 30 11:05:38.900494 r-bulldog-04 ERR swss#orchagent: :- meta_is_object_in_default_state: object oid:0x1a000000000005 has non default state on SAI_INGRESS_PRIORITY_GROUP_ATTR_BUFFER_PROFILE: oid:0x190000000004c8, expected NULL
Nov 30 11:05:38.900494 r-bulldog-04 ERR swss#orchagent: :- meta_port_remove_validation: port related object oid:0x1a000000000005 is not in default state, can't remove
...

In the suggested fix we don't have these errors, and the ref count warning message is printed only once

Also, I noticed that the SAI permits to remove the port even when there are few buffer_pg configurations, for example:
removing "BUFFER_PG|Ethernet8|0" will cause the port to be removed even if "BUFFER_PG|Ethernet8|3-4" wasn't removed yet.

@dprital
Copy link
Collaborator

dprital commented Dec 7, 2021

@zhenggen-xu Can you please review and approve this PR ?

@dprital
Copy link
Collaborator

dprital commented Dec 17, 2021

@zhenggen-xu Can you please review and approve this PR ?

@zhenggen-xu - Can you ?

@zhenggen-xu
Copy link
Collaborator

As mentioned in sonic-net/SONiC#900 (comment), please update there too.

* so we added a map that will help us to know what was the last command for this port and priority -
* if the last command was set command then it is a modify command and we dont need to increase the buffer counter
* all other cases (no last command exist or del command was the last command) it means that we need to increase the ref counter */
if (op == SET_COMMAND) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please follow the same coding style, put the { in separate line in all your changes .

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

* if the last command was set command then it is a modify command and we dont need to increase the buffer counter
* all other cases (no last command exist or del command was the last command) it means that we need to increase the ref counter */
if (op == SET_COMMAND) {
if (queue_port_flags[port_name][ind] != SET_COMMAND) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do you see any issues when first time the queue_port_flags[port_name][ind] was not set yet?

Copy link
Contributor Author

@tomer-israel tomer-israel Dec 21, 2021

Choose a reason for hiding this comment

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

I dont think we have an issue on the first time - when a key not exist on a map and we try to read it, the entry is created with null value (https://stackoverflow.com/questions/10124679/what-happens-if-i-read-a-maps-value-where-the-key-does-not-exist) - so in the first time it will enter to this if (" if (queue_port_flags[port_name][ind] != SET_COMMAND)")

polling_config = PollingConfig(polling_interval = 1, timeout = 5.00, strict = True))

# verify that the port was removed properly since all buffer configuration was removed also
assert len(num) == num_of_ports - 1
Copy link
Collaborator

Choose a reason for hiding this comment

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

Add test case to add the port back?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the port is added at the end of the test case
other test cases of delete/create ports will be in the VS test PR:
#2047

Copy link
Collaborator

Choose a reason for hiding this comment

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

We need a test case to add the port back and with buffer cfg?

Also, How does this PR going to merge with the other one since you share some of the code? You will need make the other PR (2047) depending on this one, or I would think we just put that PR's content here and get everything in one shot?

change "if" coding style
change "if" coding style
@liat-grozovik
Copy link
Collaborator

@zhenggen-xu kindly reminder to review recent changes following your feedback

@liat-grozovik
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@liat-grozovik
Copy link
Collaborator

/azp run Azure.sonic-swss

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

EdenGri pushed a commit to EdenGri/sonic-swss that referenced this pull request Feb 28, 2022
…net#2022)

- What I did
For SYSTEM READY feature. Currently, there is a booting stage in system health service to indicate that the system is loading SONiC component. This booting stage is no longer needed because SYSTEM READY feature will treat that stage as system "NOT READY".

- How I did it
1. Remove booting stage
2. Adjust unit test cases

- How to verify it
Manual test, Unit test, sonic-mgmt Regression
@zhenggen-xu
Copy link
Collaborator

@zhenggen-xu kindly reminder to review recent changes following your feedback

I don't see this is addressed "We need a test case to add the port back and with buffer cfg?", again, since this PR has ref counter, we do need test cases to increase/decrease the ref counters.

@dprital
Copy link
Collaborator

dprital commented Mar 23, 2022

Hi @zhenggen-xu
As I couldn't change this PR, I raised new PR with the fixes according to your comments.
The new PR is: #2194.
Would like to ask you to review and approve.
Thanks, Dror.

dprital added a commit to dprital/sonic-swss that referenced this pull request Apr 26, 2022
dprital added a commit to dprital/sonic-swss that referenced this pull request May 8, 2022
dprital added a commit to dprital/sonic-swss that referenced this pull request May 16, 2022
dprital added a commit to dprital/sonic-swss that referenced this pull request May 26, 2022
liat-grozovik pushed a commit that referenced this pull request Aug 29, 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.
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants