前言在服务器网卡性能测试中DPDK 是绕不开的“性能天花板”。最近在超聚变 V7/V8 服务器Intel Xeon搭载Intel E810-XXV 25G 双口网卡上配合信而泰Renix测试仪表完成了一次基于 DPDKl3fwd的三层双端口双向转发测试。由于网上大多是基于 CentOS/BCLinux 的教程且针对 L3fwd 的流量走向与仪表配置讲得不够透彻导致新手极易踩坑比如明明打流了DPDK 接收却一直是 0或者疯狂丢包。本文基于Ubuntu 22.04 LTS系统从底层原理、环境搭建、路由逻辑、仪表配置四个维度带你完整跑通这套测试闭环并附上血泪排障经验。一、 核心原理小白必读1.1 DPDK 与 L3fwd 是什么DPDK (Data Plane Development Kit)简单来说它是一个“劫持”了网卡控制权的开发套件。它绕过 Linux 内核庞大的协议栈直接在用户态采用轮询模式PMD收发数据包从而榨干网卡的极限性能。L3fwd是 DPDK 官方提供的一个三层网络层转发示例程序。它的工作逻辑很纯粹收包 - 提取目的 IP - 查本地路由表 - 从指定端口转发出去。1.2 流量打不通因为这三个条件缺一不可为了让 DPDK 成功转发报文你的环境必须同时满足二层 MAC 匹配仪表发出的包目的 MAC 必须是服务器网卡的真实 MAC否则网卡硬件层直接过滤。三层 IP 路由命中仪表发出的包目的 IP 必须在l3fwd启动时加载的路由表里否则查表失败被丢弃。双向闭环仪表 Port_1 发往服务器 Port 0服务器查路由后从 Port 1 发出最终被仪表 Port_2 接收。二、 环境准备与编译 (Ubuntu 22.04)2.1 安装编译依赖Ubuntu 下的包名与 CentOS 不同直接复制以下命令sudo apt update sudo apt install -y build-essential python3 python3-pip pkg-config libnuma-dev libpcap-dev libelf-dev libssl-dev meson ninja-build2.2 下载与编译 DPDK 24.11.7mkdir -p ~/dpdk cd ~/dpdk wget https://fast.dpdk.org/rel/dpdk-24.11.7.tar.xz tar xf dpdk-24.11.7.tar.xz cd dpdk-stable-24.11.7 编译 DPDK 并包含 l3fwd 示例 meson setup build -Dexamplesl3fwd ninja -C build编译完成后生成的l3fwd可执行文件位于build/examples/dpdk-l3fwd。三、 大页内存与网卡绑定3.1 配置 HugepagesUbuntu 默认没有挂载大页内存我们需要手动分配并挂载 2MB 的大页E810 推荐分配 1024 个# 临时分配 1024 个 2MB 的大页 sudo sysctl -w vm.nr_hugepages1024 sudo mkdir -p /mnt/huge sudo mount -t hugetlbfs nodev /mnt/huge3.2 绑定网卡到 vfio-pci首先查看网卡 PCI 地址假设是0000:2a:00.0和0000:2a:00.1lspci | grep -i ether然后关闭内核驱动绑定至 DPDK# 加载 vfio 模块 sudo modprobe vfio-pci 关闭网卡并解绑Ubuntu 网卡名通常是 enpXXX请根据实际情况替换 sudo ip link set enp42s0f0 down sudo ip link set enp42s0f1 down 绑定 sudo ./usertools/dpdk-devbind.py --bindvfio-pci 0000:2a:00.0 0000:2a:00.1 确认状态显示 drivervfio-pci 即成功 sudo ./usertools/dpdk-devbind.py --status四、 L3fwd 启动与路由表解析4.1 L3fwd 默认路由如果不使用外部文件l3fwd默认加载的路由表如下去往198.18.0.0/24的包从Port 0发出。去往198.18.1.0/24的包从Port 1发出。4.2 启动命令sudo ./build/examples/dpdk-l3fwd \ -l 1,2,3,4,5,6,7,8 -n 4 -- \ -P -p 0x3 \ --config(0,0,1),(0,1,2),(0,2,3),(0,3,4),(1,0,5),(1,1,6),(1,2,7),(1,3,8) \ --parse-ptype-P开启混杂模式。-p 0x3掩码表示使用第 0 和第 1 个网口。--config核心绑定端口 0 用 1~4 核处理端口 1 用 5~8 核处理。五、 信而泰 (Renix) 仪表配置保姆级解析假设你的连线是仪表 Port_1 连服务器 Port 0仪表 Port_2 连服务器 Port 1。根据日志服务器 Port 0 的 MAC 是6C:B3:11:00:1D:28Port 1 是6C:B3:11:00:1D:2A。5.1 MAC 与 IP 配置矩阵配置项流 1 (正向流)流 2 (反向流)配置原理与作用发送端口Port_1Port_2仪表的物理发包口。目的 MAC6C:B3:11:00:1D:286C:B3:11:00:1D:2A【极其关键】必须填服务器对应的 MAC否则网卡硬件直接丢弃。源 MAC默认默认随便填因为l3fwd转发时会自动重写源 MAC。源 IPv41.1.1.22.2.2.2随便填不冲突即可。目的 IPv4198.18.1.10198.18.0.10【极其关键】必须落在l3fwd的路由表内否则查表失败。启用签名勾选勾选仪表统计流量的“身份证”不勾选无法计算时延和精确丢包。5.2信而泰 RFC 2544 完整测试流程第一阶段测试前准备基准打通在做 2544 之前必须先确保你手动配置的两条流双向能 100% 无丢包转发否则 2544 测试一定会失败。这一步是整个测试的“地基”RFC 2544 的吞吐量、时延、丢包率等指标都是在这两条已经打通的流基础上做速率扫描和统计的。如果基准流本身就存在丢包向导在探底过程中会把“环境问题”误判成“性能瓶颈”最终得到的吞吐量曲线和时延数据都不可信白白浪费几十分钟甚至几小时的测试时间。因此建议先把发送速率压到 10% 线速确认收发计数完全对齐、丢包率为 0再进入向导配置阶段。启动 L3fwd确保服务器端命令已运行。手动打流在仪表“流模板”中启动你配置好的两条流目的 IP 在 198.18.0.x 和 198.18.1.x。核对基准仪表上的发送速率设为 10% 线速观察接收端。必须做到发多少、收多少、零丢包。如果此时就丢包先去排查 L3fwd核隔离、NUMA等不要往下走。第二阶段Renix 向导配置核心避坑启动向导菜单栏 - 配置向导 - 测试套件 - RFC 2544 向导。选择测试项勾选 吞吐量 (Throughput)、时延 (Latency)、丢包率 (Packet Loss)。选择端口选择仪表连接服务器的 Port_1 和 Port_2。配置流防止多出流的关键模式选择必须选择“手动 (Manual)”模式。流选择在下方列表中勾选你之前调通的那两条原始流取消勾选其他任何流。配置测试参数帧长勾选用例要求的 64, 128, 256, 512, 1024, 1280, 1518。测试时长设为 60 秒/轮。精度设为 10%最高效或 1%更精确但耗时极长。可接受丢包率设为 0.001%对应测试用例要求。保存并运行点击“完成”向导会自动开始执行。第三阶段DPDK 侧性能保障解决丢包RFC 2544 的吞吐量测试会从 100% 线速疯狂往下探底如果 DPDK 侧有性能瓶颈就会出现疯狂丢包。隔离 CPU 核心在 Ubuntu 的 /etc/default/grub 中找到 GRUB_CMDLINE_LINUX加入 isolcpus1-8 rcu_nocbs1-8然后 sudo update-grub 并重启。这能防止操作系统抢占 DPDK 的轮询核。关闭校验和在仪表的流编辑中尝试把 IP/UDP 的 Checksum 字段设为 0或者确保仪表开启了硬件 Offload。确认 NUMA 同侧用 lscpu 和 lspci -vv 确认你的 E810 网卡插在哪个 CPU 上L3fwd 的 -l 参数就只绑那个 CPU 的核心。第四阶段结果查看与保存测试结束后弹出 Result Analyzer 窗口。看吞吐量看 Throughput (fps/bps) 的数值。看时延看平均时延和最大时延。导出报告点击左上角 文件 - 导出保存为 PDF 或 HTML 格式。5.3逐包变化 IP (Modifier 递增配置)测试方案要求“逐包变化目的 IP”以测试查表性能。在报文编辑界面右键Destination IP- 选择Modifier流 1起始198.18.1.1步长1Count 设为 254。流 2起始198.18.0.1步长1Count 设为 254。 避坑指南为什么 Count 是 254因为l3fwd默认路由是/24掩码只认识1~254。如果你设成了 1000超过 254 后的 IP (如198.18.1.255) 在路由表里找不到就会被 DPDK 丢弃导致仪表上显示凭空丢包六、 常见排障与丢包分析6.1 为什么仪表显示接收报文为 0MAC 填错了核对仪表的目的 MAC 是否和 DPDK 终端打印的网卡 MAC 完全一致。没开混杂模式启动命令里是不是漏了-P参数。IP 不在路由表检查仪表的目的 IP 是否落在198.18.0.x或198.18.1.x。发送端口地址没配对信而泰界面里的“发送端口地址”是指测试仪机箱的管理地址不要把它当成目的 MAC 填进去。6.2 为什么刚打流就疯狂丢包丢包率 20%Modifier 越界正如前文所述递增数量超过了 254后面的 IP 匹配不到路由。线速过高导致 CPU 瓶颈25G 跑 64 字节小包线速可达 37 Mpps。检查服务器 CPU 是否被打满top命令如果是性能瓶颈适当降低仪表的发送百分比如调到 10%。NUMA 跨节点网卡插在 CPU 0 的 PCIe 槽但--config绑定的核在 CPU 1跨 NUMA 访存性能会大打折扣。用lscpu确认绑核与网卡在同一 NUMA 节点。没有使能签名如果仪表没有勾选启用签名DPDK 转发回来的包仪表无法匹配到具体的某一条流会全部当作无效包处理。
前言在服务器网卡性能测试中DPDK 是绕不开的“性能天花板”。最近在超聚变 V7/V8 服务器Intel Xeon搭载Intel E810-XXV 25G 双口网卡上配合信而泰Renix测试仪表完成了一次基于 DPDKl3fwd的三层双端口双向转发测试。由于网上大多是基于 CentOS/BCLinux 的教程且针对 L3fwd 的流量走向与仪表配置讲得不够透彻导致新手极易踩坑比如明明打流了DPDK 接收却一直是 0或者疯狂丢包。本文基于Ubuntu 22.04 LTS系统从底层原理、环境搭建、路由逻辑、仪表配置四个维度带你完整跑通这套测试闭环并附上血泪排障经验。一、 核心原理小白必读1.1 DPDK 与 L3fwd 是什么DPDK (Data Plane Development Kit)简单来说它是一个“劫持”了网卡控制权的开发套件。它绕过 Linux 内核庞大的协议栈直接在用户态采用轮询模式PMD收发数据包从而榨干网卡的极限性能。L3fwd是 DPDK 官方提供的一个三层网络层转发示例程序。它的工作逻辑很纯粹收包 - 提取目的 IP - 查本地路由表 - 从指定端口转发出去。1.2 流量打不通因为这三个条件缺一不可为了让 DPDK 成功转发报文你的环境必须同时满足二层 MAC 匹配仪表发出的包目的 MAC 必须是服务器网卡的真实 MAC否则网卡硬件层直接过滤。三层 IP 路由命中仪表发出的包目的 IP 必须在l3fwd启动时加载的路由表里否则查表失败被丢弃。双向闭环仪表 Port_1 发往服务器 Port 0服务器查路由后从 Port 1 发出最终被仪表 Port_2 接收。二、 环境准备与编译 (Ubuntu 22.04)2.1 安装编译依赖Ubuntu 下的包名与 CentOS 不同直接复制以下命令sudo apt update sudo apt install -y build-essential python3 python3-pip pkg-config libnuma-dev libpcap-dev libelf-dev libssl-dev meson ninja-build2.2 下载与编译 DPDK 24.11.7mkdir -p ~/dpdk cd ~/dpdk wget https://fast.dpdk.org/rel/dpdk-24.11.7.tar.xz tar xf dpdk-24.11.7.tar.xz cd dpdk-stable-24.11.7 编译 DPDK 并包含 l3fwd 示例 meson setup build -Dexamplesl3fwd ninja -C build编译完成后生成的l3fwd可执行文件位于build/examples/dpdk-l3fwd。三、 大页内存与网卡绑定3.1 配置 HugepagesUbuntu 默认没有挂载大页内存我们需要手动分配并挂载 2MB 的大页E810 推荐分配 1024 个# 临时分配 1024 个 2MB 的大页 sudo sysctl -w vm.nr_hugepages1024 sudo mkdir -p /mnt/huge sudo mount -t hugetlbfs nodev /mnt/huge3.2 绑定网卡到 vfio-pci首先查看网卡 PCI 地址假设是0000:2a:00.0和0000:2a:00.1lspci | grep -i ether然后关闭内核驱动绑定至 DPDK# 加载 vfio 模块 sudo modprobe vfio-pci 关闭网卡并解绑Ubuntu 网卡名通常是 enpXXX请根据实际情况替换 sudo ip link set enp42s0f0 down sudo ip link set enp42s0f1 down 绑定 sudo ./usertools/dpdk-devbind.py --bindvfio-pci 0000:2a:00.0 0000:2a:00.1 确认状态显示 drivervfio-pci 即成功 sudo ./usertools/dpdk-devbind.py --status四、 L3fwd 启动与路由表解析4.1 L3fwd 默认路由如果不使用外部文件l3fwd默认加载的路由表如下去往198.18.0.0/24的包从Port 0发出。去往198.18.1.0/24的包从Port 1发出。4.2 启动命令sudo ./build/examples/dpdk-l3fwd \ -l 1,2,3,4,5,6,7,8 -n 4 -- \ -P -p 0x3 \ --config(0,0,1),(0,1,2),(0,2,3),(0,3,4),(1,0,5),(1,1,6),(1,2,7),(1,3,8) \ --parse-ptype-P开启混杂模式。-p 0x3掩码表示使用第 0 和第 1 个网口。--config核心绑定端口 0 用 1~4 核处理端口 1 用 5~8 核处理。五、 信而泰 (Renix) 仪表配置保姆级解析假设你的连线是仪表 Port_1 连服务器 Port 0仪表 Port_2 连服务器 Port 1。根据日志服务器 Port 0 的 MAC 是6C:B3:11:00:1D:28Port 1 是6C:B3:11:00:1D:2A。5.1 MAC 与 IP 配置矩阵配置项流 1 (正向流)流 2 (反向流)配置原理与作用发送端口Port_1Port_2仪表的物理发包口。目的 MAC6C:B3:11:00:1D:286C:B3:11:00:1D:2A【极其关键】必须填服务器对应的 MAC否则网卡硬件直接丢弃。源 MAC默认默认随便填因为l3fwd转发时会自动重写源 MAC。源 IPv41.1.1.22.2.2.2随便填不冲突即可。目的 IPv4198.18.1.10198.18.0.10【极其关键】必须落在l3fwd的路由表内否则查表失败。启用签名勾选勾选仪表统计流量的“身份证”不勾选无法计算时延和精确丢包。5.2信而泰 RFC 2544 完整测试流程第一阶段测试前准备基准打通在做 2544 之前必须先确保你手动配置的两条流双向能 100% 无丢包转发否则 2544 测试一定会失败。这一步是整个测试的“地基”RFC 2544 的吞吐量、时延、丢包率等指标都是在这两条已经打通的流基础上做速率扫描和统计的。如果基准流本身就存在丢包向导在探底过程中会把“环境问题”误判成“性能瓶颈”最终得到的吞吐量曲线和时延数据都不可信白白浪费几十分钟甚至几小时的测试时间。因此建议先把发送速率压到 10% 线速确认收发计数完全对齐、丢包率为 0再进入向导配置阶段。启动 L3fwd确保服务器端命令已运行。手动打流在仪表“流模板”中启动你配置好的两条流目的 IP 在 198.18.0.x 和 198.18.1.x。核对基准仪表上的发送速率设为 10% 线速观察接收端。必须做到发多少、收多少、零丢包。如果此时就丢包先去排查 L3fwd核隔离、NUMA等不要往下走。第二阶段Renix 向导配置核心避坑启动向导菜单栏 - 配置向导 - 测试套件 - RFC 2544 向导。选择测试项勾选 吞吐量 (Throughput)、时延 (Latency)、丢包率 (Packet Loss)。选择端口选择仪表连接服务器的 Port_1 和 Port_2。配置流防止多出流的关键模式选择必须选择“手动 (Manual)”模式。流选择在下方列表中勾选你之前调通的那两条原始流取消勾选其他任何流。配置测试参数帧长勾选用例要求的 64, 128, 256, 512, 1024, 1280, 1518。测试时长设为 60 秒/轮。精度设为 10%最高效或 1%更精确但耗时极长。可接受丢包率设为 0.001%对应测试用例要求。保存并运行点击“完成”向导会自动开始执行。第三阶段DPDK 侧性能保障解决丢包RFC 2544 的吞吐量测试会从 100% 线速疯狂往下探底如果 DPDK 侧有性能瓶颈就会出现疯狂丢包。隔离 CPU 核心在 Ubuntu 的 /etc/default/grub 中找到 GRUB_CMDLINE_LINUX加入 isolcpus1-8 rcu_nocbs1-8然后 sudo update-grub 并重启。这能防止操作系统抢占 DPDK 的轮询核。关闭校验和在仪表的流编辑中尝试把 IP/UDP 的 Checksum 字段设为 0或者确保仪表开启了硬件 Offload。确认 NUMA 同侧用 lscpu 和 lspci -vv 确认你的 E810 网卡插在哪个 CPU 上L3fwd 的 -l 参数就只绑那个 CPU 的核心。第四阶段结果查看与保存测试结束后弹出 Result Analyzer 窗口。看吞吐量看 Throughput (fps/bps) 的数值。看时延看平均时延和最大时延。导出报告点击左上角 文件 - 导出保存为 PDF 或 HTML 格式。5.3逐包变化 IP (Modifier 递增配置)测试方案要求“逐包变化目的 IP”以测试查表性能。在报文编辑界面右键Destination IP- 选择Modifier流 1起始198.18.1.1步长1Count 设为 254。流 2起始198.18.0.1步长1Count 设为 254。 避坑指南为什么 Count 是 254因为l3fwd默认路由是/24掩码只认识1~254。如果你设成了 1000超过 254 后的 IP (如198.18.1.255) 在路由表里找不到就会被 DPDK 丢弃导致仪表上显示凭空丢包六、 常见排障与丢包分析6.1 为什么仪表显示接收报文为 0MAC 填错了核对仪表的目的 MAC 是否和 DPDK 终端打印的网卡 MAC 完全一致。没开混杂模式启动命令里是不是漏了-P参数。IP 不在路由表检查仪表的目的 IP 是否落在198.18.0.x或198.18.1.x。发送端口地址没配对信而泰界面里的“发送端口地址”是指测试仪机箱的管理地址不要把它当成目的 MAC 填进去。6.2 为什么刚打流就疯狂丢包丢包率 20%Modifier 越界正如前文所述递增数量超过了 254后面的 IP 匹配不到路由。线速过高导致 CPU 瓶颈25G 跑 64 字节小包线速可达 37 Mpps。检查服务器 CPU 是否被打满top命令如果是性能瓶颈适当降低仪表的发送百分比如调到 10%。NUMA 跨节点网卡插在 CPU 0 的 PCIe 槽但--config绑定的核在 CPU 1跨 NUMA 访存性能会大打折扣。用lscpu确认绑核与网卡在同一 NUMA 节点。没有使能签名如果仪表没有勾选启用签名DPDK 转发回来的包仪表无法匹配到具体的某一条流会全部当作无效包处理。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
