PCIE 性能解释

标签：解释 TLP 字节 性能 bytes PCIE ns 数据包 读取

概述

PCI Express技术， 是串行点对点互连协议， 提供用于可靠数据的高带宽可扩展解决方案传输。 虽然 PCIe传输速率相比PCI非常快，但是用户应该了理解原始bit rate传输与有效data传输数据性能不同之处 。

本文探讨了 PCI Express 的性能影响因素，提供如何评估系统性能指导。本文信息主要覆盖到PCIe GEN3。

性能的定义

PCIe GEN1最大传输速率是2.5Gbps,PCIe GEN2最大传输速率是5Gbps，PCIe GEN3最大传输速率是8Gbps。这些速率只的是raw bit传输速率，并不是系统的有效data传输速率。有效的数据传输速率因为overhead要比此低。

各种类型的数据，例如内存、I/O 或配置数据，通过 PCI Express 系统传输。大多数设计都专注于尽可能有效地传输数据 。就本白皮书而言，性能定义为 系统的有效数据传输。 此后， data统称有效数据。

PCIe Gen1 和 Gen2 有许多相似之处，但 Gen3 为实现速率翻倍引入了新的概念。 本文介绍Gen 1 / Gen 2 实现并解释GEN3实现区别。

数据传输overhead

通过 PCI Express 系统的任何数据移动都包含一定数量的数据overhead开销。 PCIe系统影响包括 symbol encoding， 传输层数据包 （TLP） overhead， 和 traffic overhead。

Symbol Encoding

PCIe GEN1 和 GEN2协议使用 8B/10B 编码方案传输保持DC平衡。与某些性能因素不同， 编码方案不能调整; 这 是8B/10B 编码要求。 表1是示例

表1：8B/10B编码例子

8位	10 位 +	10 位 –
00000000	1001110100	0110001011
00000001	0111010100	1000101011
00000010	1011010100	0100101011
……	……	……
11111101	1011100001	0100011110
11111110	0111100001	1000011110
11111111	1010110001	0101001110

8B/10B 编码方案保证了 transition-rich的数据流，以便接收设备可以对传入的串行数据执行时钟恢复。Transition rich 是指每传输 20 个连续位，1 和 0 的数量之差不能超过 2，并且连续不能超过 5 个 1 或 5 个 0。

为了保持 DC 平衡，传输的每个字节都有一个正视差 10 位编码和一个负视差 10 位编码。对于发送的每个字节，发送器必须确定是发送该字节的正编码版本还是负编码版本。因此，要传输 1 个字节的数据，需要在串行链路上传输 10 位，从而导致由于编码而造成的可能吞吐量损失 20%。该结果一般称为链路的理论带宽（公式1）

PCIe GEN3传输速率设置为 8.0 Gb/s。为了将第二代速率 5.0 Gb/s 的有效带宽加倍，决定使用具有 2% 损耗特性的 128B/130B 编码，而不是 8B/10B（20% 损耗特性）。
表 2 显示了各种 PCI Express 链路宽度和速度的理论带宽。

表 2：全双工理论带宽 (GB/s)

尽管第一代传输线可以以 2.5 Gb/s 的速度运行，但 8B/10B 编码将有效带宽降低至每个通道每个方向 2.0 Gb/s。
同样，第三代可以使用 128B/130B 编码以 8.0 Gb/s 的速度运行，这将理论带宽降低到 7.9。由于数据包和流量开销，实际系统带宽略低，总体系统效率为每通道每方向 7.8 Gb/s。

Transaction Layer Packet Overhead

PCI Express 系统在 TLP 的有效负载中传输数据。内存数据在内存写入 TLP 和完成数据 TLP 中传输，这是对内存读取操作的响应。图 1 和图 3 分别显示了 Gen 2 和 Gen 3 的典型 TLP。

memroy请求32bit和64bit地址头

事务层、数据链路层 (DLL) 和物理层 (PHY) 增加了每个TLP的开销，从而降低有效数据传输率。事务层
增加加数据包头和可选的端到端循环冗余校验（ECRC）。 DLL 将序列号和链路层 CRC (LCRC) 添加到
数据包以保证通过链路的成功传输。 PHY 增加了标记数据包开始和结束的信息。
TLP 开销在 20 到 30 个字节之间变化，具体取决于 Gen 2 或 Gen 3 速度，使用 32 位或 64 位寻址以及可选的 ECRC。内存读取或写入 TLP 可以使用 32 位或 64 位寻址。 64 位可寻址 TLP 标头为 16 字节（32 位寻址为 12 字节），并且需要在数据包中交换额外的 4 字节信息。图4 内存请求TLP 32 位和 64 位寻址的头格式。

大量数据的传输需要多个TLP，每个TLP都有自己的overhead。尽管每个 TLP 包含给定量的开销，但更大的倍数
TLP 传输提高了链路效率。最大有效负载大小 (MPS) 设置，分配给通信设备，确定最大 TLP 大小。
增加MPS并不一定会导致链接相应增加效率，因为随着单个 TLP 变得更大，其他因素例如流量开销开始影响链路性能。

Traffic Overhead

PHY 和 DLL 都会引入流量开销。当链路达到正常运行状态 (L0) 时，PHY 会插入skip-ordered集以补偿两个通信端口之间的比特率差异。对于 Gen 1 和 Gen 2 速度，skip-ordered集的长度为四个字节。对于 Gen 3 速度，skip-ordered集的长度通常为 16 个字节。对于 Gen1 和 Gen2，skip-ordered集被安排以 1,180 到 1,538 个符号时间之间的间隔插入。符号时间是将一个字节（由于 8B/10B 编码而为 10 位）放入串行通道所需的时间量。对于 Gen 3，skip-ordered集必须安排在 370 到 375 个块内发生。 PCI Express 规范不允许将有序集或其他数据包插入到 TLP 中间。这意味着来自 DLL 的skip-ordered 集和其他链路管理数据包只能在 TLP 流量的间隙期间传输。这一要求是增加 MPS 不会导致链路效率同等提高的原因之一。随着 TLP 变得越来越大，TLP 之间的链路管理活动差距也会增加。
DLL 的目的是维持两个链接伙伴之间的可靠数据传输。为了实现这一目标，PCI Express 规范定义了源自 DLL 层并由 DLL 层使用的数据链路层数据包 (DLLP)。各种类型的 DLLP 用于链接管理。确认 (ACK) DLLP、非确认 (NAK) DLLP 和流量控制 (FC) DLLP 对性能影响最大。

Link Protocol Overhead

对于从一个设备发送到另一设备的每个 TLP，必须向 TLP 的发送方返回 ACK 或 NAK，以指示数据包的接收成功或不成功。发送设备必须将 TLP 保存在其重播缓冲区中，直到收到该 TLP 的 ACK。如果在原始传输过程中出现问题，则可以再次发送数据包，确保不会丢失数据，并实现高度可靠的链路。鉴于协议的 ACK/NAK 性质，当发送大量 TLP 时，还会生成大量 ACK/NACK DLLP，从而减少链路带宽。
该协议允许将等待传输的相同类型的多个 DLLP 折叠为单个 DLLP，如图 5 所示。例如，如果五个传输的 TLP 均已成功接收，并且接收方确认了第五个 TLP，则发送方假定所有五个 TLP 均已正确接收。在链路上折叠 ACK 既有优点也有缺点。折叠 ACK 或 NAK 可减少链路上的流量开销。然而，如果 ACK 发送得不够频繁，则发送器可能会在数据包等待从重播缓冲区中清除时限制数据包传输。确定何时或何时不将多个 DLLP 折叠为一个的机制是单个设备数据链路层设计的一部分。如果数据包确认速度不够快，传输设备的重放缓冲区就会填满，并且在确认旧数据包之前不允许发送新数据包。这会停止线路上的数据传输。

Flow Control Protocol Overhead

基于信用的流量控制消除了由于接收缓冲区溢出而导致的数据包丢弃。虽然流量控制是必要的，并且比传统 PCI 中较旧的“重试”模型更有利，但它仍然具有降低链路效率的潜在后果。每个链路伙伴发送的 FC DLLP 不断更新设备接收器的状态，以便发送设备仅在知道接收器有足够的缓冲区空间时才发送数据包。发送器保存链路伙伴接收器上可用信用数量的运行计数，并在每次发送数据包时递减该计数，如图 6 所示。接收器处理数据包并释放缓冲区空间后，它会发送 FC 更新 DLLP，通知发送设备可用空间。设备处理和传输 FC 更新 DLLP 的效率会影响链路的整体性能。与设备处理折叠 ACK/NAK 的方式类似，设备用于处理和传输流量控制更新的机制取决于设备的设计，并且在设备之间可能有所不同。同样，根据发送流量控制更新的频率，有利有弊。不太频繁的流量控制更新可减少链路管理流量开销。然而，接收器的缓冲区更大以维持合理的性能。

System Parameters Affecting Performance

除了协议和流量开销之外，还有其他因素会影响 PCI Express 系统的性能。其中三个是最大有效负载大小、最大读取请求大小和请求类型。

Maximum Payload Size

尽管 PCI Express 规范允许高达 4,096 字节的有效负载，但规范说：“软件必须注意确保每个数据包不超过
数据包路径上任何系统元素的 Max_Payload_Size 参数。”这意味着层次结构中的每个设备必须使用相同的 MPS 设置，并且设置不得超出层次结构中任何设备的能力。所以，具有高 MPS 功能的设备需要在较低 MPS 设置下运行，以容纳具有最低 MPS 能力的设备。例如，MPS图 7 中的 PCI Express 系统被编程为 128 字节以容纳端点 3。

系统的 MPS 设置是在枚举和配置过程中确定的过程。层次结构中的每个设备都会在其设备中通告其 MPS 能力寄存器，位于设备的配置空间中。软件探测每个设备以确定其 MPS 能力、确定 MPS 设置，以及通过将 MPS 设置写入其设备控制寄存器来对每个设备进行编程。

MPS 设置确定传输给定数据量所需的 TLP 数量。随着 MPS 的增加，传输同一块数据所需的 TLP 数量会减少
。然而如表 3 和图 8 显示，增加有效负载大小并不会以相同速率提高效率。

公式 2 定义了数据包效率。

表 3 显示了四种 MPS 设置的数据包效率计算。这些示例假设 TLP 具有 3 DW 或 12 字节标头并且没有 ECRC，从而产生总共 20 字节的开销。

理论最大数据吞吐量是数据包效率占理论带宽的百分比，如表 2 所示。例如，对于 128 字节的 MPS，链路上传输的 86% 的位可能是数据位。然而，由于“Traffic Overhead”中讨论的流量开销，情况并非如此。

图 8 是表 3 中数据包效率计算的图形表示。

图 8 显示数据包效率随着 MPS 的增加而增加，但速率不同。例如，当MPS从128字节增加到256字节时，数据包效率增加6%。当MPS从512字节增加到1024字节时，数据包效率仅增加2%。对于当前可用的大多数系统，MPS 往往设置为 128 字节或 256 字节。无论给定 MPS 的传输大小如何，数据包效率都是固定的。例如，使用 128 字节 MPS 设置，任何大小的传输的数据包效率均为 86%。对于 x8 链路，使用表 2 中的值的半双工写入吞吐量效率为 1720 MB/s (0.86 × 2000 MB/s)。表 4 显示了链接率，也称为理论最大数据吞吐量。

表 4 假设写入的 MPS 为 128 字节。对于读取，假设读取完成边界（RCB）为 64 字节，这意味着大部分完成
数据包将包含 64 字节的数据。此示例假设所有读取都满足数据包的 64 字节完成倍数。理论最大值读取的数据吞吐量仅基于完成流量。初始读取请求存在一些相关的延迟，但因为读取请求会移动大数据块通常以流的形式发送，初始延迟不会太长。实际上，当内存控制器处理并返回完成时，读取会在主机中进行管道化和排队。读取效率通过与表3中类似的公式计算：64/(64+20)=76%。

Maximum Read Request Size

在配置过程中，软件还将最大读取请求大小编程到每个设备的控制寄存器中。该参数设置内存读取请求的最大大小，最大可设置为 4096 字节，以 128 字节为增量。
最大读取请求大小可以大于 MPS。例如，可以向具有 128 字节 MPS 的设备发出 512 字节读取请求。返回读取请求数据的设备将 Completion with Data TLP 的大小限制为 128 字节或更少，这需要一次读取多次完成。
系统使用最大读取请求大小来平衡整个拓扑中的带宽分配。限制设备在一次传输中可以读取的最大数据量可以防止其独占系统带宽。
最大读请求大小也会影响性能，因为它决定了需要多少个读请求才能获取数据，读请求为100%开销，因为它们不包含任何有效负载。使用最大读取请求大小 128 字节读取 64 KB 数据需要 512 个内存读取 TLP（64 KB / 128 字节 = 512）来从内存请求数据。为了提高移动大数据块时的效率，读取请求的大小应尽可能接近最大读取请求大小，以减少必须传输的读取次数。

Read Completion Boundary

数据完成 TLP 返回数据以响应读取请求。读取完成边界 (RCB) 允许来自单个读取请求的数据由多个完成提供服务。数据分为 64 字节或 128 字节补全，自然地与地址边界对齐。这意味着数据量某些完成返回的值可能小于 RCB 设置，具体取决于下一个地址边界的位置。通常，大多数根复合体将 RCB 设置为 64 字节，并以 64 字节完成形式返回数据，而不是 MPS 允许的数据。图 9 显示了端点从地址 0x00010028 读取的 256 (0x100) 字节如何由 RCB 设置为 64 字节的根联合体返回。

需要五次数据完成才能返回 256 字节的数据。每个数据TLP有3个DW头，因此单个64字节数据包的数据包效率为76%（64/（64+20）=76%）。
许多根联合体使用 64 字节 RCB，即使 MPS 设置为 128 字节或更高，这意味着读取完成不仅会受到传输请求所花费的时间的影响，而且还会受到完成被划分为RCB 设置允许的最小封装。请参阅第 13 页“读取事务吞吐量”中的示例计算，以更好地了解在考虑其他系统参数时 RCB 如何影响带宽。

Posted and Non-Posted Transactions

Non-Posted事务是从事务返回完成 TLP 的请求Completer，表明交易已成功处理。完成者
是请求的最终目的地的设备，而不是中间设备沿着数据包的路径，例如交换机。
这些请求是Non-Posted事务：

• Memory Read

• Memory Read Lock

• I/O Read

• I/O Write

• Configuration Read (both Type 0 and Type 1)

• Configuration Write (both Type 0 and Type 1)

对于读取请求，Completer 返回带有数据 TLP 的完成。如果 Completer 无法满足请求，则 Completer 将返回一个无数据 TLP 的 Completion，其中包含一条指示事务未成功的消息。对于Non-Posted的写入请求，Completer 返回一个不带数据的 Completion TLP，指示写入是否成功。

Memory Writes and Messages是posted的事务。这些事务不需要来自数据包最终目的地的完成 TLP。相反，发送设备假定posted的请求是成功的，因为 ACK/NAK DLLP 协议保证了数据包通过系统的成功传输。如果完成者在处理发布的请求时遇到错误，则不会通过完成 TLP 通知请求者。然而，在大多数情况下，Completer 会生成一条错误消息，通知根联合体出现了问题。

Calculating Bandwidth

考虑到目前为止讨论的因素，可以计算或至少获得系统性能的合理估计。一般来说，带宽是总带宽 传输的数据量除以传输数据的时间。总体带宽考虑了写入和读取，并且是随时间推移的可持续值，而不是峰值性能（公式 3）。

在进行计算时，可能需要对某些参数做出合理的假设，例如更新 FC DLLP 的发送频率。该信息可能在设备的文献中提供，或者可以使用链路分析器来研究实际的链路流量来获取。

本节中的三个示例不考虑接收器缓冲区大小或发送器重播缓冲区大小，这会影响数据包传输的频率。
链接。这些示例的目的是说明用户在尝试评估其性能预期时应考虑的一些参数

Write Transaction Throughput

本节显示两个计算写入事务吞吐量的示例。这些计算中使用的值并不代表任何一个系统。

Example 1

In this example, 200 posted writes are transmitted at 128 bytes (MPS) each on a x8 link.
Step 1: Establish known parameters
These parameters are already known:
• The PCIe® link is running at 2.5 Gb/s
1 byte is transmitted every 4 ns (Symbol Time)
• There are 8 lanes, meaning packets are distributed across each lane
8 bytes can be sent every 4 ns
Step 2: Calculate TLP and DLLP transfer times based on known parameters
• 128-byte, 32-bit addressable Memory Write TLP transfer time:
[(128 bytes payload + 20 bytes overhead) / 8 bytes/clock] * [4 ns/clock] = 74 ns
• DLLP transfer time:
[8 bytes / 8 bytes/clock] × [4 ns/clock] = 4 ns
Step 3: Make reasonable assumptions about system parameters
These assumptions are made regarding system parameters:
• The TLP to ACK ratio is 1 ACK for every 5 TLPs.
• An FC update is issued every 4 TLPs.
Step 4: Calculate bandwidth
To calculate the bandwidth using Equation 3, the total bytes transferred and the
transfer time are needed.
• Total bytes transferred:
200 posted writes × 128 bytes/posted write = 25,600 bytes
• Transfer time:
(200 × 74 ns) + (40 × 4 ns) + (50 × 4 ns) = 15,160 ns
• Bandwidth:
[25,600 bytes / 15,160 ns] × [1 GB / 1s] = 1.689 GB/s or 1,689 MB/s

Example 2

In this example, 50 posted writes are transmitted at 512 bytes (MPS) each on a x8 link.
Step 1: Establish known parameters
These parameters are already known:
• The PCIe link is running at 2.5 Gb/s
1 byte is transmitted every 4 ns (Symbol Time)
• There are 8 lanes, meaning packets are distributed across each lane
8 bytes can be sent every 4 ns
Step 2: Calculate TLP and DLLP transfer times based on known parameters
• 512 byte, 32-bit addressable Memory Write TLP transfer time:
[(512 bytes payload + 20 bytes overhead) / 8 bytes/clock] × [4 ns/clock] = 266 ns
• DLLP Transfer time:
[8 bytes / 8 bytes/clock] × [4 ns/clock] = 4 ns
Step 3: Make reasonable assumptions about system parameters
These assumptions are made regarding system parameters:
• The TLP to ACK ratio is 1 ACK for every 5 TLPs.
• An FC update is issued every 4 TLPs.
Step 4: Calculate bandwidth
To calculate the bandwidth using Equation 3, the total bytes transferred and the
transfer time are needed.
• Total bytes transferred:
200 posted writes × 128 bytes/posted write = 25,600 bytes
• Transfer time:
(50 × 266 ns) + (10 × 4 ns) + (13 × 4 ns) = 13,392 ns
• Bandwidth:
[25,600 bytes / 13,392 ns] × [1 GB / 1s] = 1.912 GB/s or 1,912 MB/s

Summary of Examples 1 and 2
示例 1 和 2 具有相同的传输大小，但 MPS 增加了 4 倍。总体带宽不会缩放 4 倍，因为随着数据包的增长
越大，传输和处理它们需要更多的时间。这假设 ACK 、FC 更新、传输和处理时间不会改变。实际上，作为数据包变大，DLLP 发送的频率会降低，因为协议不允许注入DLLP 或 TLP 中间的有序集。因此，随着数据包变大，数据包间隙也增加以允许 DLLP 和skip ordered集传输。

Read Transaction Throughput

如第 11 页“发布和非发布事务”中所述，内存读取事务使用分割完成模型。请求者发送读取的TLP。完成者从内存中获取数据后，以 Completion with Data TLP 的形式将数据发送回。完成的大小由完成者的读取完成边界因素决定。请求者可以在完成开始返回之前连续传输多个读取请求。此外，单个读取请求TLP 可能会导致多个带有数据 TLP 的完成，每个都会产生开销和处理延迟。事实上，按64 字节或 128 字节 TLP组返回完成结果是正常的
，具体取决于 RCB。
完成的分配方式取决于设备的设计。完成TLP中的有效负载的大小不能高于为设备设置的MPS值。因此，即使设备能够使用数据 TLP 生成大量补全，但如果 MPS 低于设备的能力，它仍然必须将数据分解为多个 TLP。

影响读取性能的另一个主要因素是返回完成结果的往返延迟。例如，如果端点向内存控制器发送读取请求，则必须考虑处理读取、获取数据以及生成返回端点的完成所需的时间。

Example 3

In this example, 4096 bytes of data are read on a x8 link where the maximum read
request size is 256 bytes.
Step 1: Establish known parameters
These parameters are already known:
• The PCIe link is running at 2.5 Gb/s
1 byte is transmitted every 4 ns (Symbol Time)
• There are 8 lanes, meaning packets are distributed across each lane
8 bytes can be sent every 4 ns
Step 2: Calculate TLP and DLLP transfer times based on known parameters
• 32-bit addressable Memory Read TLP transfer time:
[(20 bytes overhead) / 8 bytes/clock] × [4 ns/clock] = 10 ns
• DLLP transfer time:
[8 bytes / 8 bytes/clock] × [4 ns/clock] = 4 ns
• RCB is 64 bytes, so the majority of completions are 64-byte TLPs.
[(64 bytes payload + 20 bytes overhead) / 8 bytes/clock] × [4 ns/clock] = 42 ns
Step 3: Make reasonable assumptions about system parameters
These assumptions are made regarding system parameters:
• The TLP to ACK ratio is 1 ACK for every 5 TLPs.
• An FC update is issued every 4 TLPs.
• The receiver incoming read to completion generation time is 300 ns.
Step 4: Calculate bandwidth
To calculate the bandwidth using Equation 3, the total bytes transferred and the
transfer time are needed.
• Total bytes transferred:
4,096 bytes
• Transfer time:
(16 × 10 ns) + (16 × 300 ns) + (64 × 42 ns) + (16 × 4 ns) + (20 × 4 ns) = 7,792 ns
• Bandwidth:
[4096 bytes / 7,792 ns] × [1 GB / 1s] = 0.523 GB/s or 523 MB/s

Summary of Example 3

示例 3 中的计算得出的吞吐量为 523 MB/s，低于预期。主要原因是假设内存控制器没有对读取进行流水线处理，一次只能处理一次读取，从而导致每 300 ns 完成一次。最有可能的是，现实世界的系统设计将在内存控制器上对读取进行流水线处理，从而以更高的效率返回完成结果。这个例子强调了内存控制器对整体性能有很大的影响。

结论

PCI Express 规范定义了许多强大的功能，使链路能够以非常高的吞吐量和效率运行。但与此同时，还有一些因素会影响性能，例如数据包和流量开销以及其他可编程功能（例如 MPS）。虽然协议的某些方面无法更改，例如串行线路编码以及 DLLP 和有序集的必要性，但其他方面（例如设备选择、设备功能和设备交互）可能会对性能和效率产生影响。考虑到所有这些元素的系统和应用程序设计可以在正确的期望下实现非常高的性能。

标签：解释,TLP,字节,性能,bytes,PCIE,ns,数据包,读取
From： https://www.cnblogs.com/FireLife-Cheng/p/18551952