Silicon waterfall #341
Closed
Silicon waterfall #341
Conversation
This file contains hidden or 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
added 2 commits
February 19, 2016 12:59
During image discovery, ONIE looks for installer names in the following order: 1. onie-installer-<cpu_arch>-<hw_vendor>_<machine>-r<machine_revision> 2. onie-installer-<cpu_arch>-<hw_vendor>_<machine> 3. onie-installer-<hw_vendor>_<machine> 4. onie-installer-<cpu_arch> 5. onie-installer With the advent of ONIE enabled systems supporting multiple switch silicon vendors, step 4 has become ambiguous. This patch adds an additional step to the ONIE waterfall that includes the switch silicon vendor. In the above waterfall this new step would be between steps 3 and 4. The new step looks like: onie-installer-<cpu_arch>-<switch_silicon_vendor> Before the change the kvm_x86_64 machine waterfall discovery looks like this: <cpu_arch> = x86_64 <hw_vendor>_<machine> = kvm_x86_64 Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64-r0 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64 ... Info: Fetching http://10.0.2.2/onie-installer ... After the changing, using a completely fictitious silicon vendor, the waterfall looks like: <switch_silicon_vendor> = qemu Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64-r0 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-kvm_x86_64 ... Info: Fetching http://10.0.2.2/onie-installer-x86_64-qemu ... Info: Fetching http://10.0.2.2/onie-installer-x86_64 ... Info: Fetching http://10.0.2.2/onie-installer ... Technically the same information is contained in step opencomputeproject#3 "onie-installer-<hw_vendor>_<machine>", however the new file name is more generic and will be easier for customers to maintain when using multiple platforms. Imagine the case of a customer who has multiple x86 hardware platforms, from different hardware vendors, using different switch silicon. Also imagine NOS installers that target a specific switch silicon. The customer could maintain NOS installers named as in step opencomputeproject#2 and be OK, however, that is a lot of files to manage. Using the new step "<cpu_arch>-<switch_silicon_vendor>" the end customer could target all of the x86 platforms from a particular silicon vendor with a single NOS image.
To each machine.make, where the switch silicon vendor is known, add a line of the form: SWITCH_ASIC_VENDOR = <silicon_vendor> For machines where the switch silicon vendor is unknown the string will default to "unknown". The following silicon vendor to string mapping is used: Silicon Vendor | string =================+========== Broadcom | bcm Centec | centec Mellanox | mlnx QEMU | qemu (for the virtual machines)
Contributor
Author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Add switch silicon vendor string to the image discovery default paths
During image discovery, ONIE looks for installer names in the
following order:
With the advent of ONIE enabled systems supporting multiple switch
silicon vendors, step 4 has become ambiguous.
This patch adds an additional step to the ONIE waterfall that includes
the switch silicon vendor. In the above waterfall this new step would
be between steps 3 and 4. The new step looks like:
Before the change the kvm_x86_64 machine waterfall discovery looks
like this:
After the changing, using a completely fictitious silicon vendor, the
waterfall looks like:
Technically the same information is contained in step 3
onie-installer-<hw_vendor>_<machine>, however the new file name ismore generic and will be easier for customers to maintain when using
multiple platforms.
Imagine the case of a customer who has multiple x86 hardware platforms,
from different hardware vendors, using different switch silicon. Also
imagine NOS installers that target a specific switch silicon.
The customer could maintain NOS installers named as in step 2 and be
OK, however, that is a lot of files to manage.
Using the new step
<cpu_arch>-<switch_silicon_vendor>the endcustomer could target all of the x86 platforms from a particular
silicon vendor with a single NOS image.