使用加速桥接 CNI 和 NVIDIA 以太网网络进行 Kubernetes 集群部署的技术预览

创建于 2023 年 4 月 3 日，作者 Vitaliy Razinkov。本文档提供了关于如何评估 NVIDIA 硬件加速 Linux 桥接技术及其优势的背景信息和指南。

文档目录

创建于 2023 年 4 月 3 日，作者 Vitaliy Razinkov

范围

NVIDIA 的硬件加速 Linux 桥接是一种新解决方案，可在使用 Linux 桥接时显著提升网络性能并降低 CPU 开销。本技术预览文档提供了评估该技术及其在各种用例中优势的背景信息和指南。

缩写和缩略语

术语	定义	术语	定义
CNI	容器网络接口	LLDP	链路层发现协议
CR	自定义资源	NFD	节点特性发现
CRD	自定义资源定义	OCI	开放容器倡议
CRI	容器运行时接口	PF	物理功能
DHCP	动态主机配置协议	QSG	快速入门指南
DNS	域名系统	RDG	参考部署指南
DP	设备插件	RoCE	融合以太网上的 RDMA
DPDK	数据平面开发套件	SR-IOV	单根输入输出虚拟化
IPAM	IP 地址管理	VF	虚拟功能
K8s	Kubernetes	VF-LAG	链路聚合上的虚拟功能

引言

本文档提供了在 Kubernetes 集群上安装和配置硬件加速 Linux 桥接的分步指南，使用 NVIDIA® ConnectX®-6 Dx SmartNIC 来提升网络性能和效率。

Linux 桥接是 Linux 操作系统中众所周知的软件组件，用于桥接虚拟机或容器。由于它在软件中实现并在主主机 CPU 上执行，因此性能并非最优，且可能占用大量 CPU 资源。另一方面，传统 SR-IOV 允许虚拟机/容器直接连接到网卡，从而实现最佳性能和效率。然而，传统 SR-IOV 缺乏 Linux 桥接提供的许多功能，如绑定或 VLAN 中继。

加速 Linux 桥接使用 NVIDIA ASAP² 框架，允许虚拟机/容器仍然通过 SR-IOV VF 连接，同时将 Linux 桥接用作控制平面。这样，我们既能获得 Linux 桥接的功能，又能获得 SR-IOV 的性能。

加速桥接 CNI 用于在 K8s 环境中启用加速 Linux 桥接。

在本指南中，我们使用 NVIDIA Network Operator 和加速桥接 CNI 为 Kubernetes 集群启用高性能辅助网络。NVIDIA Network Operator 自动安装和配置 K8s 集群中的网络组件。加速桥接 CNI 提供了一种快速高效的方式，通过 VF-LAG 以硬件加速方式将 Pod 连接到辅助网络。

该解决方案部署基于 x86 标准服务器，用于 K8s 工作节点和 K8s 控制平面节点，操作系统为 Ubuntu 22.04。Kubernetes 管理网络和辅助网络均由 NVIDIA 端到端以太网架构处理。

注意： 本指南适用于全新部署。

参考资料

解决方案架构

关键组件和技术

NVIDIA Spectrum SN3000 开放式以太网交换机 NVIDIA® Spectrum®-2 SN3000 以太网交换机非常适合叶脊数据中心网络解决方案，每个端口支持从 1GbE 到 200GbE 的端口速度，端口密度可实现任何速度下全机架连接。SN3000 拥有高达 12.8Tb/s 的双向交换容量和里程碑式的 8.33Bpps 数据包处理速率。SN3000 专为现代数据中心设计，结合了高性能、丰富功能、可扩展性和可视性，并提供灵活的外形。
NVIDIA Cumulus Linux NVIDIA® Cumulus® Linux 是业界最具创新性的开放网络操作系统，可让您像其他系统一样自动化、定制和扩展数据中心网络。
NVIDIA® ConnectX®-6 Dx SmartNIC ConnectX-6 Dx SmartNIC 是业界最安全、最先进的云网络接口卡，可加速关键任务数据中心应用，如安全、虚拟化、SDN/NFV、大数据、机器学习和存储。该 SmartNIC 提供最多两个 100Gb/s 端口或单个 200Gb/s 端口以太网连接，并提供任何智能网络接口卡中最高的投资回报率 (ROI)。ConnectX-6 Dx 是 NVIDIA 世界级、屡获殊荣的 ConnectX 系列网卡的一员，由领先的 50Gb/s (PAM4) 和 25/10Gb/s (NRZ) SerDes 技术以及加速云和数据中心负载的新功能驱动。
NVIDIA LinkX 线缆 NVIDIA® LinkX® 线缆和收发器产品系列提供了业界最完整的 10、25、40、50、100、200 和 400GbE 以太网以及 100、200 和 400Gb/s InfiniBand 产品线，适用于云、HPC、超大规模、企业、电信、存储和人工智能数据中心应用。
Kubernetes Kubernetes 是一个开源容器编排平台，用于容器化应用程序的部署自动化、扩展和管理。
Kubespray Kubespray 由 Ansible playbooks、清单、配置工具和领域知识组成，用于通用操作系统/Kubernetes 集群配置管理任务，并提供：
- 高可用集群
- 可组合属性
- 支持最流行的 Linux 发行版
NVIDIA Network Operator NVIDIA Network Operator 使用 Kubernetes 自定义资源定义 (CRD) 和自定义资源 (CR) 来管理网络配置。它自动化了网络组件的安装和配置，包括网卡固件、驱动程序、容器网络接口 (CNI) 插件和设备插件。

使用加速桥接 CNI 和 NVIDIA 以太网网络进行 Kubernetes 集群部署的技术预览

创建于 2023 年 4 月 3 日，作者：Vitaliy Razinkov

范围

NVIDIA 的硬件加速 Linux 桥接是一种新解决方案，可显著加速网络性能。本文档提供了在 Kubernetes 集群中部署加速桥接 CNI 和 NVIDIA 以太网网络的分步指南。

概述

NVIDIA 网络操作员简化了 Kubernetes 集群中 NVIDIA 网络资源的配置和管理。该操作员自动安装所需的主机网络软件，汇集所有必要组件以提供高速网络连接。这些组件包括 NVIDIA 网络驱动程序、Kubernetes 设备插件、CNI 插件、IP 地址管理 (IPAM) 插件等。NVIDIA 网络操作员与 NVIDIA GPU 操作员协同工作，为可扩展的 GPU 计算集群提供高吞吐量、低延迟的网络。

逻辑设计

逻辑设计包括以下部分：

运行 Kubespray 的部署节点，用于部署 Kubernetes 集群
K8s 主节点，运行所有 Kubernetes 管理组件
带有 NVIDIA ConnectX-6 Dx 网卡的 K8s 工作节点
用于 DPDK 流量仿真的 TRex 服务器
高速以太网结构（K8s 辅助网络）
部署和 K8s 管理网络

逻辑设计图

网络/结构设计

本指南展示了最简单的部署，基于一个用于 K8s 部署和管理网络的交换机，以及一个用于高速以太网网络的交换机。

高速网络是 Kubernetes 集群的辅助网络，需要 L2 网络拓扑。

Kubernetes 管理网络和 DNS/DHCP 网络服务属于 IT 基础设施的一部分，不在本文档讨论范围内。

主机设计

下图显示了 K8s 工作节点的逻辑设计。主机绑定来自同一网卡的两个物理功能 (PF) 网络接口。借助 NVIDIA VF-LAG 技术，这两个端口的 VF 也将绑定，使用与物理端口相同的绑定模式。例如：如果 BOND 配置为 LACP 模式，则所有 VF-LAG 接口具有相同的配置。

要使用 VF-LAG，网卡必须处于 SR-IOV switchdev 模式，我们将使用 Linux 桥接作为 SR-IOV switchdev 控制平面。我们使用 K8s SR-IOV 设备插件（“Hostdev 模式”）和加速桥接 CNI 来配置辅助 POD 接口。

SR-IOV 设备插件负责为 Pod 提供 VF-LAG 接口。加速桥接 CNI 将 VF-LAG 接口连接到 Pod，并在加速桥接上配置代表端口。

VF-LAG 图

软件栈组件

以下软件组件已用于部署系统：

物料清单

下表列出了设置中使用的硬件组件。

物料清单图

部署和配置

网络/结构

网络配置

以下是服务器名称及其相关网络配置。

服务器/交换机类型	服务器/交换机名称	高速网络	管理网络 (100GbE)
部署节点	depserver		ens4f0: DHCP 192.168.100.202
主节点	node1		ens4f0: DHCP 192.168.100.25
工作节点	node2	bond0: 无 IP	ens4f0: DHCP 192.168.100.34
工作节点	node3	bond0: 无 IP	ens4f0: DHCP 192.168.100.39
TRex 服务器	node4	ens2f0: 无 IP ens2f1: 无 IP	ens4f0: DHCP 192.168.100.50
高速交换机	switch01		mgmt0: 来自 DHCP 192.168.100.201

bond0 高速网络接口无需额外配置。

布线

在每个 K8s 工作节点上，NVIDIA 网卡的两个端口都使用 NVIDIA® LinkX® DAC 电缆连接到高速结构中的 NVIDIA 交换机。此外，所有节点的管理端口都连接到 NVIDIA SN2100 以太网交换机。

下图说明了构建 K8s 集群所需的布线。

布线图

注意： 服务器远程管理和交换机管理通过 1GbE 网络的布线不在本指南讨论范围内。

结构配置

此解决方案使用 Cumulus Linux v5.4 网络操作系统部署。

请确保您的 Cumulus Linux 交换机已完成初始配置阶段（有关更多信息，请参阅版本 5.4 的快速入门指南）。

结构配置步骤：

以管理员身份启用所有物理端口。
创建绑定。
创建桥接并进行配置。
创建 VLAN。
将 VLAN 添加到桥接。
提交配置。

交换机配置步骤：

# 示例命令（根据实际环境调整）
net add interface swp1-48
net add bond bond0 bond members swp1,swp2
net add bridge bridge ports bond0
net add vlan 100
net add bridge bridge vids 100
net commit

nv set interface swp1-32
nv set system hostname switch01
nv config apply
nv set interface bond1 bond member swp1-2
nv set interface bond2 bond member swp3-4
nv set interface swp5-32 bridge domain br_default
nv set interface bond1-2 bridge domain br_default
nv set bridge domain br_default vlan 2001-2005
nv config apply -y
nv config save

要查看链路状态，请使用 nv show interface 命令。

节点配置

一般先决条件：

硬件

所有 K8s Worker 节点具有相同的硬件规格，并在相同的 PCIe 插槽中安装 ConnectX-6 Dx 网卡。
主机 BIOS

确认使用的是支持 SR-IOV 的服务器平台，并查看服务器平台供应商文档中的 BIOS 设置，以在 BIOS 中启用 SR-IOV。
主机操作系统

所有服务器应安装 Ubuntu Server 22.04 操作系统，并包含 OpenSSH 服务器软件包。
Kubernetes 经验

必须熟悉 Kubernetes 集群架构。

主机操作系统先决条件

确保所有服务器上安装了 Ubuntu Server 22.04 操作系统，并包含 OpenSSH 服务器软件包，然后创建一个具有 sudo 权限且无需密码的非 root 用户 depuser。

通过运行以下命令更新 Ubuntu 软件包并安装特定的 Linux 内核：

$ sudo apt-get update
$ sudo apt-get upgrade -y
$ sudo apt install -y lldpd rdma-core linux-image-5.19.0-32-generic linux-modules-extra-5.19.0-32-generic
$ sudo reboot

在此解决方案中，我们在 /etc/sudoers 文件末尾添加了以下行：

$ sudo vim /etc/sudoers

#includedir /etc/sudoers.d

#K8s cluster deployment user with sudo privileges without password
depuser ALL=(ALL) NOPASSWD:ALL

网卡固件升级

建议将所有节点上的网卡固件升级到最新版本。将 mlxup 固件更新和查询实用程序下载到每个 Worker 节点，并更新网卡固件。最新版本的 mlxup 可从官方下载页面下载。该实用程序需要 sudo 权限才能执行：

# chmod +x mlxup
# ./mlxup -online -u -y

Netplan 配置

注意： 此步骤应应用于所有 K8s Worker 节点。

Netplan 是用于在 Linux 系统上轻松配置网络的网络配置抽象渲染器。配置通过创建所需网络接口的简单 YAML 描述以及每个接口应执行的操作来完成。以下是部署所需的 YAML 文件示例。 Netplan 的默认配置文件是 /etc/netplan/00-installer-config.yaml。在我们的部署中，网卡 enp57s0f0np0 和 enp57s0f1np1 被用作 Linux 加速桥接的一部分。

# This is the network config written by 'subiquity'
network:
  version: 2
  ethernets:
    enp57s0f0np0:
      dhcp4: false
      mtu: 9216
      embedded-switch-mode: switchdev
      virtual-function-count: 8
      delay-virtual-functions-rebind: true
    enp57s0f1np1:
      dhcp4: false
      mtu: 9216
      embedded-switch-mode: switchdev
      virtual-function-count: 8
      delay-virtual-functions-rebind: true
    enp64s0f0np0:
      dhcp4: true
      dhcp-identifier: mac
    enp64s0f0np1:
      dhcp4: false
  bonds:
    bond0:
      dhcp4: false
      mtu: 9216
      interfaces:
        - enp57s0f0np0
        - enp57s0f1np1
      parameters:
        mode: 802.3ad
        transmit-hash-policy: layer3+4
        lacp-rate: fast
        mii-monitor-interval: 100

应用 Netplan 配置：

# netplan apply

需要重启才能应用配置。

服务器启动后，请查看 dmesg 日志文件，其中应包含如下所示的行。这些行表明 VF-LAG 已正确激活。

[   48.305593] mlx5_core 0000:39:00.1: E-Switch: Enable: mode(OFFLOADS), nvfs(8), active vports(9)
[   49.195354] mlx5_core 0000:39:00.0: lag map active ports: 1
[   49.195361] mlx5_core 0000:39:00.0: shared_fdb:1 mode:hash
[   49.321334] mlx5_core 0000:39:00.0: Operation mode is single FDB
[   49.733106] mlx5_core 0000:39:00.0: lag map active ports: 1, 2

管理 HugePages

注意： 此步骤应应用于所有 K8s Worker 节点。

Kubernetes 支持 Pod 中的应用程序分配和使用预分配的 HugePages。节点将自动发现并报告所有 HugePages 资源作为可调度资源。有关 K8s HugePages 管理的更多信息，请参见此处。有关内核命令行参数及参数描述的更多信息，请参见此处。

要分配 HugePages，需要修改 /etc/default/grub 中的 GRUB_CMDLINE_LINUX_DEFAULT 参数。我们 K8s Worker 节点的 GRUB_CMDLINE_LINUX_DEFAULT 参数如下：

...

GRUB_CMDLINE_LINUX_DEFAULT="iommu=pt numa_balancing=disable processor.max_cstate=0 default_hugepagesz=1G hugepagesz=1G hugepages=64 isolcpus=2-45 nohz_full=2-45 rcu_nocbs=2-45"

...

运行 update-grub 将配置应用到 grub 并重启服务器：

# update-grub
# reboot

Linux 桥接配置

注意： 此步骤应应用于所有 K8s Worker 节点。

Linux 桥接是一种标准接口，被各种 Linux 发行版广泛支持。Linux 桥接的基本功能在 upstream Linux 内核中实现。Linux bond 支持也包含在 upstream Linux 内核中。特定的 Linux 桥接功能在以下 upstream Linux 内核中实现：

带 VLAN 的桥接卸载 - 5.14
桥接 LAG 支持 - 5.15
桥接欺骗检查 - 5.16
桥接 QinQ 支持 - 6.0

加速 Linux 桥接是一种创新技术，旨在取代传统的 SR-IOV。它提供仅内核空间的解决方案，用于物理上行链路和 VF 之间的基本连接，无需依赖用户空间组件（如 Open vSwitch）。该解决方案可以通过附加功能（LAG/Bond、VGT+ 等）进行增强。

现在，我们创建并启用 systemd 服务，以便在系统启动时启动加速桥接。

在我们的部署中，加速 Linux 桥接通过标准服务 /etc/systemd/system/ab-configuration.service 创建。

[Unit]
Description=Accelerated Bridge Configuration
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/ab-config.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

创建 /usr/local/bin/ab-config.sh 脚本：

#!/bin/bash
# Accelerated Bridge Configuration Script

# Create bridge
ip link add name br0 type bridge
ip link set dev br0 up

# Add physical interfaces to bridge
ip link set dev enp57s0f0np0 master br0
ip link set dev enp57s0f1np1 master br0

# Create VFs and add to bridge
# (Assuming VFs are already created via netplan)
# Add VFs to bridge
for vf in /sys/class/net/enp57s0f0np0/device/virtfn*; do
    vf_name=$(basename $(readlink $vf/net))
    ip link set dev $vf_name master br0
    ip link set dev $vf_name up
done

for vf in /sys/class/net/enp57s0f1np1/device/virtfn*; do
    vf_name=$(basename $(readlink $vf/net))
    ip link set dev $vf_name master br0
    ip link set dev $vf_name up
done

使脚本可执行并启用服务：

# chmod +x /usr/local/bin/ab-config.sh
# systemctl enable ab-configuration.service
# systemctl start ab-configuration.service

[Unit]
Description=Configures Linux Bridge for using by K8s AB CNI
Wants=sys-devices-virtual-net-bond0.device
Before=sys-devices-virtual-net-bond0.device

[Service]
Type=oneshot
ExecStart=/usr/local/bin/configure-ab.sh
StandardOutput=journal+console
StandardError=journal+console

[Install]
WantedBy=online.target

脚本执行文件 - /usr/local/bin/configure-ab.sh。

#!/bin/bash
set -eux

#Create and configure bridge - accelbr for using it by K8s AB CNI

ip link add name accelbr type bridge
ip link set accelbr mtu 9216
ip link set bond0 master accelbr
ip link set accelbr up
ip link set accelbr type bridge ageing_time 200
ip link set accelbr type bridge vlan_filtering 1
ip link set accelbr type bridge fdb_flush

应用配置。

# chmod +x /usr/local/bin/configure-ab.sh
# systemctl daemon-reload
# systemctl enable ab-configuration.service

警告： 需要重启服务器才能正确激活服务。

K8s 集群部署与配置

本解决方案中的 Kubernetes 集群使用 Kubespray 从 部署节点 以非 root 用户 depuser 安装。

SSH 私钥与免密码登录

以部署用户（本例中为 depuser）登录 部署节点，并运行以下命令创建 SSH 私钥以配置免密码认证：

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/depuser/.ssh/id_rsa):
Created directory '/home/depuser/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/depuser/.ssh/id_rsa
Your public key has been saved in /home/depuser/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:IfcjdT/spXVHVd3n6wm1OmaWUXGuHnPmvqoXZ6WZYl0 depuser@depserver
The key's randomart image is:
+---[RSA 3072]----+
|                *|
|               .*|
|      . o . .  o=|
|       o + . o +E|
|        S o  .**O|
|         . .o=OX=|
|           . o%*.|
|             O.o.|
|           .*.ooo|
+----[SHA256]-----+

将您的 SSH 私钥（例如 ~/.ssh/id_rsa）复制到部署中的所有节点，运行以下命令（示例）：

$ ssh-copy-id depuser@192.168.100.25
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/depuser/.ssh/id_rsa.pub"
The authenticity of host '192.168.100.25 (192.168.100.25)' can't be established.
ECDSA key fingerprint is SHA256:6nhUgRlt9gY2Y2ofukUqE0ltH+derQuLsI39dFHe0Ag.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
depuser@192.168.100.25's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'depuser@192.168.100.25'"
and check to make sure that only the key(s) you wanted were added.

验证您是否能够免密码 SSH 连接到 部署中的所有节点，运行以下命令（示例）：

$ ssh depuser@192.168.100.25

Kubespray 部署与配置

通用设置

要在 部署节点 上安装运行 Kubespray 和 Ansible 所需的依赖项，运行以下命令：

$ cd ~
$ sudo apt -y install python3-pip jq
$ wget https://github.com/kubernetes-sigs/kubespray/archive/refs/tags/v2.21.0.tar.gz
$ tar zxf v2.21.0.tar.gz
# cd kubespray-2.21.0/
$ sudo pip3 install -r requirements.txt

警告： 后续命令的默认文件夹为 ~/kubespray-2.21.0。

部署自定义

创建新的集群配置和主机配置文件。将下面的 IP 地址替换为您的节点 IP 地址：

$ cp -rfp inventory/sample inventory/mycluster
$ declare -a IPS=(192.168.100.25 192.168.100.34 192.168.100.39)
$ CONFIG_FILE=inventory/mycluster/hosts.yaml python3 contrib/inventory_builder/inventory.py ${IPS[@]}

结果将创建 inventory/mycluster/hosts.yaml 文件。检查并更改文件中的主机配置。以下是此部署的示例。

all:
  hosts:
    node1:
      ansible_host: 192.168.100.25
      ip: 192.168.100.25
      access_ip: 192.168.100.25
    node2:
      ansible_host: 192.168.100.34
      ip: 192.168.100.34
      access_ip: 192.168.100.34
      node_labels:
        "node-role.kubernetes.io/worker": ""
    node3:
      ansible_host: 192.168.100.39
      ip: 192.168.100.39
      access_ip: 192.168.100.39
      node_labels:
        "node-role.kubernetes.io/worker": ""
  children:
    kube_control_plane:
      hosts:
        node1:
    kube_node:
      hosts:
        node2:
        node3:
    etcd:
      hosts:
        node1:
    k8s_cluster:
      children:
        kube_control_plane:
        kube_node:

检查并更改文件 inventory/mycluster/group_vars/k8s-cluster/k8s-cluster.yml 中的集群安装参数。在此文件中，通过设置所需的 kube_network_plugin 值来设置默认的 Kubernetes CNI：flannel（默认值：calico）。

...

# Choose network plugin (cilium, calico, contiv, weave or flannel. Use cni for generic cni plugin)
# Can also be set to 'cloud', which lets the cloud provider setup appropriate routing
kube_network_plugin: flannel

# Setting multi_networking to true will install Multus: https://github.com/intel/multus-cni
kube_network_plugin_multus: false

...

使用 KubeSpray Ansible Playbook 部署集群

运行以下命令启动部署过程：

$ ansible-playbook -i inventory/mycluster/hosts.yaml --become --become-user=root cluster.yml

此部署需要一些时间才能完成。确保没有遇到错误。如果部署成功，应显示类似以下的行。

... PLAY RECAP ***********************************************************************************************************************************************************************************

localhost                  : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
node1                      : ok=674  changed=114  unreachable=0    failed=0    skipped=1195 rescued=0    ignored=5
node2                      : ok=482  changed=68   unreachable=0    failed=0    skipped=707  rescued=0    ignored=1
node3                      : ok=487  changed=92   unreachable=0    failed=0    skipped=712  rescued=0    ignored=1

Sunday 12 March 2023  12:20:05 +0000 (0:00:00.115)       0:09:56.967 *****
===============================================================================
kubernetes/kubeadm : Join to cluster ------------------------------------------------------------------------------------------------------------------------------------------------- 30.36s
kubernetes/control-plane : kubeadm | Initialize first master ------------------------------------------------------------------------------------------------------------------------- 13.83s
download : download_container | Download image if required ---------------------------------------------------------------------------------------------------------------------------- 9.79s
kubernetes-apps/ansible : Kubernetes Apps | Start Resources --------------------------------------------------------------------------------------------------------------------------- 8.39s
kubernetes/preinstall : Preinstall | wait for the apiserver to be running

K8S集群部署验证

以下是使用Flannel CNI插件部署K8s集群的输出示例。

要确保Kubernetes集群安装正确，请运行以下命令：

# kubectl get nodes -o wide
NAME        STATUS   ROLES           AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION         CONTAINER-RUNTIME
node1       Ready    control-plane    1d   v1.25.6   192.168.100.25   <none>        Ubuntu 22.04.1 LTS   5.19.0-32-generic      containerd://1.6.15
node2       Ready    worker           1d   v1.25.6   192.168.100.34   <none>        Ubuntu 22.04.2 LTS   5.19.0-32-generic      containerd://1.6.15
node3       Ready    worker           1d   v1.25.6   192.168.100.39   <none>        Ubuntu 22.04.2 LTS   5.19.0-32-generic      containerd://1.6.15

# kubectl -n kube-system get pods -o wide
NAME                                         READY   STATUS    RESTARTS      AGE   IP               NODE        NOMINATED NODE   READINESS GATES
coredns-588bb58b94-8wccf                     1/1     Running   0              1d   10.233.64.2      node2       <none>           <none>
coredns-588bb58b94-zr62x                     1/1     Running   0              1d   10.233.67.89     node3       <none>           <none>
dns-autoscaler-5b9959d7fc-9rc8r              1/1     Running   0              1d   10.233.64.3      node1       <none>           <none>
kube-accelerated-bridge-cni-ds-amd64-bskjh   1/1     Running   0              1d   192.168.100.39   node3       <none>           <none>
kube-accelerated-bridge-cni-ds-amd64-lnhrm   1/1     Running   0              1d   192.168.100.34   node2       <none>           <none>
kube-apiserver-node1                         1/1     Running   0              1d   192.168.100.25   node1       <none>           <none>
kube-controller-manager-node1                1/1     Running   0              1d   192.168.100.25   node1       <none>           <none>
kube-flannel-6g2kj                           1/1     Running   0              1d   192.168.100.34   node2       <none>           <none>
kube-flannel-9xnbz                           1/1     Running   0              1d   192.168.100.25   node1       <none>           <none>
kube-flannel-skdnh                           1/1     Running   0              1d   192.168.100.39   node3       <none>           <none>
kube-proxy-rxvnj                             1/1     Running   0              1d   192.168.100.34   node2       <none>           <none>
kube-proxy-wgjjq                             1/1     Running   0              1d   192.168.100.25   node1       <none>           <none>
kube-proxy-wn8xj                             1/1     Running   0              1d   192.168.100.39   node3       <none>           <none>
kube-scheduler-node1                         1/1     Running   0              1d   192.168.100.25   node1       <none>           <none>
nginx-proxy-node2                            1/1     Running   0              1d   192.168.100.34   node2       <none>           <none>
nginx-proxy-node3                            1/1     Running   0              1d   192.168.100.39   node3       <none>           <none>
nodelocaldns-72zsq                           1/1     Running   0              1d   192.168.100.25   node1       <none>           <none>
nodelocaldns-9db7z                           1/1     Running   0              1d   192.168.100.39   node3       <none>           <none>
nodelocaldns-nt94k                           1/1     Running   0              1d   192.168.100.34   node2       <none>           <none>

为K8s集群安装NVIDIA Network Operator

NVIDIA Network Operator利用Kubernetes CRD和Operator SDK来管理网络相关组件，从而为K8s集群中的工作负载启用快速网络和RDMA。快速网络是K8s集群的辅助网络，适用于需要高带宽或低延迟的应用程序。

要使其正常工作，需要配置和部署多个组件。所有Operator的配置和安装步骤应在K8s Master节点上使用root用户账户执行。

前提条件

安装Helm。

# snap install helm --classic

部署

添加NVIDIA Network Operator Helm仓库。

# helm repo add mellanox https://mellanox.github.io/network-operator
# helm repo update

在用户主目录下创建values.yaml文件（示例）。

nfd:
  enabled: true

sriovNetworkOperator:
  enabled: false

ofedDriver:
  deploy: false
nvPeerDriver:
  deploy: false
rdmaSharedDevicePlugin:
  deploy: false

sriovDevicePlugin:
  deploy: true
  resources:
    - name: vflag
      pfNames: ["enp57s0f0np0"]
      devices: ["101e"]

deployCR: true
secondaryNetwork:
  deploy: true
  cniPlugins:
    deploy: true
  multus:
    deploy: true
  ipamPlugin:
    deploy: true

部署Operator。

# helm install -f ./values.yaml -n network-operator --create-namespace --wait mellanox/network-operator --generate-name
NAME: network-operator-1676546312
LAST DEPLOYED: Mon Mar 13 11:18:32 2023
NAMESPACE: network-operator
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Get Network Operator deployed resources by running the following commands:

$ kubectl -n network-operator get pods

要确保Operator部署正确，请运行以下命令。

# kubectl -n network-operator get pods -o wide
NAME                                                              READY   STATUS              RESTARTS   AGE   IP               NODE        NOMINATED NODE   READINESS GATES
cni-plugins-ds-vxzmq                                              1/1     Running             0          18s   192.168.100.34   node2       <none>           <none>
cni-plugins-ds-z526k                                              1/1     Running             0          18s   192.168.100.39   node3       <none>           <none>
kube-multus-ds-5lznw                                              1/1     Running             0          18s   192.168.100.39   node3       <none>           <none>
kube-multus-ds-jds9c                                              1/1     Running             0          18s   192.168.100.34   node2       <none>           <none>
network-operator-1676546312-85ccdf64cf-zmr65                      1/1     Running             0          43s   10.233.64.5      node1       <none>           <none>

network-operator-1676546312-node-feature-discovery-master-gnwp5   1/1     Running             0          43s   10.233.64.6      node1       <none>           <none>
network-operator-1676546312-node-feature-discovery-worker-8tbdp   1/1     Running             0          43s   10.233.64.4      node1       <none>           <none>
network-operator-1676546312-node-feature-discovery-worker-k8gdk   1/1     Running             0          43s   10.233.65.3      node2       <none>           <none>
network-operator-1676546312-node-feature-discovery-worker-ss4dx   1/1     Running             0          43s   10.233.66.2      node3       <none>           <none>
sriov-device-plugin-5p2xt                                         0/1     ContainerCreating   0          18s   192.168.100.39   node3       <none>           <none>
sriov-device-plugin-n9pjp                                         0/1     ContainerCreating   0          18s   192.168.100.34   node2       <none>           <none>
whereabouts-2dng2                                                 0/1     ContainerCreating   0          18s   192.168.100.34   node2       <none>           <none>
whereabouts-xjhq6                                                 0/1     ContainerCreating   0          18s   192.168.100.39   node3       <none>           <none>

检查工作节点资源。

# kubectl describe nodes node2
...

Addresses:
  InternalIP:  192.168.100.34
  Hostname:    node2
Capacity:
  cpu:                48
  ephemeral-storage:  459283568Ki
  hugepages-1Gi:      64Gi
  hugepages-2Mi:      0
  memory:             528157216Ki
  nvidia.com/vflag:   8
  pods:               110
Allocatable:
  cpu:                46
  ephemeral-storage:  421128251920
  hugepages-1Gi:      64Gi
  hugepages-2Mi:      0
  memory:             456751648Ki
  nvidia.com/vflag:   8
  pods:               110

...

部署加速桥接CNI插件

该插件在Kubernetes的容器和编排器中启用支持硬件卸载的Linux桥接。加速桥接CNI插件需要网卡支持SR-IOV技术，VF处于switchdev模式，并支持Linux桥接卸载。

使用以下YAML文件部署CNI插件。

# kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/accelerated-bridge-cni/master/images/accelerated-bridge-cni-daemonset.yaml

默认情况下，插件将部署在kube-system K8s命名空间中。

# kubectl -n kube-system get pod -o wide | grep bridge

kube-accelerated-bridge-cni-ds-amd64-bskjh   1/1     Running             0          43s   192.168.100.39   node3       <none>           <none>
kube-accelerated-bridge-cni-ds-amd64-lnhrm   1/1     Running             0          43s   192.168.100.34   node2       <none>           <none>

创建Linux桥接网络附加定义并部署。

您需要创建一个Linux桥接网络附加定义，以便将POD连接到辅助网络。加速桥接CNI支持多种部署模式：VLAN或TRUNK。

以下是VLAN模式的示例 - net-vst.yaml。

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: net-vst
  annotations:
    k8s.v1.cni.cncf.io/resourceName: nvidia.com/vflag
spec:
  config: '{
  "type": "accelerated-bridge",
  "cniVersion": "0.3.1",
  "name": "net-vst",
  "vlan": 2001,
  "mtu": 9000,
  "setUplinkVlan": true,
  "bridge": "accelbr",
  "capabilities": {"CNIDeviceInfoFile": true},
  "ipam": {
      "datastore": "kubernetes",
      "kubernetes": {
        "kubeconfig": "/etc/cni/net.d/whereabouts.d/whereabouts.kubeconfig"
      },
      "log_file": "/tmp/whereabouts.log",
      "log_level": "debug",
      "type": "whereabouts",
      "range": "192.168.101.0/24"
    }
}'

# kubectl create -f net-vst.yaml

检查网络附加定义是否成功部署。

# kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME      AGE
net-vst    1m

启用CPU和拓扑管理

CPU管理器管理CPU组并将工作负载约束到特定CPU。

CPU管理器适用于具有以下某些属性的工作负载：

需要尽可能多的CPU时间
对处理器缓存未命中敏感
低延迟网络应用程序
与其他进程协调并受益于共享单个处理器缓存

拓扑管理器使用从收集的提示中获取的拓扑信息，根据配置的拓扑管理器策略和POD请求的资源，决定POD是否可以在节点上被接受或拒绝。为了获得最佳性能，需要与CPU隔离以及内存和设备局部性相关的优化。

拓扑管理器适用于使用硬件加速器支持延迟关键执行和高吞吐量并行计算的工作负载。

注意： 要使用拓扑管理器，必须使用static策略的CPU管理器。

有关更多信息，请参阅控制节点上的拓扑管理策略和控制节点上的拓扑管理策略。

为了启用CPU管理器和拓扑管理器，在每个K8s工作节点的kubelet配置文件**/etc/kubernetes/kubelet-config.yaml**中添加以下行。

...
systemReserved:
  cpu: "2"
  memory: "4Gi"
  ephemeral-storage: "2Gi"
reservedSystemCpus: 0,1,46,47
cpuManagerPolicy: static
cpuManagerReconcilePeriod: 10s
topologyManagerPolicy: single-numa-node
featureGates:
  CPUManager: true
  TopologyManager: true

由于cpuManagerPolicy的更改，删除*/var/lib/kubelet/cpu_manager_state*并重新启动每个受影响的K8s工作节点上的kubelet服务。

# rm -f /var/lib/kubelet/cpu_manager_state
# service kubelet restart

应用程序

对于应用程序测试，使用了基于Ubuntu 22.04并包含inbox软件包的容器镜像。下面提供了容器镜像创建的Dockerfile示例。

FROM ubuntu:22.04
# Ubuntu 22.04 container with inbox Mellanox drivers

# LABEL about the custom image
LABEL maintainer=vitaliyra@nvidia.com
LABEL description="This is custom Container Image with inbox perftest package."

WORKDIR /tmp/
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get clean -y && apt-get -y update && apt-get install -y apt-utils udev vim bash sysstat && apt-get -y upgrade
RUN apt-get install -y iproute2 rdma-core libibmad5 ibutils ibverbs-utils infiniband-diags perftest \
            mstflint strace iputils-ping iperf3 netperf iperf dpdk dpdk-dev
RUN ln -fs /usr/share/zoneinfo/America/New_York /etc/localtime
RUN dpkg-reconfigure --frontend noninteractive tzdata && apt-get clean all -y
CMD bash

请使用您喜欢的容器构建工具（docker、podman等）从Dockerfile创建容器镜像，以便在下面的部署中使用。创建镜像后，将其推送到容器注册表。

警告： 本指南中列出的性能结果仅供参考，不应视为NVIDIA产品的正式性能目标。

RoCE和TCP流量测试

流量如测试床流程图所示。流量从一个POD通过网络接口net1发送到另一个POD的网络接口net1。流量分布在网卡的两个物理端口之间。RoCE流量测试使用Ubuntu PERFTEST inbox软件包中的ib_write_bw命令进行，如下所示。TCP流量测试与基于RoCE的测试类似，可以使用iperf3命令进行。

以下是一个用于运行基准测试的部署示例。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-inbox-dep
  labels:
    app: sriov
spec:
  replicas: 2
  selector:
    matchLabels:
      app: sriov
  template:
    metadata:
      labels:
        app: sriov
      annotations:
        k8s.v1.cni.cncf.io/networks: net-vst
    spec:
      containers:
      - image: < container image name >
        name: test-pod
        securityContext:
          capabilities:
            add: [ "IPC_LOCK" ]
        resources:
          requests:
            cpu: 10
            memory: 64Gi
            nvidia.com/vflag: 1
          limits:
            cpu: 10
            memory: 64Gi
            nvidia.com/vflag: 1
        command:
        - sh
        - -c
        - sleep inf

IB_WRITE_BW 测试服务器命令：

ib_write_bw -d rocep57s0f0v1 -q 20 -F a

IB_WRITE_BW 测试客户端命令：

ib_write_bw -d rocep57s0f0v0 192.168.101.4 --report_gbits -q 20 -F -a

输出示例：

...
---------------------------------------------------------------------------------------
 #bytes     #iterations    BW peak[Gb/sec]    BW average[Gb/sec]   MsgRate[Mpps]
 2          100000           0.067015            0.066925            4.182788
 4          100000           0.14               0.14   		   4.248459
 8          100000           0.27               0.27   		   4.248299
 16         100000           0.54               0.54   		   4.246437
 32         100000           1.09               1.09   		   4.247007
 64         100000           2.18               2.17   		   4.247745
 128        100000           4.35               4.35   		   4.247277
 256        100000           8.69               8.68   		   4.239377
 512        100000           17.36              17.35  		   4.236006
 1024       100000           34.54              34.52  		   4.213616
 2048       100000           68.45              68.37  		   4.173146
 4096       100000           135.30             129.47 		   3.951161
 8192       100000           169.81             169.68 		   2.589131
 16384      100000           170.64             170.58 		   1.301397
 32768      100000           170.29             169.29 		   0.645800
 65536      100000           169.69             169.03 		   0.322402
 131072     100000           169.28             167.92 		   0.160142
 262144     100000           169.12             167.85 		   0.080038
 524288     100000           169.19             167.79 		   0.040004
 1048576    100000           168.54             168.19 		   0.020050
 2097152    100000           168.30             167.79 		   0.010001
 4194304    100000           168.34             167.97 		   0.005006
 8388608    100000           168.34             168.20 		   0.002506
---------------------------------------------------------------------------------------

POD VF-LAG 加速网络端口根据测试接收了约 170Gb/s 的流量。

DPDK 流量模拟

DPDK 流量模拟如下图所示。

流量从 Trex 服务器通过 ens2f0 接口推送到 TestPMD POD 的网络接口 net1。TestPMD POD 转发 MAC 地址，并将入站流量通过同一 net2 重新路由到 Trex 服务器的 ens3f0 接口。测试使用 64B 消息。流量分布在网卡的两个物理端口之间。

TRex 服务器部署

我们在设置中使用 TRex 包 v3.02。有关详细的 TRex 安装和配置指南，请参阅 TRex 文档。

TRex 安装和配置步骤使用 root 用户 账户执行。

先决条件。

对于 TRex 服务器，使用安装了 RDMA 子系统的标准服务器。

使用 netplan 激活 TRex 应用程序使用的网络接口。在我们的部署中，使用了接口 ens2f0 和 ens2f1：

# This is the network config written by 'subiquity'
network:
  ethernets:
    ens4f0:
      dhcp4: true
      dhcp-identifier: mac
    ens2f0: {}
    ens2f1: {}
  version: 2

然后重新应用 netplan 并检查 ens2f0/ens2f1 网络接口的链路状态。

# netplan apply
# rdma link
link mlx5_0/1 state ACTIVE physical_state LINK_UP netdev ens2f0
link mlx5_1/1 state ACTIVE physical_state LINK_UP netdev ens2f1
link mlx5_2/1 state ACTIVE physical_state LINK_UP netdev ens4f0
link mlx5_3/1 state DOWN physical_state DISABLED netdev ens4f1

更新接口 ens2f0 和 ens2f1 的 MTU 大小。

# ip link set ens2f0 mtu 9000
# ip link set ens2f1 mtu 9000

安装。

创建 TRex 工作目录并解压 TRex 包。

# cd /tmp
# wget https://trex-tgn.cisco.com/trex/release/v3.02.tar.gz --no-check-certificate
# mkdir /scratch
# cd /scratch
# tar -zxf /tmp/v3.02.tar.gz
# chmod 777 -R /scratch

首次运行脚本。

下一步从文件夹 /scratch/v3.02 继续。

以交互模式运行 TRex 配置脚本。按照屏幕上的说明创建基本配置文件 /etc/trex_cfg.yaml。

# ./dpdk_setup_ports.py -i

将创建 /etc/trex_cfg.yaml 配置文件。稍后将更改此文件以适应我们的设置。

性能测试

接下来展示 DPDK 流量模拟的性能测试，在 TRex 流量生成器和运行在 K8s Worker 节点上的 TESTPMD 应用程序之间进行，符合上述测试平台图。

先决条件

在开始测试之前，使用 TESTPMD pod 中高性能接口的 MAC 地址更新 TRex 配置文件 /etc/trex_cfg.yaml。以下是完成此更新的步骤。

根据 YAML 配置文件 testpmd-inbox.yaml 在 K8s 集群上运行包含 TESTPMD 应用程序的 pod（容器镜像应包含 InfiniBand 用户空间驱动程序和 TESTPMD 应用程序）。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dpdk-inbox-dep
  labels:
    app: sriov
spec:
  replicas: 2
  selector:
    matchLabels:
      app: sriov
  template:
    metadata:
      labels:
        app: sriov
      annotations:
        k8s.v1.cni.cncf.io/networks: net-vst,net-vst
    spec:
      containers:
      - image: < container image name >
        name: dpdk-pod
        securityContext:
          capabilities:
            add: [ "IPC_LOCK", "NET_ADMIN" ]
        volumeMounts:
        - mountPath: /hugepages
          name: hugepage
        resources:
          requests:
            cpu: 10
            memory: 64Gi
            nvidia.com/vflag: 2
            hugepages-1Gi: 16Gi
          limits:
            cpu: 10
            memory: 64Gi
            nvidia.com/vflag: 2
            hugepages-1Gi: 16Gi
        command:
        - sh
        - -c
        - sleep inf
      volumes:
      - name: hugepage
        emptyDir:
          medium: HugePages

使用以下命令部署：

# kubectl apply -f testpmd-inbox.yaml

通过运行以下命令获取已部署 pod 的网络信息：

# kubectl get pod -o wide
NAME                               READY   STATUS        RESTARTS   AGE    IP            NODE    NOMINATED NODE   READINESS GATES
dpdk-inbox-dep-676476c78d-glbfs    1/1     Running       0          30s    10.233.92.5   node3   <none>           <none>

# kubectl exec -it dpdk-inbox-dep-676476c78d-glbfs -- ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if72: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether d2:c5:68:a5:47:36 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.233.65.239/24 brd 10.233.65.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::d0c5:68ff:fea5:4736/64 scope link valid_lft forever preferred_lft forever 50: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000 link/ether be:24:2d:ea:9a:73 brd ff:ff:ff:ff:ff:ff inet 192.168.101.3/24 brd 192.168.101.255 scope global net1 valid_lft forever preferred_lft forever inet6 fe80::bc24:2dff:feea:9a73/64 scope link valid_lft forever preferred_lft forever 57: net2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000 link/ether 76:c8:42:33:bf:94 brd ff:ff:ff:ff:ff:ff inet 192.168.101.5/24 brd 192.168.101.255 scope global net2 valid_lft forever preferred_lft forever inet6 fe80::74c8:42ff:fe33:bf94/64 scope link valid_lft forever preferred_lft forever

更新TRex配置文件 /etc/trex_cfg.yaml，使用NET1和NET2网络接口的MAC地址。

### Config file generated by dpdk_setup_ports.py ###

- version: 2
  interfaces: ['81:00.0', '81:00.1']
  port_info:
      - dest_mac: be:24:2d:ea:9a:73 # MAC OF NET1 INTERFACE
        src_mac:  0c:42:a1:1d:d1:7a
      - dest_mac: 76:c8:42:33:bf:94 # MAC OF NET2 INTERFACE
        src_mac:  0c:42:a1:1d:d1:7b

  platform:
      master_thread_id: 0
      latency_thread_id: 12
      dual_if:
        - socket: 0
          threads: [2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23]

在容器中运行TESTPMD应用：

# kubectl exec -it test-deployment-676476c78d-glbfs -- bash
root@test-deployment-676476c78d-glbfs:/tmp# # cat /sys/fs/cgroup/cpuset.cpus
12-21
# export | grep VFLAG
declare -x PCIDEVICE_NVIDIA_COM_VFLAG="0000:39:01.1,0000:39:00.2"
# dpdk-testpmd  -l 12-21 -m 1024 -a 0000:39:01.1 -a 0000:39:00.2 -- --burst=64 --txd=1024 --rxd=1024 --mbcache=512 --rxq=4 --txq=4 --nb-cores=1 --rss-udp --forward-mode=mac --eth-peer=0,0c:42:a1:1d:d1:63 --eth-peer=1,0c:42:a1:1d:d1:7b -a -i ...
testpmd>

警告：特定TESTPMD参数：

$PCIDEVICE_NVIDIA_COM_VFLAG - 系统变量，NET1、NET2的PCI地址

更多关于其他TESTPMD参数的信息：

https://doc.dpdk.org/guides/testpmd_app_ug/run_app.html?highlight=testpmd

https://doc.dpdk.org/guides/linux_gsg/linux_eal_parameters.html

在TRex服务器上运行TRex流量生成器：

# cd /scratch/v3.02/
# ./t-rex-64 -i -c 14 --no-ofed-check

在TRex服务器上打开第二个屏幕，并在文件夹 /scratch/v3.02 中创建流量生成文件 mlnx-trex.py：

from trex_stl_lib.api import *

class STLS1(object):

    def create_stream (self):

        pkt = Ether()/IP(src="https://networking-docs.nvidia.com/sol/16.0.0.1",dst="48.0.0.1")/UDP(dport=12)/(22*'x')

        vm = STLScVmRaw( [
                    STLVmFlowVar(name="v_port",
                                min_value=4337,
                                    max_value=5337,
                                    size=2, op="inc"),
                    STLVmWrFlowVar(fv_name="v_port",
                                    pkt_offset= "UDP.sport" ),
                    STLVmFixChecksumHw(l3_offset="IP",l4_offset="UDP",l4_type=CTRexVmInsFixHwCs.L4_TYPE_UDP),

                        ]
                    )

        return STLStream(packet = STLPktBuilder(pkt = pkt ,vm = vm ) ,
                        mode = STLTXCont(pps = 8000000) )

    def get_streams (self, direction = 0, **kwargs):
        # create 1 stream
        return [ self.create_stream() ]

# dynamic load - used for trex console or simulator
def register():
    return STLS1()

接下来，运行TRex控制台并向TESTPMD Pod生成流量：

# cd /scratch/v3.02/
# ./trex-console
Using 'python3' as Python interpeter

Connecting to RPC server on localhost:4501                   [SUCCESS]

Connecting to publisher server on localhost:4500             [SUCCESS]

Acquiring ports [0, 1]:                                      [SUCCESS]

Server Info:
Server version:   v3.02 @ STL
Server mode:      Stateless
Server CPU:       11 x Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz
Ports count:      2 x 100Gbps @ MT2892 Family [ConnectX-6 Dx]

-=TRex Console v3.0=-

Type 'help' or '?' for supported actions

trex> tui<enter>
...
tui> start -f mlnx-trex.py -m 30mpps -p 0
...
Global Statistitcs

connection   : localhost, Port 4501                       total_tx_L2  : 23.9 Gbps
version      : STL @ v3.02                                total_tx_L1  : 20.93 Gbps
cpu_util.    : 82.88% @ 11 cores (11 per dual port)       total_rx     : 17.31 Gbps
rx_cpu_util. : 0.0% / 0 pps                               total_pps    : 29.51 Mpps
async_util.  : 0.05% / 11.22 Kbps                         drop_rate    : 0 bps
total_cps.   : 0 cps                                      queue_full   : 0 pkts
...

总结

从上述测试可以看出，在POD中使用VF-LAG网络端口时，期望的流量约为30mpps。

警告：TRex和TESTPMD是强大的网络性能测试工具，但需要进行一些微调才能达到最佳效果。

警告：本指南中列出的性能结果仅供参考，不应视为NVIDIA产品的正式性能目标。

完成！

作者


	Vitaliy Razinkov Vitaliy Razinkov是NVIDIA网络团队的一名解决方案架构师，专注于复杂的Kubernetes、OpenShift和Microsoft解决方案。凭借超过25年的高级技术职位经验，他在设计和实施先进基础设施方面拥有深厚的专业知识。Vitaliy撰写了多份关于Microsoft技术、RoCE/RDMA加速机器学习在Kubernetes/OpenShift以及容器化解决方案的参考设计指南——所有这些都可以在NVIDIA网络文档中找到。

Vitaliy Razinkov Vitaliy Razinkov是NVIDIA网络团队的一名解决方案架构师，专注于复杂的Kubernetes、OpenShift和Microsoft解决方案。凭借超过25年的高级技术职位经验，他在设计和实施先进基础设施方面拥有深厚的专业知识。Vitaliy撰写了多份关于Microsoft技术、RoCE/RDMA加速机器学习在Kubernetes/OpenShift以及容器化解决方案的参考设计指南——所有这些都可以在NVIDIA网络文档中找到。

作者

头像	简介
	Amir Zeidner

多年来，Amir一直担任解决方案架构师，主要专注于电信领域，领导先进解决方案以满足5G、NFV和SDN网络基础设施需求。Amir在数据平面加速技术（如ASAP²和DPDK）方面的专业知识，加上对开源云基础设施的深入了解，使他能够在电信领域推广并提供独特的端到端NVIDIA网络解决方案。 | | | Itai Levy

过去几年中，Itai Levy一直担任解决方案架构师，是NVIDIA网络“解决方案实验室”团队的成员。Itai设计和执行围绕云计算、软件定义网络、存储和安全的前沿解决方案。他的主要专业领域包括NVIDIA BlueField数据处理单元（DPU）解决方案以及加速K8s/OpenStack平台。 |