系列文章目录

PCI Express 体系结构导读摘录（一）
PCI Express 体系结构导读摘录（二）
PCI Express 体系结构导读摘录（三）
PCI Express 体系结构导读摘录（四）
PCI Express 体系结构导读摘录（五）
PCI Express 体系结构导读摘录（六）

---

---

第 9 章 流量控制

   流量控制（ Flow Control）的概念起源于网络通信。一个复杂的网络系统由各类设备（如交换机、路由器、核心网），与这些设备之间的连接通路组成。从数据传输的角度来看，整个网络中具有两类资源，一类是数据通路，另一类是数据缓冲。

  数据通路是网络上最珍贵的资源，直接决定了数据链路可能的最大带宽；而数据缓冲是另外一个重要的资源。当一个网络上的设备从一点传送到另外一点时，需要通过网络上的若干节点才能最终到达目的地。在这些网络节点中含有缓冲区，暂存在这个节点中没有处理完毕的报文。网络设备使用这些数据缓冲，可以搭建数据传送的传送流水线，从而提高数据传送性能。最初在网络设备中只为一条链路提供了一个缓冲区，如图 9-1 所示。

   当网络设备使用单数据通路进行数据传递时， 假设在该通路中正在传递两个数据报文， 分别是 A 和 B。 其中数据报文 B 需要经过 Node1 ～ 5 才能到达最终的目的地， 而数据报文 B 在经过 Node 3 时发现由于 Node 3 正在向 Node 4 发送一个数据报文 A。 从而数据报文 B 到达 Node 3 后， 由于 Node 4 的接收缓存被数据报文 A 占用， 而无法继续传递。 此时虽然在整个数据通路中， Node 4 和 Node 5 之间的通路是空闲的， 但是报文 B 还是无法通过 Node 3 和 4， 因为在 Node 4 中只有一个数据缓冲， 而这个数据缓冲正在被报文 A 使用。

   使用这种数据传送规则会因为一个节点的数据缓冲被占用， 而影响了后继报文的数据传递。 为了解决这个问题， 在现代网络节点中设置了多个虚通路 VC， 不同的数据报文可以使用不同的通路进行传递。从而有效解决了单数据通路带来的问题，基于多通路的数据传递如图 9-2 所示。

   如上图所示， 所谓多通路是指在每一个节点内设置两个以上的缓存。 上例中设置了两个缓存， 报文 A 经过 Node 1 ～ 5 时使用缓存 2 进行缓存， 然后进行数据传递， 而报文 B 使用缓存 1 进行缓存。 因此虽然报文 A 因为某种原因不能继续传递， 也只是将报文阻塞在缓存 2 中， 而不影响报文 B 的数据传递。

   所谓 VC 是指缓存到缓存之间的传递通路。 如图 9-2 所示的例子中含有两个 VC， 分别是 VC1 和 VC2。 其中 VC1 对应节点间缓存 1 到缓存 1 的数据传递， 而 VC2 对应缓存 2 到缓存 2 的数据传递。 VC 间的数据传递， 如 Node 1 的缓存 1 / 2 到 Node 2 的缓存 1 / 2， 都要使用实际的物理链路 “链路 1” ， 这也是将 VC 称为 “虚” 通路的主要原因。

   在一个实际的系统中， 虚通路的使用需要遵循一定的规则。 如在 PCIe 总线中， 将不同的数据报文根据 TC 分为 8 类， 并约定这些 TC 报文可以使用哪些 VC 进行数据传递。 在 PCIe 总线中使用 TC / VC 的映射表， 决定 TC 与 VC 的对应关系。

   PCIe 总线规定同一类型的 TC 报文只能与一条 VC 对应， 当然从理论上讲， 不同的 TC 报文可以与不同的 VC 对应， 也可以实现一种自适应的算法根据实际情况实现 TC 报文和 VC 的对应关系。 只是使用这种方法需要付出额外的硬件代价， 效果也不一定明显。

   下文以图 9-2 所示的数据传递为例， 进一步对此说明相同类型的报文使用不同 VC 的情况。 假设报文 A 和 B 属于相同种类的报文， 但是报文 A 使用 VC1， 而报文 B 使用 VC2。 首先报文 A 传递到 Node 4 后被阻塞。 而报文 B 使用的 VC 和报文 A 使用的 VC 不同， 报文 B 最终也会到达 Node 4。

   由于报文 A 和报文 B 属于相同类型的报文， Node 4 阻塞报文 B 的概率非常大， 因为 Node 4 已经阻塞了报文 A。 阻塞报文 A 的原因在很大概率上也会对报文 B 适用。 此时两个虚通路都被同一种类型的报文阻塞， 其他报文将无法通过。 因此在实际应用中， 相同类型的数据报文多使用同一个 VC 进行数据传递， 而在 PCIe 总线中， 一个 TC 只能对应一个 VC。

   目前多通路技术的应用已经普遍应用到网络传输中， 虚通路是一种防止节点拥塞的有效方法。 但是在网络传送中， 还存在一种不可避免的拥塞现象， 即某一条链路或者某个节点是整个系统的瓶颈。

   我们假设图 9-2 中 Node 4 将报文转发到 Node 5 的速度低于 Node 3 发送报文的速度。 在这种情况下， Node 4 将成为整个传送路径上的瓶颈， 无论 Node 4 中的缓存 1 和 2 有多大，总会被填满， 从而造成节点拥塞。

   当缓存填满后， 如果 Node 3 继续向 Node 4 发送报文时， Node 4 将丢弃这些报文， 之后 Node 3 将会择时重发这个报文， 而 Node 4 仍然会继续丢弃这个报文， 这种重复丢弃的行为将极大降低网络带宽的利用率， 而且 Node 3 也会成为网络中新的瓶颈， 从而引发连锁反应，造成整个网络的拥塞。 为了避免这类事件发生， 网络中的各个组成部件需要对数据传送进行一定的流量控制， 合理地接收和发送报文。

   如上文所述， 在网络中有两类资源， 一类是数据通路， 另一类是数据缓冲。 而流量控制的作用是合理地管理这两类资源， 使这些资源能够被有效利用。

9. 1　 流量控制的基本原理

   目前流量控制从理论到实现大多基于多通道技术， 本节也仅讨论基于多通道的流量控制（FCVC， Flow⁃Controlled Virtual Channels） 的基本原理。

   流量控制的主要作用是在发送端和接收端进行数据传递时， 合理地使用物理链路， 避免因为接收端缓冲区容量不足而丢弃来自发送端的数据， 从而要求发送端重新发送已经发送过的报文， 并最终有效地利用网络带宽。

   目前几乎所有流量控制算法的核心都是根据接收端缓冲区的容量， 向发送端提供反馈。而发送端根据这个反馈， 决定向接收端发送多少数据。 这些流量控制算法都力求发送的每一个数据报文都能够被接收端正确接收， 而不会被接收端因为缓冲不足而丢弃。 使用流量控制机制并不能提高网络的峰值带宽， 相反还会降低网络的带宽， 但是可以有效减少数据报文的重新发送， 从而保证网络带宽被充分利用。

   流量控制的目标是在充分利用网络带宽的前提下， 尽量减少数据报文因为接收端缓存容量不足而被丢弃的情况， 因为此时数据发送端将会择时重新传送这些丢弃的报文， 从而降低了数据通路的利用率。

   为了实现流量控制， 数据接收端需要及时地向发送端反馈一些信息， 发送端依此决定，是否能够向接收端继续发送数据。 这些反馈信息也需要占用一定的数据通路带宽。 但是采用这种方法可以有效避免数据报文的丢失与重发， 从而在整体上提高了数据通路的利用率。 流量控制针对端到端的数据传递， 目前流行的流量控制方法共有两种， 分别为 Rate⁃Based 机制和 Credit⁃Based 机制。

9. 1. 1　 Rate⁃Based 流量控制

   Rated⁃Based 机制适合 “可预知带宽” 的数据传递方式， 而 Credit⁃Based 机制更加适合 “突发数据传送” 。 下面将以图 9-3 所示的实例简单介绍 Rate⁃Based 机制。

   假设 Node 1 与 Node 2 之间共存在 5 个 VC， 即在链路 1 的两端设置了 5 组缓存。 而这 5 个 VC 共享一个物理通路， 即链路 1。 为方便起见， 假设链路 1 的带宽为 1， 而在系统初始化时， 将 VC1 ～ 5 可以使用的带宽 BCVC 都设为 1 / 4 （即 Rate 值为 1 / 4） ， 而且每一个 VC 使用的最大数据传送率不能超过 BCVC。

   在某些情况下， 由于在 Node 1 中， 每个 VC 的 BCVC 最大值为 1 / 4， 因此 Node 1 可以向 Node 2 发送的数据带宽总和为 5 / 4， 大于链路 1 所能提供的峰值带宽， 因此链路 1 将可能成为瓶颈， 从而造成网络拥塞。 此时来自 Node 1 的数据报文必然会阻塞在各自 VC 的发送缓冲中， 并可能出现报文重传现象。

   Rate⁃Based 机制使用 “自适应” 调解的办法有效防止了这种网络拥塞。 Rate⁃Based 机制规定每一个 VC 在发送一定数量的报文后， 将主动地将相应 VC 的 Rate 调整为 Rate 减去 ADR （Additive Decrease Rate） ， 直到 Rate 等于 MCR （ Minimum Cell Rate） （在本节的实例中， 5 × MCR≤1。 即所有 VC 使用的 MCR 之和小于或等于链路总带宽。）； 当 Node 2 的 Egress 端口并不拥塞时， Node 2 将向 Node 1 的对应 VC 发出正向反馈， 通知该 VC 可以适当提高数据传送率， 当 Node 1 的 VC 收到这个正向反馈后， 将更新其 BCVC。

   假设在本例中 MCR 为 x， 当链路 1 严重拥塞时， Node 2 不会向 Node 1 的所有 VC 发出正向反馈， 最终 Node 1 所有 VC 的 Rate 都将降为 MCR， 此时 Node 1 将不会向 Node 2 发送过多的数据报文； 当链路 1 并不拥塞时， Node 2 将向 Node 1 的相应 VC 发出正反馈， 通知 Node 1 可以适当提高数据报文的数据传送率。

   Rate⁃Based 流量控制机制可以使用漏桶 （ Leaky Bucket） 算法或者令牌桶 （ Token Bucket） 算法实现。 使用令牌桶算法时， 一个设备至少具有 MCR 个令牌， 这个设备每发送一定数量的报文后， 将令牌减少 ADR 个， 但是总令牌数不低于 MCR。 当这个设备收到下游设备的正反馈时， 将增加令牌数。采用 Rate⁃Based 流量控制机制可以有效解决 “可预知带宽” 的数据传递。 比如 Node 1 向 Node 2 发送音频或者视频数据， 这些音视频数据占用的数据带宽基本恒定， 因此使用这种方法可以保证这类数据报文的流畅传递。

   而对于多数长度 “不可预知” 的突发数据传递， 该机制并不能完全适用。 因为 Rate⁃Based 流量控制的实时性较弱， 当一个 VC 需要瞬间传递大量报文时， Rate⁃Bsed 机制不能及时地为这条 VC 提供足够的数据传送率； 而当一个 VC 拥塞时， 也不能及时地降低数据传送率。 因此使用 Rate⁃Based 机制并不能满足网络上突发数据传送的需要， 此时需要使用 Credit⁃Based 机制对流量进行控制。

9. 1. 2　 Credit⁃Based 流量控制

   为便于 Credit⁃Based 流量控制机制的讨论， 假设在网络中存在三类节点， 分别是 Upstream 节点、 Current 节点和 Downstream 节点， 这些节点之间通过实际的物理链路互连， 在每一个节点内部都使用两个 VC， 其结构如图 9-4 所示。

   其中 Upstream 节点通过物理链路将数据报文发向 Current 节点， 而 Current 节点通过物理链路将数据报文发向 Downstream 节点。 在虚通路的设计中， 每个节点的发送端口和接收端口之间具有分属于不同 VC 的数据缓冲， 这些数据缓冲之间的互连组成了不同的 VC。

   Current 节点首先将来自 Upstream 节点的报文暂存在数据缓冲中， 然后再发送到 Downstream 节点。 当 Upstream 节点通过 Current 节点， 向 Downstream 节点发送数据报文时， 流量控制发生在 Upstream 节点和 Current 节点、 Current 节点和 Downstream 节点之间， 而不是 Upstream 节点到 Downstream 节点。 简而言之， 流量控制发生在链路的两端， 基于端到端之间， 而不是基于节点到节点间。

   在 Upstream 节点、 Current 节点和 Downstream 节点中存在两个 VC， 下文以其中的一个 VC 为例， 说明如何使用 Credit⁃Based 机制进行数据传递。 值得注意的是， Current 节点、 Upstream 节点和 Downstream 节点只是一个相对概念。 Current 节点也可以从 Downstream 节点接收数据报文， 而向 Upstream 节点转发这些数据报文， 从而组成一个双向通路。 为简便起见，本章仅讨论在单向通路下， Credit⁃Based 流量控制机制的原理与实现。

   Credit⁃Based 机制基于 “Credit” 进行数据传递， 当 Upstream 节点需要发送数据报文时，需要具备足够的 Credit， 才能向 Current 节点发送数据。 这个 Credit 由 Current 节点提供， 并与 Upstream 节点保存的 Credit 同步， 为此 Current 节点需要定时向 Upstream 发送 “传递 Credit” 的数据报文。

   下文为简便起见， 假设节点间传送的数据报文， 其长度固定， 而且每次只能传递一个数据报文。 Credit⁃Based 机制需要使用以下参数进行报文传递。

• Buf_Alloc 参数。 该参数保存在 Current 节点中接收数据缓冲的总大小。 Upstream 节点能够发送的数据报文总数不能大于该参数。
• Crd_Bal 参数。 该参数是 Upstream 节点可以发送的数据报文数， Current 节点需要定时向 Upstream 节点发送 Credit 报文。 Upstream 节点收到该报文后， 使用该报文中的 “Credit” 同步 Crd_Bal 参数。 Upstream 节点可以发送的数据报文数不能超过 Credit_Bal 参数。
• Tx_Cnt 参数。 该参数为 Upstream 节点已经发送的数据报文数。
• Fwd_Cnt 参数。 该参数为 Current 节点转发到 Downstream 节点的数据报文数。

   Credit⁃Based 流量控制使用的各个参数之间的关系如图 9-5 所示。

1. Upstream 节点向 Current 节点发送报文
      Upstream 节点向 Current 节点发送报文时， Current 节点必须有足够的缓冲， 而且 Current 节点需要预先将其剩余的缓冲数量， 即 Credit （其值为一个正整数） ， 及时地发送给 Upstream 节点。 Upstream 节点使用 Crd_Bal 参数保存这个 Credit。
     
      Crd_Bal 参数的初始值为 Buf_Alloc， 即 Current 节点能够接收的最大报文个数， 该值在系统初始化时由 Current 节点发向 Upstream 节点。 因此 Upstram 节点在流量控制机制初始化完毕后， Crd_Bal 参数与 Current 节点中能够存放的最大报文数相同。
     
      Upstream 节点每成功发送一个数据报文后， Crd_Bal 值减 1， 当 Crd_Bal 参数为 0 时，Upstream 节点不能向 Current 节点发送数据报文。 此时 Upstream 节点必须等待 Current 节点发送 Credit 报文， 更新 Crd_Bal 参数后， 才能继续发送数据报文。

2. Current 节点向 Upstream 节点发送 Credit
      Current 节点收到来自 Upstream 节点的数据报文后， 将会根据链路的实际情况， 将这些报文转发到 Downstream 节点。
     
      假设在一段时间之内， Current 节点共收到了 Tx_Cnt 个报文， 而转发了 Fwd_Cnt 个报文，那么此时在 Current 节点中还能容纳 $Buf\_Aloc-（Tx\_Cnt-Cx\_Cnt）$ 个报文空间。 Current 节点将这个值作为 Credit， 发送到 Upstream 节点。 而 Upstream 节点将根据这个 Credit 的值更新 Crd_Bal 参数。

3. Current 节点将报文转发到 Downstream 节点
      Current 节点接收到报文之后再将其转发出去涉及一些路由算法。 常用的算法有 CutThrough 路由和 Wormhole 路由算法。
     
      当使用 Wormhole 路由方式时， 一个报文将被分解为若干个 Flit， 包括 Header Flit、 DataFlit 和 Tail Flit。 当数据报文到达 Current 节点后， Current 节点立即对 Header Flit 进行分析， 首先根据路由算法决定发向哪个 Downstream 节点（在网络系统中， Current 节点可能对应多个 Downstream 节点。）。 如果在对应的 Downstream 节点中， 链路空闲且有足够的缓冲资源时， Current 节点将发送 Data Flit 直到 Tail Flit， 即发送整个数据报文； 如果对应的 Downstram 节点没有资源接收这个报文， 数据报文将在 Current 节点中存储。
     
      Cut⁃Through 路由与 Wormhole 路由类似。 采用 Cut⁃Through 路由时， Downstream 节点必须具有接收整个报文的能力时， 才能接收报文； 而采用 Wormhole 路由时， Downstream 节点具有接收部分报文的能力时， 就可以接收报文。 采用 Wormhole 路由的优点是数据报文传送延时较短， 每一个节点所需要的数据缓存相对较小。 当网络发生拥塞时， 采用 Wormhole 路由技术可能会使一个报文分别缓冲在 Current 节点和 Downstream 节点中， 而使用 Cut⁃Though 路由技术数据报文最终缓冲在一个节点中。
     
      巨型机一般使用 Wormhole 技术进行报文传递， 而网络系统中多使用 Cut⁃Though 路由技术。 巨型机应用针对的是可预知的网络拓扑结构， 而网络系统的拓扑结构是变化的。 在一个网络拓扑结构可预知的前提下， 采用 Wormhole 技术可以在避免拥塞的前提下， 降低网络报文的传递延时； 而对于一个未知的网络拓扑结构， 使用 Cut⁃Though 技术更为合理。

9. 2　 Credit⁃Based 机制使用的算法

   Overrun 指 Current 节点没有足够的缓存接收来自 Upstream 节点的数据报文； 或者 Downstream 节点没有足够的缓存接收来自 Current 节点的数据报文。

   Underrun 指 Downstream 节点有足够的缓存可以接收 Current 节点的报文， 但是 Current 节点的缓存中没有需要发送的报文； 或者 Current 节点有足够的缓存可以接收 Upstream 节点的报文， 但是在 Upstream 节点的缓存中没有需要发送的报文。

9. 2. 1　 N123 算法和 N123 + 算法

9. 2. 2　 N23 算法

9. 2. 3　 流量控制机制的缓冲管理

   上文讲述了基于单个 VC 的流控机制， 实际上在 Upstream、 Current 和 Downstream 节点中一般含有多个 VC。 多个 VC 之间如何合理地使用缓存值得重点关注， 在实际设计中， 可以为每一个 VC 设置独立接收缓存， 也可以使多个 VC 共享同一个接收缓存。 在 FCVC 的实现中， 可以根据实际情况选择独立缓存或者共享缓存。其中， 每一个 VC 都使用独立接收缓存的流量控制方法称为静态 （ Static） 流量控制；而使用共享缓存的流量控制方法称为自适应 （Adaptive） 流量控制。

   目前接收缓存的分配常使用两种算法， 分别是 Sender⁃Oriented 和 Receiver⁃Oriented 管理算法。 这两种算法的缓冲设置如图 9 - 9 所示。 使用 Sender⁃Oriented 管理算法时， Adaptive Buffer 的分配在 Upstream 节点中完成， 如果系统中有多个 Upstream 节点， Current 节点需要在其接收端点处为每个 Upstream 节点准备 Adaptive Buffer， 而且 Current 节点并不知道 Upstream 节点的使用情况， 这为 Current 节点的缓冲管理带来了不小的困难。

   而使用 Receiver⁃Oriented 管理算法可以有效避免这类困难， 使用这种算法时， 所有来自 Upstream 节点的数据报文在 Current 节点的发送端准备一个 Adaptive Buffer， 对这个 Buffer 的分配也在 Current 节点内部完成。 这两种算法的具体实现都较为复杂， 本节并不详细介绍这些算法， 在 PCIe 总线中， RC 和 Switch 的硬件设计将会涉及这些内容， 而 EP 无需关心这些问题。

   图中的上半部分是 Sender⁃Oriented 管理算法的示意图， 而下半部分是 Receiver⁃Oriented 管理算法的示意图。 由图 9-9 可以发现， 使用这两种算法时 Adaptive Buffer 都在 Current 节点中， 只是位置不同。

9. 3　 PCIe 总线的流量控制

   我们仍然使用上文的 Upstream、 Current 和 Downstream 节点模型分析 PCIe 总线使用的流量控制机制。 在 PCIe 总线中， Upstream 节点和 Downstream 节点可以为 RC 或者 EP， 而 Current 节点只能为 Switch 或 RC （如果 RC 支持 Peer⁃to⁃Peer 传送方式）。

   此外在 PCIe 总线中， 允许 Upstream 节点和 Downstream 节点直接相连， 而不需要经过 Current 节点， 如 RC 的某个端口可以和 EP 直接相连。 当然这种情况也可以理解为 Upstream 和 Current 节点直接相连， 但是 Current 节点不需要与 Downstream 节点相连。

   与传统的流量控制机制相比， PCIe 总线的流量控制机制有所不同。 流量控制机制首先出现在互联网中， 使用流量控制机制最典型的应用是基于 ATM （ Asynchronous TransferMode） 的分组交换网。 在 ATM 分组交换网系统中， 数据传递以报文为单位进行， 每一个报文都可以独立地通过分组交换网， 到达目的地。 而 PCIe 总线的数据传递基于节点到节点间的数据传递， 一个完整的 PCIe 总线传输需要使用多个报文， 而且这些报文和报文之间还有一定的联系， 如一个完整的存储器读由存储器读请求 TLP 和存储器读完成 TLP 组成。

   在 PCIe 总线中， RC 端口和 EP 之间可以直接互连， 而不需要中间节点， 这和基于分组交换的网络有很大的不同。 此外在 PCIe 总线中， 报文的大小并不固定， 如数据报文的大小可以为 128B、 256B， 只要数据报文的有效负载小于 Max_Payload_Size 参数即可。

   这些长度不确定的数据报文， 为 PCIe 总线的流量控制带来了不小的困难， 也是因为这个原因， PCIe 总线的流量控制机制将一个 TLP 分为 TLP 头和 Payload 两部分， 并分别为这两部分提供不同的接收缓冲， 以合理利用 PCIe 链路的带宽。

   PCIe 总线的这些特性实际上不利于流量控制的实现， 为此 PCIe 总线在传统流量控制理论的基础上， 做出了许多改动。 在 PCIe 总线中存在多条 VC， 其流量控制也是基于 FCVC 的， 但是 PCIe 总线在接收缓冲的设计上与传统的流量控制机制有很大的不同。

   PCIe 总线的主要应用领域在 PC 或者服务器中进行板内互连， 在这个应用领域中， 流量控制并不是最重要的。 PCIe 总线的流控机制远非完美， 这在某种程度上影响了 PCIe 总线在大规模互连结构中的使用。 但是 PCIe 总线的流量控制机制仍有其闪光之处， 因此读者仍有必要了解 PCIe 总线的流量控制机制。

   与传统流量控制机制相比， PCIe 总线在实现流量控制机制时需要更多的接收缓存， 因此 PCIe 总线实现流控的代价相对较大。 值得庆幸的是， 目前 PCIe 总线上的设备， 包括 RC、EP 和 Switch， 很少有支持两个以上 VC 通路的。 一般来说 PCIe 总线上的设备， 如 RC 和Switch 上也只有两个 VC， 多数 EP 仅支持一个 VC。

   PCIe 总线的流量控制机制由事务层和数据链路层协调实现， 而对系统软件透明。 PCIe 总线使用 Credit⁃Based 流量控制机制， 其中 Credit 报文以 DLLP 的形式从 Current 节点反馈到 Upstream 节点。 在 PCIe 总线中， 数据报文首先以 TLP 的形式通过数据链路层， 而到达数据缓存时被分解为 Header 和 Data 两个部分， 分别存放到不同的接收缓存队列中。

9. 3. 1　 PCIe 总线流量控制的缓存管理

   在 PCIe 总线的节点中， 一个 VC 的接收缓存由 PH （ Posted Header） 缓存、 PD （ Posted Data） 缓存、 NPH （Non⁃Posted Header） 缓存、 NPD （Non⁃Posted Data） 缓存、 CplH （ Completion Header） 缓存和 CplD （Completion Data） 缓存组成。

• PH 缓存存放存储器写请求 TLP 和 Message 报文使用的 TLP 头。
• PD 缓存存放存储器写请求 TLP 和 Message 报文使用的 Payload。
• NPH 缓存存放 Non⁃Posted 请求 TLP 使用的 TLP 头。
• NPD 缓存存放 Non⁃Posted 请求 TLP 使用的 Payload。 在 Non⁃Posted 请求 TLP 中， 如存储器读请求 TLP 并不含有 Payload 字段， 但是 I / O 和配置写请求 TLP 使用 Payload字段。
• CplH 缓存存放完成报文使用的 TLP 头。
• CplD 缓存存放完成报文使用的 Payload。 如上文所述， 完成报文分为两大类， 带数据的完成报文和不带数据的完成报文。 其中不带数据的完成报文不需要使用 CplD 缓存。

   在 PCIe 总线中， 一个 TLP 从 Upstream 节点传送到 Current 节点时， 必须同时具备多个缓存的 Credit 后才能发送。 如存储器写请求 TLP， 需要同时具备 PH 和 PD 缓存的 Credit， 才能发送； 而 “不带数据的” 存储器读完成 TLP， 仅需要具备 CplH 缓存即可。 这些缓存在 PCIe 设备中的组成结构如图 9-10 所示。

   PCIe 总线将 Header 和 Data 缓存分离的主要原因是， 一个 TLP 的 Header 大小是固定的，如 PH 和 NPH 大小在 5DW 之内， CplH 大小在 4DW 之内； 而 Data 的大小并不固定， 除了 NPD 的大小为 1 个 DW 之外， 其他数据报文的长度由 TLP 的 Length 字段确定， 并不固定。PCIe 总线将 Header 和 Data 缓存分离有利于 Data 缓存的合理使用。

   PCIe 总线规范将这些缓存使用的 Unit 统称为 FC （Flow Control） Unit， 下文将以 FC Unit 简称这些对应缓存的 Unit。 因为 Header 的大小固定， 所以 Header 缓存能够精确地预知可以容纳几个 Header； 而由于 Data 的大小并不固定， Data 缓存无法精确预知可以存放几个 Data，当然 Data 缓存也不可能将 Data 的基本单位设置为 Max_Payload_Size 参数。 因为这样做不仅不合理， 而且非常浪费资源。 将 Header 和 Data 缓存分离， 有利于 Data 缓存使用类似 Adaptive 流量控制的方法使所有 Data 共用一个缓存， 从而提高了 Data 缓存的利用率。 但是也造成 TLP 因为不能同时具有 Head 和 Data 缓存， 而无法传送。

   在 PCIe 总线中， 不同的 TLP 使用对应缓存的 Unit 数量也不同， Current 节点有时需要两种缓存才能接收一个 TLP。 不同 TLP 使用的缓存数目如表 9-2 所示。

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  

  
 

☆