sonic-buildimage/device/virtual/x86_64-kvm_x86_64-r0
SuvarnaMeenakshi d88e8cf87b
[multi-asic][vs]: Add new multi-asic vs hwsku with four asics (#6558)
- Why I did it
Current mutli-asic vs hwsku consists of 6 asics with each asic having 32 interfaces. When bringing this up, below issue was seen:
When all 32 interfaces(sonic interfaces and linux interface) are set to 9100 mtu, DMA error is seen "DMA: Out of SW-IOMMU space for 4096 bytes at device 0000:06:03.0" which can be fixed by updating swiotlb=65536 in /host/grub/grub.cfg .In order to keep multi-asic VS lighter and easier to bring up and test, new hwsku 'msft_four_asic_vs' is added to represent 4-asic hwsku with 2 frontend asics and 2 backend asics and each asic having 8 interfaces interconnected by port-channels.
- How I did it
Add msft_four_asic_hwsku directory to have the right number of directories (4) and update port_config.ini and lanemap.ini files to include 8 ports information.
Add topology.sh script to create the internal asic-asic connectivity.
- How to verify it
Update asic.conf with the 4 asic information as below and build sonic-vs.img:
NUM_ASIC=4
DEV_ID_ASIC_0=0
DEV_ID_ASIC_1=1
DEV_ID_ASIC_2=2
DEV_ID_ASIC_3=3
Modify sonic_multiasic.xml to have 8 front panel interfaces.
create virtual switch using "sudo virsh sonic_mutliasic.xml" command.
Start topology service and Load config_db files for switch and each asic.
Ensure that that all internal interfaces and port_channels are coming up.
multi-asic vs testbed:
Bring up mutli-asic VS testbed with a multi-asic image(asic.conf updated to 4 asics) and using t1-lag topology.
./testbed-cli.sh -t vtestbed.csv -m veos_vtb -k ceos add-topo vms-kvm-four-asic-t1-lag password.txt
Load minigraph/config_dbs.
Ensure all internal and external interfaces come up.
No change on single asic vs.
2021-02-23 13:36:26 -08:00
..
brcm_gearbox_vs [warm-reboot] Remove warmboot file path that overrides the default path (#6198) 2020-12-13 22:17:33 -08:00
msft_four_asic_vs [multi-asic][vs]: Add new multi-asic vs hwsku with four asics (#6558) 2021-02-23 13:36:26 -08:00
msft_multi_asic_vs [multi-asic][vs]: Update topology script to retrieve hwsku from minigraph (#6219) 2021-02-18 22:02:29 -08:00
plugins [sonic-utilities] Update submodule; Build and install as a Python 3 wheel (#5926) 2020-11-25 10:28:36 -08:00
asic.conf [baseimage]: support building multi-asic component (#3856) 2020-01-26 13:56:42 -08:00
default_sku [vs]: build sonic vs kvm image (#2269) 2018-11-20 22:32:40 -08:00
installer.conf [vs]: Update swiotlb buffer size to support multi-asic VS platform. (#6674) 2021-02-04 09:04:00 -08:00
pmon_daemon_control.json [supervisor] Install vanilla package once again, install Python 3 version in Buster container (#5546) 2020-11-19 23:41:32 -08:00
README.md Add gearbox phy device files and a new physyncd docker to support VS gearbox phy feature (#4851) 2020-09-25 08:32:44 -07:00

Changing the virtual device

You can control the hw sku and default factory configuration for the VS image by modifying the content of the file default_sku in this directory.

The format of default_sku is a single line:

<hw_key> <default_preset>

Allowable values for hw_key

hw_key Device
Force10-S6000 Dell Force10 S6000
brcm_gearbox_vs Similar to Force10-S6000, but implements a virtual BRCM81724 Gearbox Phy

Allowable values for default_preset

These include "t1", "l2", and "empty". See the file sonic-buildimage/src/sonic-config-engine/config_samples.py for details on how each default_preset value is interpreted.

Changing the hwsku of an existing VS switch

To change the default hwsku for a VS image that has already been built and installed, follow these steps:

  • Edit /usr/share/sonic/device/x86_64-kvm_x86_64-r0/default_sku. For details, see the section below (Device Specific Documentation)

  • Edit /etc/sonic/config_db.json, and change the "hwsku" key in DEVICE_METADATA:localhost to match the hw_key used in default_sku. Example:

    "DEVICE_METADATA": { "localhost": { ... "hwsku": "brcm_gearbox_vs", ... } }, ...

  • Reboot the switch

  • Use "show platform summary" to verify, and follow any steps specific to the platform, as needed, such as those described below for the brcm_gearbox_vs hwsku.

Device Specific Documentation

For general info on building, see https://github.com/Azure/sonic-buildimage/blob/master/README.md

Force-10-S6000

This is the default VS for SONiC. To enable, set contents of default_sku to:

Force10-S6000 t1

To build:

make init
make configure PLATFORM=vs
make target/sonic-vs.img.gz

brcm_gearbox_vs

This sku simulates a device with a Broadcom BRCM81724 gearbox PHY. To enable, set default_sku to:

brcm_gearbox_vs t1

To build (same as Force-10-S6000):

make init
make configure PLATFORM=vs
make target/sonic-vs.img.gz

To verify, install and bring up SONiC. There will be a new gbsyncd docker which is designed to respond to configuration directed towards the gearbox phy "switch". swss will create that gearbox switch on startup after detecting the gearbox is present (this is done by a short lived gearsyncd that runs in the swss docker).

The commands "show gearbox interfaces status" and "show gearbox phys status" can be used to verify the virtual gearbox phy has been created. See https://github.com/Azure/sonic-utilities/blob/master/doc/Command-Reference.md#gearbox for details.