6 流量控制.md · springkiss/Chinese Translation of PCI Express Technology

## Chapter 6      Flow Control //流量控制

### 关于上一章

上一章节讨论了主要的三种类型的数据包：TLP事务层包（Transaction Layer Packets）、DLLP数据链路层包（Data Link Layer Packets）、Ordered Sets命令集。并且在上一章中主要讲述TLP的用法、格式和不同种类的定义，并将详细的讲解TLP的相关字段含义。关于DLLP的内容将会在Chapter 9 “DLLP Element”中进行单独讲解。

### 关于本章

本章节将讨论流量控制协议（Flow Control）的目的以及细节操作。流量控制是用来确保在接收者无法接收TLP时，发送方不会再继续发送TLP。这避免了接收Buffer溢出，也消除了原本PCI工作方式中的一些低效行为，比如断开（disconnect）、重试（retry）和等待态（wait-state）。

### 关于下一章

下一章节将会讨论用于支持QoS（Quality of Service）的机制，并描述对网络结构中传输的不同数据包的传输时间和带宽进行控制的意义。这些机制包括，特定应用的软件将会给每个数据包都分配优先级，以及每个设备内构建可选的硬件来启用事务优先级管理。

### 6.1 流量控制概念（Flow Control Concept）

每条PCIe链路两端的端口都必须实现流量控制机制。在一个数据包允许被发出之前，流量控制机制必须确认接收端口拥有足够的可用Buffer空间来接收数据包。而在像PCI这种并行总线中，尽管不知道目标方是否准备好了处理数据，事务也会尝试去发送执行，如果因为没有足够的可用Buffer空间，请求被拒绝了，那么事务就会一直重试（Retry）直至完成。这就是PCI的“Delayed Transaction Model延迟的事务模型”，然而这种方式的效率很低。

流量控制机制可以改善当多个虚拟通道（Virtual Channel，VC）被占用时的传输效率。每个虚拟通道自己的事务是与其他VC的事务流量相独立的，因为流量控制Buffer是VC各自单独维护的。因此，若一个VC的流控Buffer满了，它也不会阻塞对其他VC Buffer的访问。PCIe支持最多8条虚拟通道。

流量控制机制使用一种基于信用（Credit-based）的机制，使得发送端口可以知道接收端口有多少可用的Buffer空间。作为它们初始化的一部分，每个接收者都要将自己的Buffer大小报告给链路对端的发送者，并在运行过程中使用DLLP来定期地更新这个“信用值”。技术上来说，明显地，DLLP是一种开销，因为它并不携带任何数据荷载，但是DLLP始终很小（始终为8个符号大小），这样可以使其对性能的影响最小。

流量控制逻辑实际上是两个层级的共同职责：事务层包含了计数器用于对可用Buffer空间进行计数，但是数据链路层也要负责发送和接收这些包含了可用Buffer空间信息的DLLP。如图 6‑1展示了这种共同职责。在流量控制的的工作过程中：

n **设备报告可用的Buffer****空间**：接收者的每个端口都要报告自己的流量控制Buffer的大小，单位为credit（信用）。一个Buffer中credit的数量会从自身接收侧事务层发送至发送侧数据链路层（如图 6‑1）。在合适的时间，数据链路层将会产生一个流量控制DLLP来将这个credit信息转发至每个流量控制Buffer的链路对端的接收者的。

n **接收者寄存Credit**：接收者收到流量控制DLLP，并将credit值传输至自身发送侧事务层。这就完成了credit从链路的一端到对端的传输。这些操作是双向进行的，直到所有的流量控制信息都完成了交换。

n **发送者检查Credit**：在发送者可以发送一个TLP之前，它需要检查流量控制计数器（Flow Control Counter），以此来知道对方是否有足够的credit。如果credit数量足够，那么就将TLP转发至数据链路层，但是如果credit不足，那么TLP的发送操作就会被阻塞直至获知的更多的足够的流量控制credit。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image258-16402718651011.jpg)

图 6‑1流量控制逻辑所处的位置

### 6.2 流量控制Buffer和Credit（Flow Control Buffer and Credits）

一个端口所支持的每个VC（Virtual Channel）资源都会实现流量控制Buffer。回想一下，链路两端的端口可能支持的VC数量是不同的，因此由软件进行配置和启用的VC的最大数量就是两个端口间的最大公共VC数量。

#### 6.2.1     VC流量控制Buffer的组成（VC Flow Control Buffer Organization）

接收者的每个VC流控buffer是按照通过VC的每种事务类别来进行管理的。这些类别为：

n Posted事务——MWr（Memory Write）和Message

n Non-Posted事务——MRd（Memory Read）、配置读/写、IO读/写

n 完成包——读和写完成包

除此之外，每个既有Header也有数据荷载的事务类别，都会被分成Header和数据两部分。这将产出6种不同的Buffer，每个Buffer都实现自己的流控。（见图 6‑2）。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image260.jpg)

图 6‑2流控Buffer组成

对于有些事务，例如读请求，它只由Header组成，而像写请求就既有Header也有数据荷载。发送者必须确认Header的Buffer空间和数据荷载的Buffer空间都满足了事务传输的需求，才能发送事务。注意，当事务被转发至软件或者是在Switch中被转发至出口端口时，必须在VC流控Buffer中保持事务顺序。因此，接收者也biubiu跟踪Buffer内的Header和数据荷载的顺序。

#### 6.2.2     流控Credit（Flow Control Credits）

接收者需要报告Buffer空间的大小，使用的单位是Credit，或者叫流量控制Credit。Header和数据荷载Buffer的一个流控Credit（FCC，Flow Control Credit）的大小值分别为：

n Header Credit：Header大小的最大值+digest

—  完成包为4DW

—  请求包为5DW

n 数据Credit：4DW（16byte对齐）

流量控制DLLP会传达这个信息，而DLLP自身的传输是不需要流控Credit的。这是因为DLLP产生和终结的地方都是在数据链路层，并不需要使用到事务层Buffer。

### 6.3 初始流量控制通告（Initial Flow Control Advertisement）

在流控的初始化过程中，PCIe设备们会通过对Buffer空间的流控Credit进行“advertising通告”的方式，来相互传达各自的Buffer大小。PCIe也专门定义了一些Buffer需要的流控Credit初始值。一个通告过自己的初始Buffer空间的接受者可以有效的保证它的Buffer空间永远不会溢出。

#### 6.3.1     流控通告的最大值和最小值（Minimum and Maximum Flow Control Advertisement）

协议规范定义了各种不同的流控Buffer类型所报告的Credit数量的最小值，表 6‑1列出了这些Buffer类型对应的Credit最小值。然而，设备一般通告的Credit数量会远大于最小值，表 6‑2列出了协议所允许的Credit数量通告的最大值。

| Credit类型                                                | 通告（Advertisement）最小值                                  |
| --------------------------------------------------------- | ------------------------------------------------------------ |
| Posted  Request Header  （PH）  Posted请求Header          | 1单位：  Credit值= 1个4DW Header+Digest= 5DW                 |
| Posted  Request Data  （PD）  Posted请求数据              | 这个值是Max_Payload_Size的最大值用Credit的表示。  例如：如果支持的最大的Max_Payload_Size为1024Byte，那么允许的最小的初始Credit值就是040h（64*16byte）。 |
| Non-Posted  Request Header  （NPH）  Non-Posted请求Header | 1单位：  Credit值= 1个4DW Header+Digest= 5DW                 |
| Non-Posted  Request Data  （NPD）  Non-Posted请求数据     | 1单位：  Credit值= 1个4DW Header+Digest= 5DW  2单位：  如果接收方支持AtomicOP路由或者具有作为AtomicOP完成者的能力，那么Credit值可以为02h。 |
| Completion  Header  （CplH）  完成包Header                | 1单位：  Credit值= 1个3DW Header+Digest= 4DW。这种情况是对于支持Peer-to-Peer的RC和Switch。  无限数量：初始Credit值=全0。应用于不支持Peer-to-Peer的RC和EP。 |
| Completion  Data  （CplD）  完成包数据                    | n单位：  这个值是Max_Payload_Size或者是读请求size这二者可能的最大值（一般读请求size会比前者小）除以FC单位大小（4DW）。这种情况是对于支持Peer-to-Peer的RC和Switch。  无限数量：初始Credit值=全0。应用于不支持Peer-to-Peer的RC和EP。 |

表 6‑1流控通告最小值

| Credit类型                                                | 通告（Advertisement）最小值                                  |
| --------------------------------------------------------- | ------------------------------------------------------------ |
| Posted  Request Header  （PH）  Posted请求Header          | 128单位：  128 Credits=128*5DW=2560 Bytes                    |
| Posted  Request Data  （PD）  Posted请求数据              | 2048单位：  值为设备支持多有Function（8个）的Max_Payload_Size（4096 bytes）总和,总和为8*4096=32768,除以Credit大小（4DW）。  2048 Credits=2048*4DW=32768Bytes |
| Non-Posted  Request Header  （NPH）  Non-Posted请求Header | 128单位：  128 Credits=128*5DW=2560 Bytes                    |
| Non-Posted  Request Data  （NPD）  Non-Posted请求数据     | 作者无法给Non-Posted数据找到一个准确的Credit数量最大值。给出的单纯数据的Credit数量最大值为2048。然而，一种更合理的计算的方法是使用Non-Posted Header来限制在128 Credits内，因为Non-Posted数据总是与Non-Posted Header相关联。 |
| Completion  Header  （CplH）  完成包Header                | 128单位：  128 Credits=128*4DW=2048 Bytes。这是对不发起事务的端口的限制（例如支持Peer-to-Peer的RC和Switch）。  无限数量：初始Credit值=全0。应用于发起事务的端口（例如不支持Peer-to-Peer的RC和EP）。 |
| Completion  Data  （CplD）  完成包数据                    | 2048单位：  值为设备支持多有Function（8个）的Max_Payload_Size（4096 bytes）总和,总和为8*4096=32768,除以Credit大小（4DW）。  2048 Credits=2048*4DW=32768Bytes  无限数量：初始Credit值=全0。应用于发起事务的端口（例如不支持Peer-to-Peer的RC和EP）。 |

表 6‑2流控通告最大值

#### 6.3.2     无限Credit（Infinite Credits）

可以注意到，如果流控Credit值为00h，那么其意思就是拥有无限多的Credit。在流控初始化之后，不会再进行任何的通告（advertisement）。发起事务的设备必须要保留足够的buffer空间，这些buffer空间用来存放执行拆分事务（split transaction）的过程中返回的数据以及状态信息。这些事务组合包括：

n Non-Posted读请求和返回的完成包数据

n Non-Posted读请求和返回的完成包状态

n Non-Posted写请求和返回的完成包状态

#### 6.3.3     无限Credit通告的特殊用法

协议规范指出，当一个设备只实现了VC0时，需要有一些特别的考虑。例如，仅有的两种Posted写请求：IO Write与Configuration Write，二者仅允许使用VC0。因此，Non-Posted数据buffer并不会被VC1-VC7所使用，那么就可以为VC1-VC7宣告一个无限Credit值。然而Non-Posted Header仍然需要进行操作，所以Header Credit的值需要继续更新，而并非保持无限。

### 6.4 流量控制初始化（Flow Control Initialization）

#### 6.4.1     整体说明（General）

在发送任何事务之前，都需要进行流控初始化（flow control initialization）。事实上，在流控初始化成功完成之前，TLP是不能在链路上进行发送的。流控初始化会发生于系统中的每一个链路，其过程主要为链路两端设备之间的一次握手。这一过程会在物理层的链路训练（link training）完成后就开始进行。链路层从国观察LinkUp信号是否有效就可以知道物理层何时处于Ready状态，如图 6‑3所示。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image262.jpg)

图 6‑3物理层报告自己已经Ready

一旦流量控制初始化开始，那么这个过程从根本上来说在各个虚拟通道（VC）上都是一样的，当一个VC被启用时，硬件就负责控制它的流量控制初始化过程。VC0默认总是启用，因此它的初始化过程是自动的。这使得配置事务可以遍历整个拓扑结构，并进行枚举过程。其他的VC只有在配置软件对链路两端都进行了设置并且启用它们之后才会进行初始化。

#### 6.4.2     流控初始化流程（The FC Initialization Sequence）

流控初始化过程涉及到链路层的DLCMSM（Data Link Control and Management State Machine，数据链路控制与管理状态机）。如图 6‑4所示，复位后状态机将处于DL_Inactive状态。在DL_Inactive状态中，会发出DL_Down信号，这个信号会作用于链路层和事务层。与此同时，也会在此状态中等待物理层的LinkUp信号，此信号是用于表示LTSSM（Link Training and Status State Machine，链路训练和状态状态机）已经完成了工作，也就是物理层已经处于Ready状态。当物理层Ready后，将会使得DLCMSM跳转至DL_Init状态，它包含两级子状态用于处理流控初始化：FC_INIT1和FC_INIT2。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image264.jpg)

图 6‑4 DLCMSM数据链路控制与管理状态机

#### 6.4.3     FC_Init1详细说明（FC_Init1 Details）

在FC_Init1状态中，设备会连续的发送一系列的3种InitFC1流控DLLP来通告它的接收Buffer大小（见图 6‑5）。根据协议规范，数据包必须按照这样的顺序来进行发送：Posted，Non-Posted，Completion完成包，如图 6‑6所示。协议规范中强烈建议频繁的重复这些DLLP的发送，这会使接收设备能够更容易的发现它们，特别是在当前没有TLP或者DLLP需要发送的情况下。每个设备都需要从对端设备接收到这一系列DLLP，这样它才可以将对端设备的Buffer空间大小寄存下来。一旦设备已经发送出了自身的Buffer空间大小的值，并且接收到了足够次数的完整的DLLP序列，所谓足够次数就是设备足以相信接收到的对端Buffer大小的值是正确的，那么此时设备就已经可以跳出FC_INIT1状态了。要进行跳出的操作，设备需要将接收到的值记录在传输计数器（transmit counter）中，置起一个内部的flag信号（FL1），然后就可以跳转到FC_INIT2状态来进行初始化操作中的第二步。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image266.jpg)

图 6‑5 INIT1流控DLLP格式及内容

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image268.jpg)

图 6‑6设备在DL_Init状态下发送InitFC1 DLLP

#### 6.4.4     FC_Init2详细说明（FC_Init2 Details）

在FC_Init2这个状态中，设备需要连续的发送InitFC2 DLLP。发送DLLP的顺序和FC_Init1中一样，并且其中也包含了相同的有关Credit的信息，但是这些DLLP还有一个作用就是发送方用来确认流控初始化（FC initialization）已经成功。由于设备在FC_Init1状态中就已经寄存了对端的可用Buffer值，因此它不在需要任何关于Credit数量的信息，它在等待InitFC2 DLLP时会忽略传来的所有InitFC1 DLLP。尽管对于链路另一端设备来说此时并没有完成初始化，初始化的完成与否是通过DL_Up信号来对事务层进行指示的，但是设备可以在此时发送TLP。（见图 6‑7）

你可能会有疑问，初始化过程为什么还需要这个第二步呢？一个简单的回答是：链路两端的设备在完成流控初始化（FC Initialization）时需要的时间可能是不一样的，而这样两步的方法可以确保在较快的设备完成初始化后，较慢的那一端依然能够继续接收到需要的流控信息（FC Information）。一旦一个设备接收到了任意Buffer种类的FC_INIT2数据包，那么它就会置起一个内部的flag（FL2）。（这个操作不需要等待接收到所有种类的FC_INIT2数据包）注意，FL2也是在接收到一个UpdateFC包或者TLP之后才被置起的。当链路两端的设备都完成了这些步骤并且都发送出了InitFC2 DLLP之后，DLCMSM将会跳转至DL_Active状态，这也就意味着链路层已经准备好了执行常规的操作，链路层初始化完成。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image270.jpg)

图 6‑7 FC值已经寄存-接下来发送InitFC2并报告DL_Up

#### 6.4.5     FC_INIT1和FC_INIT2的传输速率（Rate of FC_INIT1 and FC_INIT2 Transmission）

在协议规范中定义了发送FC_INIT DLLP之间的延时，如下：

n VC0：基于硬件进行流控的VC0要求FC_INIT1包和FC_INIT2包要 “连续地以尽可能大的速率”进行传输。也就是说重发计时器（resend timer）设置的重发间隔值为0。

n VC1-VC7：当软件启动了其他VC（VC0之外）的流控初始化时，FC_INIT DLLP序列需要在“当没有其他TLP或者DLLP需要传输时”被重复发送。然而需要注意，两组DLLP序列发送的起始时刻最多只能间隔17us。

#### 6.4.6     流控初始化协议违例

设备对流控初始化协议违例的检测是可选的。检测到的错误可以作为数据链路层协议错误进行报告。

### 6.5 流控机制的介绍（Introduction to Flow Control Mechanism）

#### 6.5.1     整体说明（General）

协议规范定义了流量控制机制所要求的寄存器、计数器，以及一系列的机制用于报告（reporting）、追踪（tracking）和计算（calculating）一个事务是否可以被发出。这些元素并不是必需的，它们的实际实现是由设备的设计者来决定的。本节将介绍协议规范模型，并解释相关概念和对需求进行定义。

#### 6.5.2     流控相关元素（The Flow Control Elements）

图 6‑8说明了用于管理流量控制的元素。图中展示了在连路上单向传输的事务，而另一组这些流控元素则支持相反方向的传输。每个元素的主要功能都会再下面的内容中列出。虽然对于全部的6种接收buffer都重复有这些流控元素，但是为了简单起见，在本例子中仅考虑Non-Posted Header流控。

与管理流控相关的最后一个元素是流控更新DLLP（Flow Control Update），它也是在链路正常传输期间唯一可使用的流控包。FC Update包的格式如图 6‑9所示

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image272.jpg)

图 6‑8流控元素

##### 6.5.2.1   发送方流控元素（Transmitter Elements）

n 事务等待缓冲区（Transactions Pending Buffer）：把将要发送进统一虚拟通道的事务暂存起来。

n Credit消耗计数器（Credits Consumed counter）：该计数器是记录发送给对端当前类型Buffer的所有事务的Credit总和（也就是消耗了接收端多少Credit），这个计数值也可以被缩写成“CC”。

n Credit额度计数器（Credit Limit count）：该计数器的初始值由对端接收者相应类型的Buffer大小而决定。在初始化之后，对端接收者会定期的发送流控更新包（FC Update），以便在接收方Buffer可用时更新流控Credit。这个值可以被缩写为“CL”。

n 流控门控逻辑（Flow Control Gating Logic）：它用于进行计算来确定对端接受者是否有足够的流控Credit来接收等待发送中的TLP（Pending TLP，PTLP）。本质上来说，这个逻辑就是检查CREDITS_CONSUMED（CC）加上下一个PTLP所需要消耗的Credit是否大于CREDIT_LIMIT（CL）。协议规范中定义了下面的方程，以此来完成上述的检查，方程中所有的值的单位都是Credit。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image274.jpg)

关于应用此方程式的例子，请参阅“Stage 1 – Flow Control Following Initialization”一节。

##### 6.5.2.2   接收方流控元素（Receiver Elements）

n 流控缓冲区（Flow Control Buffer）：储存输入的Header或者数据。

n Credit分配计数（Credit Allocated）：记录已分配（可用）的全部的流控Credit数量。它是由硬件进行初始化的，反映了已分配的流控Buffer的大小。这些Buffer会在事务到达时被填充，但是填充进去的事务最终都会被接收端取出，也就是从Buffer中移除。当它们被移除时，这部分的Buffer空间Credit数量将会被加到CREDIT_ALLOCATED计数值上。因此这个计数器会记录并表征当前可用的Credit数量。

n 已接收Credit计数器（Credit Received counter，optional）：这是一个可选项，它用于记录进入流控Buffer的所有TLP的总Credit数量。当流控功能正常时，CREDIT_RECEIVED计数值应该小于等于CREDIT_ALLOCTED计数值。如果并未满足这二者的“小于等于”条件，那么就会发生buffer溢出并检测到出错。协议规范推荐设计者实现这一可选的机制，并且需要注意的是这里若出现违例则应该将其视作是一个Fatal Error，即致命的错误（也就是非常严重的错误）。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image276.jpg)

图 6‑9流控DLLP的类型和包格式

### 6.6 流控示例（Flow Control Example）

接下来将会以Non-Posted Header流控Buffer作为例子进行讲解，并尝试捕捉出在多种情况下流控实现的细微差别。对流控的讨论将会分为如下几个基本阶段：

n **阶段一**：在初始化之后紧跟着传输一个事务，并对其进行追踪，以此来解释流控元素中的计数器和寄存器的一些基本操作。

n **阶段二**：发送方发送事务的速度大于接收方能处理事务的速度，使得接收方Buffer被填满。

n **阶段三**：当计数器翻转到0（持续增大后回到0），流控机制依然可以正常工作，但是需要考虑几个问题。

n **阶段四**：接收方可以对Buffer溢出错误进行检查，这是一个可选项。

#### 6.6.1     阶段一——初始化后的流控（Flow Control Following Initialization）

一旦流控初始化完成后，设备就已经准备好进行正常工作了。我们的示例中的流控Buffer大小为2KB，且种类为Non-Posted Header Buffer，因此1个Credit代表5dwords大小，也就是20Bytes。这意味着可用的流控单位数量为102d（66h）。图 6‑10显示出了涉及到的流控元素，包括流控初始化后各计数器和寄存器的值。

当发送方准备好要发送一个TLP时，它必须首先检查流控Credit。我们给出的例子会比较简单，因为发出的数据包有且仅有一个Non-Posted Header，它永远只会需要1个FC Credit即可，并且我们也事先假设这个事务中不存在数据荷载。

关于Header Credit的检查使用的是无符号算术（2的补码，2’s complement），它需要满足以下公式：

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image278.jpg)

代入图 6‑10中所示的值得到：

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image280.jpg)

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image282.jpg)

图 6‑10初始化后的流控元素

在本例中，将当前CREDITS_CONSUMED计数值（CC）加上PTLP所需的 Credit（Header需要1 Credit，也就是PTLP所需的Credit数量=01h），以此来确定CREDITS_REQUIRED（CR），也就是00h+01h=01h。然后再用CREDIT_LIMIT计数值（CL）减去CREDITS_REQUIRED（CR），这样就能确定是否有足够的可用Credit。

下面的描述包含了对利用2的补码（就是计算机网络中熟知的补码，另一个1的补码其实是反码）进行减法的简要回顾。当使用2的补码进行减法计算时，将要减去的数先转换为反码（1的补码）再加1，这要就得到了减数的补码（2的补码）。然后再将被减数与减数的补码（2的补码）相加，并丢弃最高位进位。

Credit检查：

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image284.jpg)

CR转换为2的补码：

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image286.jpg)

CR的2的补码加上CL：

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image288.jpg)

结果是否小于等于80h呢？是的。减法运算后的结果小于等于计数器最大值的一半，这里是用模256的计数器进行记录的，因此最大值的一半就是128，满足此条件我们就认为接收Buffer有足够的空间，可以发送当前的数据包。这其中只使用一半的计数器值的做法可以避免潜在的计数错误的问题，参阅“Stage3—Counter Roll Over”一节。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image290.jpg)

图 6‑11第一个TLP发送后的流控元素

#### 6.6.2     阶段二——流控Buffer已满（Flow Control Buffer Fills Up）

假设现在接收方已经有一段时间没有从流控Buffer中移除事务了，或许是Device Core繁忙，无法处理事务。最终流控Buffer完全被填满，如图 6‑12所示。此时如果发送方又希望发送一个TLP，那么它先进行流控Credit检查：

Credit Limit（CL）=66h

Credits Required（CR）=67h

进行CL-CR无符号减法运算，也就是减数转换为2的补码的加法运算：

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image292.jpg)

不难发现FFh<=80h并不成立，因此不能发送数据包。

这个通道会一直被阻塞，直到发送方接收到Update Flow Control DLLP（更新流控DLLP），这个DLLP将CREDIT_LIMIT（CL）的值更新为67h或者更大的值。当新的值存入CL寄存器时，发送方的Credit检查就可以通过了，也就可以发送下一个TLP了（Header只占1个Credit）。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image294.jpg)

00h<=80h成立，可以发送数据包。这里之所以CREDIT_LIMIT值加1就够用是因为我们是使用Non-Posted Header流控Buffer，Header只占1个Credit。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image296.jpg)

图 6‑12流控Buffer填满后的流控元素

#### 6.6.3     阶段三——计数器翻转为0（Counters Roll Over）

由于Credit Limit（CL）和Credit Required（CR）计数只会向上增加，它们最终会翻转为0。当CL翻转而CR还没翻转时，Credit检查（CL-CR）就会出现较小值的CL减去较大值的CR的情况。然而，在使用无符号算术时，这种情况并不会引发问题。如前面的例子所描述的那样，当使用2的补码进行减法运算时，是可以得到正确的处理结果的。图 6‑13展示了CL翻转前后，CL与CR的值，以及CL-CR的2的补码减法运算结果。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image298.jpg)

图 6‑13流控计数器翻转问题

#### 6.6.4     阶段四——流控Buffer溢出错误检查（FC Buffer Overflow Error Check）

尽管这是一个可选操作，但是协议规范还是推荐实现这个FC Buffer溢出错误检查机制。图 6‑14展示了和溢出错误检查相关联的流控元素，包括：

n Credits Received（CR）计数器（注意这里CR不是前面的Credit Required）

n Credits Allocated（CA）计数器

n 错误检查逻辑（Error Check Logic）

这些元素使得接收方可以使用跟发送方相同的方式来记录流控Credit。如果流控机制正确运行，那么发送方的Credits Consumed计数值（CC）永远不会超过它的Credit Limit（CL），并且接收方的Credits Received（CR）也永远不会超过它的Credits Allocated计数值（CA）。

若检测到下面的公式成立，那么就说明出现了溢出情况。注意公式中的Field Size对Header来说为8，对数据来说为12。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image300.jpg)

当公式成立时，说明发送至FC Buffer的Credits数量已经超过了可用的数量，也就是说发生了溢出。注意在PCIe 1.0a版本中定义的公式中使用的是≥而不是＞。这是一个错误，因为CA=CR（Credits Received）时并没有发生溢出。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image302.jpg)

图 6‑14 Buffer溢出错误检查

### 6.7 流控更新（Flow Control Update）

当接收方的Buffer内有事务被移除时，也就说明这一部分Buffer空间又变为可用了，那么接收方就需要定期的用最新的流控Credit数量来更新对端设备。图 6‑15给出了一个例子，示例中发送方原本由于Buffer已满的原因阻塞了Header事务的发送，而后接收方从流控Buffer中移除了3个Header，这使得现在有可用的Buffer空间了，但是此时对端设备并不知道这件事。当3个Header从Buffer中移除时，CREDITS_ALLOCATED计数值（CA）会从66h增加至69h，这个新的计数值被报告给对端设备（发送方）的CREDIT_LIMIT寄存器，报告的方式是使用流控更新包（FC Update packet）。一旦CREDIT_LIMIT被更新，发送方就可以继续发送TLP了。

需要特别指出的一点是，这里更新报告的是CREDITS_ALLOCATED寄存器的实际值。其实我们本可以只报告寄存器值的变化量，比如“Non-Posted Header +3 Credits”，但是这种表示会存在一个潜在的问题。为了理解这其中所含的风险，我们需要考虑如果包含了寄存器变化增量信息的DLLP因为某些原因造成了丢失，此时会发生什么。对于DLLP来说是没有replay机制的，如果出现了错误那么处理方式就是简单的把DLLP丢弃。在这种情况下，增量信息将会丢失，并且没有方法恢复它。

反过来说，如果报告的是寄存器的实际值而不是增量，那么在DLLP传输失败时，下一个DLLP依然可以完成计数值的同步更新。虽然这种情况有时会浪费一些时间，比如发送方需要在一个DLLP发送失败时等待下一个DLLP来更新流控Credit，但是并不会有信息的丢失出现。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image304.jpg)

图 6‑15流控更新示例

#### 6.7.1     流控更新DLLP格式和内容（FC_Update DLLP Format and Content）

回想一下，流控更新包与流控初始化包一样，包含两个Credit字段，一个是Header Credit字段，一个是Data Credit字段，如图 6‑16所示。接收方报告在HdrFC和DataFC字段的Credit值可能已经更新了很多次，也有可能自从上次发送更新包后就没有变过。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image306.jpg)

图 6‑16流控更新包的格式和内容

#### 6.7.2     流控更新频率（Flow Control Update Frequency）

针对流控更新DLLP应该如何发送，协议规范定义了各种规则以及建议的实现方式。它们是为了：

n 尽可能早的将最新的CREDITS_ALLOCATED（CA）告知给发送方，特别是当有事务已经被阻塞的时候。

n 确立FC包之间的延时最坏情况。

n 平衡各相关的流控操作的需求，例如：

—  需要足够频繁的报告Credit信息，以此来避免事务阻塞

—  希望减少流控更新DLLP所需要的链路带宽

—  选择最优的Buffer大小

—  选择最大的数据荷载大小

n 检测流控包之间关于最大时延的违例情况。

流控更新仅在链路处于活跃状态（active state，L0 or L0s）时才能使用。所有其他的链路状态表示更加积极的电源管理，它具有更长的恢复时延。

##### 6.7.2.1   立即通告CREDITS_ALLOCATED（Immediate Notification of CA）

当一个流控Buffer已经满到无法接收最大的数据包时，协议规范要求要在Buffer出现更多可用空间时立即发送一个FC_Update DLLP。存在两种情况：

n **最大数据包大小=1Credit**。当数据包的发送由于非无限的NPH（Non-Posted Header）、NPD（Non-Posted Data）、PH（Posted Header）和CplH（Completion Header）这些种类的Buffer已满而被阻塞时，若此时有1个或多个的Credit变为可用（已分配），那么流控更新包（UpdataFC Packet）必须要被安排传输。

n **最大数据包大小=Max_Payload_Size**。对于非无限的PD和CplD的Credit类型，流控Buffer空间可能会减小到无法发送最大数据包的程度。在这种情况下，当1个或多个的Credit变为可用（已分配），流控更新包必须要被安排传输。

##### 6.7.2.2   流控更新DLLP间最大延时（Maximum Latency Between UpdateFC）

每种FC Credit类型（非无限）的流控更新包安排发送的频率至少要达到每30us（-0%/+50%）发送一次。如果设置了控制链路寄存器（Control Link Register）内的扩展同步位（Extended Sync bit），那么安排更新的频率必须不低于120us（-0%/+50%）一次。注意，实际安排发送流控更新包的频率可能要比协议规范中要求的更频繁。

##### 6.7.2.3   基于Payload Size和链路宽度计算更新频率

协议规范中提供了一个公式用于计算更新频率，这个计算是基于最大Payload Size以及链路宽度的。在下面展示的公式中，使用符号时间（symbol time）来定义流控更新的发送间隔。作为参考，1个符号时间的定义为传输1个symbol所需要的时间，Gen1为4ns，Gen2为2ns，Gen3为1ns。表 6‑3、表 6‑4、表 6‑5展示了每种速率下的原生未调整的流控更新参数值。（UF意为UpdateFactor，FC应该是写错了，应该也是UF）

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image308.jpg)

n **最大荷载大小（MaxPayloadSize****）**：这个值在设备的控制寄存器（Control Register）中的Max_Payload_Size字段。

n **TLP****开销（TLP Overhead****）**：常数值（28 symbol）表示消耗链路带宽的附加TLP组件（TLP前缀Prefix、序列号Sequence Number、包头Header、LCRC、组帧符号Framing Symbol）。

n **更新因子（UpdateFactor****）**：在两个相邻流控更新包被接收到的中间间隔的这段时间里，所能发送的最大大小TLP的数量。这个数字是为了平衡链路带宽效率和接收Buffer大小——因为这个值会随Max_Payload_Size和链路宽度而发生变化。

n **链路宽度（LinkWidth****）**：链路所使用的通道（Lane）数量。

n **内部延时（InternalDelay****）**：是一个常数值，为19个符号时间（symbol time），表示接收到TLP并发送DLLP所需要的内部处理延迟。

公式中定义的关系表明，发送流控更新包的频率随链路宽度增加而减少，建议使用计时器来触发流控更新包的调度发送。需要注意，这个公式不考虑接收方或是发送方在L0s电源管理状态时相关的延时（前面提到过仅在active状态才可以使用流控更新）。

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image310.jpg)

表 6‑3 PCIe Gen1原生未调整的AckNak_LATENCY_TIMER值（单位为Symbol time）

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image312.jpg)

表 6‑4 PCIe Gen2原生未调整的AckNak_LATENCY_TIMER值（单位为Symbol time）

![img](img/6%20%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6/clip_image314.jpg)

表 6‑5 PCIe Gen3原生未调整的AckNak_LATENCY_TIMER值（单位为Symbol time）

*译者对上面三个表格进行举例说明，选取PCIe Gen1，Max Payload=256，x2 Link，代入公式得到((256+28)*1.4/2)+19=217.8，不难发现就是对应表中217这个值。而对于Gen2、Gen3可能发现不符合公式，其实不难发现Gen2=Gen1+51，Gen3=Gen2+45，这应该是书中没有提供一些常数参数的原因，总之Gen2表格内的值都等于Gen1对应的值加上51；Gen3表格内的值都等于Gen2对应的值加上45。

协议规范认识到这个公式其实对于许多应用场景的使用是不恰当的，比如那些使用大块数据的流的应用。这些应用可能会要求实际Buffer的大小要大于规范中给出的大小，以及使用更复杂的更新策略，以此来优化性能和降低功耗。由于一个给定的解决方案是依赖于具体应用的特定需求的，因此协议规范中并没有提供此类策略的定义。

#### 6.7.3     错误检测计时器——一个软要求（Error Detection Timer——A Pseudo Requirement）

协议规范中为流控包定义了一个可选的超时（time-out）机制，并且强烈建议实现它，目前它只是一个软要求，但是在未来版本的协议中它可能会成为一个硬性的要求。对于一种给定的Credit类型，它的两个流控包之间的最大延时间隔为120us，而对于超时机制来说超时界限为200us。对于每种流控Credit类型（Posted、Non-Posted、Completion），都各自有单独的超时计时器，且每个计时器都在收到相应类型的流控更新DLLP时进行复位。需要注意，与无限流控Credit相关联的超时计时器一定不能报告错误。

除开无限Credit的情况之外，其他情况下的超时意味着链路存在一个严重的问题。如果超时发生了，那么物理层就会被通知进入恢复状态（Recovery state），并重新进行链路训练，以期望清除错误状态。超时计时器的特性包括：

n 仅在链路处于active状态（L0 or L0s）才进行工作。

n 最大时间限为200us（-0%/+50%）

n 当接收到初始化（Init）或者流控更新包（Update FCP）时，计时器就会复位。或者可选的，也可以在接收到任何DLLP时都复位计时器。

n 超时（Timeout）会强制物理层进入LTSSM（链路训练和状态状态机，Link Training and Status State Machine）的恢复状态（Recovery State）。

springkiss/Chinese Translation of PCI Express Technology

简介

发行版

贡献者

近期动态

springkiss/Chinese Translation of PCI Express Technology .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

springkiss/Chinese Translation of PCI Express Technology