-
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 Calc] Bug fix: Don't create lossless buffer profile for active ports without speed configured #1822
Conversation
… configured Root cause: - In handlePortTableUpdate, refreshPgsFromPort is called if admin status is updated even if the speed is not configured. This is reasonable because the port can be configured as headroom override and the profile should be applied in that case. - However, the port's state is set to PORT_READY in refreshPgsForPort regardless whether speed is configured, which is not correct. This is should be avoided and PORT_READY should be set by caller if necessary Fix: - Don't set port's state to READY in refreshPgsForPort - Explicitly set port's state to READY in handlePortState. This has been done by all other callers. Signed-off-by: Stephen Sun <[email protected]>
Signed-off-by: Stephen Sun <[email protected]>
…ofile for active ports without speed configured (#1820) **What I did** Bugfix: Don't create lossless buffer profiles for active ports without speed configured This is to backport PR #1822 to 202012. Root cause: - In `handlePortTableUpdate`, `refreshPgsFromPort` is called if admin status is updated even if the speed is not configured. This is reasonable because the port can be configured as headroom override and the profile should be applied in that case. - However, as a side-effect, the port's state is set to `PORT_READY` in `refreshPgsForPort` regardless of whether the speed is configured, which is not correct. This is should be avoided and `PORT_READY` should be set by the caller if necessary Fix: - Don't set the port's state to `PORT_READY` in `refreshPgsForPort` and check the port's state before calling it. Note: - The change is covered by the existing vs tests. - The scenario where the bug was originally found can not be covered by vs test because: - The speed is always configured in vs image by default - Removing speed is not handled in buffer manager since it's not a valid flow. - A regression test will be opened to cover this case.
Update sonic-swss submodule head to include below fixes: Ignore ALREADY_EXIST error in FDB creation (sonic-net/sonic-swss#1815) Update MACsec SA PN counter to support SAI API 1.8 (sonic-net/sonic-swss#1818) [swss]: Allow portsyncd to run on system without ports (sonic-net/sonic-swss#1808) [debugcounterorch] check if counter type is supported before querying… (sonic-net/sonic-swss#1789) [configure.ac] Add the option of passing libnl path to configure script (sonic-net/sonic-swss#1824) refactor(fdbsyncd): Convert files with dos2unix (sonic-net/sonic-swss#1828) [VS] Fix for VS test failures (sonic-net/sonic-swss#1836) Td2: Reclaim buffer from unused ports (sonic-net/sonic-swss#1830) [gearbox] Set context for phys based on configs (sonic-net/sonic-swss#1826) [Dynamic Buffer Calc] Bug fix: Don't create lossless buffer profile for active ports without speed configured (sonic-net/sonic-swss#1822) Bridge mac setting, fix statedb time format (sonic-net/sonic-swss#1844) [cfgmgr]: Introduce common libs. (sonic-net/sonic-swss#1842)
…t#8313) Update sonic-swss submodule head to include below fixes: Ignore ALREADY_EXIST error in FDB creation (sonic-net/sonic-swss#1815) Update MACsec SA PN counter to support SAI API 1.8 (sonic-net/sonic-swss#1818) [swss]: Allow portsyncd to run on system without ports (sonic-net/sonic-swss#1808) [debugcounterorch] check if counter type is supported before querying… (sonic-net/sonic-swss#1789) [configure.ac] Add the option of passing libnl path to configure script (sonic-net/sonic-swss#1824) refactor(fdbsyncd): Convert files with dos2unix (sonic-net/sonic-swss#1828) [VS] Fix for VS test failures (sonic-net/sonic-swss#1836) Td2: Reclaim buffer from unused ports (sonic-net/sonic-swss#1830) [gearbox] Set context for phys based on configs (sonic-net/sonic-swss#1826) [Dynamic Buffer Calc] Bug fix: Don't create lossless buffer profile for active ports without speed configured (sonic-net/sonic-swss#1822) Bridge mac setting, fix statedb time format (sonic-net/sonic-swss#1844) [cfgmgr]: Introduce common libs. (sonic-net/sonic-swss#1842)
@stephenxs, not able to cherry-pick this PR in 202106 cleanly. Is there other depedent PR's ? Or please please create a separate PR for 202106. |
I’ll check it. Thanks |
Hi @judyjoseph |
…or active ports without speed configured (#1822) **What I did** Bugfix: Don't create lossless buffer profiles for active ports without speed configured Root cause: - In `handlePortTableUpdate`, `refreshPgsFromPort` is called if admin status is updated even if the speed is not configured. This is reasonable because the port can be configured as headroom override and the profile should be applied in that case. - However, as a side-effect, the port's state is set to `PORT_READY` in `refreshPgsForPort` regardless of whether the speed is configured, which is not correct. This should be avoided and `PORT_READY` should be set by the caller if necessary Fix: - Don't set the port's state to `PORT_READY` in `refreshPgsForPort` and check the port's state before calling it. - Explicitly set port's state to `PORT_READY` in `handlePortStateTable`. This has been done by all other callers. Note: - The change is covered by the existing vs tests. - The scenario where the bug was originally found can not be covered by vs test because: - The speed is always configured in vs image by default - Removing speed is not handled in buffer manager since it's not a valid flow. - A regression test will be opened to cover this case.
…or active ports without speed configured (sonic-net#1822) **What I did** Bugfix: Don't create lossless buffer profiles for active ports without speed configured Root cause: - In `handlePortTableUpdate`, `refreshPgsFromPort` is called if admin status is updated even if the speed is not configured. This is reasonable because the port can be configured as headroom override and the profile should be applied in that case. - However, as a side-effect, the port's state is set to `PORT_READY` in `refreshPgsForPort` regardless of whether the speed is configured, which is not correct. This should be avoided and `PORT_READY` should be set by the caller if necessary Fix: - Don't set the port's state to `PORT_READY` in `refreshPgsForPort` and check the port's state before calling it. - Explicitly set port's state to `PORT_READY` in `handlePortStateTable`. This has been done by all other callers. Note: - The change is covered by the existing vs tests. - The scenario where the bug was originally found can not be covered by vs test because: - The speed is always configured in vs image by default - Removing speed is not handled in buffer manager since it's not a valid flow. - A regression test will be opened to cover this case.
…uffer for unused ports (sonic-net#1822) Signed-off-by: Stephen Sun [email protected] What I did Db migrator support reclaiming reserved buffer for unused ports How I did it For admin down ports, if the buffer objects configuration aligns with default configuration, set the buffer objects configuration as: Dynamic model: all normal buffer objects are configured on admin down ports. Buffer manager will apply zero profiles on admin down ports. Static model: zero buffer objects are configured on admin down ports. How to verify it Unit test. Manually test.
What I did
Bugfix: Don't create lossless buffer profiles for active ports without speed configured
Root cause:
handlePortTableUpdate
,refreshPgsFromPort
is called if admin status is updated even if the speed is not configured.This is reasonable because the port can be configured as headroom override and the profile should be applied in that case.
PORT_READY
inrefreshPgsForPort
regardless of whether the speed is configured, which is not correct.This should be avoided and
PORT_READY
should be set by the caller if necessaryFix:
PORT_READY
inrefreshPgsForPort
and check the port's state before calling it.PORT_READY
inhandlePortStateTable
. This has been done by all other callers.Note:
Signed-off-by: Stephen Sun [email protected]
Why I did it
How I verified it
Regression test and vs test.
Details if related