This PR includes necessary changes for correct generating BUFFER_QUEUE values in DB. Changes are based on the schema.md
Why I did it
Change format of generating BUFFER_QUEUE in DB according to schema.md and yang-model.
Old format:
"BUFFER_QUEUE": {
"Ethernet0,Ethernet100,Ethernet104,Ethernet108,Ethernet112,Ethernet116,Ethernet12,Ethernet120,Ethernet124,Ethernet16,Ethernet20,Ethernet24,Ethernet28,Ethernet32,Ethernet36,Ethernet4,Ethernet40,Ethernet44,Ethernet48,Ethernet52,Ethernet56,Ethernet60,Ethernet64,Ethernet68,Ethernet72,Ethernet76,Ethernet8,Ethernet80,Ethernet84,Ethernet88,Ethernet92,Ethernet96|queue": {
"profile": "profile"
},
"Ethernet0,Ethernet100,Ethernet104,Ethernet108,Ethernet112,Ethernet116,Ethernet12,Ethernet120,Ethernet124,Ethernet16,Ethernet20,Ethernet24,Ethernet28,Ethernet32,Ethernet36,Ethernet4,Ethernet40,Ethernet44,Ethernet48,Ethernet52,Ethernet56,Ethernet60,Ethernet64,Ethernet68,Ethernet72,Ethernet76,Ethernet8,Ethernet80,Ethernet84,Ethernet88,Ethernet92,Ethernet96|queue": {
"profile": "profile"
}
},
New format:
"BUFFER_QUEUE": {
"Ethernet0|queue": {
"profile": "profile"
},
"Ethernet0|queue": {
"profile": "profile"
},
"Ethernet4|queue": {
"profile": "profile"
},
"Ethernet4|queue": {
"profile": "profile"
},
"Ethernet8|queue": {
"profile": "profile"
},
"Ethernet8|queue": {
"profile": "profile"
},
...
}
How I did it
Updated structure of buffers_defaults jinja templates.
Signed-off-by: Oleksandr Kozodoi <oleksandrx.kozodoi@intel.com>
* [BFN] Implementation API for platform component
SONiC has a concept of "platform components"
this may include - CPLD, FPGA, BIOS, BMC, etc.
These changes are needed to read the version of the BIOS and BMC component.
What I did
Create components.py module
Add funcion for reading componet version to thrift interface
How I did it
The previous implementaion didn't have platform components API, so fwutil return an empty list.
After implementation of the platform component API, we have actual list of platform components and firmware versions
How to verify it
Run manually 'fwutil show status' or run unit tests
Previous command output
Chassis Module Component Version Description
------------------------ -------- ----------- --------- -------------
New command output
Chassis Module Component Version Description
------------------------ -------- ----------- --------- -------------
Chassis1 N/A BIOS 1.2.3 Chassis BIOS
BMC 5.1 Chassis BMC
Signed-off-by: Taras Keryk <tarasx.keryk@intel.com>
* [BFN] Implementation API for platform component
SONiC has a concept of "platform components"
this may include - CPLD, FPGA, BIOS, BMC, etc.
These changes are needed to read the version of the BIOS and BMC component.
What I did
Create components.py module
Add funcion for reading componet version to thrift interface
How I did it
The previous implementaion didn't have platform components API, so fwutil return an empty list.
After implementation of the platform component API, we have actual list of platform components and firmware versions
How to verify it
Run manually 'fwutil show status' or run unit tests
Previous command output
Chassis Module Component Version Description
------------------------ -------- ----------- --------- -------------
New command output
Chassis Module Component Version Description
------------------------ -------- ----------- --------- -------------
Chassis1 N/A BIOS 1.2.3 Chassis BIOS
BMC 5.1 Chassis BMC
Signed-off-by: Taras Keryk <tarasx.keryk@intel.com>
* [BFN] Implementation API for platform component
get chassis name from json
* [BFN] Implementation API for platform component
Updated platform and platrom_components json
* [BFN] Implementation API for platform component
Fixed spaces in component.py
* [BFN] Implementation API for platform component
Fixed exception in component.py
* Update chassis.py
* [BFN] Implementation API for platform component
Fixed spaces in component.py, chassis.py
* [BFN] Implementation API for platform component: Fixed spaces in component.py, chassis.py
* Fixed exception in get_bios_version
Why I did it
For sonic-mgmt Platform API tests to have data to compare with
How I did it
updated platform info for device x86_64-accton_wedge100bf_32x-r0
How to verify it
Run sonic-mgmt Platform API tests get_name fo:
chassis
fans
fan_drawers
psus
thermals
#### Why I did it
Add platform_asic file to each platform folder in sonic-device-data package. The file content will be used as the ground truth of mapping from PLATFORM_STRING to switch ASIC family.
One use case of the mapping is to prevent installing a wrong image, which targets for other ASIC platforms. For example, currently we have several ONIE images naming as sonic-*.bin, it's easy to mistakenly install the wrong image. With this mapping built into image, we could fetch the ONIE platform string, and figure out which ASIC it is using, and check we are installing the correct image.
After this PR merged, each platform vendor has to add one mandatory text file `device/PLATFORM_VENDOR/PLATFORM_STRING/platform_asic`, with the content of the platform's switch ASIC family.
I will update https://github.com/Azure/SONiC/wiki/Porting-Guide after this PR is merged.
You can get a list of the ASIC platforms by `ls -b platform | cat`. Currently the options are
```
barefoot
broadcom
cavium
centec
centec-arm64
generic
innovium
marvell
marvell-arm64
marvell-armhf
mellanox
nephos
p4
vs
```
Also support
```
broadcom-dnx
```
#### How I did it
#### How to verify it
Test one image on DUT. And check the folders under `/usr/share/sonic/device`
Depends on Azure/sonic-utilities#1626
Depends on Azure/sonic-swss#1754
QOS tables in config db used ABNF format i.e "[TABLE_NAME|name] to refer fieldvalue to other qos tables.
Example:
Config DB:
"Ethernet92|3": {
"scheduler": "[SCHEDULER|scheduler.1]",
"wred_profile": "[WRED_PROFILE|AZURE_LOSSLESS]"
},
"Ethernet0|0": {
"profile": "[BUFFER_PROFILE|ingress_lossy_profile]"
},
"Ethernet0": {
"dscp_to_tc_map": "[DSCP_TO_TC_MAP|AZURE]",
"pfc_enable": "3,4",
"pfc_to_queue_map": "[MAP_PFC_PRIORITY_TO_QUEUE|AZURE]",
"tc_to_pg_map": "[TC_TO_PRIORITY_GROUP_MAP|AZURE]",
"tc_to_queue_map": "[TC_TO_QUEUE_MAP|AZURE]"
},
This format is not consistent with other DB schema followed in sonic.
And also this reference in DB is not required, This is taken care by YANG "leafref".
Removed this format from all platform files to consistent with other sonic db schema.
Example:
"Ethernet92|3": {
"scheduler": "scheduler.1",
"wred_profile": "AZURE_LOSSLESS"
},
Dependent pull requests:
#7752 - To modify platfrom files
#7281 - Yang model
Azure/sonic-utilities#1626 - DB migration
Azure/sonic-swss#1754 - swss change to remove ABNF format
What I did:
add platform components
How I did it:
In platform_components.json add chassis and empty component
How to verify it:
Run show platform firmware updates
#### Why I did it
To get rid of obsolete code
#### How I did it
Removed plugins folder from device/barefoot
Signed-off-by: Volodymyr Boyko <volodymyrx.boiko@intel.com>
Dynamic Port Breakout fall in case "autoneg" field exist in config_db.
- How I did it
Added "autoneg" field in sonic-port yang model.
- How to verify it
Add "autoneg" field into config_db like this:
"Ethernet8": {
"index": "2",
"lanes": "8,9,10,11",
"fec": "rs",
"pfc_asym": "off",
"mtu": "9100",
"alias": "Ethernet8",
"admin_status": "up",
"autoneg": "on",
"speed": "100000",
},
To fix [DPB| wrong aliases for interfaces](https://github.com/Azure/sonic-buildimage/issues/6024) issue, implimented flexible alias support [design doc](https://github.com/Azure/SONiC/pull/749)
> [[dpb|config] Fix the validation logic of breakout mode](https://github.com/Azure/sonic-utilities/pull/1440) depends on this
#### How I did it
1. Removed `"alias_at_lanes"` from port-configuration file(i.e. platfrom.json)
2. Added dictionary to "breakout_modes" values. This defines the breakout modes available on the platform for this parent port, and it maps to the alias list. The alias list presents the alias names for individual ports in order under this breakout mode.
```
{
"interfaces": {
"Ethernet0": {
"index": "1,1,1,1",
"lanes": "0,1,2,3",
"breakout_modes": {
"1x100G[40G]": ["Eth1"],
"2x50G": ["Eth1/1", "Eth1/2"],
"4x25G[10G]": ["Eth1/1", "Eth1/2", "Eth1/3", "Eth1/4"],
"2x25G(2)+1x50G(2)": ["Eth1/1", "Eth1/2", "Eth1/3"],
"1x50G(2)+2x25G(2)": ["Eth1/1", "Eth1/2", "Eth1/3"]
}
}
}
```
#### How to verify it
`config interface breakout`
Signed-off-by: Sangita Maity <samaity@linkedin.com>
Y* profile is the name pattern for p4 programs that developed for the current platform. The difference between them is features enabled and resource reservation.
For this platform, it is expected to work on any Y profile. but after the latest changes, the first Y profile is always used.
Submodule updates include the following commits:
* src/sonic-utilities 9dc58ea...f9eb739 (18):
> Remove unnecessary calls to str.encode() now that the package is Python 3; Fix deprecation warning (#1260)
> [generate_dump] Ignoring file/directory not found Errors (#1201)
> Fixed porstat rate and util issues (#1140)
> fix error: interface counters is mismatch after warm-reboot (#1099)
> Remove unnecessary calls to str.decode() now that the package is Python 3 (#1255)
> [acl-loader] Make list sorting compliant with Python 3 (#1257)
> Replace hard-coded fast-reboot with variable. And some typo corrections (#1254)
> [configlet][portconfig] Remove calls to dict.has_key() which is not available in Python 3 (#1247)
> Remove unnecessary conversions to list() and calls to dict.keys() (#1243)
> Clean up LGTM alerts (#1239)
> Add 'requests' as install dependency in setup.py (#1240)
> Convert to Python 3 (#1128)
> Fix mock SonicV2Connector in python3: use decode_responses mode so caller code will be the same as python2 (#1238)
> [tests] Do not trim from PATH if we did not append to it; Clean up/fix shebangs in scripts (#1233)
> Updates to bgp config and show commands with BGP_INTERNAL_NEIGHBOR table (#1224)
> [cli]: NAT show commands newline issue after migrated to Python3 (#1204)
> [doc]: Update Command-Reference.md (#1231)
> Added 'import sys' in feature.py file (#1232)
* src/sonic-py-swsssdk 9d9f0c6...1664be9 (2):
> Fix: no need to decode() after redis client scan, so it will work for both python2 and python3 (#96)
> FieldValueMap `contains`(`in`) will also work when migrated to libswsscommon(C++ with SWIG wrapper) (#94)
- Also fix Python 3-related issues:
- Use integer (floor) division in config_samples.py (sonic-config-engine)
- Replace print statement with print function in eeprom.py plugin for x86_64-kvm_x86_64-r0 platform
- Update all platform plugins to be compatible with both Python 2 and Python 3
- Remove shebangs from plugins files which are not intended to be executable
- Replace tabs with spaces in Python plugin files and fix alignment, because Python 3 is more strict
- Remove trailing whitespace from plugins files
- Updated buffers config;
- Set eth2 as CPU port;
- Added systemd service file to load bf_fpga.ko
Signed-off-by: Andriy Kokhan <akokhan@barefootnetworks.com>
* Fixed initial state for eeprom.py and sfputil.py when thrift server is down
* Added transceiver plug-in/out event processing
Signed-off-by: Andriy Kokhan <akokhan@barefootnetworks.com>
Added exceptions handling for BFN psuutil.py and eeprom.py which are raised when syseepromd and psud try to connect to the BFN thrift server which is not up yet. Now the exceptions backtrace is not logged to the syslog. Also psud doesn't exit on system bootup due to uncaught exception.
Signed-off-by: Vitaliy Senchyshyn <vsenchyshyn@barefootnetworks.com>
