PCI Express Technology 3.0 链路初始化与训练节15 动态带宽改变

14.15 Dynamic Bandwidth Changes // 动态带宽改变

更新一代的 PCIe 协议以更高的速率和更宽的链路提供了比早先版本更高的性能，但也消耗了更多功耗。所以，2.0 协议的作者提出了另一种电源管理机制，即允许硬件在运行过程中动态地（on the fly）调整链路的速率和宽度。这项机制允许链路在需要提高性能时，使用尽可能快的速率和尽可能宽的链路宽度。而在需要降低功耗时，尽可能低地降低链路速率，或者减少链路宽度，或者二者皆为。动态带宽改变机制相比改变链路状态或者设备电源状态地机制，有两点明显的优势：

第一点，在带宽改变期间，链路始终能够工作，改变带宽对业务传输的中断时间较短。第二点优势在于节省功耗的程度更大。举例来说，一个 x16 链路，如果以一个 x1 链路工作，所需的功耗比一个 L0s 状态的 x16 链路还要小。

除了节省功耗之外，带宽降低还可以用于解决可靠性问题。举例而言，某个不可接受的链路可靠性问题可能是过高的链路速率造成的。这种情况下，链路双方都可以通过带宽改变过程，从自己宣告的支持速率列表中移除较高的速率。不过，协议中没有具体规定设备如何做出该可靠性决定。有趣的是（译注：好像也没有很有趣），除了通过带宽改变过程之外，设备也可以通过直接进入 Recovery 状态，通告不同的速率支持列表来解决这个问题。

改变链路的速率或者带宽需要链路被重新训练。当链路处于 L0 状态，需要改变速率时，希望改变速率的端口的 LTSSM 会向链路对端发送 TS1，使链路双方端口的 LTSSM 进入 Recovery 状态，完成速率切换后返回 L0 状态。

相似地，希望改变链路宽度的端口向链路对端发送 TS1，使链路双方端口的 LTSSM 进入 Recovery 状态，然后进入 Configuration 状态，完成链路宽度切换后以新的链路宽度返回 L0 状态。

因为链路带宽改变需要 LTSSM 的参与，这与速率改变有所不同，所以在本节中会分别讨论链路带宽管理的两个过程：动态链路速率改变和动态链路宽度改变。本节将单独地讨论这两个话题，接下来让我们从链路速率切换开始本节的内容。

14.15.1 Dynamic Link Speed Changes //动态链路速率改变

为了帮助读者们回忆前几节中讨论的 LTSSM 各状态，原文 620 页的图 14-45 提供了 LTSSM 粗略的状态转移图。在最早的 Gen1 协议中，速率切换被规划在 Polling 状态进行，但是在随后的 Gen2 中，速率转换行为被改在 Recovery 状态进行。

图 14-45 LTSSM 状态概览

在 Polling 状态期间，链路双方交换 TS1 序列，其中携带的信息如原文 621 图 14-46 所示。其中最有趣的部分在于 Byte4 的速率标识符（Rate Identifier）。其中的比特 1，2，3 分别表示支持哪些速率，协议指出所有设备都需要支持 2.5 GT/s，如果设备支持 8.0 GT/s，那么必须也支持 5.0 GT/s。

比特 6 的含义取决于端口面向链路的上游还是下游，以及端口当前所处的 LTSSM 状态。然而，在速率改变时，有意义的只有 USP 发出的 TS1 中的该比特，表示此次速率改变是否是一次自发行为。自发（Autonomous）表示该端口因为自身的硬件原因请求速率改变，而不是为了解决某个可靠性问题。USP 通过将比特 7 置 1 以发起速率改变请求。TS1 中的各个域及其含义和 TS2 的非常近似，但是 TS2 中的比特 6 有其他含义，和自发的链路宽度改变有关，我们将在下一节讨论这个问题。

图 14-46 TS1 含义

图 14-47 TS2 含义

14.15.2 Upstream Port Initiates Speed Change // USP 发起的速率改变

速率改变必须由 USP （面向上游的端口，一般指 EP 设备）发起，发起后进入 Recovery 状态。Recovery 状态的次状态如原文 622 页的图 14-48 所示，其中与本节相关的部分，使用椭圆圈出高亮了。接下来的讨论将会在高层次的速率改变过程展开，将不会深入讨论 LTSSM 的行为细节。如果想要了解其中的细节，可以参见原文 571 页的 “Recovery State” 一节。

图 14-48 Recovery 状态次状态示意图

14.15.3 Speed Change Example // 速率改变示例

通过原文 623 页的图 14-49 展示的速率改变示例，我们能更清楚地了解整个过程。注意，该示例中略去了均衡（Equalization）相关状态，以使整个示例的示意图更加简单和容易理解。考虑到示例展示的是从 2.5GT/s 改变到 5GT/s 的过程，所以反正也不会进入均衡次状态。如果速率要改变为 8GT/s，那么整个过程也是相同的，除了需要在最后增加进入均衡次状态进行均衡的过程。如果需要了解更多关于均衡次状态的信息，可以参照原文 587 页的 “Recovery.Equalization” 一节（译文 14.8.6 节）。

在如图 14-49 所示的示例拓扑连接中，EP 设备仅有一个 USP，连接到 RC 唯一的 DSP。在发起阶段中，只有 USP 可以发起速率改变请求，示例中的 USP 也是这么做的，其内部变量 Directed Speed Change 标志位先前已经在硬件实现定义的条件满足后置起，触发 USP 发起速率改变请求。在发起速率改变请求时，USP 将其 LTSSM 跳变至 Recovery 状态，进入 Recovery.RcvrLock 次状态，并发起 Speed Change 比特置起，包括其所支持速率列表的 TS1 序列，如原文 623 页的图 14-49 所示。当 DSP 接收到这些 USP 发生的 TS1 序列后，其同样进入 Recovery 状态，并开始给 USP 返回 TS1 序列。因为接收到的 TS1 中的 Speed Change 比特置起，所以 RC 内部变量 Directed Speed Change 标志位也被置起，这样一来 RC DSP 发送的 TS1 序列中的 Speed Change 比特同样会被置起。因为链路之后会尝试进入双方所同时支持的最高速率，所以，如果某个设备希望链路使用更低的速率，其只需要在宣告的速率列表中，不要列出它不想使用的更高速率即可。

图 14-49 速率改变示例 - 发起阶段

第二阶段，当 USP 检测到返回的 TS1 序列输入后，USP 状态机跳变为 Recovery.RcvrCfg 次状态，并开始发送 Speed Change 比特仍然置起的 TS2 序列，过程如原文 624 页图 14-50 所示。如果速率改变并不是因为链路可靠性引起的，那么这些 TS2 中的自主带宽改变（Autonomous Change）比特置为 1。DSP 在接收到这些 Speed Change 比特置起的 TS2 后， LTSSM 同样进入 Recovery.RcvrCfg 次状态，并向 USP 返回 Speed Change 比特置起的 TS2。不过，DSP 发送的 TS2 中的自主带宽改变比特数值与接收到的 TS2 中的数值相反（译注：此例中，取反为 0）。

图 14-50 速率改变示例 - 第二阶段

第三阶段，在每个端口都接收到 8 个连续的 Speed Change 比特置起的 TS2 后，链路双方意识到下一步是双方一起进入 Recovery.Speed 次状态，如原文 625 页的图 14-51 所示。此时，DSP 需要记录接收到的 TS2 中的带宽自主改变比特的数值，在 PCIe 的 Capability Register 中添加了额外的数值域用于实现这一点。

如原文 625 页的图 14-52 所示，链路状态（Link Status）寄存器中有用于记录链路带宽改变目的的状态比特。如果设备硬件支持并已使能相关功能，上述状态比特的改变也可以被用于触发中断，提醒软件发生了速率变化事件。控制这一功能使能的是链路带宽改变提醒使能（Link Bandwidth Notification Capable）比特，寄存器域如原文 626 页图 14-53 所示，以及链路控制（Link Control）寄存器中的中断使能（Interrupt Enable）比特，寄存器域如原文 626 页图 14-54 所示。注意有两种不同的带宽改变情况：自主带宽改变（autonomous）和带宽管理（bandwidth management）。自主带宽改变意味着并不是因为链路可靠性问题，所以才改变链路带宽（速率），而带宽管理指的就是为解决可靠性问题，改变链路带宽（速率）。

图 14-51 速率改变-第三阶段

图 14-52 带宽改变状态比特

图 14-53 带宽通知 Capability

图 14-54 链路控制寄存器（原文图注有误）

结束阶段，在进入 Recovery.Speed 次状态后，链路会在两个方向上都被置于电气空闲状态，并调整内部电路的速率。调整后的速率是双方在 TS1 以及 TS2 中发送的支持速率列表（Rate ID 域）中双方同时支持的最高速率。本例中，双方共同支持的最高速率为 5GT/s，所以链路改变为该速率。在等待一段延时后，链路双方同时回到 Recovery.RcvrLock 次状态，并通过重新发送 TS1 退出电气空闲状态，如原文 627 页图 14-55 所示。在 USP 接收到重新发送的 TS1 后，其 LTSSM 跳转到 Recovery.RcvrCfg 状态，开始发送 TS2 序列，同上一次由Recovery.RcvrLock 次状态进入 Recovery.RcvrCfg 次状态过程相同。不过此时 TS1 中的 Speed Change 比特不会被置起。最终，USP 接收到 DSP 返回的，Speed Change 比特未置起的 TS2 序列，此时 USP （以及 DSP）LTSSM 途径 Recovery.Idle 次状态返回 L0 状态。

如果速率改变因为一些原因失败，设备不被允许在失败并返回 L0 的 200ms 内重新协商该速率或者更高速率，或者等待链路伙伴通告其支持新的更高速率，才能重新发起速率改变协商。

图 14-55 速率改变-结束阶段

14.15.4 Software Control of Speed Changes // 速率改变的软件控制

当硬件已经决定改变链路速率后，软件无法再控制速率改变流程，但是软件可以限制或者禁止硬件的速率改变行为。通过原文 628 页图 14-56 所示的链路控制 2 （Link Control 2）寄存器的目标链路速率（Target Link Speed）数值可以限制硬件速率改变行为。该数值会设定 USP 所能发起速率改变的最高目标速率，或者用于保持当前链路速率。软件也可以强制硬件尝试将链路速率设定为某个特定速率，首先设置 USP 的目标链路速率，然后置位链路控制（Link Control）寄存器中的（Retrain Link）链路重训练比特，寄存器域如原文 629 页图 14-57 所示。另外，如前文所述，软件可以通过链路带宽通知机制得知任何硬件完成的链路速率或者带宽变化。最后，软件可以通过设置禁止硬件自发速率改变（Hardware Autonomous Speed Disable）比特关闭硬件的自动速率改变功能。

图 14-56 链路控制 2 寄存器

图 14-57 链路控制寄存器

14.15.5 Dynamic Link Width Changes // 动态链路宽度改变

链路宽度改变的基本过程和速率改变相同，但是位宽改变的过程会相对更加复杂，因为牵涉到更多的 LTSSM 状态改变步骤。软件在使能链路宽度改变之前需要了解一件重要的事情，那就是对端设备是否支持将窄链路恢复成宽度较宽的链路（该特性被称为 Link Upconfiguring）。设备在他们训练期间发送的 TS2 序列中的 Rate ID 域的比特 6 位置通告他们是否支持这一特性，如原文 630 页图 14-58 所示。如果对端设备不支持这一特性，那么意味着将链路宽度改小会是一锤子买卖（无法恢复回原来将宽的链路宽度），此时只会在出现链路可靠性问题时，才会减小链路宽度。

图 14-58 TS2 序列内容

14.15.6 Link Width Change Example // 链路宽度改变示例

让我来看一个示例，示例基于如原文 631 页图 14-59 所示的连接拓扑，一个根端口（Root Port）连接到一个 EP（千兆以太网设备）。同样地，只有 USP 才能够发起链路宽度的改变，和前文速率改变时一样，USP 先使自身进入 Recovery 状态发起这一操作。但此时不会在 TS1/2 中置起 Speed Change 标志。为了确定改变后的链路宽度，USP 会通知 DSP 在从 Recovery 状态返回 L0 状态之前，进入一次 Configuration 状态，如原文 631 页图 14-60 所述。Configuration 状态包含多个次状态，原文 632 页的图 14-60 给出了一个简化版的状态跳变过程示意图。接下来，我们会一一讨论各个步骤。

图 14-59 链路宽度改变示例拓扑连接图

图 14-60 链路宽度改变 LTSSM 状态变化过程

图 14-61 简化后的 Configuration 次状态跳变示意图

如前文所述速率变化的过程相同，USP 进入 Recovery 状态发起链路宽度改变请求，并发送 TS1 序列，其中 Speed Change 比特并未置起，如原文 631 页图 14-59所示，示例中以太网设备作为 USP，率先发起这一过程。作为回应，DSP 也发送 TS1 返回给 USP，其 Speed Change 比特也未置起，此时 TS1 中的链路和通道编号保持不变，仍为先前链路训练的结果值。根据前文中位于原文 622 页的图 14-48，此时，接下来一个次状态是 Recovery.RcvrCfg，在该次状态双方会交换 TS2。

图 14-62 链路宽度改变 - 开始阶段

因为此时没有请求速率变换（TS 中的 Speed Change 比特为 0），所以接下来直接进入 Recovery.Idle 状态。在该次状态中，双方一般发送逻辑空闲信号（即全零信号），如原文 634 页图 14-63 所示。但是，因为此时 USP 想要改变链路宽度，所以 USP 不会发送逻辑空闲信号，而是，发送链路和通道编号均为 PAD 的 TS1。DSP 识别到接收的 TS1 中，原本已经完成配置的通道编号变成了 PAD，意识到对端想要改变位宽，所以接下来进入 Configuration 的第一个次状态：Config.Linkwidth.Start。

图 14-63 链路宽度改变 - Recovery Idle 阶段

DSP 在 Configuration 状态中发起对 USP 通道的配置工作，向 USP 发送 TS1 序列，其中链路编号域为原协商链路编号，但是所有通道上发送的 TS1 中的通道编号域都使用 PAD 填充，如原文 635 页图 14-64 所示。USP 在其想要 “激活” （active）的通道上回应相同的 TS1，但在 USP 不想要激活的通道上，发送链路和通道编号均使用 PAD 填充的 TS1。DSP 在接收到这些 TS1 回复后，转入 Config.Linkwidth.Accept 次状态。注意，此时所有 TS1 的自主改变（Autonomous Change）比特均为 1。

图 14-64 USP 标识所需激活的通道

作为回应，RP 在那些已激活通道上，转而发送带有合适通道编号的 TS1 序列，而在那些非激活通道上则发送链路和通道编号都是 PAD 的 TS1 序列。USP 则回应相同的 TS1 序列，如原文 636 页图 14-65 所示，并将状态机状态改变为 Config.Lanenum.Accept 次状态。此时，RP 更新其寄存器中的状态比特，表示检测到一次自发的带宽改变，并将状态转移为 Config.Complete 次状态。

图 14-65 DSP/USP 响应通道编号变化

下一步中，RP 开始在那些激活通道上发送 TS2 序列，并将非激活通道改变为电气空闲状态。让我们回忆一下，TS2 会在其相关字段中通报该设备是否支持 “upconfigure” 能力，在本例中，链路双方都支持该能力。EP 以相同的行为作为回应，在那些激活通道上发送 TS2 序列，并将非激活通道改变为电气空闲状态。在检测到 EP 的回应后，RP 状态机改变为 Config.Idle 状态，并在激活通道上发送逻辑空闲信号。EP 以相同的行为作为回应，并将其状态机改变回到 L0 工作状态。此时，链路已经恢复了正常的工作状态，只是或许为了省电，减少通道降低了带宽。