8.6. SR-IOV と Node Tuning Operator を使用した DPDK ラインレートの実現
Node Tuning Operator を使用して、分離された CPU、ヒュージページ、およびトポロジースケジューラーを設定できます。その後、Node Tuning Operator と Single Root I/O Virtualization (SR-IOV) を使用して、特定の Data Plane Development Kit (DPDK) ラインレートを実現できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - SR-IOV Network Operator がインストールされている。
-
cluster-admin権限を持つユーザーとしてログインしている。 スタンドアロン Node Tuning Operator をデプロイしている。
注記OpenShift Container Platform の以前のバージョンでは、パフォーマンスアドオン Operator を使用して自動チューニングを実装し、OpenShift アプリケーションの低レイテンシーパフォーマンスを実現していました。OpenShift Container Platform 4.11 以降では、この機能は Node Tuning Operator の一部です。
手順
次の例に基づいて
PerformanceProfileオブジェクトを作成します。apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: globallyDisableIrqLoadBalancing: true cpu: isolated: 21-51,73-1031 reserved: 0-20,52-722 hugepages: defaultHugepagesSize: 1G3 pages: - count: 32 size: 1G net: userLevelNetworking: true numa: topologyPolicy: "single-numa-node" nodeSelector: node-role.kubernetes.io/worker-cnf: ""- 1
- システムでハイパースレッディングが有効になっている場合は、関連するシンボリックリンクを
isolatedおよびreservedの CPU グループに割り当てます。システムに複数の Non-Uniform Memory Access (NUMA) ノードが含まれている場合は、両方の NUMA から両方のグループに CPU を割り当てます。このタスクには Performance Profile Creator を使用することもできます。詳細は、コントロールプレーンプロファイルの作成 を参照してください。 - 2
- キューが予約済みの CPU 数に設定されているデバイスのリストを指定することもできます。詳細は、Node Tuning Operator を使用した NIC キューの削減 を参照してください。
- 3
- 必要なヒュージページの数とサイズを割り当てます。ヒュージページの NUMA 設定を指定できます。デフォルトでは、システムは、そのシステムにあるすべての NUMA ノードに偶数分を割り当てます。必要に応じて、ノードのリアルタイムカーネルの使用をリクエストできます。詳細は、リアルタイム機能を備えたワーカーのプロビジョニング を参照してください。
-
yamlファイルをmlx-dpdk-perfprofile-policy.yamlとして保存します。 次のコマンドを使用して、パフォーマンスプロファイルを適用します。
$ oc create -f mlx-dpdk-perfprofile-policy.yaml
8.6.1. コンテナーアプリケーションで使用する DPDK ライブラリー リンクのコピーリンクがクリップボードにコピーされました!
オプションライブラリー の app-netutil は、その Pod 内で実行されるコンテナーから Pod に関するネットワーク情報を収集するための複数の API メソッドを提供します。
このライブラリーは、DPDK (Data Plane Development Kit) モードの SR-IOV Virtual Function (VF) のコンテナーへの統合を支援します。このライブラリーは Golang API と C API の両方を提供します。
現時点で 3 つの API メソッドが実装されています。
GetCPUInfo()- この機能は、コンテナーで利用可能な CPU を判別し、リストを返します。
GetHugepages()-
この機能は、各コンテナーの
Pod仕様で要求される huge page メモリーの量を判別し、値を返します。 GetInterfaces()- この機能は、コンテナーのインターフェイスセットを判別し、インターフェイスタイプとタイプ固有のデータと共にリストを返します。戻り値には、インターフェイスのタイプと、各インターフェイスのタイプ固有のデータが含まれます。
ライブラリーのリポジトリーには、コンテナーイメージ dpdk-app-centos をビルドするためのサンプル Dockerfile が含まれます。コンテナーイメージは、Pod 仕様の環境変数に応じて、l2fwd、l3wd または testpmd の DPDK サンプルアプリケーションのいずれかを実行できます。コンテナーイメージは、app-netutil ライブラリーをコンテナーイメージ自体に統合する例を提供します。ライブラリーを init コンテナーに統合することもできます。init コンテナーは必要なデータを収集し、データを既存の DPDK ワークロードに渡すことができます。
8.6.2. Virtual Function の SR-IOV Network Operator の例 リンクのコピーリンクがクリップボードにコピーされました!
Single Root I/O Virtualization (SR-IOV) Network Operator を使用して、ノード上の SR-IOV をサポートする Physical Function NIC から Virtual Function (VF) を割り当てて設定できます。
Operator のデプロイの詳細は、SR-IOV Network Operator のインストール を参照してください。SR-IOV ネットワークデバイスの設定の詳細は、SR-IOV ネットワークデバイスの設定 を参照してください。
Intel VF と Mellanox VF での Data Plane Development Kit (DPDK) ワークロードの実行にはいくつかの違いがあります。このセクションでは、両方の VF タイプのオブジェクト設定の例を示します。以下は、Intel NIC で DPDK アプリケーションを実行するために使用される sriovNetworkNodePolicy オブジェクトの例です。
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
name: dpdk-nic-1
namespace: openshift-sriov-network-operator
spec:
deviceType: vfio-pci
needVhostNet: true
nicSelector:
pfNames: ["ens3f0"]
nodeSelector:
node-role.kubernetes.io/worker-cnf: ""
numVfs: 10
priority: 99
resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
name: dpdk-nic-1
namespace: openshift-sriov-network-operator
spec:
deviceType: vfio-pci
needVhostNet: true
nicSelector:
pfNames: ["ens3f1"]
nodeSelector:
node-role.kubernetes.io/worker-cnf: ""
numVfs: 10
priority: 99
resourceName: dpdk_nic_2
以下は、Mellanox NIC の sriovNetworkNodePolicy オブジェクトの例です。
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
name: dpdk-nic-1
namespace: openshift-sriov-network-operator
spec:
deviceType: netdevice
isRdma: true
nicSelector:
rootDevices:
- "0000:5e:00.1"
nodeSelector:
node-role.kubernetes.io/worker-cnf: ""
numVfs: 5
priority: 99
resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
name: dpdk-nic-2
namespace: openshift-sriov-network-operator
spec:
deviceType: netdevice
isRdma: true
nicSelector:
rootDevices:
- "0000:5e:00.0"
nodeSelector:
node-role.kubernetes.io/worker-cnf: ""
numVfs: 5
priority: 99
resourceName: dpdk_nic_2
8.6.3. SR-IOV Network Operator の例 リンクのコピーリンクがクリップボードにコピーされました!
以下は、sriovNetwork オブジェクトの定義例です。この場合、Intel と Mellanox の設定は同じです。
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
name: dpdk-network-1
namespace: openshift-sriov-network-operator
spec:
ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.1.0/24"}]],"dataDir":
"/run/my-orchestrator/container-ipam-state-1"}'
networkNamespace: dpdk-test
spoofChk: "off"
trust: "on"
resourceName: dpdk_nic_1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
name: dpdk-network-2
namespace: openshift-sriov-network-operator
spec:
ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.2.0/24"}]],"dataDir":
"/run/my-orchestrator/container-ipam-state-1"}'
networkNamespace: dpdk-test
spoofChk: "off"
trust: "on"
resourceName: dpdk_nic_2
- 1
- Whereabouts など、別の IP Address Management (IPAM) 実装を使用できます。詳細は、Whereabouts を使用した動的 IP アドレス割り当ての設定 を参照してください。
- 2
- ネットワークアタッチメント定義が作成される
networkNamespaceを要求する必要があります。openshift-sriov-network-operatornamespace でsriovNetworkCR を作成する必要があります。 - 3
resourceNameの値は、sriovNetworkNodePolicyで作成されたresourceNameの値と一致する必要があります。
8.6.4. DPDK ベースワークロードの例 リンクのコピーリンクがクリップボードにコピーされました!
以下は、Data Plane Development Kit (DPDK) コンテナーの例です。
apiVersion: v1
kind: Namespace
metadata:
name: dpdk-test
---
apiVersion: v1
kind: Pod
metadata:
annotations:
k8s.v1.cni.cncf.io/networks: '[
{
"name": "dpdk-network-1",
"namespace": "dpdk-test"
},
{
"name": "dpdk-network-2",
"namespace": "dpdk-test"
}
]'
irq-load-balancing.crio.io: "disable"
cpu-load-balancing.crio.io: "disable"
cpu-quota.crio.io: "disable"
labels:
app: dpdk
name: testpmd
namespace: dpdk-test
spec:
runtimeClassName: performance-performance
containers:
- command:
- /bin/bash
- -c
- sleep INF
image: registry.redhat.io/openshift4/dpdk-base-rhel8
imagePullPolicy: Always
name: dpdk
resources:
limits:
cpu: "16"
hugepages-1Gi: 8Gi
memory: 2Gi
requests:
cpu: "16"
hugepages-1Gi: 8Gi
memory: 2Gi
securityContext:
capabilities:
add:
- IPC_LOCK
- SYS_RESOURCE
- NET_RAW
- NET_ADMIN
runAsUser: 0
volumeMounts:
- mountPath: /mnt/huge
name: hugepages
terminationGracePeriodSeconds: 5
volumes:
- emptyDir:
medium: HugePages
name: hugepages
SLEEP 状態の Pod を起動し、その Pod で exec 操作を実行して testpmd または DPDK ワークロードを開始しないでください。これにより、exec プロセスがどの CPU にも固定されていないため、割り込みが追加される可能性があります。
8.6.5. testpmd スクリプトの例 リンクのコピーリンクがクリップボードにコピーされました!
以下は、testpmd を実行するスクリプトの例です。
#!/bin/bash
set -ex
export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus)
echo ${CPU}
dpdk-testpmd -l ${CPU} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_1} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_2} -n 4 -- -i --nb-cores=15 --rxd=4096 --txd=4096 --rxq=7 --txq=7 --forward-mode=mac --eth-peer=0,50:00:00:00:00:01 --eth-peer=1,50:00:00:00:00:02
この例では、2 つの異なる sriovNetwork CR を使用しています。環境変数には、Pod に割り当てられた Virtual Function (VF) PCI アドレスが含まれています。Pod 定義で同じネットワークを使用する場合は、pciAddress を分割する必要があります。トラフィックジェネレータの正しい MAC アドレスを設定することが重要です。この例では、カスタム MAC アドレスを使用しています。