2. 多核数据面性能瓶颈定位方法
在 Marvell OCTEON 系列 DPU 上做多核数据面优化，第一步不是改代码，而是把瓶颈"定位准"。DPU 的典型数据面形态是：多个 ARM 核（或专用加速核）并行轮询/中断收包，经解析、查表、转发后从以太网口发出。整条链路里，算力、访存、同步、I/O 四类瓶颈往往同时存在，但真正卡住吞吐的通常只有一到两类。若不做量化定位，很容易把时间花在优化一个只占 5% 的环节上。
本节围绕四类瓶颈，讲清用什么工具、看什么计数器、如何判读，并给出一个可复用的定位流程。
一、四类瓶颈的判据与对应计数器
先建立"症状—计数器—结论"的映射，这是定位的核心。Marvell DPU 上可用的观测手段主要有三类：Linux 侧的 perf（含 PMU 硬件事件）、OCTEON 特有的核间中断/邮箱统计、以及内存带宽与缓存计数器（如 CCPI/CCPI2 一致性互连计数器、L2/L3 缓存事件）。
| 瓶颈类型 | 典型症状 | 关键计数器/指标 | 判读阈值（示例） |
|---|---|---|---|
| 算力瓶颈 | 核利用率接近 100%，吞吐不再随核数增长 | perf stat 的 cycles、instructions、IPC | IPC < 1.0 且 cycles 饱和 |
| 访存瓶颈 | IPC 低但核不空闲，缓存缺失高 | L1D/L2 缺失率、CCPI 带宽、DDR 带宽 | L2 缺失率 > 20%，带宽接近峰值 |
| 同步瓶颈 | 核间等待、自旋，吞吐抖动大 | 核间中断次数、锁自旋周期、mailbox 统计 | 同步开销占比 > 15% |
| I/O 瓶颈 | 收发包速率受限，队列积压 | NIC/PKI 队列深度、DMA 描述符、丢包计数 | 队列持续满、drop 增长 |
注意：上表阈值是教学示例中的经验参考值，实际应以本平台基线压测数据为准，不同 OCTEON 型号、不同固件版本会有差异。
二、用 perf 与 PMU 抓算力与访存
算力瓶颈最直接的证据是 IPC（每周期指令数）与核占用。在 DPU 的 Linux 侧对数据面进程采样：
# 统计 5 秒内目标进程的算力指标
perf stat -p <pid> -e cycles,instructions,cache-misses,\
cache-references,branch-misses sleep 5
# 采样热点函数，定位算力消耗点
perf record -p <pid> -g -- sleep 5
perf report --stdio | head -40
判读逻辑：若 instructions per cycle 明显偏低（例如 0.6），同时 cache-misses 占 cache-references 比例很高，说明核在"等数据"，属于访存瓶颈而非纯算力瓶颈；反之若 IPC 接近 1 以上但 cycles 已打满、吞吐不涨，则是算力瓶颈，需要减少每包指令数或卸载到硬件加速单元。
Marvell OCTEON 的 PMU 还提供一致性互连与缓存相关事件，可通过 perf list 查看本平台支持的事件名（不同 SDK 命名不同，常见如 l2c_miss、ccpi_* 等）。用这些事件可以量化 L2 缺失与 CCPI 流量，判断访存压力来自缓存还是来自 DDR。
三、核间中断与同步统计
多核数据面常用"一个核收包、分发到多个工作核"的模型，核间通信（IPI/mailbox）开销容易被忽视。OCTEON 平台可通过 /proc/interrupts 观察 IPI 计数增长，或读取 SDK 提供的 mailbox/SSO（调度单元）统计。
# 观察核间中断增长速率
watch -n 1 'grep -i ipi /proc/interrupts'
# 若使用 SSO 调度，查看队列与工作项统计
cat /sys/kernel/debug/octeon/sso_stats 2>/dev/null
若 IPI 每秒增长与包速率同量级，说明每包都触发一次核间同步，同步开销会随核数增加而放大。此时应改为批量分发（一次分发多个描述符）或使用无锁环形队列，把同步频率降下来。
四、内存带宽计数器
访存瓶颈的最终判据是带宽是否接近上限。DPU 上需同时看 L2 带宽与 DDR 带宽：若 L2 命中率高、DDR 带宽远低于峰值，则瓶颈在缓存容量或访问模式（如随机访问、伪共享）；若 DDR 带宽已接近理论峰值，则必须减少访存次数或提升数据局部性。
五、四类瓶颈的定位决策关系
下图把上述判据组织成一张定位关系图：从吞吐不达标出发，按计数器证据分流到四类瓶颈，并给出对应的下一步动作。图中数值均为教学示例阈值。
六、一个可复用的定位流程
把上面的判据串成操作顺序，便于在真实项目中执行：
- 建立基线：在未优化状态下，用
perf stat记录目标进程的 cycles、instructions、cache-misses，同时记录包速率与队列深度，作为后续对比基准。 - 排除 I/O 限速：检查 NIC/PKI 队列是否持续满、drop 是否增长。若是，先调大队列、启用批量收包，再复测。
- 区分算力与访存：看 IPC 与缓存缺失率。IPC 低且缺失高，转访存方向；IPC 高且 cycles 满，转算力方向。
- 检查同步开销：观察 IPI 增长速率与锁自旋周期占比，若与包速率同量级，改为批量分发或无锁结构。
- 确认带宽上限：用 CCPI/L2/DDR 计数器确认是否已接近带宽峰值，决定是优化访问模式还是减少访存总量。
- 复测验证：优化后重跑同一组计数器，确认主瓶颈指标改善且吞吐提升，避免"优化了非瓶颈"。
掌握这套方法后，面对任何多核数据面性能问题，都能先量化、再定位、后优化，把有限的优化精力集中在真正的主瓶颈上。