2. ASPM开启后的预期行为：链路速率协商与电源状态切换对带宽的影响
做ASPM故障排查，第一步得搞清楚——什么叫做“正常”。
很多人一看到链路速度掉到Gen1，就喊着“降速了！降速了！”。其实，这很可能就是ASPM预期的行为。你想想看，如果设备空闲时还跑在8GT/s，那功耗控制就白设计了。
这一章，我们来拆解两个核心概念：
- 链路速率协商：ASPM是如何让链路在空闲时“慢下来”的？
- 电源状态切换：L0→L0s→L1，这些状态切换对实际带宽到底有多大影响？
我把话先说清楚：我们讲的是“预期行为”。只有先知道什么是“正确”的，才能精准地抓住“异常”。
2.1 链路速率协商：不是你想降就能降
PCIe链路的速率和宽度，是两端设备通过Training Sequence协商出来的。这个过程发生在链路初始化阶段，也发生在链路从低功耗状态唤醒时。
ASPM开启后，设备进入L1状态时，链路的物理连接会被断开。当需要重新传输数据时，链路必须重新进行Training。这个重新Training的过程，就是速率协商的窗口。
我个人习惯把这件事类比成“唤醒”：
- 设备空闲：ASPM说“睡吧睡吧”，链路进入L1，电都省了。
- 数据来了：设备被唤醒，链路重新建立连接。
- 重新训练：两端重新协商速率和宽度。
关键在于，重新协商时，速率不一定能回到Gen3/Gen4。为什么？
我曾经踩过一个坑：一块网卡在低负载时频繁掉包。查了一圈，发现是ASPM让链路频繁进入L1，每次唤醒重训时，对端Root Complex的PLL锁相环状态不稳定，导致链路只能降到Gen1速率通信。虽然不是每次都会降，但一旦降了，带宽就只剩原来的十分之一。
所以，链路速率协商不是板上钉钉的事。它受信号质量、功耗预算、甚至温度影响。ASPM只是允许链路降速，但是否真的降速，由两端实际的硬件能力决定。
下面这张流程图帮你理清ASPM开启后，链路的状态机演变：
2.2 电源状态切换：L0/L0s/L1 到底差多少？
ASPM定义了两种低功耗状态：L0s和L1。它们的目标都是省电，但“省电”和“性能”向来是跷跷板的两头。
说白了，L0s是“浅睡眠”，L1是“深度睡眠”。
咱们直接看一个对比表格，一目了然：
| 状态 | 描述 | 唤醒延迟 | 功耗节省 | 对带宽的影响 |
|---|---|---|---|---|
| L0 | 全速运行，数据随时传输 | N/A | 0%（基线） | 全带宽，无损失 |
| L0s | TX或RX方向独立关闭 | ~几十ns | 低（约20-40%） | 几乎无感，适合突发流量 |
| L1 | 链路时钟、参考时钟都停 | 几us到几十us | 高（可达80-90%） | 明显，小包场景下性能下降 |
2.3 对带宽的真实影响：别被数据表骗了
讲个真实的项目经历。有一次，我在优化一块NVMe SSD的性能。数据表上写支持Gen4 x4，理论带宽8GB/s。但实际跑4K随机读写，IOPS死活上不去。
我用perf和lspci -vvv抓了一下，发现ASPM打开了L1状态。每次IO请求间隔超过5us，链路就进入L1。下一个IO来时，光唤醒就要花几十us。你想想看，4K随机读，延迟从10us涨到上百us，IOPS直接砍半。
这里有一个计算思路：
- L0状态下：4K读延时 ~10us，每秒可完成10万次IO。
- 开了L1 ASPM后：唤醒时间 ~30us，传输时间 ~10us，总延时变成40us。每秒只能完成2.5万次IO。
2.4 总结：预期行为是你排查的“标尺”
这一章我们梳理了ASPM开启后的正常表现。我归纳一下核心点：
- 链路速率协商是动态的：链路可以在L0→L0s/L1→L0的切换过程中，主动降速到Gen1/Gen2，这是预期行为，但不一定每次都会发生。
- 电源状态切换有代价：L0s几乎无感，L1的唤醒延迟会显著影响小包/低延时场景的带宽。
- 降速不等于故障：要结合实际的流量模型（连续大包 vs 间歇小包）来判断。如果间歇小包场景下速率降到Gen1，可能只是省电策略在起作用。
嗯，这里要注意：很多工程师用lspci看到链路速率掉到Gen1，就急着去调设备树或者BIOS设置。我建议你先用perf stat抓一下链路的实际利用率。如果利用率很低，那降速反而是对的。
这一章的内容，就是你后面排查所有ASPM相关问题的基线。记住这个基线，我们才能知道自己面对的究竟是“预期行为”还是“异常故障”。