-
Notifications
You must be signed in to change notification settings - Fork 113
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
Avoid reconfiguring unmentioned DPDK VFs #710
Avoid reconfiguring unmentioned DPDK VFs #710
Conversation
Thanks for your PR,
To skip the vendors CIs use one of:
|
Pull Request Test Coverage Report for Build 9447901897Details
💛 - Coveralls |
3406e9b
to
349b8ef
Compare
Thanks for your PR,
To skip the vendors CIs use one of:
|
Pull Request Test Coverage Report for Build 9449952944Details
💛 - Coveralls |
349b8ef
to
a02d734
Compare
Thanks for your PR,
To skip the vendors CIs use one of:
|
Pull Request Test Coverage Report for Build 9450305059Details
💛 - Coveralls |
api/v1/helper.go
Outdated
// need to reset VF if it is not a part of a group and: | ||
// a. has DPDK driver loaded | ||
// b. has VDPA device | ||
if !ingroup && vfStatus.VdpaType != "" { |
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.
@lmilleri @wizhaoredhat I'm thinking about removing also this case. Are you aware of any case in which a VF with VdpaType that is not referenced by any policy should be configured/reset by the operator?
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.
@zeeke Vdpa devices should be created/delete with policies, they should not be on their own. IIUC with this change, we won't trigger a reconfiguration if vdpa device is not in a policy? If yes, it looks ok to me
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.
Correct, this if
statement checks if a VF has Vdpa but it is not referenced by any policy. The current behavior is to try to reconcile it (not sure which changes are going to be done). I'm proposing to make the operator leave the device as is, as there is no policy that says it should be managed.
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.
Looks good to me too.
a02d734
to
2613897
Compare
Thanks for your PR,
To skip the vendors CIs use one of:
|
2613897
to
a5c080d
Compare
Thanks for your PR,
To skip the vendors CIs use one of:
|
Pull Request Test Coverage Report for Build 9547721609Details
💛 - Coveralls |
Add an end-to-end test to verify removing a partial SriovNetworkNodePolicy does not trigger any issue in the operator's deployment. Refs: - https://issues.redhat.com/browse/OCPBUGS-34934 - k8snetworkplumbingwg#710 Signed-off-by: Andrea Panattoni <[email protected]>
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.
LGTM
a5c080d
to
ebc9719
Compare
Thanks for your PR,
To skip the vendors CIs use one of:
|
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.
LGTM !
If a Virtual Function is configured with a DPDK driver (e.g. `vfio-pci`) and it is not referred by any SriovNetworkNodePolicy, `NeedToUpdateSriov` function must not trigger a reconfiguration. This may happen if a PF is configured by multiple policies (via PF partitioning) and a policy is deleted by the user. In these cases, the VF is not reconfigured [1] and a drain loop is started The same logic applies to VDPA devices. refs: [1] https://github.com/k8snetworkplumbingwg/sriov-network-operator/blob/5f3c4e903f789aa177fe54686efd6c18576b7ab1/pkg/host/internal/sriov/sriov.go#L457 Signed-off-by: Andrea Panattoni <[email protected]>
ebc9719
to
8b7f22a
Compare
Thanks for your PR,
To skip the vendors CIs use one of:
|
Pull Request Test Coverage Report for Build 9677744999Details
💛 - Coveralls |
Add an end-to-end test to verify removing a partial SriovNetworkNodePolicy does not trigger any issue in the operator's deployment. Refs: - https://issues.redhat.com/browse/OCPBUGS-34934 - k8snetworkplumbingwg#710 Signed-off-by: Andrea Panattoni <[email protected]>
Add an end-to-end test to verify removing a partial SriovNetworkNodePolicy does not trigger any issue in the operator's deployment. Refs: - https://issues.redhat.com/browse/OCPBUGS-34934 - k8snetworkplumbingwg#710 Signed-off-by: Andrea Panattoni <[email protected]>
Add an end-to-end test to verify removing a partial SriovNetworkNodePolicy does not trigger any issue in the operator's deployment. Refs: - https://issues.redhat.com/browse/OCPBUGS-34934 - k8snetworkplumbingwg#710 Signed-off-by: Andrea Panattoni <[email protected]>
Add an end-to-end test to verify removing a partial SriovNetworkNodePolicy does not trigger any issue in the operator's deployment. Refs: - https://issues.redhat.com/browse/OCPBUGS-34934 - k8snetworkplumbingwg#710 Signed-off-by: Andrea Panattoni <[email protected]>
If a Virtual Function is configured with a DPDK driver (e.g.
vfio-pci
) and it is not referred by any SriovNetworkNodePolicy,NeedToUpdateSriov
function must not trigger a reconfiguration. This may happen if a PF is configured by multiple policies (via PF partitioning) and a policy is deleted by the user. In these cases, the VF is not reconfigured [1] and a drain loop is startedrefs:
[1]
sriov-network-operator/pkg/host/internal/sriov/sriov.go
Line 457 in 5f3c4e9