Zynq网口速率上不去这种事十有八九不是硬件坏了而是测试方法不对。很多人在把Linux跑起来之后用默认的iperf单线程去测TCP吞吐卡在四五百兆就以为是板子设计有问题或者驱动没调好折腾半天其实只是没把带宽压满。这期内容我就围绕Zynq上的千兆网口聊聊iPerf多线程测试的正确打开方式以及你大概率会踩进去的坑。1. 网口速率不达标的根因判断先分清到底是谁的锅1.1 硬件设计隐藏的定时炸弹MDIO 共用与 PHY 配置Zynq 的 PS 端自带两个千兆网控制器GEM0/GEM1绝大多数板子会用外部 PHY 芯片做电平转换比如 RTL8211、AR8031 这类。这里第一个隐藏问题就是热词里提到的“双网口共用一个 MDIO”。如果你在板卡设计上让两个 PHY 挂在同一条 MDIO 总线上驱动加载顺序、PHY 地址冲突或时序问题就会直接影响协商速率和稳定性。常见表现是某个网口偶尔只能协商到 100M或者两个网口无法同时跑满。遇到这种问题先用mii-tool或者 ethtool 查看当前链路状态和协商速率别急着调 iPerf。如果确认 MDIO 共用导致的问题建议在设备树的重置引脚上做序列控制确保两个 PHY 的复位时序错开同时检查 PHY 地址跳线有没有和驱动配置对应上。另外很多新手容易忽略的还有电源纹波。PHY 的 DVDDH、AVDD 纹波过大会导致信号完整性问题尤其在收发大流量时出现 CRC 错误和丢包。调试时ethtool -S eth0一旦看到 rx_crc_errors 不断增长先别骂驱动量一下 PHY 供电纹波和 RX 差分走线的耦合电容。硬件底子不稳软件怎么调都是白搭。1.2 软件协议栈的瓶颈往往比硬件更常见假定你的链路协商已经是 1000Mb/s 全双工但 iPerf 单线程只能跑出 300~500Mbps这种时候大概率是软件栈的限制。Zynq 的 GEM 控制器在 Linux 内核里由macb驱动支撑中断处理、NAPI 轮询、DMA 描述符环的大小都会影响吞吐。单线程 iPerf 测试本质上是单一 TCP 流整条链路中只要有一环处理不过来比如中断太频繁、DMA 描述符太少、socket buffer 默认值偏低带宽自然上不去。多线程的意义就在于把负载分散开用多个 TCP 流填满网卡的收包队列触发 NAPI 和中断负载均衡机制从而压出网卡的物理极限。这里也有一部分是 Zynq 单核 A9 的处理能力问题尤其是运行在 667MHz 或 800MHz 频率时单纯靠 CPU 搬运 TCP 包真的扛不住千兆线速。理解了这个背景你就能明白后面多线程参数该往哪个方向调。2. iPerf 多线程测试的原理为什么单线程测不准2.1 单 TCP 流的天然瓶颈iPerf 默认只建立一条 TCP 连接而一条 TCP 流的吞吐量受限于窗口大小rwnd/cwnd、往返延迟RTT以及丢包重传。在 Zynq 这种嵌入式平台上CPU 单核处理协议栈的能力有限单线程测出来的数字反映的是“单流的最大能力”而不是链路的最大带宽。比如在一个 1000Mb/s 的局域网里RTT 通常在 0.1~1ms 级别理论上单流也能跑满但由于 CPU 处理中断和拷贝报文的开销实际单流吞吐往往只有线速的 60% 左右。多线程测试通过建立多条 TCP 流-P参数控制让网卡、DMA、内核协议栈并行处理多个连接把并发能力调动起来。对于嵌入式板子多线程还能把多个 CPU 核心Zynq 是双核 A9都利用上避免了单个核成为瓶颈。2.2 多线程在不同场景下的真实意义如果是纯粹测板子本身的转发性能多线程是必须的因为它更能反映网卡和 DMA 在满负荷时的极限。如果你要模拟的是真实业务流量比如视频流、文件并发传输多线程也更接近实际负载形态。不过有相反的场景要注意嵌入式设备做的是实时控制、小包交互比如 UDP 通信这时候多线程反而容易掩盖小包处理的延迟问题。所以测试前先明确目的别把所有情况都套同一个命令模板。3. 实操五分钟跑通 iPerf 多线程测试3.1 板端与 PC 端的准备Zynq 跑 Linux 时iPerf 有两种用法一种是用 Buildroot 或 Petalinux 直接编译进根文件系统另一种是交叉编译后拷贝到板子上。如果你手头已经有可用的串口或 SSH 终端直接确认版本即可iperf -v。如果是老式 iperf 2.x多线程参数是-P如果已经换成了 iperf3那参数变成了-P同样是并发流数但 iperf3 在嵌入式上资源占用略大老平台建议优先用 iperf 2.x 版本。PC 端的准备比较简单。Windows 可以直接用 magic iperf 之类的图形工具或者用 Cygwin 编译的 iperf 命令行版本。Linux PC 更简单装iperf或iperf3包后即可用。下面我以最常用的 iperf 2.x 为例理清两端命令。3.2 关键命令参数解析PC 当服务端板子当客户端大多数人的测试场景服务端PC 侧iperf -s -p 5001客户端板子侧iperf -c PC_IP -t 30 -P 4这里-t 30表示测试 30 秒-P 4表示同时开 4 条并发 TCP 流。对于双核 A9-P 4是一个比较容易跑出效果的起始值。然后观察最终的 SUM 行那个数字才是聚合带宽。反向测试板子当服务端PC 当客户端# PC 侧 iperf -c 板子IP -t 30 -P 4这时候需要板子上先起服务端iperf -s -p 5001。实际跑的时候下行PC→板和上行板→PC的速率可能有差别原因大概率出在 DMA 方向或中断亲和性上具体后面说。3.3 判定结果的标准节奏跑完 iPerf 之后不要只看一眼数值就收工。正确的节奏是先确认协商速率是否 1000Methtool eth0或者mii-tool eth0全双工 1000Mb/s 是前提。跑单线程-P 1作为基准记录下来比如 500Mbps。再逐步加到-P 2、-P 4、-P 8观察聚合吞吐的变化曲线。正常情况下从 1 到 4 会有明显提升从 4 到 8 可能只有微小提升甚至下降因为 CPU 已经饱和、上下文切换变多。记录系统 CPU 占用top或mpstat -P ALL 1如果 CPU 在 90% 以上说明处理器就是瓶颈如果还有余量瓶颈在驱动或内存带宽。这套判断思路能帮你少走很多弯路。很多人一上来就是-P 8压满测出来一个数字但根本不知道瓶颈在哪后面优化无从谈起。4. 避坑指南从驱动到硬件的实战心得4.1 双网口与 MDIO 共用引发的认卡问题热词里反复出现的“双网口共用一个 MDIO”就是典型的生产事故现场。Zynq 的双 GEM 在设计上的确可以做单根 MDIO 总线挂两个 PHY但此时必须保证每个 PHY 有独立的复位引脚并且设备树里的 PHY 地址要和硬件实际跳线一致。我调试过一块板子两个网口均挂在 MDIO 0 上一个 PHY 地址是 0x01另一个是 0x02。设备树里最初只配了一个phy-handle导致系统启动后两个网口都指向同一个 PHY主网口速率正常另一个网口插上后协商成了 100M 半双工。重新核对原理图后在设备树里补充第二个 PHY 节点、单独配置phy-mode为rgmii-id问题才解决。另一个 MDIO 共用的常见副作用是驱动初始化时读写 PHY 寄存器的 MDC/MDIO 时序会受到干扰间歇性造成 PHY 寄存器读回全 0。代码里如果没做错误恢复驱动会认为链路断开。这种问题往往在长时间压测比如 iPerf 跑 30 分钟以上时才会暴露并且很难稳定复现。排查手段是抓取 MDIO 波形确认是否满足 PHY 芯片手册的最小周期要求。4.2 中断与 DMA 的锁定技巧Zynq 的 GEM 驱动默认中断可能在 CPU0 上双核环境下另一个核闲着这严重浪费了吞吐潜力。你可以手动设置中断亲和性让两个网口的中断分别落到不同核心上# 查看 GEM 中断号 cat /proc/interrupts | grep eth # 设置 eth0 中断亲和到 CPU0 echo 1 /proc/irq/中断号/smp_affinity # 设置 eth1 中断亲和到 CPU1 echo 2 /proc/irq/中断号/smp_affinity配合多线程 iPerf这个调整对双网卡同时跑满的场景尤其明显。我实测过一块双网口 Zynq默认收包都在 CPU0双网口同时-P 4测速时总吞吐只有 900Mbps 左右CPU0 满载CPU1 空转。手动把网口中断亲和分开后双网口同时跑到了 1800Mbps 聚合吞吐。DMA 方面macb驱动支持调整 RX 描述符环大小默认值一般偏保守。在内核设备树中可以添加rx-ring-size属性。如果你的内核驱动版本较旧不支持该属性可以通过增加 NAPI 权重或调整中断合并阈值interrupt coalescing来改善。在高速率接收场景下描述符环过小会导致丢包并触发 TCP 重传直接拉低 iPerf 数值。合理的 RX ring 大小起步建议 1024低延时场景可以放宽到 2048。4.3 缓存一致性的隐性陷阱Zynq 在 DMA 传输时CPU 和 DMA 控制器共享 DDR如果驱动里没有正确使用 cache maintenance 接口如dma_map_single/dma_unmap_single就可能出现收到数据时缓存里的数据是旧的TCP 校验和计算错误导致内核静默丢包。这种问题不会直接报错但 iPerf 吞吐会忽高忽低而且 UDP 测试时丢包率呈随机分布。遇到该现象时检查驱动是否在 DMA 请求前正确执行了 cache clean在 DMA 完成后再执行 invalidate。手写裸机 DMA 程序时特别容易漏掉这一步。4.4 网线与交换机导致的“伪瓶颈”别小看物理层的坑。Zynq 开发板设计时有的时候 RJ45 座子自带变压器设计上没做阻抗匹配长网线或者劣质网线产生大量 CRC 错误直接让 TCP 重传率飙升测出来的 iPerf 数值可以被腰斩。另一个容易忽略的是交换机或 PC 网卡的节能以太网EEE功能部分交换机会在长时间低流量时进入节能状态突然大流量时会有一个爬坡过程导致 iPerf 前几秒速率偏低。建议测试时固定 PC 网卡速率不要用自协商可以排除这类干扰。5. 常见问题与排查技巧实录5.1 问题速查表现象可能原因排查手段解决方案只能协商到 100MPHY 地址冲突 / 差分对布线不良ethtool / mii-tool 查看协商结果检查 MDIO 地址跳线、复位时序单线程跑不满多线程可以CPU 单核协议栈瓶颈top查看 CPU 占用用多线程测试优化中断亲和性双网口同时跑速降一半中断都在一个核上/proc/interrupts统计设置 smp_affinity 分散中断RX 丢包持续增长DMA 描述符环太小ethtool -S eth0看 rx_dropped增大 ring buffer 或检查驱动缓存一致性iPerf 吞吐忽高忽低网线质量差或 EEE换线 / 关闭 EEE固定 PC 端网卡速率禁止节能两个 PHY 挂在同一 MDIO 时只有一口通PHY 复位时序问题示波器量复位与 MDIO 时序独立复位引脚增加复位间隔延时UDP 测试丢包大驱动未处理缓存一致性查看内核日志、校验失败计数修正 DMA map/unmap 代码当然嵌入式调试里永远是“具体问题具体分析”但这张表覆盖了 Zynq 上千兆网口最常见的 70% 问题。5.2 总线带宽链路的完整排查顺序最后给出一个相对固定的排查链条建议按顺序走物理链路确认网线、交换机、PC 网卡速率协商千兆全双工。PHY 寄存器状态读 PHY 的 Basic Mode Status Register地址 0x01确认 link status、duplex、speed 位。驱动层统计ethtool -S eth0看 rx_crc_errors、rx_frame_errors、rx_dropped 是否有增长。协议栈层netstat -s看 TCP retrans、checksum errors。应用层测试iperf 单线程到多线程记录每个并发数的吞吐和 CPU 负载。中断分布查看/proc/interrupts中 GEM 中断在哪个核必要时绑定亲和性。设备树检查PHY 模式、PHY 地址、reset-gpio、rx-ring-size 是否与硬件匹配。这一套走完基本能把问题收敛到硬件设计还是驱动配置上。5.3 实战中的三个个人经验我实际测过一块 Zynq-7020 的板子跑 Petalinux 2019.2内核版本 4.19。默认设置下单线程 iPerf 只能跑到 580Mbps多线程-P 4能到 850Mbps再加到-P 8反而跌回 780Mbps。后来把 GEM 中断从 CPU0 绑到 CPU1并且把 RX ring 从默认的 512 调到 1024-P 4稳定跑到了 940Mbps基本摸到千兆线速的上限。这说明 Zynq 网口在正确调优下完全能发挥硬件能力只是默认配置偏向低功耗和低资源占用不会为你压榨极限性能。不过有一类特殊情况有的 Prj 用了实时补丁PREEMPT_RT内核协议栈被插桩的延迟会变化iPerf 测出的吞吐可能有抖动。这时需要把测试流程放到非实时 CPU 上isolcpus 隔离或者在 iPerf 的线程优先级上做调整否则数据会很难看。另外一个小建议批量压测时建议加上 UDP 测试对比比如iperf -u -b 1000M -t 30 -P 4因为 UDP 没有流控和重传能更直观地反映网卡收包能力和驱动瓶颈。TCP 测的是吞吐UDP 测的是丢包率和线速承受能力两者结合才能刻画完整性能画像。只是 UDP 测试时一定要留意 CPU 占用Zynq 跑到 800Mbps 的 UDP 接收CPU 占用率大概率已经接近 100% 了。
