Skip to content

Commit

Permalink
design doc for the externally-manage-pf support
Browse files Browse the repository at this point in the history
Signed-off-by: Sebastian Sch <[email protected]>
  • Loading branch information
SchSeba committed Jul 25, 2023
1 parent 37ddcd4 commit dcb3119
Showing 1 changed file with 212 additions and 0 deletions.
212 changes: 212 additions & 0 deletions doc/design/externally-manage-pf.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,212 @@
---
title: Externally Manage PF
authors:
- SchSeba
reviewers:
- zeeke
- adrianchiris
creation-date: 12-07-2023
last-updated: 12-07-2023
---

# Externally Manage PF

## Summary

Allow the SR-IOV operator to configure and allocate a subset of virtual functions from a physical function not
configured by the operator

## Motivation

The feature is needed to allow the operator to only configure a subset of virtual functions.
This allows a third party component like nmstate, kubernetes-nmstate, NetworkManager to handle the creation
and the usage of the virtual functions on the system.Some of the examples are using the virtual function as the primary
nic for the k8s SDN network or a storage network.

Before this change the SR-IOV operator is the only component that should use/configure VFs. not allowing the user
to use some of the VFs for host networking.

### Use Cases

* As a user I want to use a virtual function for SDN network
* As a user I want to create the virtual functions via nmstate
* As a user I want pods to use virtual functions from a pre-configured PF

### Goals

* Allow the SR-IOV operator to handle the configure and pod allocation of a subset of virtual functions
* Allow the user to Allocate the number of virtual functions he wants for the system and the subset he wants for pods
* Not resetting the numOfVfs for PFs that are externally managed

### Non-Goals

* Supporting switchdev mode (may change in the future if there is a request)

## Proposal

Create a sub-flow in the SR-IOV operator where the user can request a configuration for a subset of virtual functions
without any changes in the PF level.

The operator will first validate the requested PF contains the requested amount of virtual functions allocated, it
will also validate the requested MTU is configured as expected on the PF.
Then the operator will configure the subset of virtual functions with the requested driver and will update the device plugin
configmap with the expected information to create the relevant pools.

Existing flow:
1. Apply the `numOfVfs`
2. Configure the MTU on the PF
3. Copy the Administrative mac address from the VFs
4. Bind the right driver for the VF
5. Create SR-IOV device plugin pools

Externally manage flow:
1. Copy the Administrative mac address from the VFs
2. Bind the right driver for the VF
3. Create SR-IOV device plugin pools

### Workflow Description

The user will allocate the virtual functions on the system with any third party tool like nmstate, Kubnernetes-nmstate,
systemd scripts, etc..

Then the user will be able to create a policy telling the operator that the PF is externally managed by the user.

Policy Example:
```yaml
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
name: sriov-nic-1
namespace: sriov-network-operator
spec:
deviceType: netdevice
nicSelector:
pfNames: ["ens3f0#5-9"]
nodeSelector:
node-role.kubernetes.io/worker: ""
numVfs: 10
priority: 99
resourceName: sriov_nic_1
externallyManaged: true
```
#### Validation
The SR-IOV operator will do a validation webhook to check if the requested `numVfs` is equal to what the user allocate
if not it will reject the policy creation.

The SR-IOV operator will do a validation webhook to check if the requested MTU is equal to what exist on the PF
if not it will reject the policy creation.


*Note:* Same validation will be done in the SR-IOV config-daemon container to cover cases where the user doesn't want to deploy"
the webhook and to cover scale-up adding new nodes. If the verification failed in the policy apply stage
the `sriovNetworkNodeState.status.SyncStatus` field will be report a `Failed` status and the error description will
get exposed in `sriovNetworkNodeState.status.LastSyncError`


#### Configuration

The SR-IOV operator config daemon will reconcile on the SriovNetworkNodeState update and will follow the regular
flow of virtual functions *SKIPPING* only the Virtual function allocation.

The SR-IOV operator will update the SR-IOV Network Device Plugin with the pool information

Another change with the operator beavior is when we delete a policy with had `externallyManaged: true` the SR-IOV operator
will *NOT* reset the `numVfs`

### API Extensions

For SriovNetworkNodePolicy

```golang
// SriovNetworkNodePolicySpec defines the desired state of SriovNetworkNodePolicy
type SriovNetworkNodePolicySpec struct {
// SRIOV Network device plugin endpoint resource name
ResourceName string `json:"resourceName"`
// NodeSelector selects the nodes to be configured
NodeSelector map[string]string `json:"nodeSelector"`
// +kubebuilder:validation:Minimum=0
// +kubebuilder:validation:Maximum=99
// Priority of the policy, higher priority policies can override lower ones.
Priority int `json:"priority,omitempty"`
// +kubebuilder:validation:Minimum=1
// MTU of VF
Mtu int `json:"mtu,omitempty"`
// +kubebuilder:validation:Minimum=0
// Number of VFs for each PF
NumVfs int `json:"numVfs"`
// NicSelector selects the NICs to be configured
NicSelector SriovNetworkNicSelector `json:"nicSelector"`
// +kubebuilder:validation:Enum=netdevice;vfio-pci
// The driver type for configured VFs. Allowed value "netdevice", "vfio-pci". Defaults to netdevice.
DeviceType string `json:"deviceType,omitempty"`
// RDMA mode. Defaults to false.
IsRdma bool `json:"isRdma,omitempty"`
// mount vhost-net device. Defaults to false.
NeedVhostNet bool `json:"needVhostNet,omitempty"`
// +kubebuilder:validation:Enum=eth;ETH;ib;IB
// NIC Link Type. Allowed value "eth", "ETH", "ib", and "IB".
LinkType string `json:"linkType,omitempty"`
// +kubebuilder:validation:Enum=legacy;switchdev
// NIC Device Mode. Allowed value "legacy","switchdev".
EswitchMode string `json:"eSwitchMode,omitempty"`
// +kubebuilder:validation:Enum=virtio
// VDPA device type. Allowed value "virtio"
VdpaType string `json:"vdpaType,omitempty"`
// Exclude device's NUMA node when advertising this resource by SRIOV network device plugin. Default to false.
ExcludeTopology bool `json:"excludeTopology,omitempty"`
+ // don't create the virtual function only assign to the driver and allocated them to device plugin. Defaults to false.
+ ExternallyManaged bool `json:"externallyManaged,omitempty"`
}
```

For SriovNetworkNodeState

```golang
type Interface struct {
PciAddress string `json:"pciAddress"`
NumVfs int `json:"numVfs,omitempty"`
Mtu int `json:"mtu,omitempty"`
Name string `json:"name,omitempty"`
LinkType string `json:"linkType,omitempty"`
EswitchMode string `json:"eSwitchMode,omitempty"`
VfGroups []VfGroup `json:"vfGroups,omitempty"`
+ ExternallyManaged bool `json:"externallyManaged,omitempty"`
}
```

### Implementation Details/Notes/Constraints

#### Webhook
For the webhook we add more validations when the policy contains `ExternallyManaged: true`
* `numVfs` in the policy equal is equal or lower the number of virtual functions on the system
* `MTU` in the policy equals the MTU we discover on the PF

#### Controller/Manager

The changes in the manager for this feature are minimal we only copy the `ExternallyManaged` boolean from the policy
to the generated `nodeState.Spec`

#### Config Daemon

This is where most of the changes for this feature are implemented.

First step we will do a validation same as on the webhook to check the PF have everything we need to apply the requested
policy, by checking the `numVfs` and `MTU`.
Next config-daemon will skip all the PF configuration like `numVfs` and `MTU`. he will only preform the virtual function
driver allocation, administrative mac allocation and MTU. Last step as always will be to reset the device plugin so
kubelet will be able to discover the SR-IOV devices.

The config-daemon will also save on the node a cache of the last applied policy. this is needed to be able and understand
if we need to reset the PF configuration(`ExternallyManaged` was false) or not when o policy is removed.

### Upgrade & Downgrade considerations

The feature supports both Upgrade and Downgrade as we are introducing a new field in the API

### Test Plan

* Should not allow to create a policy if there are no vfs configured
* Should create a policy if the number of requested vfs is equal
* Should create a policy if the number of requested vfs is equal and not delete them when the policy is removed
* should reset the virtual functions if externallyCreated is false

0 comments on commit dcb3119

Please sign in to comment.