1. 课程导入与评估目标定义

在嵌入式与网络通信平台选型中,Layerscape 系列处理器(如 LS1046A、LS2088A、LX2160A)常被用于网关、交换机、5G UPF、工业控制等场景。工程师面对的第一个问题往往不是“这颗芯片跑多快”,而是“它在我这套业务负载下,能不能稳定地跑出我需要的吞吐和时延”。性能基准与容量评估,正是把芯片规格书上的理论峰值,转化为可交付、可复现、可决策的工程结论的过程。

本节先建立整门课的坐标系:评估对象有哪些、关键指标怎么定义、最终要交付什么。后续章节会逐一展开测试方法、工具链、数据分析和容量建模。

一、为什么需要“基准 + 容量”两件事

很多团队只做“跑分”:用 iperf3 打一条流,看到 9.4 Gbps 就认为万兆网口达标。但真实业务是混合的——转发、加解密、队列调度、DMA 搬运同时发生,CPU 核间还会争抢内存带宽。基准测试回答的是“在受控条件下,某个子系统的能力上限是多少”;容量评估回答的是“在给定业务模型和余量要求下,这套配置能承载多少用户/流/连接”。两者缺一不可:没有基准,容量模型没有输入;没有容量模型,基准数字无法指导部署。

因此本课程把评估目标定义为三层:测准(基准数据可信)、算清(容量模型可解释)、给建议(调优方向可落地)。

二、评估对象:五个必须覆盖的子系统

Layerscape 是异构 SoC,评估不能只看 CPU。建议按以下五类对象建立测试矩阵:

  • CPU:Cortex-A72/A53 集群,关注单核 IPC、多核扩展效率、中断处理开销、DPDK 轮询模式下的核占用。
  • 内存:DDR4 控制器与缓存层级,关注顺序/随机带宽、访问时延、NUMA 式本地/远端差异(多 Die 封装时)。
  • 网络:DPAA2/DPAA1 数据通路、MAC、队列、分类器,关注小包转发率(pps)、大包吞吐(Gbps)、多队列分发。
  • 加速器:SEC 加解密引擎、AIOP、压缩/解压,关注算法吞吐、时延、与 CPU 的协同开销。
  • 存储 IO:SATA、PCIe NVMe、SD/eMMC,关注 IOPS、顺序读写带宽、中断与 DMA 效率。

这五类对象之间存在耦合。例如网络小包转发会同时压满 CPU 和内存带宽,SEC 卸载能释放 CPU 但增加 PCIe/队列时延。评估时必须记录“同时开启了什么”,否则数据不可比。

三、关键指标:吞吐、时延、抖动、功耗、扩展效率

指标定义要统一口径,否则不同人测出的数字无法对齐。本课程约定如下:

指标定义与单位典型观察点
吞吐Gbps 或 Mpps,区分 L2/L3、单向/双向MAC 计数器、DPDK stats、iperf3 结果
时延单向或 RTT,单位 μs,需注明测量点硬件时间戳、PTP、ping/TRex
抖动时延标准差或 P99-P50 差值长时间采样后的分布统计
功耗整板或 SoC 功耗,单位 W功耗计、片上传感器
扩展效率N 核吞吐 / (单核吞吐 × N)逐核递增测试

其中扩展效率最容易被忽略。假设单核转发 1.2 Mpps,4 核理想是 4.8 Mpps,实测若只有 3.6 Mpps,扩展效率 75%,说明内存带宽或共享队列已成为瓶颈。这个数字直接决定容量模型里“加核能不能线性扩容”的假设是否成立。

四、交付物:报告、模型、建议

评估结束不是给一堆截图,而是三份可被他人复用的成果:

  1. 基准报告:记录硬件配置、软件版本(LSDK/BSP、内核、DPDK)、测试拓扑、命令、原始数据与结论。要求别人按同样步骤能复现。
  2. 容量模型:把基准数据折算成业务容量,例如“在 64B 小包、开启 SEC 卸载、保留 30% 余量时,单板可承载 X 万并发流”。模型要写明假设和敏感参数。
  3. 调优建议:指出瓶颈在 CPU、内存、队列还是加速器,并给出可操作的配置方向,如队列数、核绑定、缓存行对齐、SEC 通道分配。
建议在项目开始就固定一份“评估配置基线表”,把 SoC 型号、频率、DDR 速率、固件版本、内核启动参数、测试工具版本全部记录。后续任何数据都挂在这份基线上,避免“上次测的”和“这次测的”混在一起。

五、从目标到执行:一张图看清评估链路

下图把本节定义的评估对象、指标与交付物串成一条工程链路,帮助你在后续章节中始终知道“当前这一步在为哪个交付物服务”。

Layerscape 性能基准与容量评估链路 评估对象 CPU 集群 内存 / DDR 网络 DPAA2 加速器 SEC/AIOP 存储 IO 关键指标 吞吐 Gbps / Mpps 时延 μs 抖动 P99-P50 功耗 W 扩展效率 % 交付物 基准报告 容量模型 调优建议 测量 折算 反馈闭环 调优建议 → 重新配置 → 复测基准 → 修正容量模型 评估对象决定测什么,关键指标决定怎么判读,交付物决定结论如何被使用

这张链路图强调一个工程习惯:每次测试前先问“这次数据要支撑哪份交付物”。如果只是为了填报告,就容易只测好看的数字;如果是为了容量模型,就必须覆盖边界条件和多核扩展;如果是为了调优建议,就要保留瓶颈定位所需的计数器与火焰图。

六、一个可参考的评估启动清单

在正式进入后续章节前,建议先完成以下准备,避免测试中途返工:

  • 确认评估目标:是选型对比、上线前验收,还是瓶颈定位?目标不同,测试深度不同。
  • 固定软硬件基线:SoC 型号与频率、DDR 速率、LSDK/BSP 版本、内核版本、DPDK 版本、固件版本。
  • 明确业务模型:包长分布、协议类型、并发流数、是否开启加解密、是否双向。
  • 准备测量工具:TRex 或硬件打流仪、iperf3、DPDK testpmd、perf、功耗计、PTP 时间同步。
  • 定义通过标准:例如“64B 小包单向 ≥ 8 Mpps,P99 时延 ≤ 80 μs,4 核扩展效率 ≥ 80%”。
不要把厂商规格书上的峰值直接当作容量依据。规格书通常给出理想条件下的理论值,而实际系统受内存带宽、队列竞争、中断开销、散热降频影响,往往只能达到 50%~80%。本课程后续所有示例数据都会明确标注为“示例/假设”,用于说明方法,不代表任何具体硬件的实测结论。