Added support for bind/unbind sx_core #9
Merged
Conversation
This file contains 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
vadimp-nvidia
added a commit
that referenced
this pull request
Dec 2, 2020
… Ethernet system Add initial chassis management support for Nvidia modular Ethernet switch systems MSN4800, providing a high performance switching solution for Enterprise Data Centers (EDC) for building Ethernet based clusters, High-Performance Computing (HPC) and embedded environments. This system could be equipped with the different types of replaceable line cards and management board. The first system flavor will support the line card type MSN4800-C16 equipped with Lattice CPLD devices aimed for system and ASIC control, one Nvidia FPGA for gearboxes (PHYs) management, and four Nvidia gearboxes for the port control and with 16x100GbE QSFP28 ports and also with various devices for electrical control. The system is equipped with eight slots for line cards, four slots for power supplies and six slots for fans. It could be configured as fully populated or with even only one line card. The line cards are hot-pluggable. In the future when more line card flavors are to be available (for example line cards with 8x200Gb Eth port, with 4x400 Eth ports, or with some kind of smart cards for offloading purpose), any type of line card could be inserted at any slot. The system is based on Nvidia Spectrum-3 ASIC. The switch height is 4U and it fits standard rack size. Whenever a line card is enabled (inserted, verified, powered on, configured by firmware), all the ports, thermal control, hardware monitoring and cables related objects should be dynamically created. Whenever a line card is disabled (put in reset state, powered off, removed) all these objects should be removed. The patchset provides initial support for system management. It extends functionality of thermal control, hardware monitoring, cable QSFP access, while all these objects are located within the line card. mlxsw: reg: Extend MTMP register with new slot number field Extend MTMP (Management Temperature Register) with new field specifying the slot number. The purpose of this field is to support access to MTMP register for reading temperature sensors on modular system. For '1U' systems the 'sensor_index' uniquely identifies the cage sensors, while 'slot_index' is always 0. For modular systems the sensors are identified by: - 'slot_index', specifying the slot number, where line card is located; - 'sensor_index', specifying cage sensor within the line card. mlxsw: reg: Extend MTBR register with new slot number field Extend MTBR (Management Temperature Bulk Register) with new field specifying the slot number. The purpose of this field is to support access to MTBR register for reading temperature sensors on modular system. For '1U' systems the 'sensor_index' uniquely identifies the cage sensors. For modular systems the sensors are identified by two indexes: - 'slot_index', specifying the slot number, where line card is located; - 'sensor_index', specifying cage sensor within the line card. mlxsw: reg: Extend MCIA register with new slot number field Extend MCIA (Management Cable Info Access Register) with new field specifying the slot number. The purpose of this field is to support access to MCIA register for reading cage cable information on modular system. For '1U' systems the 'module' number uniquely identifies the transceiver location. For modular systems the transceivers are identified by two indexes: - 'slot_index', specifying the slot number, where line card is located; - 'module', specifying cage transceiver within the line card. mlxsw: reg: Extend MGPIR register with new slot number field Extend MGPIR (Management General Peripheral Information Register) with new field specifying the slot number. The purpose of this field is to support access to MPGIR register on modular system for getting the number of cage, equipped on the line card, inserted at specified slot. In case slot number is set zero, MGPIR will provide the information for the main board. For Top of the Rack (non-modular) system it will provide the same as before. mlxsw: core_hwmon: Fix variable names for hwmon attributes Replace all local variables 'mlwsw_hwmon_attr' by 'mlxsw_hwmon_attr'. All variable prefixes should start with 'mlxsw' according to the naming convention, so 'mlwsw' is changed to 'mlxsw'. mlxsw: core_hwmon: Split gearbox initialization Split gearbox initialization in two routines - the first one is to be used for gearbox configuration validation, the second for creation of gearbox related 'hwmon' attributes if any. Currently, mlxsw supports gearbox hwmon attributes corresponding to the objects discovered on the main board. Same hwmon attributes could be also discovered on line cards. While the initialization flow for main board and for line cards is the same, the configuration flow is different. The purpose of this patch is to allow reusing of initialization flow by main board and line cards. mlxsw: core_hwmon: Extend internal structures to support multi hwmon objects Currently, mlxsw supports a single hwmon device and registers it with attributes corresponding to the various objects found on the main board such as fans and gearboxes. Line cards can have the same objects, but unlike the main board they can be added and removed while the system is running. The various hwmon objects found on these line cards should be created when the line card becomes available and destroyed when the line card becomes unavailable. The above can be achieved by representing each line card as a different hwmon device and registering / unregistering it when the line card becomes available / unavailable. Prepare for multi hwmon device support by splitting 'struct mlxsw_hwmon' into 'struct mlxsw_hwmon' and 'struct mlxsw_hwmon_dev'. The first will hold information relevant to all hwmon devices, whereas the second will hold per-hwmon device information. mlxsw: core_hwmon: Introduce slot parameter in hwmon interfaces Add 'slot' parameter to 'mlxsw_hwmon_dev' structure. Use this parameter in mlxsw_reg_mtmp_pack(), mlxsw_reg_mtbr_pack() and Use mlxsw_reg_mtmp_slot_index_set() routines. For main board it'll always be zero, for line cards it'll be set to the physical slot number in modular systems. mlxsw: core_hwmon: Extend hwmon device with gearbox mapping field Add gearbox mapping field to 'mlxsw_hwmon_dev' structure. It should provide the mapping for gearbox sensor indexes, given gearbox number. For main board mapping is supposed to be always sequential, while for line cards on modular system it could be non-sequential. mlxsw: core_thermal: Extend internal structures to support multi thermal areas Introduce intermediate level for thermal zones areas. Currently all thermal zones are associated with thermal objects located within the main board. Such objects are created during driver initialization and removed during driver de-initialization. For line cards in modular system the thermal zones are to be associated with the specific line card. They should be created whenever new line card is available (inserted, validated, powered and enabled) and removed, when line card is getting unavailable. The thermal objects found on the line card #n are accessed by setting slot index to #n, while for access to objects found on the main board slot index should be set to default value zero. Each thermal area contains the set of thermal zones associated with particular slot index. Thus introduction of thermal zone areas allows to use the same APIs for the main board and line cards, by adding slot index argument. mlxsw: core_thermal: Introduce slot argument in thermal interfaces Add 'slot_index' argument to 'mlxsw_thermal_module' and 'mlxsw_thermal_area' structures. Use it in mlxsw_reg_mtmp_pack() for setting slot number for the thermal zones associated with the cages and gearboxes. For main board it'll be always zero, for line cards it'll be set to the physical slot number in modular systems. The thermal zones associated with ASIC ambient temperatures should be always accessed with slot zero - main thermal zone. mlxsw: core: Extend interfaces for cable info access with slot argument Extend APIs mlxsw_env_get_module_eeprom(), mlxsw_env_get_module_info() used for reading cable information with slot index argument. Extend API mlxsw_env_init() used for environment initialization with slot index argument. For main board slot will be always set to zero and these APIs will work as before. If reading cable information is required from the cages located on line card, slot should be set to the physical slot number, where line card is located in modular systems. mlxsw: minimal: Extend port structure with slot index field A number of registers have been extended with 'slot_index' field for line card support. The purpose of this field is to indicate the location of the port, so that it could be used when trying to read module info. For main board it'll always be zero, for line cards it'll be set to the physical slot number at which line card is located. For now the slot index is always 0. That is, ports are still not instantiated from line cards. Add 'slot_index' field to 'mlxsw_m_port' structure. Use it for module info access. mlxsw: core_thermal: Rename labels according to naming convention Rename labels for error flow handling in order to align with naming convention used in rest 'mlxsw' code. mlxsw: core_thermal: Split gearbox initialization Split gearbox initialization in two routines - the first one is to be used for gearbox configuration validation, the second for creation of gearbox related thermal zones if any. Currently, mlxsw supports gearbox thermal zones corresponding to the main board. For system equipped with the line cards assembled with the gearboxes, thermal zones will be associated with the gearboxes found on those line cards. While the initialization flow for main board and for line cards is the same, the configuration flow is different. The purpose of this patch is to allow reusing of initialization flow by main board and line cards. mlxsw: core_thermal: Extend thermal area with gearbox mapping field Add gearbox mapping field 'gearbox_sensor_map' to 'mlxsw_thermal_module' structure. It should provide the mapping for gearbox sensor indexes, given gearbox number. For main board mapping is supposed to be always sequential, while for line cards on modular system it could be non-sequential. mlxsw: core_thermal: Add line card id prefix to line card thermal zone name Add prefix "lc#n" to thermal zones associated with the thermal objects found on line cards. For example thermal zone for module #9 located at line card #7 will have type: mlxsw-lc7-module9. And thermal zone for gearbox #3 located at line card #5 will have type: mlxsw-lc5-gearbox3. mlxsw: core_hwmon: Add line card id prefix to line card label attribute names Add prefix "linecard#n" to 'hwmon' label attributes for the 'hwmon' objects found on the line cards. For example cage temperature for module #9 located at line card #7 will be exposed by utility 'sensors' like: linecard#07 front panel 009: +32.0°C (crit = +70.0°C, emerg = +80.0°C) And temperature for gearbox #3 located at line card #5 will be exposed like: linecard#05 gearbox 003: +41.0°C (highest = +41.0°C) For now the slot index is always 0 and field 'name' of the structure 'mlxsw_hwmon_dev' is empty. For line card this field is supposed to be initialized to 'linecard#n', when line card in slot #n is enabled. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
vadimp-nvidia
added a commit
that referenced
this pull request
Feb 28, 2021
… and thermal Add line card thermal area registration and de-registration interfaces to thermal initialization/de-initialization flows. Add callback for line card thermal area activation and de-activation. These callbacks are to be invoked, when firmware indicates it got active or inactive state. When "active event" is received for particular line card, its thermal interfaces should be configured according to the configuration obtained from the firmware. When opposite "inactive event" is received all these interfaces should be removed. Each line card is associated with the relevant thermal area, which may contain thermal zones for cages and gearboxes found on this line card. For example thermal zone for module #9 located at line card #7 will have type: mlxsw-lc7-module9. And thermal zone for gearbox #2 located at line card #5 will have type: mlxsw-lc5-gearbox2. Add line card 'hwmon' registration and de-registration interfaces to 'hwmon' initialization/de-initialization flows. Add callback for line card 'hwmon' objects activation and de-activation. These callbacks are to be invoked, when firmware indicates it got active or inactive state. When "active event" is received for particular line card, its 'hwmon' interfaces should be configured according to the configuration obtained from the firmware. When opposite "inactive event" is received all these interfaces should be removed. Each line card is associated with the relevant 'hwmon' devices, which may contain thermal attributes for the cages and gearboxes found on this line card. For example cage temperature for module #9 located at line card #7 will be exposed by utility 'sensors' like: linecard#07 front panel 009: +32.0°C (crit = +70.0°C, emerg = +80.0°C) And temperature for gearbox #3 located at line card #5 will be exposed like: linecard#05 gearbox 003: +41.0°C (highest = +41.0°C) Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
vadimp-nvidia
added a commit
that referenced
this pull request
Feb 28, 2021
… and thermal Add line card thermal area registration and de-registration interfaces to thermal initialization/de-initialization flows. Add callback for line card thermal area activation and de-activation. These callbacks are to be invoked, when firmware indicates it got active or inactive state. When "active event" is received for particular line card, its thermal interfaces should be configured according to the configuration obtained from the firmware. When opposite "inactive event" is received all these interfaces should be removed. Each line card is associated with the relevant thermal area, which may contain thermal zones for cages and gearboxes found on this line card. For example thermal zone for module #9 located at line card #7 will have type: mlxsw-lc7-module9. And thermal zone for gearbox #2 located at line card #5 will have type: mlxsw-lc5-gearbox2. Add line card 'hwmon' registration and de-registration interfaces to 'hwmon' initialization/de-initialization flows. Add callback for line card 'hwmon' objects activation and de-activation. These callbacks are to be invoked, when firmware indicates it got active or inactive state. When "active event" is received for particular line card, its 'hwmon' interfaces should be configured according to the configuration obtained from the firmware. When opposite "inactive event" is received all these interfaces should be removed. Each line card is associated with the relevant 'hwmon' devices, which may contain thermal attributes for the cages and gearboxes found on this line card. For example cage temperature for module #9 located at line card #7 will be exposed by utility 'sensors' like: linecard#07 front panel 009: +32.0°C (crit = +70.0°C, emerg = +80.0°C) And temperature for gearbox #3 located at line card #5 will be exposed like: linecard#05 gearbox 003: +41.0°C (highest = +41.0°C) Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Reviewed-by: Vadim Pasternak vadimp@mellanox.com