PCIE详解
老男孩读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,速度一代比一代快。
Link Width这一行,我们看到X1,X2,X4…,这是什么意思?这是指PCIe连接的通道数(Lane)。就像高速一样,有单根道,有2根道的,有4根道的,不过像8根道或者更多道的公路不常见,但PCIe是可以最多32条道的。
两个设备之间的PCIe连接,叫做一个Link,如下图所示:
从A到B,之间是个双向连接,车可以从A驶向B,同时,车也可以从B驶向A,各行其道。两个PCIe设备之间,有专门的发送和接收通道,数据可以同时往两个方向传输,PCIe spec称这种工作模式为双单工模式(dual-simplex),可以理解为全双工模式。
SATA是什么工作模式呢?
和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。
几个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数据的串行总线呢?
在实际时钟频率比较低的情况下,并口因为可以同时传输若干比特,速率确实比串口快。随着技术的发展,数据传输速率要求越来越快,要求时钟频率也越来越快,但是,并行总线时钟频率不是想快就能快的。
在发送端,数据在某个时钟沿传出去(左边时钟第一个上升沿),在接收端,数据在下个时钟沿(右边时钟第二个上升沿)接收。因此,要在接收端能正确采集到数据,要求时钟的周期必须大于数据传输的时间(从发送端到接收端,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请求:
- Memory
- IO
- Configuration
- 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的内存空间,因此,需要占用内存空间是:256*32*8*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详解的更多相关文章
- 2013款Mac Pro“神秘”主机详解
2013款Mac Pro"神秘"主机详解 自2013年12月下旬新款Mac Pro在美国发布以来,经过一个月的等待终于在国内已到货,笔者亲自测试了这个号称"神秘" ...
- 莱特币ltc在linux下的多种挖矿方案详解
莱特币ltc在linux下的多种挖矿方案详解 4.0.1 Nvidia显卡Linux驱动Nvidia全部驱动:http://www.nvidia.cn/Download/index.aspx?lang ...
- ipconfig/all详解
Ipconfig/all(win+R-->cmd-->ipconfig/all)最常用的就是显示自己主机的ip了,可以让我们了解自己的计算机是否成功的租用到一个IP地址.但是ipconfi ...
- route命令详解与使用实例 ,同时访问内外网
route命令详解与使用实例 2011-10-18 12:19:41| 分类: 其他 | 标签:route |字号 订阅 1. 使用背景 需要接入两个网络,一个是部署环境所在内 ...
- 计算机网络基础之IP地址详解
计算机网络基础之IP地址详解 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.IP地址概述 1>.什么是IP地址 我们为什么要使用逻辑地址(IP地址)来标识网络设备,而不采 ...
- Linq之旅:Linq入门详解(Linq to Objects)
示例代码下载:Linq之旅:Linq入门详解(Linq to Objects) 本博文详细介绍 .NET 3.5 中引入的重要功能:Language Integrated Query(LINQ,语言集 ...
- 架构设计:远程调用服务架构设计及zookeeper技术详解(下篇)
一.下篇开头的废话 终于开写下篇了,这也是我写远程调用框架的第三篇文章,前两篇都被博客园作为[编辑推荐]的文章,很兴奋哦,嘿嘿~~~~,本人是个很臭美的人,一定得要截图为证: 今天是2014年的第一天 ...
- EntityFramework Core 1.1 Add、Attach、Update、Remove方法如何高效使用详解
前言 我比较喜欢安静,大概和我喜欢研究和琢磨技术原因相关吧,刚好到了元旦节,这几天可以好好学习下EF Core,同时在项目当中用到EF Core,借此机会给予比较深入的理解,这里我们只讲解和EF 6. ...
- Java 字符串格式化详解
Java 字符串格式化详解 版权声明:本文为博主原创文章,未经博主允许不得转载. 微博:厉圣杰 文中如有纰漏,欢迎大家留言指出. 在 Java 的 String 类中,可以使用 format() 方法 ...
- Android Notification 详解(一)——基本操作
Android Notification 详解(一)--基本操作 版权声明:本文为博主原创文章,未经博主允许不得转载. 微博:厉圣杰 源码:AndroidDemo/Notification 文中如有纰 ...
随机推荐
- Verilog Review
Agenda 目的 Verilog概述 Verilog建模 模块 模块组成 书写建议 时延 Verilog基本语法 标识符 可读性 注释 空格 数据类型 操作数 运算符 条件语句 循环语句 函数 Ve ...
- 2023第十四届极客大挑战 — CRYPTO(WP全)
浅谈: 本次大挑战我们队伍也是取得了第一名的成绩,首先要感谢同伴的陪伴和帮助.在共同的努力下终不负期望! 但遗憾的是我们没有在某个方向全通关的,呜呜呜~ 继续努力吧!要学的还很多.明年有机会再战!!加 ...
- SpringBoot01:HelloWorld!
回顾Spring Spring是一个开源框架,2003年兴起的一个轻量级的Java开发框架. Spring是为了解决企业级应用开发的复杂性而创建的,简化开发. Spring是怎样简化Java开发的呢? ...
- [转帖]SQLServer的UTF8支持
排序规则和 Unicode 支持 - SQL Server | Microsoft Learn UTF-8 支持 SQL Server 2019 (15.x) 完全支持广泛使用的 UTF-8 字符编码 ...
- 鲲鹏920上面 Docker 部署 clickhouse 的方式方法
鲲鹏920上面 Docker 部署 clickhouse 的方式方法 背景 最近有一套鲲鹏920的测试环境, 研发同事想纯Dcoker部署一套环境. 其中就包括了 Clickhouse 之前发现Cli ...
- [转帖]Use TiFlash
https://docs.pingcap.com/tidb/v5.0/use-tiflash 8 Contributors After TiFlash is deployed, data replic ...
- [转帖]PD Config Learn the PD configuration file
The PD configuration file supports more options than command-line parameters. You can find the defau ...
- 如何查看服务器的Raid缓存等配置的情况
摘要 最近总遇到同一批机器的IO不一样的情况. 感觉可能跟硬件设备和Raid卡的设置不一样有关系. 所以今天学习研究了下storcli的命令. 希望能够进行一些数据的收集. Storcli简介 sto ...
- 基于Apache PDFBox的PDF数字签名
在Java语言环境中完成数字签名主要基于itext-pdf.PDFBox两种工具,itext-pdf受商业限制,应用于商业服务中需要购买授权.PDFBox是apache基金会开源项目,基于apache ...
- 期盼已久全平台支持-开源IM项目OpenIM之uniapp更新
国内uniapp使用广泛,OpenIM的uniapp sdk以及文档和demo (https://github.com/OpenIMSDK/Open-IM-Uniapp-Demo)都已更新,本文主要展 ...