PCIe扫盲——PCIe总线性能评估（有效数据速率估算）

发表于 2019/3/6 16:29:52 阅读（13844）

连载目录篇：http://blog.chinaaet.com/justlxy/p/5100061871

前面的文章提到过PCIe总线（Gen1&Gen2）采用了8b/10b编码，因此其有效数据速率为物理线路上的速率的80%。即Gen1的有效速率为2.0Gbps=2.5Gbps*80%，而Gen2的有效速率为4Gbps=5Gbps*80%。

如果以数据包的Data Payload为真实有效数据，来计算得话，实际应用中的有效速率会更低。因为，数据包的包头、包尾（LCRC和ECRC等）、数据链路层添加的包编号等等；用于Ack/Nak和Flow Control等的DLLP；用于链路训练和Skip的Order Sets等都会影响真实的有效速率。

这一篇文章，将来详细地聊一聊，如何粗略地估算一个PCIe总线的真实有效速率。

注：由于设备反应时间、数据处理时间、不确定的插入等待时间等等原因，无法从理论上，准确无误地计算出一个PCIe总线的真实有效速率。

注：关于8b/10b编码，前面的文章中已经详细地介绍过了，这里就不再重复了。

对于任意的一个TLP来说，除了Data Payload，还有物理层添加的包头（1 Byte）、数据链路层添加的包编号（2 Bytes）、事务层添加的包头（12 or 16 Bytes）、事务层添加的ECRC（4Bytes，可选的）、数据链路层添加的LCRC（4Bytes）和物理层添加的包尾（1 Byte）。具体如下图所示：

如果以3DW的事务层包头来计算，且不添加ECRC，则该TLP至少含有20 Bytes的额外数据（除了Data Payload之外的）。我们姑且称之为TLP Overhead。

注：32bits地址的TLP是3DW包头，而64bits地址的TLP是4DW包头，具体请参考前面的文章。

如果只从TLP Overhead考虑的话，显然每个TLP包含的Data Payload的量越大，真实有效速率越高。然而，实际应用中却并非如此，因为链路上的其他因素也在影响实际的真实有效速率。PCIe Spec规定，任何TLP都不允许被Order Sets或者DLLP打断。也就是说，Skip Order Sets和FC DLLP、Ack/Nak DLLP都只能在两个TLP之间发送。换一句话说，Data Payload越大，TLP的也就越长，为了保证正常通信，两个TLP之间的时间间隔也就越大。这就是为什么Data Payload越大，但真实有效速率却未必会越高的原因。

除了TLP Overhead之外，前面文章介绍的Ack/Nak机制和Flow Control机制都是需要花费时间的。这里我们分别称其所消耗的时间为Link Protocol Overhead和Flow Control Protocol Overhead。具体这里就不详细，介绍了，请参考之前的文章。

注：显然，更低频率的Flow Control Update，会一定程度上提高真实有效速率，但这需要更大的Rx Buffer，从而带来更高的硬件成本开销。一般情况下，PCIe设备都应当遵循Spec所定义的FC Update周期计算方式，具体可可参考前面的文章：http://blog.chinaaet.com/justlxy/p/5100053465

-----------------------------------------------------------------------------------------------------

除了前面介绍的TLP Overhead、Link Protocol Overhead和Flow Control Protocol Overhead之外，另一个影响真实有效速率的关键因素便是Max_Payload_Size，以及Read_Completion_Boundary（RCB）。

虽然PCIe Spec规定，TLP的Data Payload最高可达4096 Bytes，但同时也规定了PCIe体系结构中，所有的设备，都必须使用相同的Max_Payload_Size值。换一句话说，整个总线的Max_Payload_Size值必须使用总线体系结构中所有设备所支持的最小的Max_Payload_Size值。具体如下图所示：

注：每个设备中的Function的所支持的最大的Max_Payload_Size值应当是相同的。

注：每个设备所支持的Max_Payload_Size最大值信息，存在于Device Capability Register中。

Max_Payload_Size值的设置是在PCIe总线枚举和配置的过程中完成的，软件确定了Max_Payload_Size的值后，会将该值写入到每个设备的Device Control Register中。

在不考虑Ack/Nak机制和Flow Control机制等因素的情况下，真实有效速率可以这样计算：

则有：

以128 Bytes的Max_Payload_Size为例，不考虑Ack/Nak机制和Flow Control机制等因素的情况下，理论极限真实有效速率如下：

其中，1720Mb/s = 86% * 2000Mbps。（x1 Gen1）

注：读操作还需要考虑RCB等因素，后面会详细介绍。表格里的数据是在假设RCB为64 Bytes的情况下得到的，因此其计算方法为：64/(64+20)=76%。

-----------------------------------------------------------------------------------------------------

针对读操作，还有一个Maximun Read Request Size（即最大读请求）的概念，在PCIe总线配置的过程中，该值会被写入到每个设备的Device Control Register中。PCIe Spec规定，Maximun Read Request Size的值可以超过Max_Payload_Size，例如，可以向Max_Payload_Size为128 Bytes的设备，一次请求读512 Bytes的数据。此时，一次请求会对应多个返回的Completion。

然而，Maximun Read Request Size的值也并非越大越好，该值设置的过大，会导致某个PCIe设备独占整个系统带宽的时间过长。但是如果Maximun Read Request Size设置的过小，则需要发起多个读请求操作。

Read Completion Boundary（RCB）确定了针对读请求返回的每个Completion的Data Payload的最大值，一般为64 Bytes或者128 Bytes（由系统或者软件设置）。当然，Completion的Data Payload值，是可以小于RCB的。以64 Bytes 的RCB和一次读256 Bytes的请求为例，可能的情况如下图所示：