Why I did it
The 720DT-48S platform has variants with different chassis names, and these need to all be included in platform_components.json to ensure that sonic-mgmt platform_tests/fwutil/test_fwutil.py::test_fwutil_show passes
How I did it
Updated platform_components.json with the variant names for 720DT-48S.
How to verify it
Ran aforementioned testcase and verified that it passes on the different variants.
Co-authored-by: andywongarista <78833093+andywongarista@users.noreply.github.com>
Why I did it
autoneg is not supported in the previous release 202012 on Nokia-7215 platform. To migrate to the 202205 image with autoneg support, we need to disable the autoneg to allow the link to be up when issue load minigraph. This requires to change the autoneg setting to be off in the port_config.ini file.
How I did it
Modify the port_config.ini to set the autoneg off.
How to verify it
Running the new image, with load mingraph.xml, execute "show int autonet status" should show autoneg disabled
Why I did it
To bring in the following fixes:
Revert temporary fix added to disable SA equal DA drops
CS00012273013 - [7.1][J2, J2c+] Disable SA Equals DA trap on DNX
CS00012274222 - How to block the voq for given destination port for a flow from a remote mod-id
CS00012275381 - SAI_INGRESS_PRIORITY_GROUP_STAT_PACKETS is incremented for port's PG's even if there are no traffic sent to that PG
CS00012274433 - Local Fault and Remote Fault are not polled by linkscan thread
How I did it
Merged above fixes to SAI code
How to verify it
Validated by running the basic sanity tests on XGS and DNX chassis platforms including
fib/test_fib.py
decap/test_decap.py
drop_counters/test_drop_counters.py
arp/test_arpall.py
Why I did it
Update the Nokia-7215 device data which is required by the new version of the Marvell SAI 1.10.2-2 to fix the syncd crash issue.
How I did it
Update the device data in folder device/nokia/armhf-nokia_ixs7215_52x-r0 /Nokia-7215.
How to verify it
With this PR, syncd should be running fine. Syncd should not crash.
Signed-off-by: mlok <marty.lok@nokia.com>
Why I did it
This is to fix test_forward_ip_packet_with_0xffff_chksum_tolerant test failure on 720DT-48S. IP packets with checksum set to 0xffff will be forwarded with the same checksum on this platform, instead of updating to the correct value.
How I did it
Add bcm config sai_verify_incoming_chksum=0 so that checksum is updated instead of being left unchanged when checksum is 0xffff. Note that packets with invalid checksum are still dropped with this config.
Add missing system_ref_core_clock_khz in Arista-7800R3A-36D2-C36 and Arista-7800R3A-36D2-C72
Co-authored-by: Maxime Lorrillere <mlorrillere@arista.com>
Port indexes of front panel ports are not contiguous in multi-asic because we didn't distiguish between
front panel and internal ports, e.g., recycle ports. Fix this by assigning index to front panel port first
and then internal ports.
Co-authored-by: Song Yuan <64041228+ysmanman@users.noreply.github.com>
Add missing aggregate port_config.ini needed by sonic-mgmt
Concatenate the ASIC specific port_config.ini from device/arista/x86_64-arista_7800r3a_36d2_lc/Arista-7800R3A-36D2-C36/[01] to create the aggregate file.
This change is to disable the pcie firmware check done by Broadcom SAI. The change is needed for the Arista platform x86_64-arista_7050cx3_32s; otherwise, the check will fail, blocking the initialization.
There was a pcie firmware check added in brcm SDK and certain Arista hardwares do not compliant with the check, so we added the disable_pcie_firmware_check originally for x86_64-arista_7060dx4_32. For x86_64-arista_7050cx3_32s, it was able to pass the check but some firmware change done in August made it fail.
Why I did it:
Fix multiple seastone platform issues caused by sonic kernel upgrade.
How I did it:
Get gpio base id with new label path in gpio sys fs.
How to verify it:
After the change, show platform fan/psustatus/temperature works well.
Signed-off-by: Neetha John <nejo@microsoft.com>
Why I did it
ECN parameters need to be updated for storage backend
How I did it
Included the check for storage backend devices to update qos configs
How to verify it
Verified that the new ecn settings are applied on storage backend device.
Verified that the old ecn settings are applied for storage frontend, non storage frontend/backend devices
Why I did it
Added to allow test_crm_route to pass; the test tries to add a /126 ipv6 route and this change is required in order for the count of available routes to be updated correctly.
Why I did it
Some sonic-mgmt platform_tests/api were failing on the 7060CX-32S
How I did it
Added the missing metadata in platform.json and platform_components.json
This is purely test data and does not impact our API implementation.
How to verify it
Run platform_tests / api and expect 100% pass rate.
Why I did it
Some sonic-mgmt platform_tests/api were failing on the 7260CX3-64
How I did it
Added the missing metadata in platform.json and platform_components.json
This is purely test data and does not impact our API implementation.
How to verify it
Run platform_tests/api and expect 100% passrate.
Why I did it
The PR is to apply separated DSCP_TO_TC_MAP and TC_TO_QUEUE_MAP to uplink ports on dualtor.
The traffic with DSCP 2 and DSCP 6 from T1 is treated as lossless traffic.
DSCP TC Queue
2 2 2
6 6 6
Traffic with DSCP 2 or DSCP 6 from downlink is still treated as lossy traffic as before.
How I did it
Define DSCP_TO_TC_MAP|AZURE_UPLINK and TC_TO_QUEUE_MAP|AZURE_UPLINK.
How to verify it
Verified by UT
Verified by coping the new template to a testbed, and rendering a config_db.json
Signed-off-by: Neetha John <nejo@microsoft.com>
Why I did it
There is a need to have separate profiles on compute and storage and this infra update will help achieve that
How I did it
Moved buffer pool/profile and qos definitions on TD2 to a common folder and all TD2 hwsku's will reference that folder
Why I did it
TX FIR tuning should be done based on the type of inserted transceiver
How I did it
Add media_settings.json which contains the tuning data for 100G optic and 400G optic.
How to verify it
Tested against x86_64-arista_7800r3a_36d2_lc
- Why I did it
A new SKU for MSN4700 Platform i.e. Mellanox-SN4700-V16A96
Requirements:
Breakout:
Port 1-24: 4x25G(4)[10G,1G]
Port 25-28: 2x100G[200G,50G,40G,25G,10G,1G]
Port 29-32: 2x200G[100G,50G,40G,25G,10G,1G]
Downlinks: 96 (1-24) + 4 (25-28)
Uplinks: 4 (29-32)
Shared Headroom: Enabled
Over Subscribe Ratio: 1:4
Default Topology: T0
Default Cable Length for T1: 5m
VxLAN source port range set: No
Static Policy Based Hashing Supported: No
Additional Details:
QoS params: The default ones defined in qos_config.j2 will be applied
Small Packet Percentage: Used 50% for traditional buffer model Note: For dynamic model, the value defined in LOSSLESS_TRAFFIC_PATTERN|AZURE|small_packet_percentage is used
SKU was drafted under the assumption that the downlink ports uses xcvr's that will only support the first 4 lanes of the physical port they are connected to. Hence for the ports 1-24, the last four lanes are not used
Cable Lengths used for generating buffer_defaults_{t0,t1}.j2 values
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
A new SKU for MSN4700 Platform i.e. Mellanox-SN4700-V48C32
Requirements:
Breakout:
Port 1-24: 2x200G
Port 25-32: 4x100G
Downlinks: 48 (1-24)
Uplinks: 32 (25-32)
Shared Headroom: Enabled
Over Subscribe Ratio: 1:8
Default Topology: T1
Default Cable Length for T1: 300m
VxLAN source port range set: No
Static Policy Based Hashing Supported: No
Additional Details:
QoS params: The default ones defined in qos_config.j2 will be applied
Small Packet Percentage: Used 50% for traditional buffer model Note: For dynamic model, the value defined in LOSSLESS_TRAFFIC_PATTERN|AZURE|small_packet_percentage is used
Cable Lengths used for generating buffer_defaults_{t0,t1}.j2 values
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
- Why I did it
Add new sensor conf file to support respined platforms(SN3700/SN3700C/SN4600C)
- How I did it
Add new sensor conf
Update the get_sensors_conf_path scripts to apply the sensor conf according to the HW respin version info
- How to verify it
run platform test(including sensor test)
Signed-off-by: Kebo Liu <kebol@nvidia.com>
Why I did it
Fixes#12614
How I did it
In the container_checker the database_chassis is added to expected container if device is supervisor
To detect the device is superviso, add supervisor=1 to the platform_env.conf of 7808 sup platform
How to verify it
run container_checker monit check
Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>
#### Why I did it
To add new SKU Mellanox-SN2700-D44C10 with following requirements:
| Port configuration | Value |
| ------ |--------- |
| Breakout mode for each port |**Defined in port mapping** |
| Speed of the port | **Defined in Port mapping** |
| Auto-negotiation enable/disable | **No setting required** |
| FEC mode | **No setting required** |
|Type of transceiver used | **Not needed**|
Buffer configuration | Value
------ |---------
Shared headroom | **Enabled**
Shared headroom pool factor | **2**
Dynamic Buffer | **Disable**
In static buffer scenario how many uplinks and downlinks? | **44 x50G and 2x100G Downlinks 8x100G uplinks**
2km cable support required? | **No**
Switch configuration | Value
------ |---------
Warmboot enabled? | **yes**
Should warmboot be added to SAI profile when enabled? | **yes**
Is VxLAN source port range set? | **No**
Should Vxlan source port range be added to SAI profile when set. | **No**
Is Static Policy Based Hashing enabled? | **No**
Port Mapping
| Ports | Mode |
| ------ |--------- |
| 1,2 | 1x100G |
| 3-6 | 2x50G |
| 7-10 | 1x100G |
| 11-22 | 2x50G |
| 23-26 | 1x100G |
| 27-32 | 2x50G |
Number of Uplinks / Downlinks:
TO topology: **44 x50G and 2x100G Downlinks 8x100G uplinks**.
#### How I did it
Defined the SKU as per requirements
#### How to verify it
Load the SKU and verify if all links come up and traffic passes.
changed the platform device name under nokia directory; we now need to specify marvell armhf/arm64 to provide more accurate platform identity. otherwise onie discovery won't recognize the asic being installed.
Why I did it
when we load images using onie discovery, the process was failing because of marvell ASIC mismatch
How I did it
replace the platform asic with marvell-armhf under 7215
How to verify it
load a new image using http server and verify that the image can be loaded successfully
Why I did it
Add components data for sonic-mgmt testing
How I did it
Update platform.json and add platform_components.json
How to verify it
Ran sonic-mgmt tests (test_chassis and test_component)
