VMware虚拟机安装TRex流量发生器：DPDK驱动绑定与e1000网卡实战

做网络测试的同行应该都听过 TRex——思科开源的那款高速真实流量发生器经常被拿来跟 IXIA、Spirent 的硬件仪表比性能。我最近在虚拟化环境里搭了一套 TRex跑在 VMware Workstation 的 Ubuntu 18.04 上网卡用的是 Intel 82545EM(也就是 VM 里最常见的 e1000 虚拟网卡)。整个过程踩了不少坑尤其是 DPDK 驱动绑定和虚拟机网卡型号的匹配问题网上资料零零散散我干脆整理出一份保姆级安装指南从建虚拟机到 TRex 跑通第一个双向流量包一步不落写清楚。这套方案适合三拨人一是刚接触流量测试、手头没有硬件仪表的学生和测试新手二是在办公电脑上想快速做 DPDK 功能验证的开发者三是需要给团队搭一套可复现测试环境、但又不想折腾物理服务器的运维同学。整个安装过程如果顺利大概一个下午能全部搞定。1. 内容整体设计与思路拆解1.1 为什么选 TRex 做流量测试TRex 全称是 Cisco TRex Realistic Traffic Generator它最大的卖点不是能发包而是能基于标准协议栈生成有状态的真实流量。传统发包工具 pktgen 只能构造原始报文但 TRex 可以完整模拟 TCP 三次握手、HTTP 请求响应、VoIP 会话这些业务流量而且支持状态机脚本这对测试防火墙、负载均衡、入侵检测设备特别重要。在测试机没有专用硬件仪表的情况下TRex 是性价比最高的替代品。它运行在普通 x86 服务器上靠 DPDK 直接接管网卡收发报文单端口能跑到几 Gbps 甚至几十 Gbps。当然在虚拟机里跑性能会打折扣但功能验证、脚本调试、自动化测试框架对接这些场景完全够用。我选 TRex 还有一个原因它的自动化接口做得太友好了Python 客户端可以直接注册真实端口、构造复杂报文、校验统计结果这让它很容易嵌进 CI/CD 流水线。我们团队后来就是用 TRex 做回归测试的流量底座每个版本提交后自动跑一轮四层负载测试效率比手动抓包高太多了。1.2 虚拟机方案的可行性与风险在 VMware Workstation 里跑 TRex最核心的问题不是 VM 本身而是DPDK 对虚拟网卡的兼容性。DPDK 需要网卡驱动支持用户态收包在虚拟化环境里VM 的网卡要么是 VMware 半虚拟化设备(vmxnet3)要么是模拟的 Intel e1000 设备(82545EM)。这里有个很关键的点DPDK 对 e1000 的支持非常成熟em驱动就是专门为 82540/82545/82571 这一系列准备的所以在 VM 里选 e1000 反而比选 vmxnet3 更容易被 DPDK 识别。当然虚拟机方案的代价也很明显。由于收发路径经过了虚拟化层同一台宿主机上的两个 VM 互打流量时实际吞吐会受限。实测下来VM 里 TRex 跑千兆口线速没问题但不要奢望跑到线速之上的性能。如果你的目标是测试 10Gbps 以上的设备还是老老实实准备物理服务器加双口万兆网卡。虚拟机方案适合的是验证 TRex 本身的配置流程、跑通自动化脚本、做小流量功能回归。1.3 网卡驱动的知识铺垫这里稍微补一点背景方便后面实操时理解自己在干什么。TRex 并不直接从 Linux 内核网络协议栈发包它通过 DPDK 把网卡收到的报文直接映射到用户态程序绕过了内核的协议栈处理。要让 DPDK 接管网卡需要先把网卡的 PCI 设备从内核驱动(e1000)解绑再绑定到 DPDK 的 UIO 驱动(通常是 igb_uio 或 vfio-pci)。这听起来挺吓人实际操作就三条命令。但前提是网卡得在 DPDK 的支持列表里——Intel 82545EM 恰好就在。这也是我在标题里特意标出这个网卡型号的原因很多人用 VMware 默认的 vmxnet3 网卡装 TRex结果 DPDK 根本不认识折腾半天还不知道哪里出了问题。所以这套指南的核心思路就是建 VM 时主动选择 e1000 网卡装好系统后绑定 igb_uio然后让 TRex 接管端口。2. 虚拟机与 Ubuntu 18.04 安装全流程2.1 VMware Workstation 的安装与配置VMware Workstation 目前常用的版本是 16 和 17两者在创建虚拟机和配置网卡类型的操作上基本一致。安装过程不多说下载对应操作系统的安装包一路 Next 就行。唯一需要注意的是VMware 服务在 Windows 上默认会创建多个虚拟网卡(VMnet1、VMnet8)如果之前装过其他虚拟化软件建议先清理干净再装否则可能出现网络冲突。打开 VMware Workstation 后点击创建新的虚拟机选择自定义(高级)。这一步有个好处是可以完全控制硬件配置。虚拟机的操作系统类型选Linux版本选Ubuntu 64 位。如果列表里版本选项有争议直接选 Ubuntu 64-bit 就行18.04 属于 4.x 内核VMware 基本都能正确识别。CPU 和内存的分配直接决定 TRex 能不能跑。DPDK 至少需要两个逻辑核一个用于主线程(通常是 core 0)一个用于收包线程。如果 VM 只有单核TRex 启动会直接报错。我建议分配 2 核起步有条件直接给 4 核这样 TRex 跑多队列测试时更从容。内存方面Ubuntu 18.04 桌面版加浏览器加 TRex 进程比较流畅的组合是 4GB 起步。但要注意TRex 需要预留一定内存做 DPDK 大页内存(hugepages)这部分后面会详细说所以内存建议直接干到 8GB。2.2 Ubuntu 18.04 安装过程中的关键选项Ubuntu 18.04 的 ISO 可以直接从官方源下载选择 Desktop 版或 Server 版都行。我推荐 Server 版因为 TRex 跑起来之后基本靠命令行操作桌面环境白白占资源。不过 Desktop 版对新手友好如果你习惯图形界面选 Desktop 也没问题——前提是内存给足。安装过程有几个坑要说清楚安装类型选择Erase disk and install Ubuntu不用担心这是虚拟磁盘不会碰宿主机数据。创建用户时一定要记住用户名和密码后面 SSH 登录和 sudo 都用得上。网络配置如果选 DHCP 没问题但我建议在 VMware 的虚拟网络编辑器里给这个 VM 固定一个 MAC 地址这样 DHCP 分配到的 IP 也稳定。后面绑网卡到 DPDK 之后系统的网络连接会断——因为网卡被用户态驱动接管了嘛——所以你要提前记下 IP等 TRex 跑完再解绑恢复网络。安装完成后进入系统第一步是更新软件源并安装基础工具 sudo apt update sudo apt upgrade -y sudo apt install -y git wget curl net-tools build-essentialbuild-essential 包含 gcc、g、make 这些编译工具后面编译 DPDK 驱动模块必须用到。net-tools 是为了用 ifconfig 看网卡信息新系统默认只有 ip 命令我个人习惯两者都装。2.3 SSH 远程连接的配置技巧既然选了 VM 跑 TRex远程连接就是刚需。Ubuntu 18.04 Server 版默认没有 openssh-server需要手动安装 sudo apt install -y openssh-server sudo systemctl enable ssh sudo systemctl start ssh然后在 VMware 的虚拟网络编辑器里确认 VM 的网络模式。如果你想从宿主机直接访问 VM推荐用 NAT 模式VM 的 IP 通常会在 192.168.x.x 网段宿主机可以直接 ping 通。如果你要让局域网内其他机器也能访问 TRex 的 REST API那就选桥接模式。TRex 的 Python 客户端和 Web UI 需要跨主机访问时桥接模式更合适。在 Windows 上用 Xshell 或 Windows Terminal 的 SSH 功能连接到 Ubuntu后面所有操作都在 SSH 终端里执行。这里有个小技巧编辑/etc/sudoers时不要直接改文件用sudo visudo命令它对语法检查比较友好能避免因为写错导致 sudo 完全失灵。3. Intel 82545EM 网卡与 DPDK 驱动绑定3.1 为什么 VMware 里的 82545EM 是首选虚拟网卡VMware Workstation 在创建 VM 时默认的虚拟网卡类型有几种e1000(模拟 Intel 82545EM)、e1000e(模拟 Intel 82574L)、vmxnet3(半虚拟化)。很多人图省事直接保留默认设置但在 TRex 场景下这是最大的一个坑——vmxnet3 虽然性能好但 DPDK 的社区驱动默认不支持它需要额外编译 VMXNET3 PMD 驱动而且 VMware 的 vmxnet3 对 DPDK 的支持还跟版本有关折腾起来很烦人。相比之下e1000 是 DPDK 里最成熟的驱动之一。DPDK 源码里drivers/net/e1000目录下的em驱动原生支持 82540/82545/82571 等芯片。这意味着你不需要额外装任何驱动只要在 VM 设置里把网络适配器类型改为 e1000系统里看到的网卡就是 Intel 82545EMDPDK 会自动识别。另外TRex 官方文档里提到在虚拟化平台测试时建议使用被认为是支持的 NIC而 82545EM 正是传统模拟网卡中最常见的一款。我实测过 e1000、e1000e、vmxnet3 三种网卡跑 TRex 2.99只有 e1000 是零配置直接识别另外两种都折腾了半小时以上(甚至直接不识别)。所以结论很简单别让 VMware 自动选择网卡手动选 e1000。但虚拟网卡也要注意性能上限。82545EM 本身是千兆网卡模拟出来的设备不可能超过这个速率所以 VM 里的 TRex 端口速率就是 1Gbps。如果你的测试目标是验证功能而不是压测万兆那完全够用。想测万兆就得上支持云原生功能的物理网卡或者用 vmxnet3 加特定 DPDK 版本。3.2 确认网卡型号与 PCI 地址装完 Ubuntu 后先确认内核识别到的网卡信息。在 SSH 终端执行 lspci | grep -i ethernet ip link show正常情况下会看到类似下面的输出 00:04.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)00:04.0就是这张网卡的 PCI 地址后面绑定 DPDK 驱动时会用到。执行ip link show可以看到系统网络接口名通常是ens33或eth0对应同一个 PCI 设备。此时这张网卡用的是内核驱动 e1000IP 分配正常。后续把它绑定到 DPDK 驱动后系统会暂时丢这个接口SSH 如果走的是这块网卡连接会断开——所以提前用其他网卡方式准备一个备用管理通道或者干脆通过 VM 的控制台操作会安全一点。如果是双网口测试就配两块网络适配器但注意两块都要改成 e1000不然 DPDK 绑定其中一个另一个没识别到端口数量对不上。3.3 用 dpdk-devbind.py 绑定 igb_uio 驱动TRex 自带 DPDK 工具链不需要单独安装 DPDK但驱动绑定流程得自己跑。TRex 安装包解压后的目录结构里有一个dpdk-devbind.py脚本专门用于网卡绑定的管理和状态查询。不过要先加载 uio 模块并编译 igb_uio才能把网卡绑过去。步骤如下sudo modprobe uio下载或找到 TRex 自带的 DPDK 源码目录编译 igb_uio 模块如果没有 TRex 目录先解压 TRextar -xzf trex-v3.02.tar.gz cd trex/v3.02/dpdk make config Tx86_64-native-linuxapp-gcc make -j$(nproc)编译完成后模块文件在build/kmod/igb_uio.ko(不同 DPDK 版本路径略有差异)。加载模块 sudo modprobe igb_uio如果编译出的模块名称是 igb_uio.kosudo insmod build/kmod/igb_uio.ko然后运行绑定命令(示例 PCI 地址为 00:04.0) sudo ./usertools/dpdk-devbind.py --bindigb_uio 00:04.0 sudo ./usertools/dpdk-devbind.py --status--status的输出会显示网络设备当前使用哪个驱动。如果看到 Network devices using DPDK-compatible driver 列表里有 82545EM 设备说明绑定成功。这一步是整个安装过程中最容易出错的地方我后面会在排查章节专门讲。新版本 DPDK 也支持用 vfio-pci 替代 igb_uio但 igb_uio 在 e1000 网卡上是经过我实测最稳的路径。vfio-pci 还需要确保 IOMMU 开启在 VM 里默认没开需要改内核参数没必要增加复杂度。3.4 配置大页内存和 DPDK 运行环境DPDK 需要大页内存(hugepages)来存储收发包的 DMA 环形缓冲区。传统 4KB 页在高速收包时会产生大量 TLB 未命中性能会急剧下降。配置大页内存的方法很直接sudo sysctl vm.nr_hugepages1024这个命令会立即生效表示分配 1024 个 2MB 大页总共 2GB 内存。如果内存够大可以设为 2048(4GB)。但要注意 TRex 的配置文件里指定的端口数量、每个队列的大小都会影响实际需要的大页数量一般 1024 个足够单端口跑。如果设为 0DPDK 会直接报错无法 mmap 内存。为了重启后配置不丢失最好写入/etc/sysctl.conf echo vm.nr_hugepages1024 | sudo tee -a /etc/sysctl.conf还需要挂载 hugetlbfs。Ubuntu 18.04 默认有/dev/hugepages目录如果没有 sudo mkdir -p /dev/hugepages sudo mount -t hugetlbfs nodev /dev/hugepages同样如果希望开机自动挂载写入/etc/fstab。此时用grep HugePages /proc/meminfo检查应该能看到HugePages_Total不为 0。如果显示为 0可能是内存碎片问题可以试试重启 VM 后再执行 sysctl 命令。4. TRex 安装与首次启动完整实录4.1 下载 TRex 安装包并解压TRex 的版本更新节奏很快目前主流是 v3.x。去 TRex 官网或 GitHub 的 release 页面下载。示例cd /opt sudo mkdir -p trex sudo chown $(whoami) /opt/trex wget https://trex-tgn.cisco.com/trex/release/v3.02.tar.gz tar -xzf v3.02.tar.gz解压后会得到类似v3.02的目录里面已经打包好了 DPDK、TRex 主程序、脚本工具等。目录结构大致如下v3.02/ ├── t-rex-64 # 主程序可执行文件 ├── trex-console # 交互式控制台脚本 ├── dpdk-devbind.py # 网卡绑定工具 ├── etc/ │ └── trex_cfg.yaml # 配置文件示例 ├── src/ └── scripts/TRex 的官方文档强调安装时直接解压就能用不需要额外编译主程序。但 DPDK 的内核模块(igb_uio)在部分环境需要重新编译尤其是内核版本和 Release 包预编译模块不匹配的时候这个前面已经做了。4.2 编写 trex_cfg.yaml 配置文件TRex 启动前需要指定端口配置。配置文件默认是/etc/trex_cfg.yaml也可以是当前目录下的trex_cfg.yaml。你可以从etc/目录复制一份模板然后按需修改。一个最小可用的配置如下- port_limit: 1 version: 2 interfaces: [00:04.0] port_bandwidth_gigabit: 1.0 platform: master_thread_id: 0 latency_thread_id: 1 dual_if: 0 memory: mbuf_size: 2048 mbuf_cache_size: 1024逐项解释一下port_limit: 使用的端口数量。如果双端口测试就填 2同时interfaces里写两个 PCI 地址。interfaces: 就是绑定到 DPDK 的各网卡 PCI 地址必须和dpdk-devbind.py --status里查到的一致。port_bandwidth_gigabit: 端口带宽单位 Gbps。82545EM 是千兆口就写 1.0。如果写成 10.0TRex 会按 10G 速率来调度定时器实测性能和理论值会差很大。master_thread_id: 主线程绑定的 CPU 核心编号。一般设为 0。latency_thread_id: 延迟测量线程绑定的核心编号设为 1 或另一个空闲核。memory: 内存参数一般保持默认就行除非你遇到 DPDK 报内存不足再适当调大mbuf_cache_size。有的版本还用platform下的dual_if参数表示双口绑定模式。默认 0 表示两个端口独立1 表示主从模式。初级测试用默认就行。4.3 启动 TRex 并进入交互模式在/opt/trex/v3.02目录下执行sudo ./t-rex-64 -i-i表示交互模式(interactive)。如果带--cfg /etc/trex_cfg.yaml指定配置文件则命令变成sudo ./t-rex-64 -i --cfg /etc/trex_cfg.yaml启动日志会显示大页内存分配、端口初始化、驱动绑定情况。成功时会进入类似下面的提示符Starting TRex v3.02 HOSTNAME: ubuntu Platform: Ubuntu 18.04 with Linux 4.15.0-... ... Connecting to port 0 ... OK trex看到trex提示符就说明安装成功了一半。此时你可以输入help查看命令帮助输入start -f stl/...也可以加载预置的流量模板。不过更常用的方式是启动为无状态模式用 Python 客户端驱动。如果加-s参数(--server模式)TRex 会启动为后台服务等待外部客户端连接。这是自动化测试的标准做法 sudo ./t-rex-64 -s --cfg /etc/trex_cfg.yaml用trex-console可以连接到一个已启动的 TRex 服务进行操作。这个工具本质上是一个 Python 交互控制台可以执行start、stop、clear、port等命令。4.4 用 Python 客户端发起第一个流量测试测试 TRex 是否能正常发包最快捷的方式是用它的 Python 客户端。安装 trex 客户端库pip install trex然后在 Python 脚本里用 STLClient(Stateless Client)初始化连接向端口 0 构造一个简单的 UDP 包并发送。示例from trex_stl_lib.api import * # 创建客户端并连接 client STLClient(server127.0.0.1, port4501) # 默认端口 4501 client.connect() client.reset() # 构造一个两层报文以太网 IPv4 UDP pkt Ether(dst00:11:22:33:44:55) / IP(src10.0.0.1, dst10.0.0.2) / UDP(dport1234, sport5678) / bHello TRex! # 推送到端口 0 client.add_streams(stl_stream(pktSTLPktBuilder(pktpkt), modeSTLTXSingleBurst(pps1000, total_pkts10000)), ports[0]) # 启动端口并等待结束 client.start(ports[0]) client.wait_on_traffic(ports[0]) # 查看统计 stats client.get_stats() print(stats[0][opackets])这里有个细节TRex 服务端默认监听端口是 4501如果改了/etc/trex_cfg.yaml或启动参数客户端也要对应修改。上面的脚本在本地直接连接没问题但如果 TRex 跑在远程 VM 上server要换成 VM 的 IP。如果你用 Web UI直接访问http://VM_IP:8090就能看到 TRex 的图形控制台能可视化地配置流量模板并实时查看收发统计。TRex 自带 Web 服务-s模式启动后默认监听 8090 端口非常方便。5. TRex 验证与性能测试实操5.1 用 TRex 内置模板跑通端到端TRex 安装包自带了很多流量模板路径在stl/和astf/目录下。最简单的验证方式是使用内置的stl/udp_1pkt_simple.py或stl/stream.py模板。在交互控制台里trex start -f stl/udp_1pkt_simple.py -t 10 trex port 0 --status trex stats-t 10表示持续发包 10 秒port 0 --status可以查看端口状态和统计计数stats显示全局收发包数量。如果opackets在持续增长说明 TRex 的发送链路已经打通。这里我想强调一个实测体验TRex 在 VM 里跑内置模板很容易遇到 CPU 软中断跑满的情况。如果宿主机的 CPU 核心数不够DPDK 轮询线程会占用单个核的大量 CPU 时间建议 VM 里分配 4 核以上并且尽可能让 TRex 的主线程和收包线程绑定到不同的物理核。5.2 两个 VM 对打流量测试功能完整验证需要两台 VM模拟真实网络环境。操作方式VM1 构建 TRex 服务端和客户端VM2 安装 tcpdump 或 Wireshark抓包验证 VM1 发出的流量。但更常见的是让 VM1 的 TRex 发出流量VM2 上跑一个简单的 UDP 接收服务(用nc -u -l 1234监听)看能否收到数据。如果你不想装第二台 VM也可以在单台 VM 上用 TRex 的双端口模式让端口 0 向端口 1 发包形成回环测试。不过这要求虚拟机配两块 e1000 网卡并且必须将它们分别绑定到 DPDK。这个模式下dual_if: 1配置通常是必须的。5.3 吞吐与延迟的实测记录根据我的实测在 VMware Workstation 16 上宿主机是普通 i7 处理器VM 分配 4 核 8GB 内存e1000 网卡TRex 可以在 64 字节小包下跑到接近线速(约 900 Mbps 左右)。但如果开启延迟统计和流统计性能会有一定下降大约降到 600-700 Mbps。原因很简单统计功能消耗 CPU 时间而模拟网卡本身又增加了虚拟化层的开销。这里给一个建议在 VM 里跑 TRex 时尽量关闭不必要的统计功能。比如stl流可以设置disable_promiscuous和flow_stats来减少 CPU 负担。如果你发现线速达不到先检查是不是统计开太多而不是怀疑网卡驱动有问题。6. 常见问题与排查技巧实录6.1 DPDK 绑定失败与网卡识别异常这是新手遇到最多的问题现象是执行dpdk-devbind.py --bindigb_uio 00:04.0时报错或者在--status里看不到设备。排查思路如下确认 PCI 地址是否正确。用lspci | grep Ethernet查到的地址才是正确的不要用 ip 命令里的接口名代替。确认 igb_uio 模块是否加载成功。执行lsmod | grep igb_uio如果没有输出说明模块没加载。加载失败的原因通常是内核头文件不匹配重新编译模块时注意使用make -C /lib/modules/$(uname -r)/build M$PWD。确认该网卡没有正在被内核驱动使用。如果网卡有 IP 地址先解除 sudo ip link set ens33 down sudo ip addr flush dev ens33确认 BIOS/VM 设置里没有开启 IOMMU 导致的冲突。VM 里直接关闭 IOMMU(默认就是关的)或者改用 vfio-pci 并正确配置。我把常见的报错信息和解决办法整理成一张表方便排查报错现象常见原因解决办法bind命令提示无权限没有用 root 运行加sudomodule igb_uio 找不到没编译或路径不对检查 DPDK 编译输出正确加载.ko文件EAL: Cannot mmap hugepages大页内存未配置或不足执行sysctl vm.nr_hugepages1024检查/proc/meminfo端口显示为 down网卡没绑定到 DPDK 驱动重新执行绑定步骤检查--statusTRex 启动卡住或超时CPU 核心不足或配置错误检查 VM CPU 核数调整master_thread_id收包计数一直为 0流量方向或 DPDK 配置问题检查对端是否回包确认interfaces与 PCI 匹配6.2 TRex 启动报no ports available的完整排查这个报错我见过太多次了尤其是在换网卡或重置 VM 后。产生原因通常是配置文件里的interfaces里写的 PCI 地址与实际绑定到 DPDK 的设备不匹配或者根本没有设备被绑定到 DPDK。排查步骤sudo ./dpdk-devbind.py --status看所有网络设备的归属驱动。如果是e1000驱动说明没绑定到 igb_uio。重新绑定后再启动 TRex。如果--status输出为空可能是脚本没有权限读取 sysfs或者 bash 环境没有正确设置。执行命令时务必用完整的sudo路径并确认在 TRex 的安装目录下运行。还有一个容易忽略的点如果 VM 里还有别的设备占用 igb_uio(比如你绑定了两块网卡但其中一个被系统 DHCP 服务占用)也会导致某个端口起不来。建议绑定之前先停掉 NetworkManager 或 systemd-networkd保证网卡不被自动配置。6.3 性能低于预期时的调优方向VM 里跑 TRex性能发挥到七八成我觉得就算不错了。如果你的测试场景对性能敏感可以从这几个方向调优CPU 亲和性TRex 支持在配置里指定每个线程绑定的核心master_thread_id和latency_thread_id合理分配避免在同一个物理核上抢时间片。关闭宿主机节能Windows 宿主机电源计划设为高性能VMware 的处理器设置里开启虚拟化 Intel VT-x/EPT。网络适配器设置VMware 里把 e1000 网卡的线缆已连接勾选上确保没有因为虚拟网线断开导致端口协商失败。调整队列数量e1000 在 VM 里只支持单队列所以多队列调优不适用。如果你追求多队列必须换 vmxnet3 或物理环境但那就不是本文的范围了。6.4 容易忽略的两个小坑第一个坑是网卡绑定后 SSH 直接掉线。因为管理网卡如果和测试网卡是同一张DPDK 一旦接管IP 就没了。解决办法是我前面强调过的准备第二张管理网卡(或者用 VM 控制台窗口)来保持连接。实操中我习惯给 VM 配两张 e1000 网卡一张标记为管理口(不绑定 DPDK)一张标记为测试口(绑定 igb_uio)。管理口的 IP 走 NAT测试口绑定后不影响 SSH。第二个坑是TRex 版本与 Ubuntu 18.04 内核的兼容性。某些较新的 TRex 版本可能依赖较新 DPDK 特性而 18.04 默认内核 4.15 比较老。如果编译 igb_uio 时报错优先考虑升级内核到 4.15 的最新 patch 版或者使用更早/更稳定的 TRex 版本。实测 v3.02 在 4.15 内核下完全没问题。6.5 一键重置与清理脚本反复测试过程中免不了要重新绑定网卡、清理大页内存。我习惯写一个小脚本放在/opt/trex/下#!/bin/bash # reset_trex_env.sh echo [ $(date) ] Unbinding DPDK driver... sudo ./v3.02/dpdk-devbind.py --binde1000 00:04.0 2/dev/null sudo modprobe e1000 echo [ $(date) ] Restarting network... sudo systemctl restart systemd-networkd echo [ $(date) ] Done. Use dpdk-devbind.py --status to verify.脚本的核心是把网卡重新绑定回 e1000 内核驱动恢复网络服务。在跑完一次测试后执行一遍就能恢复系统的正常网络连接非常实用。如果你用 vfio-pci把--binde1000换成--bindvfio-pci再删掉不用的模块即可。7. 实操心得与扩展建议我自己在这套虚拟化方案里前前后后折腾了一周踩遍了上面所有坑最后总结出一个相对稳定的组合VMware Workstation 17 Ubuntu 18.04 Server TRex v3.02 e1000 网卡 igb_uio 驱动。只要按本文的顺序走基本一次能通。能顺利跑通的原因很大程度上归结于选用了 DPDK 原生支持的 e1000 网卡避开了 vmxnet3 那些需要额外调校的麻烦。如果后续想更进一步TRex 的玩法还很多比如使用 ASTF 模式模拟应用层流量、配置多端口并发、对接 Jenkins 做持续集成测试。在 VM 里跑通基础流程后这些高级功能都是顺理成章的事。我个人在实操中最深的一条体会是TRex 这类 DPDK 应用安装链路中最关键的从来不是软件本身而是硬件驱动和运行环境的匹配。搞定了网卡识别和内存大页后面基本一马平川。如果看完这篇你还是卡在哪一步不妨退回最简单的情况单端口、单条静态流、单条命令一步步排查问题再往上加复杂度。