-
Notifications
You must be signed in to change notification settings - Fork 109
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
Run mstfwreset when applying config changes #449
Run mstfwreset when applying config changes #449
Conversation
Thanks for your PR,
To skip the vendors CIs use one of:
|
/cc @wizhaoredhat @SchSeba @adrianchiris @zeeke Can anyone PTAL? Small update that is blocking our work |
LGTM |
Related issue: Mellanox/mstflint#785 |
/cc @bn222 |
@SalDaniele Could you also describe the bootloop with the config-daemon we were seeing with the latest BF2 firmware in the PR description? |
we are currently not calling mstfwreset in sriov-network-config-daemon, why is this change needed ? |
@adrianchiris Although we aren't using mstfwreset here. The mstflint package as a whole does have pciutils as a dependency. We should add this dependency in. |
Without pciutils, we will get the following error message when running mstfwreset: Continue with reset?[y/N] y Failed -E- failed to run 'setpci -s 0000:c9:02.0 0x0.w'. The setpci command is part of the pciutils package. Signed-off-by: Salvatore Daniele <sdaniele@redhat.com>
b253c36
to
ec3ca85
Compare
Thanks for your PR,
To skip the vendors CIs use one of:
|
@adrianchiris I just added an additional commit to address the crux of the issue we are encountering. As of the most recent Bluefields2 firmware update (5-18-23) config changes are no longer applied on next boot as they have been previously. This requires us to call mstfwreset manually. Without doing so, we can end up in a boot loop, where a change is applied by the config daemon, the node reboots, the change is not reflected, etc. |
Pull Request Test Coverage Report for Build 5200424111
💛 - Coveralls |
ec3ca85
to
3847d7c
Compare
Thanks for your PR,
To skip the vendors CIs use one of:
|
As of the most recent update to the Bluefield2 firmware (v24.37.1300) configuration changes no longer are applied on node reboot without running mstfwreset(). This can result in a node ending up in a bootloop when applying a new configuration. i.e. a sriov-workload-node-policy if applied to updated total vfs. This change is applied via mstconfig, however the change is not reflected in NUM_OF_VFS without running mstfwreset(). This resulted in a repeated call to reboot I0523 20:59:44.059046 7496 mellanox_plugin.go:335] Changing TotalVfs 16 to 12, needs reboot I0523 20:59:44.059057 7496 mellanox_plugin.go:172] mellanox-plugin needDrain true needReboot true Signed-off-by: Salvatore Daniele <sdaniele@redhat.com>
3847d7c
to
2d8391d
Compare
Thanks for your PR,
To skip the vendors CIs use one of:
|
LGTM |
if err := configFW(); err != nil { | ||
return err | ||
} | ||
if err := resetFW(); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
im not too keen on always running mstfwreset, perhaps only for DPUs in Embedded mode ?
i need to think about it a bit more
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also for DPU you need to run with --reset-sync=1 flag.
see:
https://docs.nvidia.com/networking/pages/viewpage.action?pageId=52009175
with current implementation, does it work for u ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aahh good to know. I was testing the current implementation on a cluster w/ the BF in NIC mode, which was working. The issue I was seeing was not specific to running in DPU embedded mode, the node would get stuck in a bootloop if I applied a policy to change the number of vfs, since after rebooting the updated configuration would not be applied, triggering another reboot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, you encountered the issue with DPU in NIC mode as well ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding since submitting this patch is that this is not intended behavior by Nvidia and a firmware patch will come in July to address this issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue is that the behavior of NIC mode changed too and is broken in a similar to DPU. With DPU mode --sync 1 causes the DPU to hang. I have code that adds --sync 1
but I want it to work correctly before pushing the changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding since submitting this patch is that this is not intended behavior by Nvidia and a firmware patch will come in July to address this issue.
that is correct, its a bug and Nvidia should fix the firmware.
@SalDaniele in that case, i think this PR is no longer required and can be closed ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes provided this fix is in the next firmware release, we can close this PR
PR is not needed, see discussion above |
As of the most recent update to the Bluefield2 firmware (v24.37.1300)
configuration changes no longer are applied on node reboot without
running mstfwreset().
This can result in a node ending up in a bootloop when applying a new
configuration.
i.e. a sriov-workload-node-policy if applied to updated total vfs. This
change is applied via mstconfig, however the change is not reflected in
NUM_OF_VFS without running mstfwreset(). This resulted in a repeated
call to reboot.
Signed-off-by: Salvatore Daniele sdaniele@redhat.com