Fix BlueField2 SR-IOV configuration #240
Conversation
|
Thanks for your PR,
To skip the vendors CIs use one of:
|
e0ne
force-pushed
the
bf2-configuration
branch
from
226ec73 to
dd85271
Compare
|
Thanks for your PR,
To skip the vendors CIs use one of:
|
This patch fixes current behaviour for BF2 NICs to configure SR-IOV VFs in vanilla Kubernetes cluster. PR k8snetworkplumbingwg#201 broke BF2 NICs configration in Kubernetes. It assumes that BF2 will be configured via systemd service in OpenShift using MachineConfigPool object. Signed-off-by: Ivan Kolodyazhny <[email protected]>
e0ne
force-pushed
the
bf2-configuration
branch
from
dd85271 to
be1f285
Compare
|
Thanks for your PR,
To skip the vendors CIs use one of:
|
|
@zshi-redhat @pliurh could you please review this PR? |
|
@e0ne Is this change to enable BF in ConnectX mode? |
|
@zshi-redhat for now we dont have a use-case to deploy BF2 via systemd service with vanilla k8s. later on we will make sriov-network-operator DPU mode aware and support both use-cases. once we move sriov configuration to systemd both flows (openshift and non-openshift) can be unified IMO. performing full sriov configuration via systemd. |
So this patch is not supposed to enable switchdev mode with BF2 in connectX mode?
Ack+, both use-cases means supporting BF2 in different modes (connectX, embedded cpu)
Agree, I think k8s_plugin applies the systemd service to enable switchdev mode in vanilla k8s, I wonder if this approach will be applied to BF in connectX mode. |
|
@zshi-redhat with this PR BF2 could be configured:
DPU mode aware logic will be implemented in a follow-up PR |
it is, as connectX, realized i wasnt clear on this :)
yes
yes it will. the goal is for it to take the same code-path as connectx in both legacy/switchdev modes in vanilla k8s |
| // Nvidia_mlx5_MT42822_BlueField-2_integrated_ConnectX-6_Dx | ||
| if ifStatus.Vendor == VendorMellanox && ifStatus.DeviceID == DeviceBF2 { | ||
| // Nvidia_mlx5_MT42822_BlueField-2_integrated_ConnectX-6_Dx in OpenShift | ||
| if ClusterType == ClusterTypeOpenshift && ifStatus.Vendor == VendorMellanox && ifStatus.DeviceID == DeviceBF2 { |
There was a problem hiding this comment.
We'd also like to support BF in connectx mode in openshift, this check makes the bf2 device in connectx mode to go through the path of systemd service configuration on openshift, which is not ideal since currently systemd service doesn't initialize the VF device as is done by config-daemon runtime configSriovDevice.
Shall we take this opptunitiy to implement the VF initialization in systemd service?
There was a problem hiding this comment.
This PR is proposed as a temporary solution to enable the use-case for vanilla k8s. @e0ne is working of VF initialization in systemd.
for openshift i suspect the need to support BF as connectx will come at a later stage so it gives us some time to move to systemd., Driver changes might be needed as well as a new mstflint version that needs to be pulled to RHEL repo (for when we need to query the DPU mode and change it).
will this be acceptable ?
There was a problem hiding this comment.
okay, the sysetmd can come later.
|
/test-all |
This patch fixes current behaviour for BF2 NICs to configure
SR-IOV VFs in vanilla Kubernetes cluster.
PR #201 broke BF2 NICs configration in Kubernetes. It assumes
that BF2 will be configured via systemd service in OpenShift
using MachineConfigPool object.
Signed-off-by: Ivan Kolodyazhny [email protected]