- Getting Started
- Building Blocks
- Application Onboarding
- Reference Architectures
- Edge Applications
- Cloud Adapters
- Development Kits
- Release history
SPDX-License-Identifier: Apache-2.0 Copyright (c) 2020 Intel Corporation
Using Intel® QuickAssist Adapter in OpenNESS: Resource Allocation, and Configuration
- Intel QuickAssist Adapter CU/DU Host Interface Overview
- Intel QuickAssist Adapter Device Plugin Deployment with Kubernetes* for CU/DU
- Using the Intel QuickAssist Adapter on OpenNESS
Intel® QuickAssist Adapter plays a key role in accelerating cryptographic operations in 5G networking.
Intel® QuickAssist Adapter provides the following features:
- Symmetric (Bulk) Cryptography:
- Ciphers (AES, 3DES/DES, RC4, KASUMI, ZUC, Snow 3G)
- Message digset/hash (MD5, SHA1, SHA2, SHA3) and authentcation (HMAC, AES-XCBC)
- Algorithm chaining (one cipher and one hash in a sigle operation)
- Authenticated encription (AES-GCM, AES-CCM)
- Asymmetric (Public Key) Cryptography:
- Modular exponentation for Diffie-Hellman (DH)
- RSA key generation, encryption/decryption and digital signature generation/verification
- DSA parameter generation and digital signature generation/verification
- Elliptic Curve Cryptography: ECDSA, ECDHE, Curve25519
Intel® QuickAssist Adapter benefits include:
- Reduced platform power, E2E latency and Intel® CPU core count requirements
- Accelerates wireless data encryption and authentication
- Accommodates space-constrained implementations via a low-profile PCIe* card form factor
For more information, see product brief in Intel® QuickAssist Adapter.
This document explains how the Intel® QuickAssist (QAT) device plugin is enabled and used on the Open Network Edge Services Software (OpenNESS) platform for accelerating network functions and edge application workloads. The Intel® QuickAssist Adapter is used to accelerate the LTE/5G encryption tasks in the CU/DU.
Intel QuickAssist Adapter CU/DU Host Interface Overview
Intel® QuickAssist Adapter used in the CU/DU solution exposes the following Physical Functions (PF) to the CPU host:
- Three interfaces, that can provide 16 Virtual Functions each.
Intel QuickAssist Adapter Device Plugin Deployment with Kubernetes* for CU/DU
CU/DU applications use the
qat.intel.com/generic resources from the Intel® QuickAssist Adapter using POD resource allocation and the Kubernetes* device plugin framework. Kubernetes* provides a device plugin framework that is used to advertise system hardware resources to the Kubelet. Instead of customizing the code for Kubernetes* (K8s) itself, vendors can implement a device plugin that can be deployed either manually or as a DaemonSet. The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand* adapters, and other similar computing resources that may require vendor-specific initialization and setup.
Using the Intel QuickAssist Adapter on OpenNESS
Further sections provide instructions on how to use the Intel® QuickAssist Adapter features: configuration and accessing from an application on the OpenNESS Network Edge.
When the Intel® QuickAssist Adapter is available on the Edge Node platform it exposes three Root I/O Virtualization (SRIOV) Physical Functions (PF) devices which can be used to create Virtual Functions. To take advantage of this functionality for a cloud-native deployment, the PF (Physical Function) of the device must be bound to the DPDK IGB_UIO userspace driver to create several VFs (Virtual Functions). Once the VFs are created, they must also be bound to a DPDK userspace driver to allocate them to specific K8s pods running the vRAN workload.
The full pipeline of preparing the device for workload deployment and deploying the workload can be divided into the following stages:
- Enabling SRIOV, binding devices to appropriate drivers, and the creation of VFs: delivered as part of the Edge Nodes Ansible automation.
- QAT Device Plugin deployment.
- Queue configuration of QAT’s PFs/VFs.
- Binding QAT’s PFs/VFs to igb_uio driver.
Intel QuickAssist Adapter for OpenNESS Network Edge
To run the OpenNESS package with Intel® QuickAssist Adapter Device Plugin functionality, the feature needs to be enabled on both Edge Controller and Edge Node. It can be deployed by setting the following variable in the flavor or group_vars/all file in Converged Edge Experience Kits:
Converged Edge Experience Kits (CEEK)
To enable Intel® QuickAssist Adapter Device Plugin support from CEEK, SRIOV must be enabled in OpenNESS:
kubernetes_cnis: - <primary CNI> - sriov
sriovcannot be the primary CNI.
Intel® QuickAssist Adapter Device Plugin is enabled by default in the
After a successful deployment, the following pods will be available in the cluster:
kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE intel-qat-plugin-dl42c 1/1 Running 0 7d9h
Requesting Resources and Running Pods for OpenNESS Network Edge
As part of the OpenNESS Ansible automation, a K8s SRIOV device plugin to orchestrate the Intel® QuickAssist Adapter VFs (bound to the userspace driver) is deployed and running. This enables the scheduling of pods requesting this device. To check the number of devices available on the Edge Node from Edge Controller, run:
kubectl get node $(hostname) -o json | jq '.status.allocatable' "qat.intel.com/generic": "48"
To request the QAT VFs as a resource in the pod, add the request for the resource into the pod specification file by specifying its name and the amount of resources required. If the resource is not available or the amount of resources requested is greater than the number of resources available, the pod status will be “Pending” until the resource is available.
A sample pod requesting the Intel® QuickAssist Adapter VF may look like this:
apiVersion: v1 kind: Pod metadata: name: test labels: env: test spec: containers: - name: test image: centos:latest command: [ "/bin/bash", "-c", "--" ] args: [ "while true; do sleep 300000; done;" ] resources: requests: qat.intel.com/generic: 1 limits: qat.intel.com/generic: 1
To test the resource allocation to the pod, save the above code snippet to the
sample.yaml file and create the pod.
kubectl create -f sample.yaml
Once the pod is in the ‘Running’ state, check that the device was allocated to the pod (a uioX device and an environmental variable with a device PCI address should be available):
kubectl exec -it test -- ls /dev kubectl exec -it test -- printenv | grep QAT
[...] crw------- 1 root root 241, 18 Mar 22 14:11 uio18 crw------- 1 root root 241, 39 Mar 22 14:11 uio39 crw------- 1 root root 241, 46 Mar 22 14:11 uio46 crw------- 1 root root 241, 8 Mar 22 14:11 uio8 [...]
QAT3=0000:1e:02.6 QAT2=0000:1c:01.2 QAT1=0000:1e:01.7 QAT0=0000:1a:02.0
To check the number of devices currently allocated to pods, run (and search for ‘Allocated Resources’):
kubectl describe node $(hostname)