3. KNI 性能指标：定义关键性能指标与测量方法

要准确评估 DPDK KNI 接口的性能瓶颈，首先需要建立一套可量化、可复现的指标体系。KNI 作为 DPDK 应用层与 Linux 内核网络协议栈之间的桥梁，其性能表现直接影响混合模式（快速路径 + 慢速路径）的整体效率。本节将定义四个核心性能指标，并给出对应的测量方法与工具链。

3.1 关键性能指标定义

下表汇总了 KNI 性能评估的四个核心维度及其定义：

3.2 吞吐量测量方法

吞吐量测量需要区分发送方向（DPDK → Kernel）和接收方向（Kernel → DPDK）。推荐使用以下工具链：

1. DPDK 内置统计：通过 rte_kni_stats_get() 获取 KNI 接口的累计发包/收包计数。
2. 内核侧 netstat：使用 netstat -s 或 ip -s link show kni0 查看内核侧统计。
3. 第三方流量发生器：如 MoonGen（基于 DPDK）或 TRex，构造固定速率流量。
4. 测试脚本：在 DPDK 应用侧记录时间戳与包计数，计算瞬时吞吐量。

// 示例：使用 rte_kni_stats_get 获取吞吐量
struct rte_kni_stats stats;
rte_kni_stats_get(kni, &stats);

printf("TX packets: %"PRIu64"\n", stats.tx_packets);
printf("RX packets: %"PRIu64"\n", stats.rx_packets);
printf("TX bytes:   %"PRIu64"\n", stats.tx_bytes);
printf("RX bytes:   %"PRIu64"\n", stats.rx_bytes);

3.3 延迟测量方法

KNI 延迟测量需要精确的时间戳，推荐使用 DPDK 的 rte_rdtsc() 获取 TSC 寄存器值，并转换为微秒。测量流程如下：

• 步骤 1：在 DPDK 应用侧，调用 rte_kni_tx_burst() 前记录时间戳 T1。
• 步骤 2：在 KNI 内核模块的接收路径（kni_net_rx_normal）中，通过自定义 hook 或 kprobe 记录时间戳 T2。
• 步骤 3：延迟 = T2 - T1（需校准 TSC 频率）。

// DPDK 侧时间戳记录
uint64_t tsc_hz = rte_get_tsc_hz();
uint64_t t1 = rte_rdtsc();

// 发送数据包到 KNI
nb_tx = rte_kni_tx_burst(kni, pkts, nb_pkt);

// 内核侧（通过 kprobe 或修改 kni 模块）记录 t2
// 延迟(us) = (t2 - t1) * 1e6 / tsc_hz

3.4 CPU 占用率测量方法

CPU 占用率需要区分用户态（DPDK 轮询线程）和内核态（kni 内核线程）。

重点关注 %softirq 和 %system 两项。如果 softirq 占比超过 30%，说明 KNI 内核侧处理成为瓶颈。

3.5 缓存命中率测量方法

缓存命中率测量依赖硬件性能计数器（PMC），推荐使用 perf stat 或 DPDK 的 rte_memcpy 相关 tracepoint。

# 使用 perf stat 测量 KNI 相关进程的缓存命中率
perf stat -e L1-dcache-loads,L1-dcache-load-misses \
         -e LLC-loads,LLC-load-misses \
         -p $(pidof dpdk_app) -- sleep 10

# 输出示例
# 1,234,567,890  L1-dcache-loads
# 123,456,789    L1-dcache-load-misses   (10.0% miss rate)
# 98,765,432     LLC-loads
# 49,382,716     LLC-load-misses         (50.0% miss rate)

KNI 场景下，缓存命中率的关键观察点：

• L1 数据缓存缺失率 > 20%：表明 KNI 环的 mbuf 访问模式导致频繁缓存未命中。
• LLC 缺失率 > 40%：说明 KNI 环大小超过 LLC 容量，或 NUMA 跨节点访问严重。

3.6 性能指标关联分析框架

以下 SVG 图展示了四个指标之间的关联关系与典型瓶颈传导路径：

3.7 测量注意事项与避坑指南

• 避免测量干扰：perf 和 kprobe 本身会引入 5%~15% 的开销，测量结果应标注“含测量开销”。
• NUMA 亲和性：确保 DPDK 应用、KNI 内核线程和测量工具运行在同一个 NUMA 节点上，否则延迟和吞吐量数据会失真。
• 冷启动 vs 稳态：KNI 环在刚创建时缓存未预热，前 1000 个包的延迟可能偏高。应丢弃前 10% 的采样数据。
• 多队列场景：如果启用 KNI 多队列（rte_kni_config.force_bind = 1），需要分别测量每个队列的性能，避免单队列瓶颈掩盖整体问题。