About Single Root I/O Virtualization (SR-IOV) hardware networks

    SR-IOV can segment a compliant network device, recognized on the host node as a physical function (PF), into multiple virtual functions (VFs). The VF is used like any other network device. The SR-IOV network device driver for the device determines how the VF is exposed in the container:

    • driver: A regular kernel network device in the netns of the container

    You can use SR-IOV network devices with additional networks on your OKD cluster for application that require high bandwidth or low latency.

    The SR-IOV Network Operator creates and manages the components of the SR-IOV stack. It performs the following functions:

    • Orchestrates discovery and management of SR-IOV network devices

    • Generates NetworkAttachmentDefinition custom resources for the SR-IOV Container Network Interface (CNI)

    • Creates and updates the configuration of the SR-IOV network device plug-in

    • Creates node specific SriovNetworkNodeState custom resources

    • Updates the spec.interfaces field in each SriovNetworkNodeState custom resource

    The Operator provisions the following components:

    SR-IOV network configuration daemon

    A daemon set that is deployed on worker nodes when the SR-IOV Network Operator starts. The daemon is responsible for discovering and initializing SR-IOV network devices in the cluster.

    SR-IOV Network Operator webhook

    A dynamic admission controller webhook that validates the Operator custom resource and sets appropriate default values for unset fields.

    SR-IOV Network resources injector

    A dynamic admission controller webhook that provides functionality for patching Kubernetes pod specifications with requests and limits for custom network resources such as SR-IOV VFs.

    SR-IOV network device plug-in

    A device plug-in that discovers, advertises, and allocates SR-IOV network virtual function (VF) resources. Device plug-ins are used in Kubernetes to enable the use of limited resources, typically in physical devices. Device plug-ins give the Kubernetes scheduler awareness of resource availability, so that the scheduler can schedule pods on nodes with sufficient resources.

    SR-IOV CNI plug-in

    A CNI plug-in that attaches VF interfaces allocated from the SR-IOV network device plug-in directly into a pod.

    SR-IOV InfiniBand CNI plug-in

    A CNI plug-in that attaches InfiniBand (IB) VF interfaces allocated from the SR-IOV network device plug-in directly into a pod.

    OKD supports the following network interface controllers:

    The SR-IOV Network Operator searches your cluster for SR-IOV capable network devices on worker nodes. The Operator creates and updates a SriovNetworkNodeState custom resource (CR) for each worker node that provides a compatible SR-IOV network device.

    The CR is assigned the same name as the worker node. The status.interfaces list provides information about the network devices on a node.

    Example SriovNetworkNodeState object

    The following YAML is an example of a SriovNetworkNodeState object created by the SR-IOV Network Operator:

    An SriovNetworkNodeState object

    You can run a remote direct memory access (RDMA) or a Data Plane Development Kit (DPDK) application in a pod with SR-IOV VF attached.

    spec that uses RDMA mode

    The following example shows a pod with a VF in DPDK mode:

    Pod spec that uses DPDK mode

    An , app-netutil, provides several API methods for gathering network information about a pod from within a container running within that pod.

    This library can assist with integrating SR-IOV virtual functions (VFs) in Data Plane Development Kit (DPDK) mode into the container. The library provides both a Golang API and a C API.

    Currently there are three API methods implemented:

    GetCPUInfo()

    This function determines which CPUs are available to the container and returns the list.

    GetHugepages()

    This function determines the amount of huge page memory requested in the Pod spec for each container and returns the values.

    GetInterfaces()

    This function determines the set of interfaces in the container and returns the list. The return value includes the interface type and type-specific data for each interface.

    The repository for the library includes a sample Dockerfile to build a container image, dpdk-app-centos. The container image can run one of the following DPDK sample applications, depending on an environment variable in the pod specification: l2fwd, l3wd or testpmd. The container image provides an example of integrating the app-netutil library into the container image itself. The library can also integrate into an init container. The init container can collect the required data and pass the data to an existing DPDK workload.

    When a pod specification includes a resource request or limit for huge pages, the Network Resources Injector automatically adds Downward API fields to the pod specification to provide the huge pages information to the container.

    The Network Resources Injector adds a volume that is named podnetinfo and is mounted at /etc/podnetinfo for each container in the pod. The volume uses the Downward API and includes a file for huge pages requests and limits. The file naming convention is as follows:

    • /etc/podnetinfo/hugepages_1G_limit_<container-name>

    • /etc/podnetinfo/hugepages_2M_request_<container-name>

    • /etc/podnetinfo/hugepages_2M_limit_<container-name>

    The paths specified in the previous list are compatible with the app-netutil library. By default, the library is configured to search for resource information in the /etc/podnetinfo directory. If you choose to specify the Downward API path items yourself manually, the app-netutil library searches for the following paths in addition to the paths in the previous list.

    • /etc/podnetinfo/hugepages_limit

    • /etc/podnetinfo/hugepages_1G_request

    • /etc/podnetinfo/hugepages_1G_limit

    • /etc/podnetinfo/hugepages_2M_request

    • /etc/podnetinfo/hugepages_2M_limit

    As with the paths that the Network Resources Injector can create, the paths in the preceding list can optionally end with a _<container-name> suffix.

    Next steps