基于DPDK测量往返时间(RTT)的方案及pktgen时延计算规则咨询

可行测量方案 #

• 方案1：pktgen + testpmd 无开发成本方案 #

  1. 机器B侧运行testpmd纯转发：启动testpmd时配置io转发模式，命令如下：

     testpmd -l 0-1 -n 4 -- -i --portmask=0x1 --txq=1 --rxq=1 --forward-mode=io
     

     该模式下收到报文后直接原封不动从原端口发回，无额外协议处理开销，是转发侧的最优配置。
  2. 机器A侧运行DPDK pktgen，开启时延统计功能即可直接得到RTT结果，无需额外二次开发。

• 方案2：自定义极简DPDK收发程序（高精度场景可选） #

  自行开发轻量DPDK应用，逻辑为：构造测试报文时在payload固定位置写入当前CPU TSC寄存器值，从端口发出后监听同端口的入方向报文，收到回包后读取当前TSC减去报文中存储的发送TSC，除以CPU主频即可得到准确RTT。该方案可完全自定义报文参数、发包速率，排除通用工具的额外开销，测量精度最高。

DPDK pktgen时延统计逻辑说明 #

pktgen内置latency统计的计算逻辑和上述自定义方案完全一致：

• 发送报文时，pktgen会在报文payload的固定偏移位置写入发送时刻的CPU TSC值
• 开启时延统计的端口收到报文后，会读取当前CPU TSC，减去报文中存储的发送TSC，换算为时间值即为往返时间RTT
• latency页面展示的最小/最大/平均时延、百分位分布，都是上述方式计算出的双机往返总耗时，完全匹配你当前的测试场景需求，不需要额外做逻辑调整。

测量优化建议 #

为了得到最稳定的测量结果，建议两台测试机都做如下配置：

• 关闭CPU睿频、C-State节能模式，固定CPU主频
• 所有DPDK进程绑定的逻辑核、使用的网卡都归属同一个NUMA节点
• 测试过程中不运行其他无关进程占用CPU、带宽资源

通用RTT基准参考 #

• 非DPDK场景（内核协议栈ping）：万兆光口同机房双机RTT基准为50~100μs，大部分耗时来自内核协议栈的收发、ICMP响应处理
• DPDK纯转发场景：万兆光口同机房双机RTT基准为10_{25μs*，25G光口同机房双机RTT基准为*3}8μs，该数值已经包含链路传输开销、两端DPDK收发包开销、转发侧转发开销，为行业通用基准值。

内容的提问来源于stack exchange，提问作者Ameer Usman