7543993af3
- Why I did it There are 3 tasks in xcvrd: main task, run a loop to recover missing SFP static information to DB every 1 minute SFP state task, a process which listens cable plug in/out event, insert SFP static information to DB while a cable is inserted SFP DOM update task, a thread which handles cable DOM information update every 1 minute Let assume user replaces QSFP with QSFP-DD. There are two issues: Only SFP state task listens cable plug in/out event, main task and SFP DOM update task does not know SFP type has changed, they still “think” the SFP type is QSFP. So, main task and SFP DOM update task uses QSFP standard to parse QSFP-DD EEPROM which causes corrupted data. There is a race condition between main task and SFP state task. They both insert SFP static information to DB. Depends on timing, it is possible that main task using wrong SFP type to override SFP static information. The PR is to fix these two issues. There is no such issue on 202205 and above because there is a refactor for xcvrd: SFP state task was changed from process to thread, so that all 3 tasks share the same memory space, they always have correct SFP type. Recover missing SFP information logical was moved from main task to SFP state task. There is no race condition anymore. - How I did it It is difficult to back port latest xcvrd because there are many refactor/new features in xcvrd after 202012 release. It will be huge effort to do so. Based on that, we decided to fix the issue on Nvidia platform API side. The fix is that: refreshing SFP type before any SFP API which accessing SFP EEPROM. Refreshing SFP type before any SFP API would cause a small performance down: Due to my test on 202012 branch, accessing transceiver INFO and DOM INFO for 32 ports takes 1.7 seconds before the change. The number changes to 2.4 seconds after the change. I suppose the performance down is acceptable. - How to verify it Manual test Regression |
||
---|---|---|
.azure-pipelines | ||
.github | ||
device | ||
dockers | ||
files | ||
installer | ||
platform | ||
rules | ||
scripts | ||
sonic-slave-buster | ||
sonic-slave-jessie | ||
sonic-slave-stretch | ||
src | ||
.artifactignore | ||
.gitignore | ||
.gitmodules | ||
azure-pipelines.yml | ||
build_debian.sh | ||
build_debug_docker_j2.sh | ||
build_docker.sh | ||
build_image.sh | ||
check_install.py | ||
functions.sh | ||
get_docker-base.sh | ||
LICENSE | ||
MAINTAINERS | ||
Makefile | ||
Makefile.cache | ||
Makefile.work | ||
onie-image-arm64.conf | ||
onie-image-armhf.conf | ||
onie-image.conf | ||
onie-mk-demo.sh | ||
push_docker.sh | ||
README.buildsystem.md | ||
README.md | ||
slave.mk | ||
ThirdPartyLicenses.txt | ||
update_screen.sh |
master builds:
201911 builds:
201811 builds:
201807 builds:
201803 builds:
sonic-buildimage
Build SONiC Switch Images
Description
Following is the instruction on how to build an (ONIE) compatible network operating system (NOS) installer image for network switches, and also how to build docker images running inside the NOS. Note that SONiC image are build per ASIC platform. Switches using the same ASIC platform share a common image. For a list of supported switches and ASIC, please refer to this list
Hardware
Any server can be a build image server. We are using a server with 1T hard disk. The OS is Ubuntu 16.04.
Prerequisites
Install pip and jinja in host build machine, execute below commands if j2/j2cli is not available:
sudo apt-get install -y python-pip
sudo python2 -m pip install -U pip==9.0.3
sudo pip install --force-reinstall --upgrade jinja2>=2.10
sudo pip install j2cli
Configure your system to allow running the 'docker' command without 'sudo':
Add current user to the docker group
sudo gpasswd -a ${USER} docker
Log out and log back in so that your group membership is re-evaluated
SAI Version
Please refer to SONiC roadmap on the SAI version for each SONiC release.
Clone or fetch the code repository with all git submodules
To clone the code repository recursively, assuming git version 1.9 or newer:
git clone https://github.com/Azure/sonic-buildimage.git
Usage
To build SONiC installer image and docker images, run the following commands:
# Ensure the 'overlay' module is loaded on your development system
sudo modprobe overlay
# Enter the source directory
cd sonic-buildimage
# (Optional) Checkout a specific branch. By default, it uses master branch. For example, to checkout the branch 201911, use "git checkout 201911"
git checkout [branch_name]
# Execute make init once after cloning the repo, or after fetching remote repo with submodule updates
make init
# Execute make configure once to configure ASIC
make configure PLATFORM=[ASIC_VENDOR]
# Build SONiC image
make all
Usage for ARM Architecture
To build Arm32 bit for (ARMHF) plaform ARM build has dependency in docker version 18, if docker version is 19, downgrade to 18 as below sudo apt-get install --allow-downgrades -y docker-ce=5:18.09.0~3-0~ubuntu-xenial sudo apt-get install --allow-downgrades -y docker-ce-cli=5:18.09.0~3-0~ubuntu-xenial
# Execute make configure once to configure ASIC and ARCH
make configure PLATFORM=[ASIC_VENDOR] PLATFORM_ARCH=armhf
make target/sonic-[ASIC_VENDER]-armhf.bin
# example:
make configure PLATFORM=marvell-armhf PLATFORM_ARCH=armhf
make target/sonic-marvell-armhf.bin
To build Arm64 bit for plaform
# Execute make configure once to configure ASIC and ARCH
make configure PLATFORM=[ASIC_VENDOR] PLATFORM_ARCH=arm64
# example:
make configure PLATFORM=marvell-arm64 PLATFORM_ARCH=arm64
NOTE:
-
Recommend reserving 50G free space to build one platform.
-
If Docker's workspace folder,
/var/lib/docker
, resides on a partition without sufficient free space, you may encounter an error like the following during a Docker container build job:/usr/bin/tar: /path/to/sonic-buildimage/<some_file>: Cannot write: No space left on device
The solution is to move the directory to a partition with more free space.
-
Use
http_proxy=[your_proxy] https_proxy=[your_proxy] make
to enable http(s) proxy in the build process. -
Add your user account to
docker
group and use your user account to make.root
orsudo
are not supported.
The SONiC installer contains all docker images needed. SONiC uses one image for all devices of a same ASIC vendor. The supported ASIC vendors are:
- PLATFORM=broadcom
- PLATFORM=marvell
- PLATFORM=mellanox
- PLATFORM=cavium
- PLATFORM=centec
- PLATFORM=nephos
- PLATFORM=innovium
- PLATFORM=p4
- PLATFORM=vs
For Broadcom ASIC, we build ONIE and EOS image. EOS image is used for Arista devices, ONIE image is used for all other Broadcom ASIC based devices.
make configure PLATFORM=broadcom
# build debian stretch required targets
BLDENV=stretch make stretch
# build ONIE image
make target/sonic-broadcom.bin
# build EOS image
make target/sonic-aboot-broadcom.swi
You may find the rules/config file useful. It contains configuration options for the build process, like adding more verbosity or showing dependencies, username and password for base image etc.
Every docker image is built and saved to target/ directory. So, for instance, to build only docker-database, execute:
make target/docker-database.gz
Same goes for debian packages, which are under target/debs/:
make target/debs/swss_1.0.0_amd64.deb
Every target has a clean target, so in order to clean swss, execute:
make target/debs/swss_1.0.0_amd64.deb-clean
It is recommended to use clean targets to clean all packages that are built together, like dev packages for instance. In order to be more familiar with build process and make some changes to it, it is recommended to read this short Documentation.
Build debug dockers and debug SONiC installer image:
SONiC build system supports building dockers and ONE-image with debug tools and debug symbols, to help with live & core debugging. For details refer to (SONiC Buildimage Guide).
Notes:
-
If you are running make for the first time, a sonic-slave-${USER} docker image will be built automatically. This may take a while, but it is a one-time action, so please be patient.
-
The root user account is disabled. However, the created user can
sudo
. -
The target directory is
./target
, containing the NOS installer image and docker images.- sonic-generic.bin: SONiC switch installer image (ONIE compatible)
- sonic-aboot.bin: SONiC switch installer image (Aboot compatible)
- docker-base.gz: base docker image where other docker images are built from, only used in build process (gzip tar archive)
- docker-database.gz: docker image for in-memory key-value store, used as inter-process communication (gzip tar archive)
- docker-fpm.gz: docker image for quagga with fpm module enabled (gzip tar archive)
- docker-orchagent.gz: docker image for SWitch State Service (SWSS) (gzip tar archive)
- docker-syncd-brcm.gz: docker image for the daemon to sync database and Broadcom switch ASIC (gzip tar archive)
- docker-syncd-cavm.gz: docker image for the daemon to sync database and Cavium switch ASIC (gzip tar archive)
- docker-syncd-mlnx.gz: docker image for the daemon to sync database and Mellanox switch ASIC (gzip tar archive)
- docker-syncd-nephos.gz: docker image for the daemon to sync database and Nephos switch ASIC (gzip tar archive)
- docker-syncd-invm.gz: docker image for the daemon to sync database and Innovium switch ASIC (gzip tar archive)
- docker-sonic-p4.gz: docker image for all-in-one for p4 software switch (gzip tar archive)
- docker-sonic-vs.gz: docker image for all-in-one for software virtual switch (gzip tar archive)
- docker-sonic-mgmt.gz: docker image for managing, configuring and monitoring SONiC (gzip tar archive)
Contribution Guide
All contributors must sign a contribution license agreement before contributions can be accepted. Contact sonic-cla-agreements@microsoft.com.
GitHub Workflow
We're following basic GitHub Flow. If you have no idea what we're talking about, check out GitHub's official guide. Note that merge is only performed by the repository maintainer.
Guide for performing commits:
- Isolate each commit to one component/bugfix/issue/feature
- Use a standard commit message format:
[component/folder touched]: Description intent of your changes [List of changes] Signed-off-by: Your Name your@email.com
For example:
swss-common: Stabilize the ConsumerTable * Fixing autoreconf * Fixing unit-tests by adding checkers and initialize the DB before start * Adding the ability to select from multiple channels * Health-Monitor - The idea of the patch is that if something went wrong with the notification channel, we will have the option to know about it (Query the LLEN table length). Signed-off-by: user@dev.null
- Each developer should fork this repository and add the team as a Contributor
- Push your changes to your private fork and do "pull-request" to this repository
- Use a pull request to do code review
- Use issues to keep track of what is going on
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.