Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Mellanox]PSU sensors dynamic configuration #18528

Merged
merged 3 commits into from
Jun 11, 2024

Conversation

yuazhe
Copy link
Contributor

@yuazhe yuazhe commented Apr 2, 2024

Why I did it

Previously, the PSU sensor configuration inside sensors.conf is hardcoded for each platform, allowing no flexibility for other PSU combination possibilities. However, there exists a scenario that user has a second source of PSU which has different sensors compared to the original sensors.conf. Thereby it requires the system to have the ability to dynamically detect the PSU model in using and load relevant sensor’s configuration file.

How I did it

This PR involves a new script and a corresponding data file which contains all PSU model’s sensor configuration info. The script reads the hardware PSU information through hw-management and determines its model. Based on that, it searches for the corresponding pre-defined PSU sensor data, integrate them into the sensors.conf, and let PMON copy it for further loading by lm-sensor.

It also integrates the script inside the platform's get_model() API. Therefore, each time this API is called by the psud code, it checks whether there has been a change in the PSU model. If a change is detected, it updates the PSU sensors configuration by calling the script.

How to verify it

use sensors command and check the psu section is rightly labeled.

Which release branch to backport (provide reason below if selected)

  • 201811
  • 201911
  • 202006
  • 202012
  • 202106
  • 202111
  • 202205
  • 202211
  • 202305

Tested branch (Please provide the tested image version)

  • 202311

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

@yuazhe yuazhe force-pushed the psu_sensors_dynamic_config branch 4 times, most recently from 482cb5d to 0fd69b7 Compare April 12, 2024 03:05
@yuazhe yuazhe marked this pull request as ready for review April 15, 2024 01:31
@yuazhe yuazhe requested a review from lguohan as a code owner April 15, 2024 01:31
@yuazhe
Copy link
Contributor Author

yuazhe commented Apr 15, 2024

/azpw run Azure.sonic-buildimage

@mssonicbld
Copy link
Collaborator

/AzurePipelines run Azure.sonic-buildimage

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@keboliu keboliu requested a review from prgeor April 15, 2024 10:16
@yuazhe yuazhe force-pushed the psu_sensors_dynamic_config branch from 0fd69b7 to 1060d66 Compare April 16, 2024 03:30
@yuazhe yuazhe force-pushed the psu_sensors_dynamic_config branch from db8c1f1 to 1060d66 Compare April 29, 2024 02:47
@yuazhe yuazhe force-pushed the psu_sensors_dynamic_config branch 2 times, most recently from 1f70f0e to aa1f312 Compare May 9, 2024 05:11
@yuazhe
Copy link
Contributor Author

yuazhe commented May 15, 2024

/AzurePipelines run Azure.sonic-buildimage

Copy link

Commenter does not have sufficient privileges for PR 18528 in repo sonic-net/sonic-buildimage

@yuazhe
Copy link
Contributor Author

yuazhe commented May 15, 2024

/azpw run Azure.sonic-buildimage

@mssonicbld
Copy link
Collaborator

/AzurePipelines run Azure.sonic-buildimage

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@yuazhe yuazhe force-pushed the psu_sensors_dynamic_config branch from 9413eb3 to 33e3d9b Compare May 16, 2024 01:38
Copy link
Collaborator

@liat-grozovik liat-grozovik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but you are missing recent new device SN5400. Please add the relevant changes to this device as well

Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
@yuazhe
Copy link
Contributor Author

yuazhe commented May 17, 2024

LGTM but you are missing recent new device SN5400. Please add the relevant changes to this device as well

I have updated relevant changes according to SN5400 sensor configuration file.

@yuazhe
Copy link
Contributor Author

yuazhe commented May 22, 2024

/azpw ms_conflict

yuazhe added 2 commits May 22, 2024 12:24
add a script to dynamically update the original sensors.conf psu section
to match the currently used psu model.

add a json file to store related platform and psu info.

simx revision is irrelevant, so there is no change on it.

Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
once the get_model api detect a psu model changing, it would firstly
regenerate sensors.conf and then restart sensord to active the new
configuration.

Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
@yuazhe yuazhe force-pushed the psu_sensors_dynamic_config branch from d6d9dfb to 2f12d00 Compare May 22, 2024 09:24
@liushilongbuaa
Copy link
Contributor

/azpw ms_conflict -f

@liat-grozovik liat-grozovik merged commit c57ac68 into sonic-net:master Jun 11, 2024
20 checks passed
mssonicbld pushed a commit to mssonicbld/sonic-buildimage that referenced this pull request Jun 12, 2024
- Why I did it
Previously, the PSU sensor configuration inside sensors.conf is hardcoded for each platform, allowing no flexibility for other PSU combination possibilities. However, there exists a scenario that user has a second source of PSU which has different sensors compared to the original sensors.conf. Thereby it requires the system to have the ability to dynamically detect the PSU model in using and load relevant sensor’s configuration file.

- How I did it
This PR involves a new script and a corresponding data file which contains all PSU model’s sensor configuration info. The script reads the hardware PSU information through hw-management and determines its model. Based on that, it searches for the corresponding pre-defined PSU sensor data, integrate them into the sensors.conf, and let PMON copy it for further loading by lm-sensor.

It also integrates the script inside the platform's get_model() API. Therefore, each time this API is called by the psud code, it checks whether there has been a change in the PSU model. If a change is detected, it updates the PSU sensors configuration by calling the script.

- How to verify it
use sensors command and check the psu section is rightly labeled.

Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
@mssonicbld
Copy link
Collaborator

Cherry-pick PR to 202405: #19291

mssonicbld pushed a commit that referenced this pull request Jun 15, 2024
- Why I did it
Previously, the PSU sensor configuration inside sensors.conf is hardcoded for each platform, allowing no flexibility for other PSU combination possibilities. However, there exists a scenario that user has a second source of PSU which has different sensors compared to the original sensors.conf. Thereby it requires the system to have the ability to dynamically detect the PSU model in using and load relevant sensor’s configuration file.

- How I did it
This PR involves a new script and a corresponding data file which contains all PSU model’s sensor configuration info. The script reads the hardware PSU information through hw-management and determines its model. Based on that, it searches for the corresponding pre-defined PSU sensor data, integrate them into the sensors.conf, and let PMON copy it for further loading by lm-sensor.

It also integrates the script inside the platform's get_model() API. Therefore, each time this API is called by the psud code, it checks whether there has been a change in the PSU model. If a change is detected, it updates the PSU sensors configuration by calling the script.

- How to verify it
use sensors command and check the psu section is rightly labeled.

Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
arun1355492 pushed a commit to arun1355492/sonic-buildimage that referenced this pull request Jul 26, 2024
- Why I did it
Previously, the PSU sensor configuration inside sensors.conf is hardcoded for each platform, allowing no flexibility for other PSU combination possibilities. However, there exists a scenario that user has a second source of PSU which has different sensors compared to the original sensors.conf. Thereby it requires the system to have the ability to dynamically detect the PSU model in using and load relevant sensor’s configuration file.

- How I did it
This PR involves a new script and a corresponding data file which contains all PSU model’s sensor configuration info. The script reads the hardware PSU information through hw-management and determines its model. Based on that, it searches for the corresponding pre-defined PSU sensor data, integrate them into the sensors.conf, and let PMON copy it for further loading by lm-sensor.

It also integrates the script inside the platform's get_model() API. Therefore, each time this API is called by the psud code, it checks whether there has been a change in the PSU model. If a change is detected, it updates the PSU sensors configuration by calling the script.

- How to verify it
use sensors command and check the psu section is rightly labeled.

Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
mssonicbld pushed a commit to mssonicbld/sonic-buildimage that referenced this pull request Aug 2, 2024
- Why I did it
Previously, the PSU sensor configuration inside sensors.conf is hardcoded for each platform, allowing no flexibility for other PSU combination possibilities. However, there exists a scenario that user has a second source of PSU which has different sensors compared to the original sensors.conf. Thereby it requires the system to have the ability to dynamically detect the PSU model in using and load relevant sensor’s configuration file.

- How I did it
This PR involves a new script and a corresponding data file which contains all PSU model’s sensor configuration info. The script reads the hardware PSU information through hw-management and determines its model. Based on that, it searches for the corresponding pre-defined PSU sensor data, integrate them into the sensors.conf, and let PMON copy it for further loading by lm-sensor.

It also integrates the script inside the platform's get_model() API. Therefore, each time this API is called by the psud code, it checks whether there has been a change in the PSU model. If a change is detected, it updates the PSU sensors configuration by calling the script.

- How to verify it
use sensors command and check the psu section is rightly labeled.

Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
@mssonicbld
Copy link
Collaborator

Cherry-pick PR to 202311: #19801

mssonicbld pushed a commit that referenced this pull request Aug 3, 2024
- Why I did it
Previously, the PSU sensor configuration inside sensors.conf is hardcoded for each platform, allowing no flexibility for other PSU combination possibilities. However, there exists a scenario that user has a second source of PSU which has different sensors compared to the original sensors.conf. Thereby it requires the system to have the ability to dynamically detect the PSU model in using and load relevant sensor’s configuration file.

- How I did it
This PR involves a new script and a corresponding data file which contains all PSU model’s sensor configuration info. The script reads the hardware PSU information through hw-management and determines its model. Based on that, it searches for the corresponding pre-defined PSU sensor data, integrate them into the sensors.conf, and let PMON copy it for further loading by lm-sensor.

It also integrates the script inside the platform's get_model() API. Therefore, each time this API is called by the psud code, it checks whether there has been a change in the PSU model. If a change is detected, it updates the PSU sensors configuration by calling the script.

- How to verify it
use sensors command and check the psu section is rightly labeled.

Signed-off-by: Yuanzhe, Liu <yualiu@nvidia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants