Replace sonic-cfggen with sonic-db-cli in banner-config & hostname-config #20048
Comments
vivekrnv
changed the title
|
@SviatoslavBoichuk FYI for banner config |
|
@vaibhavhd FYI... this may be of interest to you. |
11 tasks
qiluo-msft
pushed a commit
that referenced
this issue
Oct 4, 2024
### Why I did it Fix #20048 It is explained in ticket above, how sonic-cfggen calls in the hostname.sh, pcie-check.sh and banner-config and hogging the CPU and slightly delaying the start of swss **pcie-check.sh** redis-cli call is also replaced with sonic-db-cli since redis-cli is a wrapper around the actual redis-cli under database container <img width="1113" alt="image" src="https://github.com/user-attachments/assets/bed9d055-3b9f-4f75-aabd-1e0335716396"> **swss start** If the SKU has create_only_config_db_buffers.json set to true, the only config that's updated today is. ``` { "DEVICE_METADATA": { "localhost": { "create_only_config_db_buffers": "true" } } } ``` We use sonic-cfggen which cause 1.5 sec delay in the start of swss container. Thus replace with sonic-db-cli. If a complex use case arises in future, this can be updated. <img width="1483" alt="Screenshot 2024-09-16 at 12 45 05 PM" src="https://github.com/user-attachments/assets/ee3248b5-7623-42c4-9b50-81b114c71ae7"> ### How I did it #### How to verify it **Note: Everything was tested on MSN2700 device, Intel Celeron CPU with 2 cores** - 1.5 sec saved in the swss container start <img width="1298" alt="image" src="https://github.com/user-attachments/assets/817739f1-26a2-41ad-89e4-1e76e31532ac"> - 1.6 sec saved in the start of swss service. Previously, it took almost 1.8 sec after config-setup is finished for the swss to start. After replacing the calls, it start almost 0.2 sec after config-setup is finished In total, anywhere between 2.5 - 3.5 sec is saved
saksarav-nokia
pushed a commit
to saksarav-nokia/sonic-buildimage
that referenced
this issue
Oct 9, 2024
…et#20232) ### Why I did it Fix sonic-net#20048 It is explained in ticket above, how sonic-cfggen calls in the hostname.sh, pcie-check.sh and banner-config and hogging the CPU and slightly delaying the start of swss **pcie-check.sh** redis-cli call is also replaced with sonic-db-cli since redis-cli is a wrapper around the actual redis-cli under database container <img width="1113" alt="image" src="https://github.com/user-attachments/assets/bed9d055-3b9f-4f75-aabd-1e0335716396"> **swss start** If the SKU has create_only_config_db_buffers.json set to true, the only config that's updated today is. ``` { "DEVICE_METADATA": { "localhost": { "create_only_config_db_buffers": "true" } } } ``` We use sonic-cfggen which cause 1.5 sec delay in the start of swss container. Thus replace with sonic-db-cli. If a complex use case arises in future, this can be updated. <img width="1483" alt="Screenshot 2024-09-16 at 12 45 05 PM" src="https://github.com/user-attachments/assets/ee3248b5-7623-42c4-9b50-81b114c71ae7"> ### How I did it #### How to verify it **Note: Everything was tested on MSN2700 device, Intel Celeron CPU with 2 cores** - 1.5 sec saved in the swss container start <img width="1298" alt="image" src="https://github.com/user-attachments/assets/817739f1-26a2-41ad-89e4-1e76e31532ac"> - 1.6 sec saved in the start of swss service. Previously, it took almost 1.8 sec after config-setup is finished for the swss to start. After replacing the calls, it start almost 0.2 sec after config-setup is finished In total, anywhere between 2.5 - 3.5 sec is saved
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Description
sonic-cfggen is an expensive call to make especially on devices with weaker CPU's
Eg:
Services like banner-config, hostname-config just read from CONFIG_DB and proceed with their own stuff. Profiling with would show this.
These services complete with swss start and add some lantency to the overall control plan downtime during WR/FW.
There are straightforward calls to DB which doesn't require sonic-cfggen
The text was updated successfully, but these errors were encountered: