-
Notifications
You must be signed in to change notification settings - Fork 539
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 buffer calculation][Mellanox] Enhance the logic to identify buffer pools and profiles #2498
[Dynamic buffer calculation][Mellanox] Enhance the logic to identify buffer pools and profiles #2498
Conversation
/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). |
Failed by the following issue which is not relevant to the PR.
|
I see the following error message from the vs switch
In the test case, there is no logic to remove the vlan interface. Looks like it should be constantly failing. I was just curious how the test got passed previously...
|
Signed-off-by: Stephen Sun <[email protected]>
b5011e3
to
e0ab764
Compare
another error relevant to WR
|
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
Test issue fixed by #2504 |
Again |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
…buffer pools and profiles (#2498) Signed-off-by: Stephen Sun <[email protected]> What I did Originally, it was assumed the names of all the buffer pools follow the community buffer pool name convention ({ingress|egress}_{lossless|lossy}_pool). The heuristic algorithm to identify buffer pools and profiles was designed based on the assumption. However, some users can define the buffer pool names in other ways, which breaks the logic in the Lua plugin and introduces degradation, the pool sizes of those pools can not be generated the additional reserved memory for lossy PG can not be calculated In this PR, the logic is improved to tolerate the case. Signed-off-by: Stephen Sun [email protected] How I verified it Manually and regression test. It has been covered by regression test and vs test. No new test case is required. Details if related Separate the buffer pools into two tables according to the direction. Iterate all the profiles, generating and recording the type (lossless/lossy) for each ingress profile which is identified by checking the pool it references Identify buffer profiles for lossy PG by checking the type (lossless/lossy) generated in 2 instead of the hardcoded name ingress_lossy_profile
What I did
Originally, it was assumed the names of all the buffer pools follow the community buffer pool name convention (
{ingress|egress}_{lossless|lossy}_pool
). The heuristic algorithm to identify buffer pools and profiles was designed based on the assumption.However, some users can define the buffer pool names in other ways, which breaks the logic in the Lua plugin and introduces degradation,
In this PR, the logic is improved to tolerate the case.
Signed-off-by: Stephen Sun [email protected]
Why I did it
How I verified it
Manually and regression test.
It has been covered by regression test and vs test. No new test case is required.
Details if related
2
instead of the hardcoded nameingress_lossy_profile