[Mellanox] Fix thermal control bugs #4252
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Conflicts: device/mellanox/x86_64-mlnx_msn2700-r0/plugins/sfputil.py platform/mellanox/mlnx-platform-api/sonic_platform/thermal.py
Conflicts: platform/mellanox/mlnx-platform-api/sonic_platform/psu.py
Conflicts: platform/mellanox/mlnx-platform-api/sonic_platform/psu.py
…_available_status
…icate conditions in different policies
…m sysfs but directly return N/A
…th gearbox considered (sonic-net#4239)
|
Depend on sonic-net/sonic-platform-common#78 |
DPKG caching framework provides the infrastructure to cache the sonic module/target .deb files into a local cache by tracking the target dependency files.SONIC build infrastructure is designed as a plugin framework where any new source code can be easily integrated into sonic as a module and that generates output as a .deb file. The source code compilation of a module is completely independent of other modules compilation. Inter module dependency is resolved through build artifacts like header files, libraries, and binaries in the form of Debian packages. For example module A depends on module B. While module A is being built, it uses B's .deb file to install it in the build docker.
The DPKG caching framework provides an infrastructure that caches a module's deb package and restores it back to the build directory if its dependency files are not modified. When a module is compiled for the first time, the generated deb package is stored at the DPKG cache location. On the subsequent build, first, it checks the module dependency file modification. If none of the dependent files is changed, it copies the deb package from the cache location, otherwise, it goes for local compilation and generates the deb package. The modified files should be checked-in to get the newer cache deb package.
This provides a huge improvement in build time and also supports the true incremental build by tracking the dependency files.
- How I did it
It takes two global arguments to enable the DPKG caching, the first one indicates the caching method and the second one describes the location of the cache.
SONIC_DPKG_CACHE_METHOD=cache
SONIC_DPKG_CACHE_SOURCE=
where SONIC_DPKG_CACHE_METHOD - Default method is 'cache' for deb package caching
none: no caching
cache: cache from local directory
Dependency file tracking:
Dependency files are tracked for each target in two levels.
1. Common make infrastructure files - rules/config, rules/functions, slave.mk etc.
2. Per module files - files which are specific to modules, Makefile, debian/rules, patch files, etc.
For example: dependency files for Linux Kernel - src/sonic-linux-kernel,
SPATH := $($(LINUX_HEADERS_COMMON)_SRC_PATH)
DEP_FILES := $(SONIC_COMMON_FILES_LIST) rules/linux-kernel.mk rules/linux-kernel.dep
DEP_FILES += $(SONIC_COMMON_BASE_FILES_LIST)
SMDEP_FILES := $(addprefix $(SPATH)/,$(shell cd $(SPATH) && git ls-files))
DEP_FLAGS := $(SONIC_COMMON_FLAGS_LIST) \
$(KERNEL_PROCURE_METHOD) $(KERNEL_CACHE_PATH)
$(LINUX_HEADERS_COMMON)_CACHE_MODE := GIT_CONTENT_SHA
$(LINUX_HEADERS_COMMON)_DEP_FLAGS := $(DEP_FLAGS)
$(LINUX_HEADERS_COMMON)_DEP_FILES := $(DEP_FILES)
$(LINUX_HEADERS_COMMON)_SMDEP_FILES := $(SMDEP_FILES)
$(LINUX_HEADERS_COMMON)_SMDEP_PATHS := $(SPATH)
Cache file tracking:
The Cache file is a compressed TAR ball of a module's target DEB file and its derived-target DEB files.
The cache filename is formed with the following format
FORMAT:
<module deb filename>.<24 byte of DEP SHA hash >-<24 byte of MOD SHA hash>.tgz
Eg:
linux-headers-4.9.0-9-2-common_4.9.168-1+deb9u3_all.deb-23658712fd21bb776fa16f47-c0b63ef593d4a32643bca228.tgz
< 24-byte DEP SHA value > - the SHA value is derived from all the dependent packages.
< 24-byte MOD SHA value > - the SHA value is derived from either of the following.
GIT_COMMIT_SHA - SHA value of the last git commit ID if it is a submodule
GIT_CONTENT_SHA - SHA value is generated from the content of the target dependency files.
Target Specific rules:
Caching can be enabled/disabled on a global level and also on the per-target level.
$(addprefix $(DEBS_PATH)/, $(SONIC_DPKG_DEBS)) : $(DEBS_PATH)/% : .platform $$(addsuffix -install,$$(addprefix $(DEBS_PATH)/,$$($$*_DEPENDS))) \
$(call dpkg_depend,$(DEBS_PATH)/%.dep )
$(HEADER)
# Load the target deb from DPKG cache
$(call LOAD_CACHE,$*,$@)
# Skip building the target if it is already loaded from cache
if [ -z '$($*_CACHE_LOADED)' ] ; then
.....
# Rules for Generating the target DEB file.
.....
# Save the target deb into DPKG cache
$(call SAVE_CACHE,$*,$@)
fi
$(FOOTER)
The make rule-'$(call dpkg_depend,$(DEBS_PATH)/%.dep )' checks for target dependency file modification. If it is newer than the target, it will go for re-generation of that target.
Two main macros 'LOAD_CACHE' and 'SAVE_CACHE' are used for loading and storing the cache contents.
The 'LOAD_CACHE' macro is used to load the cache file from cache storage and extracts them into the target folder. It is done only if target dependency files are not modified by checking the GIT file status, otherwise, cache loading is skipped and full compilation is performed.
It also updates the target-specific variable to indicate the cache is loaded or not.
The 'SAVE_CACHE' macro generates the compressed tarball of the cache file and saves them into cache storage. Saving into the cache storage is protected with a lock.
- How to verify it
The caching functionality is verified by enabling it in Linux kernel submodule.
It uses the cache directory as 'target/cache' where Linux cache file gets stored on the first-time build and it is picked from the cache location during the subsequent clean build.
- Description for the changelog
The DPKG caching framework provides the infrastructure to save the module-specific deb file to be cached by tracking the module's dependency files.
If the module's dependency files are not changed, it restores the module deb files from the cache storage.
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)
DOCUMENT PR:
sonic-net/SONiC#559
… (sonic-net#4250) * [Service] Added NAT entry into CONTAINER_FEATURE. Fixes sonic-net#4247. Signed-off-by: Andriy Kokhan <akokhan@barefootnetworks.com>
I added dependencies to support the NAT feature on the virtual switch. Signed-off-by: Danny Allen <daall@microsoft.com>
stephenxs
previously approved these changes
Mar 16, 2020
* Build Arista drivers using DPKG_DEB * Update arista platform submodule
|
@Junchao-Mellanox: sonic-net/sonic-platform-common#78 has merged. Please update the submodule in this PR. |
|
retest this please |
setup ntp server to do the test Signed-off-by: Guohan Lu <lguohan@gmail.com>
Signed-off-by: Mykola Faryma <mykolaf@mellanox.com>
We believe that the supervisord issue in face of clock rolling backwards has been addressed. Therefore reverting change 2598 to allow ntp sync to right clock at the start up time. Signed-off-by: Ying Xie <ying.xie@microsoft.com>
* Fix BFN syncd RPC compilation * Remove empty line
Signed-off-by: Andriy Kokhan <akokhan@barefootnetworks.com>
|
Retest vsimage please |
|
Retest mellanox please |
* Add cache build flag * Fix bug
…ntainer (sonic-net#4101) * fancontrol restart * Cleanup the default setting for exitcodes * Remove the unnecessary stopwaitsecs default settin
marvell sonic arm64 uboot fit flattened blob file. Used by uboot as refered in this change https://github.com/Azure/sonic-buildimage/pull/4043/files#diff-f6372e5829e59e22aa068273c238ba83 Signed-off-by: Antony Rheneus <arheneus@marvell.com>
* [makefile] make error message clearer with instructions Signed-off-by: Ying Xie <ying.xie@microsoft.com>
|
Retest mellanox please |
… VLAN interfaces (sonic-net#4229) - Support parsing egress ACLs from minigraph file specified by the "OutAcl" element - Support attaching ACLs to VLAN interfaces
Signed-off-by: Ciju Rajan K <crajank@juniper.net> Signed-off-by: Ashish Bhensdadia <bashish@juniper.net> Co-authored-by: Ashish Kumar Bhensdadia <ashish@sonic-server.englab.juniper.net>
Conflicts: device/mellanox/x86_64-mlnx_msn2700-r0/plugins/sfputil.py platform/mellanox/mlnx-platform-api/sonic_platform/thermal.py
Conflicts: platform/mellanox/mlnx-platform-api/sonic_platform/psu.py
Conflicts: platform/mellanox/mlnx-platform-api/sonic_platform/psu.py
…_available_status
…icate conditions in different policies
…m sysfs but directly return N/A
…image into thermal-fix
|
I |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
- What I did
- How I did it
- How to verify it
Manually verify and run existing regression cases
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)