Felix

技术源于积累,成功始于执着! 个人邮箱:justlxy@mail.dhu.edu.cn QQ:1576109464

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

1
阅读(1405) 评论(0)

连载目录篇: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)。具体如下图所示:

image.png

如果以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值。具体如下图所示:

image.png

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

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

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

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

image.png

则有:

image.pngimage.png

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

image.png

其中,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的请求为例,可能的情况如下图所示:

image.png

注:目前,大部分的Root都固定地使用64 Bytes的RCB,尽管Max_Payload_Size的值可能是128或者更大。

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

最后,以几个例子,来回顾一下上面的内容。

image.png

image.png

image.png

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

参考文献:

1、Xilinx. Understanding Performance of PCI Express Systems