原文信息

来源: http://www.ssdfans.com/?p=3672

老男孩读PCIe之一:从PCIe速度说起

从今天开始,老男孩要开始讲PCIe了。对我来说,这是个很大的挑战:首先,我自己本身,对PCIe并没有做到胸有成竹,我的PCIe知识也只是停留在理论阶段,我并没有实际做过任何有关PCIe的东西;其次,我要把PCIe讲得深入浅出,让读者轻易接受,我觉得很难,根本原因就是我还没有做到胸有PCIe;最后,我的文章都会通过ssdfans公众号推出(还没有关注的同学,赶快关注),很多读者都是PCIe高手,班门弄斧,我深感压力。但尽管如此,我还是决定出发,我自己努力学习,尽我最大能力把我学到的东西分享给大家,也希望各位PCIe大拿们,帮忙斧正文章的错误,我希望不是我一个人,而是和各位大拿们一起,带领大家攀上PCIe的高峰。

我是从事SSD工作的,为什么要讲PCIe,原因很简单,现在很多SSD都开始使用PCIe接口。那为什么SSD要用PCIe接口?因为它快,比SATA快。它究竟有多快?我们今天首先从PCIe接口的速度开始我们的PCIe之旅。

PCIe发展到现在,从PCIe 1.0,PCIe 2.0,到现在的PCIe 3.0,速度一代比一代快。

图1.1

Link Width这一行,我们看到X1,X2,X4…,这是什么意思?这是指PCIe连接的通道数(Lane)。就像高速公路一样,有单根道,有2根道的,有4根道的,不过像8根道或者更多道的公路不常见,但PCIe是可以最多32条道的。

图1.2

两个设备之间的PCIe连接,叫做一个Link,如下图所示:

图1.3

A到B之间是个双向连接,车可以从A驶向B,同时车也可以从B驶向A,各行其道。两个PCIe设备之间,有专门的发送和接收通道,数据可以同时往两个方向传输,PCIe spec称这种工作模式为双单工模式(dual-simplex),可以理解为全双工模式。

SATA是什么工作模式呢?

图1.4

和PCIe一样,SATA也有独立的发送和接收通道,但与PCIe工作模式不一样:同一时间,只有一条道可以进行数据传输,也就是说,你在一条道上发送数据,另外一条道上不能接收数据,反之亦然。这种工作模式应该是半双工模式。PCIe犹如我们的手机,双方可以同时讲话,而SATA就是对讲机了,一个人在说话,另外一个人就只能听不能说。

回到前面PCIe带宽那张表,上面的带宽,比如PCIe3.0x1,带宽为2GB/s,是指双向带宽,即读写带宽。如果单指读或者写,该值应该减半,即1GB/s的读速度或者写速度。

我们来看看表里面的带宽是怎么算出来的。

PCIe是串行总线,PCIe1.0的线上比特传输速率为2.5Gb/s,物理层使用8/10编码,即8比特的数据,实际在物理线路上是需要传输10比特的,因此:

PCIe1.0 x 1的带宽=(2.5Gb/s x 2(双向通道))/ 10bit = 0.5GB/s

这是单条Lane的带宽,有几条Lane,那么整个带宽就0.5GB/s乘以Lane的数目。

PCIe2.0的线上比特传输速率在PCIe1.0的基础上翻了一倍,为5Gb/s,物理层同样使用8/10编码,所以:

PCIe2.0 x 1的带宽=(5Gb/s x 2(双向通道))/ 10bit = 1GB/s

同样,有多少条Lane,带宽就是1GB/s乘以Lane的数目。

PCIe3.0的线上比特传输速率没有在PCIe2.0的基础上翻倍,不是10Gb/s,而是8Gb/s,但物理层使用的是128/130编码进行数据传输,所以:

PCIe3.0 x 1的带宽=(8Gb/s x 2(双向通道))/ 8bit = 2GB/s

同样,有多少条Lane,带宽就是2GB/s乘以Lane的数目。

由于采用了128/130编码,128比特的数据,只额外增加了2bit的开销,有效数据传输比率增大,虽然线上比特传输率没有翻倍,但有效数据带宽还是在PCIe2.0的基础上做到翻倍。

这里值得一提的是,上面算出的数据带宽已经考虑到8/10或者128/130编码,因此,大家在算带宽的时候,没有必要再考虑线上编码的问题了。

和SATA单通道不同,PCIe连接可以通过增加通道数扩展带宽,弹性十足。通道数越多,速度越快。不过,通道数越多,成本越高,占用更多空间,还有就是更耗电。因此,使用多少通道,应该在性能和其他因素之间进行一个综合考虑。单考虑性能的话,PCIe最高带宽可达64GB/s,PCIe 3.0 x 32对应的带宽,很恐怖的一个数据。不过,现有的PCIe接口SSD,一般最多使用4通道,如PCIe3.0x4,双向带宽为8GB/s,读或者写带宽为4GB/s。

图1.5

几个GB/s的传输速度,读写小电影那是杠杠的。

在此,顺便来算算PCIe3.0x4理论上最大的4K IOPS。PCIe3.0x4理论最大读或者写的速度为4GB/s,不考虑协议开销,每秒可以传输4GB/4K个4K大小的IO,该值为1M,即理论上最大IOPS为1000K。因此,一个SSD,不管你底层用什么介质,flash还是3d xpoint,接口速度就这么块,最大IOPS是不可能超过这个值的。

PCIe是从PCI发展过来的,PCIe的”e”是express的简称,快的意思。PCIe怎么就能比PCI(或者PCI-X)快呢?PCIe在物理传输上,跟PCI有着本质的区别:PCI使用并口传输数据,而PCIe使用的是串口传输。我PCI并行总线,单个时钟周期可以传输32bit或者64bit,怎么就比不了你单个时钟周期传输1个bit数据的串行总线呢?

在实际时钟频率比较低的情况下,并口因为可以同时传输若干比特,速率确实比串口快。随着技术的发展,数据传输速率要求越来越快,要求时钟频率也越来越快,但是,并行总线时钟频率不是想快就能快的。

图1.6

在发送端,数据在某个时钟沿传出去(左边时钟第一个上升沿),在接收端,数据在下个时钟沿(右边时钟第二个上升沿)接收。因此,要在接收端能正确采集到数据,要求时钟的周期必须大于数据传输的时间(从发送端到接收端,flight time)。受限于数据传输时间(该时间还随着数据线长度的增加而增加),因此时钟频率不能做得太高。另外,时钟信号在线上传输的时候,也会存在相位偏移(clock skew ),影响接收端的数据采集;还有,并行传输,接收端必须等最慢的那个bit数据到了以后,才能锁住整个数据 (signal skew)。

PCIe使用串行总线进行数据传输就没有这些问题。它没有外部时钟信号,它的时钟信息通过8/10编码或者128/130编码嵌入在数据流,接收端可以从数据流里面恢复时钟信息,因此,它不受数据在线上传输时间的限制,你导线多长都没有问题,你数据传输频率多快也没有问题;没有外部时钟信号,自然就没有所谓的clock skew问题;由于是串行传输,只有一个bit传输,所以不存在signal skew问题。但是,如果使用多条lane传输数据(串行中又有并行,哈哈),这个问题又回来了,因为接收端同样要等最慢的那个lane上的数据到达才能处理整个数据。

老男孩读PCIe之二:PCIe拓扑结构

“计算机网络的拓扑结构是引用拓扑学中研究与大小、形状无关的点、线关系的方法,把网络中的计算机和通信设备抽象为一个点,把传输介质抽象为一条线,由点和线组成的几何图形就是计算机网络的拓扑结构。”

计算机网络的最主要的拓扑结构有总线型拓扑、环形拓扑、树形拓扑、星形拓扑、混合型拓扑以及网状拓扑。

PCI采用的是总线型拓扑结构,一条PCI总线上挂着若干个PCI终端设备或者PCI桥设备,大家共享该条PCI总线,哪个人想说话,必须获得总线使用权,然后才能发言。下面是一个基于PCI的传统计算机系统:

北桥下面的那根PCI总线,挂载了以太网设备、SCSI设备、南桥以及其他设备,他们共享那条总线,某个设备只有获得总线使用权才能进行数据传输。

而PCIe则采用树形拓扑结构,一个简单而又典型的PCIe拓扑结构如下:

整个PCIe拓扑结构是一个树形结构,Root Complex(RC)是树的根。RC为CPU代言,与整个计算机系统其它部分通讯,比如CPU通过它访问内存,通过它访问PCIe系统中的设备。

CPU像皇上一样高高在上,而RC好比皇上身边当红的太监,皇上想叫下面的人做点事情,通过太监传达;下面的人也是通过太监,向皇上反应一些情况。不过,这个太监不寻常,它是有根(root)的。

RC的内部实现很复杂,PCIe Spec也没有规定RC该做什么,还是不该做什么。我们也不需要知道那么多,只需清楚:它一般实现了一条内部PCIe总线(BUS 0),以及通过若干个PCIe bridge,扩展出一些PCIe Port,如下图所示:

PCIe Endpoint,就是PCIe终端设备,比如PCIe SSD,PCIe网卡等等,而Legacy Endpoint,接口是PCIe,但是内部的行为却和传统的PCI或者PCI-x一样(比如支持IO空间)。这些Endpoint可以直接连在RC上,也可以通过Switch连到PCIe总线上。Switch用于扩展链路,提供更多的端口用以连接Endpoint。拿USB打比方,我们计算机主板上提供的USB口有限,如果你要连接很多USB设备,比如无线网卡、无线鼠标、USB摄像头、USB打印机、U盘等等,这时候不够用,怎么办?我会去找马云,向它买个USB HUB,下面这个就不错:

Switch扩展了PCIe端口,靠近RC的那个端口,我们叫上游端口(upstream port),而分出来的其他端口,我们叫下游端口(downstream port)。一个Switch只有一个上游端口,可以扩展出若干个下游端口。下游端口可以直接连接Endpoint,也可以连接Switch,扩展出更多的PCIe端口。

对每个Switch来说,它下面的Endpoint或者Switch,都是归他管的:上游下来的数据,它需要甄别数据是传给它下面哪个设备,然后进行转发;下面设备向RC传数据,也要通过Switch代为转发的。因此,Switch的作用就是扩展PCIe端口,并为挂在它上面的设备(endpoint 或者switch)提供路由和转发服务。

每个Switch内部,也是有一根内部PCIe总线的,然后通过若干个Bridge,扩展出若干个下游端口,如下图所示:

最后小结一下:

PCIe采用的是树形拓扑结构,RC是树的根,或者主干,它为CPU代言,与PCIe系统其它部分通讯,一般为通讯的发起者;Switch是树枝,树枝上有叶子(Endpoint),也可节外生枝,Switch上连Switch,归根结底,是为了连接更多的Endpoint。Switch为它下面的Endpoint或Switch提供路由转发服务;Endpoint是树叶,诸如SSD,网卡,显卡等等,实现某些特定功能(function)。我们还看到有所谓的Bridge,用以将PCIe总线转换成PCI总线,或者反过来,不是我们要讲的重点,忽略之。PCIe与采用总线共享式通讯方式的PCI不同,PCIe采用点到点(Endpoint to Endpoint)通讯方式,每个设备独享通道带宽,速度和效率都比PCI好。

最后,以一个实际的计算机系统例子结束本文:

老男孩读PCIe之三:PCIe分层结构

绝大多数的总线或者接口,都是采用分层实现的。PCIe也不例外,它的层次结构如下:

PCIe定义了下三层(彩色部分):事务层(Transaction Layer),数据链路层(Data Link Layer)和物理层(Physical Layer),每层职能是不同的,且下层是为上层服务的。分层设计的一个好处:如果层次分得够好,接口版本升级时,硬件设计可能只需要改动某一层,其它层次可以保持不动。

PCIe传输的数据从上到下,都是以packet的形式传输的,每个packet都是有其固定的格式的。

事务层的主要职责是创建(发送)或者解析(接收)TLP (Transaction Layer packet),流量控制,QoS,事务排序等。

数据链路层的主要职责是创建(发送)或者解析(接收)DLLP(Data Link Layer packet),Ack/Nak协议(链路层检错和纠错),流控,电源管理等。

物理层的主要职责是处理所有的Packet数据物理传输,发送端数据分发到各个Lane传输(stripe),接收端把各个Lane上的数据汇总起来(De-stripe),每个Lane上加扰(Scramble,目的是让0和1分布均匀,去除信道的电磁干扰EMI)去扰(De-scramble),以及8/10或者128/130编码解码,等等。

今天只讲个大概,这三层以后还会专门细讲。这里先贴个这三层的细节图,自己看:

数据从上到下,一层一层打包,上层打包完的数据,作为下层的原始数据,再打包。就像人穿衣服一样,穿了内衣穿衬衫,穿了衬衫穿外套。

红色的是TLP的格式,Data是事务层上层给的数据,事务层给它头上加个Header,然后尾巴上再加个CRC校验,就构成了一个TLP;这个TLP下传到数据链路层,又被数据链路层头上加了个包序列号,尾巴再加个CRC校验,构成一个DLLP;然后DLLP下传到物理层,头上加个Start,尾巴加个End符号,把这些数据分派到各个Lane上,然后每个Lane上加扰码,经8/10或128/130编码,最后通过物理传输介质传输给接收方。

接收方物理层是最先接收到这些数据的,然后执行逆操作;在数据链路层,校验序列号和LCRC,如果没错,剥掉序列号和LCRC,往事务层走;如果校验出差,通知对方重传;在事务层,校验ECRC,有错,数据抛弃,没错,去掉ECRC,获得数据。整个过程犹如脱衣睡觉,外套脱了,衬衫脱了,内衣也脱了,光溜溜钻进被窝。

和PCI数据裸奔不同,PCIe的数据是穿有衣服的。PCIe数据以packet的形式传输,比起PCI冷冰冰的数据,PCIe的数据是鲜活有生命的。

每个Endpoint都需要实现这三层,每个Switch的每个Port也是需要实现这三层的:

上图中,如果RC要与EP1通信,中间要经历怎样的一个过程?

如果把前述的数据发送和接收过程,我们通俗的叫做穿衣脱衣,那么,RC与EP1数据传输过程中,则存在好几次这样穿衣脱衣过程:RC跟数据穿好衣服,发送给Switch的上游端口,A为了知道该笔数据发送给谁,就需要脱掉该数据的衣服,找到里面的地址信息。衣服脱光后,Switch发现它是往EP1的,又帮它换了身新衣服,发送给端口B。B又不嫌麻烦的脱掉它的衣服,换上新衣服,最后发送给EP1。

Switch的主要功能是转发数据,为什么还需要实现事务层?Switch必须实现这三层,因为数据的目的地信息是在TLP中的,如果不实现这一层,就无法知道目的地址,也就无法实现数据寻址路由。

老男孩读PCIe之四:TLP类型

Host与PCIe设备之间,或者PCIe设备与设备之间,数据传输都是以Packet形式进行的。事务层根据上层(软件层或者应用层)请求(Request)的类型、目的地址和其它相关属性,把这些请求打包,产生TLP,也就是Transaction Layer Packet。然后这些TLP往下,经历数据链路层,物理层,最终到达目标设备。

根据软件层的不同请求,事务层产生四种不同的TLP请求:

  1. Memory
  2. IO
  3. Configuration
  4. Message

前三种分别用于访问内存空间、IO空间、配置空间,这三种请求在PCI或者PCI-X时代就有了;最后的Message请求是PCIe新加的。在PCI或者PCI-X时代,像中断、错误以及电源管理相关信息,都是通过边带信号(sideband signal)进行传输的,但PCIe干掉了这些边带信号线,所有的通讯都是走带内信号,即通过Packet传输,因此,过去一些由边带信号线传输的数据,比如中断信息、错误信息等,现在就交由Message来传输了。

我们知道,一个设备的物理空间,可以通过内存映射(Memory map)的方式映射到Host的主存,有些空间还可以映射到Host的IO空间(如果Host存在IO空间的话)。但新的PCIe设备(区别于Legacy PCIe设备)只支持内存映射,之所以还存在访问IO空间的TLP,完全是为了照顾那些老设备。以后IO映射的方式会逐渐取消,为减轻学习压力,我们以后看到IO 相关的东西,大可或略之。

所有的配置空间(Configuration)的访问,都是Host发起的,确切的说是RC发起的,往往只在上电枚举和配置阶段会发起Configuration的访问,这样的TLP很重要,但不是常态; Message也是一样,只有有中断,或者有错误等情况下,才会有Message TLP,属非主流。PCIe线上主流传输的是Memory访问相关的TLP,Host与device,或者device与device之间,数据都是在彼此的Memory之间(抛掉IO)交互,因此,这种TLP是我们最常见的。

这四种请求,如果需要对方响应的,我们叫做Non-Posted的TLP;如果不期望对方给响应的,我们称之为Posted TLP。Post,有”邮政”的意思,我们只管把信投到邮箱,能不能到达对方,就取决于邮递员了。Posted TLP,就是不指望对方回复(信能不能收到都是个问题);Non-Posted TLP,就是要求对方务必回复。

哪些TLP是Posted,哪些又是non-posted的呢?像Configuration和IO访问,无论读写,都是Non-posted的,这样的请求必须得到设备的响应;Message TLP是Posted;Memory Read必须是Non-posted,我读你数据,你不返回数据(返回数据也是响应),那肯定不行的。所以,Memory Read必须得到响应。而Memory Write是Posted,我数据传给你,无需回复,这样Host或者Device可以不等对方回复,趁早把下一笔数据写下去,这样一定程度上提高了写的性能。有人会担心如果没有得到对方的响应,发送者就没有办法知道数据究竟有没有成功写入,就有丢数据的风险。虽然这个风险存在(概率很小),但数据链路层提供了ACK/NAK机制,一定程度上能保证TLP正确交互,因此能很大程度减小数据写失败的可能。

Request Type Non-Posted or Posted
Memory Read Non-Posted
Memory Write Posted
Memory Read Lock Non-Posted
IO Read Non-Posted
IO Write Non-Posted
Configuration Read (Type 0 and Type 1) Non-Posted
Configuration Write (Type 0 and Type 1) Non-Posted
Message Posted

所以,只要记住只有Memory Write和Message两种TLP是Posted就可以了。

Memory Read Lock是历史的遗留物,Native PCIe设备已经抛弃了这个,存在的意义完全是为了兼容Legacy PCIe设备。和IO一样,我们以后也忽略。能不看的就不看,PCIe东西本来就多,不要被这些过时没用的东西挡着我们学习的道路。

Configuration一栏,看到有Type 0和Type 1。我们在之前的拓扑结构中,看到除了Endpoint之外,还有Switch,他们都是PCIe设备,但配置种类不同,因此用Type 0和Type 1区分。

Request Type Non-Posted or Posted
Memory Read Non-Posted
Memory Write Posted
Configuration Read (Type 0 and Type 1) Non-Posted
Configuration Write (Type 0 and Type 1) Non-Posted
Message Posted

这样,Request TLP是不是清爽点?

对Non-Posted的Request,是一定需要对方响应的,对方是通过返回一个Completion TLP来作为响应的。对Read Request,响应者通过Completion TLP返回请求者所需的数据,这种Completion TLP包含有效数据;对Write Request(现在只有Configuration Write了)来说,响应者通过Completion TLP告诉请求者执行状态,这样的Completion TLP不含有效数据。

因此,PCIe里面所有的TLP = Request TLP + Completion TLP。

TLP Packet Type Abbreviated Name
Memory Read MRd
Memory Write MWr
Configuration Read(Type 0 and Type 1) CfgRd0, CfgRd
Configuration Write(Type 0 and Type 1) CfgWr0,CfgWr1
Message Request with Data MsgD
Message Request without Data Msg
Completion with Data CplD
Completion without Data Cpl

看个Memory Read的例子:

例子中,Switch B下面的某个Endpoint想读Host内存的数据,因此,它在事务层上生成一个Memory Read TLP,该MRd一路向上,翻过B,越过A,最终到达RC。RC收到该Request,就到内存中取该Endpoint所需的数据,RC通过Completion with Data TLP(CplD)返回数据,原路返回,直到Endpoint。

一个TLP,最多只能携带4KB有效数据,因此,上例子,如果Endpoint需要读16KB的数据,RC必须返回4个CplD给Endpoint。注意,Endpoint只需发1个MRd就可以了。

再看个Memory Write的例子:

该例子中,Host想往某个Endpoint写入数据,因此RC在其事务层生成一个Memory Write TLP(要写的数据在该TLP中),翻过A,越过B,直到目的地。前面说过Memory Write TLP是Posted的,因此,Endpoint收到数据后,是不需要返回Completion TLP(如果这个时候返回Completion TLP,反而是画蛇添足)。

同样的,由于一个TLP只能携带 4KB数据,因此Host想往Endpoint上写入16KB数据,RC必须发送4个MWr TLP。

老男孩读PCIe之五:TLP结构

无论Request TLP,还是作为回应的Completion TLP,它们模样都差不多:

TLP主要由三部分组成:Header,Data和CRC。TLP都是生于发送端的事务层(Transaction Layer),终于接收端的事务层。

每个TLP都有一个Header,跟动物一样,没有头就活不了,所以TLP可以没手没脚,但不能没有头。事务层根据上层请求内容,生成TLP Header。Header内容包括发送者的相关信息、目标地址(该TLP要发给谁)、TLP类型(前面提到的诸如Memory read,Memory Write之类的)、数据长度(如果有的话)等等。

Data Payload域,用以放有效载荷数据。该域不是必须的,因为并不是每个TLP都必须携带数据的,比如Memory Read TLP,它只是一个请求,数据是由目标设备通过Completion TLP返回的。后面我们会整理哪些TLP需要携带数据,哪些TLP不带数据的。前面也提到,一个TLP最大载重是4KB,数据长度大于4KB的话,就需要分几个TLP传输。

ECRC(End to End CRC)域,它对之前的Header和Data(如果有的话)生成一个CRC,在接收端然后根据收到的TLP,重新生成Header和Data(如果有的话)的CRC,和收到的CRC比较,一样则说明数据在传输过程中没有出错,否则就有错。它也是可选的,可以设置不加CRC。

Data域和CRC域没有什么好说的,有花头的是Header域,我们要深入其中看看。

一个Header大小可以是3DW,也可以是4DW。以4DW的Header为例,TLP的Header长下面样子:

红色区域为所有TLP Header公共部分,所有Header都有这些;其它则是跟具体的TLP相关。

稍微解释一下:

Fmt:Format, 表明该TLP是否带有数据,Header是3DW还是4DW;

Type:TLP类型,上一节提到的,Memory Read, Memory Write, Configuration Read, Configuration Write, Message和Completion,等等;

R: Reserved,为0;

TC: Traffic

Class,TLP也分三六九等,优先级高的先得到服务。这里是3比特,说明可以分为8个等级,0-7,TC默认是0,数字越大,优先级越高;

Attr: Attrbiute, 属性,前后共三个bit,先不说;

TH: TLP Processing Hints,先不说;

TD: TLP Digest,之前说ECRC可选,如果这个这个bit置起来,说明该TLP包含ECRC,接收端应该做CRC校验;

EP: Poisoned data, 有毒的数据,远离,哈哈;

AT: Address Type,地址种类,先不说;

Length: Payload数据长度,10个bit,最大1024,单位DW,所以TLP最大数据长度是4KB; 该长度总是DW的整数倍,如果TLP的数据不是DW的整数倍(不是4Byte的整数倍),则需要用到下面两个域:Last DW BE 和 1st DW BE。

我觉得,到目前为止,对于Header,我们只需知道它大概有什么内容,没有必要记住每个域是什么。

这里重点讲讲Fmt和Type,看看不同的TLP(精简版的,Native PCIe设备所有)其Fmt和Type应该怎样编码:

TLP Fmt Type Comment
Memory Read Request 000=3DW,no data 001=4DW,no data 0 0000 3DW或者4DW是指Header大小,Memory Read不带数据
Memory Write Request 010=3DW,with data 011=4DW,with data 0 0000 Memory Write必须带数据
Configuration Type 0 Read Request 000=3DW,no data 0 0100 读Endpoint的Configuration,不带数据,Header总是3DW
Configuration Type 0 Write Request 010=3DW,with data 0 0100 写Endpoint的Configuration,带数据,Header总是3DW
Configuration Type 1 Read Request 000=3DW,no data 0 0101 读Switch的Configuration,不带数据,Header总是3DW
Configuration Type 1 Write Request 010=3DW,with data 0 0101 写Switch的Configuration,带数据,Header总是3DW
Message Request 001 = 4DW, no data 1 0rrr Message的Header总是4DW
Message Request with Data 011 = 4DW, with data 1 0rrr Message的Header总是4DW
Completion 000=3DW,no data 0 1010 Completion的Header总是3DW
Completion with Data 010=3DW,with data 0 1010 Completion的Header总是3DW

从上可以看出,Configuration和Completion 的TLP(以C打头的TLP),其Header大小总是3字节;Message TLP的Header总是4字节;而Memory相关的TLP取决于地址空间的大小,地址空间小于4GB的,Header大小为3DW,大于4GB的,Header大小则为4DW。

上面介绍了几个TLP Header的通用部分,下面分别介绍具体TLP的Header。

Memory TLP

有两个重要的东西在前面没有提到,那就是TLP的源和目标,即,该TLP是哪里产生的,它要到哪里去,它们都包含在Header里面的。因为不同的TLP类型,寻址方式不同,因此要具体TLP具体来看这两个东西。

对一个PCIe设备来说,它开放给Host访问的设备空间首先会映射到Host的内存空间,Host如果想访问设备的某个空间,TLP Header当中的地址应该设置为该访问空间在Host内存的映射地址。如果Host内存空间小于4GB,则Memory读写TLP的Header大小为3DW,大于4GB,则为4DW。那是因为,对4GB内存空间,32bit的地址用1DW就可以表示,该地址位于Byte8-11;而4GB以上的内存空间,需要2DW表示地址,该地址位于Byte8-15。

该TLP经过Switch的时候,Switch会根据地址信息,把该TLP转发到目标设备。之所以能唯一的找到目标设备,那是因为不同的Endpoint设备空间会映射到Host内存空间的不同位置。

关于TLP路由,后面还会专门讲。

Memory TLP的目标是通过内存地址告知的,而源是通过”Requester ID”告知。每个设备在PCIe系统中都有唯一的ID,该ID由总线(Bus)、设备(Device)、功能(Function)三者唯一确定。这个后面也会专门讲,这里只需知道一个PCIe组成有唯一的ID,不管是RC,Switch还是Endpoint。

Configuration TLP

Endpoint和Switch的配置(Configuration)格式不一样,分别为Type 0和 Type 1来表示。配置可以认为是一个Endpoint或者Switch的一个标准空间,这段空间在初始化时也需要映射到Host的内存空间。与设备的其他空间不同,该空间是标准化的,即不管哪个厂家生产的设备,都需要有这么段空间,而且哪个地方放什么东西,都是协议规定好的,Host按协议访问这部分空间。由于每个设备ID唯一,而其Configuration又是固定好的,因此,Host访问PCIe设备的配置空间,只需指定目标设备的ID就可以了,不需要内存地址。

下面是访问Endpoint的配置空间的TLP Header (Type 0):

Bus Number + Device + Function就唯一决定了目标设备; Ext Reg Number + Register Number相当于配置空间的偏移。找到了设备,然后指定了配置空间的偏移,就能找到具体想访问的配置空间的某个位置。

Message TLP

Message TLP用以传输中断、错误、电源管理等信息,取代PCI时代的边带信号传输。Message TLP的Header 大小总是4DW。

Message Code来指定该Message的类型,具体如下:

不同的Message Code,最后两个DW的意义也不同,这里不展开。

Completion TLP

有non-posted request TLP,才有Completion TLP。有因才有果。前面看到,Requester 的TLP当中都有Requester ID和Tag,来告诉接收者发起者是谁。那么响应者的目标地址就很简单,照抄发起者的源地址就可以了。因此,Completion TLP的Header如下:

Completion TLP,一方面,可以返回请求者的数据,比如作为Memory或者Configuration Read的响应;另一方面,还可以返回该事务(Transaction)的状态,因此,在Completion TLP的Header里面有一个Completion Status,用以返回事务状态:

老男孩读PCIe之六:配置和地址空间

每个PCIe设备,有这么一段空间,Host软件可以读取它获得该设备的一些信息,也可以通过它来配置该设备,这段空间就叫做PCIe的配置空间。不同于每个设备的其它空间,PCIe设备的配置空间是协议规定好的,哪个地方放什么内容,都是有定义的。PCI或者PCI-X时代就有配置空间的概念,那时的配置空间如下:

整个配置空间就是一系列寄存器的集合,其中Type 0是Endpoint的配置,Type 1是Bridge(PCIe时代就是Switch)的配置,都由两部分组成:64 Bytes的Header+192Bytes的Capability结构,后者是设备告诉Host它有多牛逼,都会什么绝活。

进入PCIe时代,PCIe能耐更大,192 Bytes不足以罗列它的绝活。为了保持后向兼容,又要不把绝活落下,怎么办?很简单,我扩展后者的空间,整个配置空间由256 Bytes扩展成4KB,前面256 Bytes保持不变:

PCIe有什么能耐(Capability)我们不看,我们先挑软柿子捏,先看看只占64 Bytes的Configuration Header。

像Device ID,Vendor ID,Class Code和Revision ID,是只读寄存器,PCIe设备通过这些寄存器告诉Host软件,这是哪个厂家的设备、设备ID是多少、以及是什么类型的(网卡?显卡?桥?)设备。

其它的我们暂时不看,我们看看重要的BAR(Base Address Register)。

对Endpoint Configuration(Type 0),提供了最多6个BAR,而对Switch(Type 1)来说,只有2个。BAR是干什么用的?

每个PCIe设备,都有自己的内部空间,这部分空间如果开放给Host(软件或者CPU)访问,那么Host怎样才能往这部分空间写入数据,或者读数据呢?

我们知道,CPU只能直接访问Host内存(Memory)空间(或者IO空间,我们不考虑),不对PCIe等外设直接操作。怎么办?记得皇帝身边那个有根的太监吗?Root Complex,RC。RC可以为CPU分忧。

解决办法是:CPU如果想访问某个设备的空间,由于它不能(或者不屑)亲自跟那些PCIe外设打交道,因此叫太监RC去办。比如,如果CPU想读PCIe外设的数据,先叫RC通过TLP把数据从PCIe外设读到Host内存,然后CPU从Host内存读数据;如果CPU要往外设写数据,则先把数据在内存中准备好,然后叫RC通过TLP写入到PCIe设备。完美!

上图例子中,最左边虚线的表示CPU要读Endpoint A的数据,RC则通过TLP(经历Switch)数据交互获得数据,并把它写入到系统内存中,然后CPU从内存中读取数据(紫色箭头所示),从而CPU间接完成对PCIe设备数据的读取。

具体实现就是上电的时候,系统把PCIe设备开放的空间(系统软件可见)映射到内存空间,CPU要访问该PCIe设备空间,只需访问对应的内存空间。RC检查该内存地址,如果发现该内存空间地址是某个PCIe设备空间的映射,就会触发其产生TLP,去访问对应的PCIe设备,读取或者写入PCIe设备。

一个PCIe设备,可能有若干个内部空间(属性可能不一样,比如有些可预读,有些不可预读)需要映射到内存空间,设备出厂时,这些空间的大小和属性都写在Configuration BAR寄存器里面,然后上电后,系统软件读取这些BAR,分别为其分配对应的系统内存空间,并把相应的内存基地址写回到BAR。(BAR的地址其实是PCI总线域的地址,CPU访问的是存储器域的地址,CPU访问PCIe设备时,需要把总线域地址转换成存储器域的地址。)

如上图例子,一个Native PCIe Endpoint,只支持Memory Map,它有两个不同属性的内部空间要开放给系统软件,因此,它可以分别映射到系统内存空间的两个地方;还有一个Legacy Endpoint,它既支持Memory Map,还支持IO Map,它也有两个不同属性的内部空间,分别映射到系统内存空间和IO空间。

来个例子,看一下一个PCIe设备,系统软件是如何为其分配映射空间的。

上电时,系统软件首先会读取PCIe设备的BAR0,得到数据:

然后系统软件往该BAR0写入全1,得到:

BAR寄存器有些bit是只读的,是PCIe设备在出厂前就固定好的bit,写全1进去,如果值保持不变,就说明这些bit是厂家固化好的,这些固化好的bit提供了这块内部空间的一些信息:

怎么解读?低12没变,表明该设备空间大小是4KB(2的12次方),然后低4位表明了该存储空间的一些属性(IO映射还是内存映射,32bit地址还是64bit地址,能否预取?做过单片机的人可能知道,有些寄存器只要一读,数据就会清掉,因此,对这样的空间,是不能预读的,因为预读会改变原来的值),这些都是PCIe设备在出厂前都设置好的,提供给系统软件的信息。

然后系统软件根据这些信息,在系统内存空间找到这样一块地方来映射这4KB的空间,把分配的基地址写入到BAR0:

从而最终完成了该PCIe空间的映射。一个PCIe设备可能有若干个内部空间需要开放出来,系统软件依次读取BAR1,BAR2。。。,直到BAR5,完成所有内部空间的映射。

上面主要讲了Endpoint的BAR,Switch也有两个BAR,今天不打算讲,下节讲TLP路由,再回过头来讲。继续说配置空间。

前面说每个PCIe设备都有一个配置空间,其实这样说是不准确的,而是每个PCIe设备至少有一个配置空间。一个PCIe设备,它可能具有多个功能(function),比如既能当硬盘,还能当网卡。每个功能对应一个配置空间。

在一个PCIe拓扑结构里,一条总线下面可以挂几个设备,而每个设备可以具有几个功能,如下所示:

因此,在整个PCIe系统中,只要知道了Bus+Device+Function,就能找到对应的Function。寻址基本单元是功能(function),它的ID就由Bus+Device+Function组成 (BDF)。一个PCIe系统,可以最多有256条Bus,每条Bus上可以挂最多32个Device,而每个Device最多又能实现8个Function,而每个Function对应着4KB的配置空间。上电的时候,这些配置空间都是需要映射到Host的内存空间,因此,需要占用内存空间是:256328*4KB =256MB。在这个动辄4GB、8GB内存的时代,256MB算不了什么。

系统软件是如何读取Configuration空间呢?不能通过BAR中的地址,为什么?别忘了BAR是在Configuration中的,你首先要读取Configuration,才能得到BAR。前面不是系统为所有可能的Configuration预留了256MB内存空间吗?系统软件想访问哪个Configuration,只需指定相应Function对应的内存空间地址,RC发现这个地址是Configuration映射空间,就会产生相应的Configuration Read TLP去获得相应Function的Configuration。

再回想一下前面介绍的Configuration Read TLP的Header格式:

Bus Number + Device + Function就唯一决定了目标设备; Ext Reg Number + Register Number相当于配置空间的偏移。找到了设备,然后指定了配置空间的偏移,就能找到具体想访问的配置空间的某个位置。

结束前,强调一下,只有RC才能发起Configuration的访问请求,其他设备是不允许对别的设备进行Configuration读写的。

老男孩读PCIe之七:TLP的路由

一个TLP,是怎样经历千山万水,最后顺利抵达目的地呢?

今天就以上图的简单拓扑结构为例,讨论一个TLP是怎样从发起者到达接收者,即TLP路由问题。

PCIe共有三种路由方式:基于地址(Address)路由,基于设备ID(Bus number + Device number + Function Number)路由,还有就是隐式(Implicit)路由。

不同类型的TLP,其寻址方式也不同,下表总结了每种TLP对应的路由方式:

TLP类型 路由方式
Memory Read/Write TLP 地址路由
Configuration Read/Write TLP ID路由
Completion TLP ID路由
Message TLP 地址路由或者ID路由或者隐式路由

下面分别讲讲这几种路由方式。

地址路由

前面提到,Switch负责路由和TLP的转发,而路由信息是存储在Switch的Configuration空间的,因此,很有必要先理解Switch的Configuration。

BAR0和BAR1没有什么好说,跟前一节讲的Endpoint的BAR意义一样,存放Switch内部空间在Host内存空间映射基址。

Switch有一个上游端口(靠近RC)和若干个下游端口,每个端口其实是一个Bridge,都是有一个Configuration的,每个Configuration描述了其下面连接设备空间映射的范围,分别由Memory Base和Memory Limit来表示。对上游端口,其Configuration描述的地址范围是它下游所有设备的映射空间范围,而对每个下游端口的Configuration,描述了连接它端口设备的映射空间范围。大家看看下面这张图,理解一下我刚才说的。(Range由Memory Base和Memory Limit限定)

前面我们看到,Memory Read 或者Memory Write TLP的Header里面都有一个地址信息,该地址是PCIe设备内部空间在内存中的映射地址。

当一个Endpoint收到一个Memory Read或者Memory Write TLP,它会把TLP Header中的地址跟它Configuration当中的所有BAR寄存器比较,如果TLP Header中的地址落在这些BAR的地址空间,那么它就认为该TLP是发给它的,于是接收该TLP,否则就忽略。

当一个Switch上游端口收到一个Memory Read或者Memory Write TLP,它首先把TLP Header中的地址跟它自己Configuration当中的所有BAR寄存器比较,如果TLP Header当中的地址落在这些BAR的地址空间,那么它就认为该TLP是发给它的,于是接收该TLP(这个过程与Endpoint的处理方式一样);如果不是,然后看这个地址是否落在其下游设备的地址范围内(是否在memory base 和memory limit之间),如果是,说明该TLP是发给它下游设备的,因此它要完成路由转发;如果地址不落在下游设备的地方范围内,说明该TLP不是发给它下面设备的,因此不接受该TLP。

刚才的描述是针对TLP从Upstream流到Downstream的路由。如果是TLP从下游往上走呢?

它首先把TLP Header中的地址跟它自己Configuration当中的所有BAR寄存器比较,如果TLP Header当中的地址落在这些BAR的地址空间,那么它就认为该TLP是发给它的,于是接收该TLP(跟前面描述一样);如果不是,然后看这个地址是否落在其下游设备的地址范围内(是否在memory base 和memory limit之间),如果是,这个时候不是接受,而是拒绝;相反,如果地址不落在下游设备的地方范围内,Switch则把该TLP传上去。

ID路由

在一个PCIe拓扑结构中,由ID = Bus number+Device number+Function Number(BDF)能唯一找到某个设备的某个功能。这种按设备ID号来寻址的方式叫做ID路由。Configuration TLP和Completion TLP(以C打头的TLP)按ID路由,Message在某些情况下也是ID路由。

使用ID路由的TLP,其TLP Header中含有BDF信息:

当一个Endpoint收到一个这样的TLP,它用自己的ID和收到TLP Header中的BDF比较,如果是给自己的,就收下TLP,否则就拒绝。

如果是一个Switch收到这样的一个TLP,怎么处理?我们再回头去看看Switch的Configuration Header。

看三个寄存器:Subordinate Bus Number,Secondary Bus Number和Primary Bus Number,看下图就知道这几个寄存器是什么意思:

对一个Switch来说,每个Port靠近RC(上游)的那根Bus叫做Primary Bus,其Number写在其Configuration Header中的Primary Bus Number寄存器;每个Port下面的那根Bus叫做Secondary Bus,其Number写在其Configuration Header中的Secondary Bus Number寄存器;对上游端口,Subordinate Bus是其下游所有端口连接的Bus 编号最大的那个Bus,Subordinate Bus Number写在每个Port的Configuration Header中的Subordinate Bus Number寄存器。

当一个Switch收到一个基于ID寻址的TLP,首先检查TLP中的BDF是否与自己的ID匹配,如匹配,说明该TLP是给自己的,收下;否则,则检查该TLP中的Bus Number是否落在Secondary Bus Number和Subordinate Bus Number之间,如果是,说明该TLP是发给其下游设备的,然后转发到对应的下游端口;如果其他情况,则拒绝这些TLP。

隐式路由

只有Message TLP才支持隐式路由。在PCIe总线中,有些Message是与RC通信的,RC是该TLP的发送者或者接收者,因此没有必要明明白白的指定地址或者ID,而是采用”你懂的”的方式进行路由,这种路由方式为隐式路由。Message TLP还支持地址路由和ID路由,但以隐式路由为主。

Message TLP的Header总是4DW,如下图所示:

Type字段,低三位,用rrr表示的,指明该Message的路由方式,具体如下:

当一个Endpoint收到一个Message TLP,检查TLP Header,如果是RC的广播Message(011b)或者该Message终结于它(100b),它就接受该Message。

当一个Switch收到一个Message TLP,检查TLP Header,如果是RC的广播Message(011b),则往它每个下游端口复制该Message然后转发;如果该Message终结于它(100b),则接受该TLP;如果下游端口收到发给RC的message,往上游端口转发便是。

上面说的是Message使用隐式路由的情况。如果是地址路由或者ID路由,Message TLP的路由跟别的TLP一样,不赘述。

【转载】老男孩读PCIe的更多相关文章

  1. [转载]我读过最好的Epoll模型讲解

    转载来自:http://blog.csdn.net/mango_song/article/details/42643971 首先我们来定义流的概念,一个流可以是文件,socket,pipe等等可以进行 ...

  2. 【转载】读懂IL代码就这么简单(三)完结篇

    一 前言 写了两篇关于IL指令相关的文章,分别把值类型与引用类型在 堆与栈上的操作区别详细的写了一遍这第三篇也是最后一篇,之所以到第三篇就结束了,是因为以我现在的层次,能理解到的都写完了,而且个人认为 ...

  3. 【转载】读懂IL代码就这么简单(二)

    一 前言 IL系列 第一篇写完后 得到高人指点,及时更正了文章中的错误,也使得我写这篇文章时更加谨慎,自己在了解相关知识点时,也更为细致.个人觉得既然做为文章写出来,就一定要保证比较高的质量,和正确率 ...

  4. 【转载】读懂IL代码就这么简单 (一)

    一前言 感谢 @冰麟轻武 指出文章的错误之处,现已更正 对于IL代码没了解之前总感觉很神奇,初一看完全不知所云,只听高手们说,了解IL代码你能更加清楚的知道你的代码是如何运行相互调用的,此言一出不明觉 ...

  5. FPGA实战操作(2) -- PCIe总线(协议简述)

    目录 1. PCIe基础知识 2. 事务层协议 2.1 数据包结构 2.2 帧头含义详述 3. 报文举例 3.1 寄存器读报文 3.2 完成报文 4. 机制简述 4.1 Non-Posted和Post ...

  6. PCIe固态存储和HDD常见的硬盘性能对比测试

    2周测试后,导致以下结果 MySQL-OLTP测试结果:(50表.每个表1000广域网数据,1000个线程) TPS:MySQL在PCIe固态存储上执行是在HDD上执行的5.63倍 writes:My ...

  7. PCIE 调试过程记录

    遇到的问题 PCIE link不稳定 配置空间读写正常,Memory mapping空间读写异常 缘由 之前对PCIE的认识一直停留在概念的阶段,只知道是一个高速通讯协议,主要用于板内.板间的高速BU ...

  8. 转载:使用Xilinx IP核进行PCIE开发学习笔记(一)简介篇

    https://zhuanlan.zhihu.com/p/32786076 最近接触到一个项目,需要使用PCIE协议,项目要求完成一个pcie板卡,最终可以通过电脑进行通信,完成电脑发送的指令.这当中 ...

  9. 转载 大话pcie

    原文https://blog.csdn.net/abcamus/article/details/76167747 一.PCIe DMA机制 PCIe控制器也提供DMA(Direct Memory ac ...

  10. Unity3D — —存读档【转载】

    详细可参考此篇博文: Unity序列化之XML,JSON--------合成与解析 简单例子(SiKi学院教程): using System.Collections; using System.Col ...

随机推荐

  1. Linux(五)用户管理与文件权限

    1 常用的基本命令 Shell可以看作一个命令解释器,为我们提供一个交互式的文本控制台界面,可以通过终端控制台来输入命令,由shell进行解释并最终交给linux内核运行.可以看作用户和硬件的桥梁. ...

  2. 【SpringCloud】(二)Eureka注册中心和Feign远程调用

    1 SpringCloud 核心 SpringCloud基于HTTP协议,这是和Dubbo最本质的区别,Dubbo的核心是RPC(远程方法调用) Eureka:注册中心 Ribbon:客户端负载均衡 ...

  3. CSS页面布局方式

    css页面布局方式 1.标准流 <!DOCTYPE html> <html lang="en"> <head> <meta charset ...

  4. Git代码提交规范

    1. 引言 思想,因人而异,难以重复 写代码时,每个人的习惯是不一样的,所以,引入了代码规范,为了省力,引入了自动格式化代码工具,前端工程中比较典型的自动格式化代码工具如:Prettier · Opi ...

  5. C# 闭包类对弱引用的坑

    闭包.弱引用的简单概念,大佬们描述的很多,有不了解的可以看看: 理解C#中的闭包 - 黑洞视界 - 博客园 (cnblogs.com) C#弱引用(WeakReference) - 简书 (jians ...

  6. 2021-02-23:给定一个正数n,求n的裂开方法数。规定:后面的数不能比前面的数小 。比如4的裂开方法有: 1+1+1+1、1+1+2、1+3、2+2、4,5种,所以返回5。

    2021-02-23:给定一个正数n,求n的裂开方法数.规定:后面的数不能比前面的数小 .比如4的裂开方法有: 1+1+1+1.1+1+2.1+3.2+2.4,5种,所以返回5. 福哥答案2021-0 ...

  7. Vue入门浅析

    title: vue入门浅析 author: Sun-Wind date: May 14,2022 写这篇博文的目的在于为初学vue的同学对vue有一些更进一步的了解 读这篇博文前,您应该至少安装了v ...

  8. Go开源世界主流成熟ORM框架gorm实践分享

    @ 目录 概述 定义 核心功能 声明模型与约定 gorm.Model 字段级权限 时间惯例 嵌入结构 字段标签 使用 安装 数据库链接 连接池 CRUD 接口 创建 查询 高级查询 修改 删除 原始S ...

  9. vue横向导航条滚动到顶部固定同时瞄点对应内容(copy即用)

    这里监听window 的scroll实现一个页面滚动,导航菜单定位,内容联动的一个简单组件,结合一些案例,按需进行了整合,在此记录一下 效果图如下 具体实现如下 一.先创建一个NavigateTool ...

  10. cv学习总结(10.31-11.6)

    这一周主要焦点在于实现反向传播和全连接两层神经网络的具体代码以及书写博客记录课程学习的心得体会,目前完成了反向传播的具体代码以及相应博客的书写,完成了assignment1中figure的SVM版提取 ...