【PCIe页请求服务】到底到底到底是啥?半年搜遍全网找不到一篇介绍文章,没人写那我来写吧

本文涉及的产品
公网NAT网关,每月750个小时 15CU
简介: 【PCIe页请求服务】到底到底到底是啥?半年搜遍全网找不到一篇介绍文章,没人写那我来写吧

1. 背景介绍


1.1 从ATS到ATS+PRS


Page Request Services(PRS),页请求服务,是Address Translation Services (ATS)地址转换服务的扩展项。若支持ATS的EP发送一笔地址转换请求,但RC地址转换代理(Translation Agent,TA)的地址转换保护表(Address Translation & Protection Table,ATPT)中没找到该虚拟地址对应的物理地址,这时候设备仍然想访问这个地址的数据,该怎么办?


有两种解决办法:① 放弃ATS服务,EP端继续发送未转换地址的读写访问,让RC端的SMMU/IOMMU对未转换地址进行转换处理,这种方式显然不如ATS性能好;② RC端把这一段地址映射添加到RC TA ATPT中,继续采用ATS进行访问。PRS便是属于第二种方式。


 ATS不一定支持PRS,但PRS一定需要ATS,为什么呢?因为PRS是ATS的扩展啊,两者紧密配合,携手并进。


 简单讲, PRS就是在数据Unpin情况下实现EP DMA的一种机制。




1.2 PRS的优势


 如果Device仅采用ATS来搬运大量的数据,从单个设备来看,我肯定希望把所有数据都Pin在主存里,不用置换页,多好。但是,主存空间就那么大,你占用得多,那其他进程分得的就少,从系统层面看势必会影响整体性能。从全局利益出发,你ATS少Pin一点,剩下的用PRS来干。


 PRS采用动态存储机制,在需要访问内存某页的时候就把其Pin在主存,使用完就释放,保证了整体系统性能。





2. PRS机制


 为了在EP和RC之间沟通地址转换事宜,PRS机制用到了两种消息:页请求消息 和 页请求组响应消息。


 ATS+PRS协同工作流程大致如下:


  1.    EP发送地址转换请求给RC;


  1.    RC未找到相关地址映射,反馈转换失败消息给EP;


  1.    EP发送页请求消息给RC;


  1.    如果虚拟地址对应主存空间,那就直接pin住;如果虚拟地址对应外存空间,从外存搬到主存后pin住,并生成虚拟地址到物理地址的映射;


  1.    RC反馈页请求组响应消息给EP;


  1.    EP再次发送地址转换请求给RC;


  1.    RC回复转换完成消息CplD给EP;


  1.    EP采用转换后的地址完成访问。




2.1 页请求消息(Page Request Message)


 页请求是指Function需要访问主存中的页,或言Function要访问主存中的某段地址范围。页请求消息是EP发给RC的消息,EP中的Function给其相关RC发送页请求消息来请求页访问。


2.1.1 页请求消息格式


 页请求服务允许把多笔页请求归类为一组,组成页请求组(Page Request Groups, PRGs)。一个PRG包括一笔或多笔页请求,每一笔页请求单独发送一次页请求消息,同一PRG中的多个页请求消息采用统一的PRG Index(9bit),用以在当前Function中唯一标识该PRG。


 页请求消息格式如下图所示(图1),整体由4DW组成,前2DW为标准的PCIe消息头标,后2DW为请求页的未转换地址、访问许可、PRG Index等信息。


cd2d7834b40043eea51611a7be32af2c.png



图1 Page Request Message


 各主要字段意义介绍如下:


  •    Fmt: 001b,表示当前TLP为4DW头标、无数据的TLP。


  •    Type: 1000*b,表示当前TLP为路由到RC的Msg。


  •    Length: 0,标识Data长度为0。


  •    Message Code:4,页请求消息的消息码。


  •    Page Address:请求页的未转换地址,地址低12bit为0,4KB对齐,当然也可以采用更大的页,比如8KB,届时RC需要忽略page_address[13],以此类推。


  •    Page Request Group Index:PRG Index。正常情况下,RC响应某个页请求时,应采用与页请求消息相同的PRG Index。


  •    L,Last Request in PRG:由于RC不知道一组PRG有多少页请求消息,所以一组PRG中最后发送的页请求消息应进行特殊标记,告知RC这是当前PRG消息的最后一笔。该bit置1表示当前页请求消息是其所在PRG中的最后一笔页请求消息。该bit置0表示当前页请求组的页请求消息还没发完,后续还有采用当前PRG Index的页请求消息。对于PRG内只有一笔页请求的情况,该位置1。对于PRG内有多笔页请求的情况,除最后一笔页请求之外,其他所有页请求消息的L字段都应置0。


  •    W,Write Access Request:写访问请求,该位置1表明Function接下来要写该页,RC收到W=1的页请求消息后可以把相关页标记为脏页*。ATS中跟这个字段相关联的由地址转换请求中的NW字段以及转换完成消息中的R/W字段(注:脏页是指高速缓存中数据被进程修改过的页,脏页需要在合适的时间刷入磁盘。)


  •    R,Read Access Request:读访问请求,该位置1表明Function接下来要读该页。对于代有PASID TLP Prefix且Executed Requested可执行请求位为0的页请求,R字段必须置1(要先读出来才能执行)。



2.1.2 页请求消息排序


 如上所述,RC不知道一组PRG有多少页请求消息,对于PRG内有多笔页请求的情况,除最后一笔页请求之外,其他所有页请求消息的L字段都应置0。为了提升多Function、多PRG的系统性能,使用过程中往往会开启宽松排序或ID排序,这就导致一个问题,即最后一笔有可能会被重新排序从而超过其前面发送的同组页请求消息,导致RC误判为这组PRG消息已经结束,从而导致不可预知的风险。


为了解决该问题,最后一笔页请求消息必须关闭宽松排序,确保同组PRG消息中该笔请求消息最后发送也是最后达到。PCIe事务排序规则请参考 【PCIe事务排序】。



2.1.3 页请求接口信用量


 页请求接口(Page Request Interface,PRI)控制PCIe Controller收发页请求/响应消息。每个Function的页请求接口都分配有特定数目的页请求消息信用量。RC或系统软件可以以任何合适的方式对信用量进行划分(比如在多个PRG见分配不同的信用量),RC采用任何方式来确保PRI正确计量信用量都是可行的。


页请求接口不能采用超出所分配最大范围的请求,否则在超出root缓存上限后页请求机制会被关闭。页请求接口能够处理的页请数目上限是静态分配好的,在开启PRI的时候已经分配好,想要更改只能关闭并重启PRI。


 对于PRG内有多笔页请求的情况,每一笔页请求消息占用一个信用量,而非一组页请求消息占用一个信用量。


   ⚠️注意:


  •        RC在收到页请求消息后不能选择忽视,必须进行响应,否则发送页请求消息的Function会一直等待。


  •        同一个请求组内包含多个针对相同页的页请求,或者多个PRG内请求同一页,均是合规的。


  •        Function在不查看页状态情况下便一次发送针对该页的多笔页请求,仍然是合法的。


  •        页请求消息TC=0,RC收到TC不为0的页请求消息,应当做畸形包处理,Switch等中间路由节点不必关注该消息的TC字段。



2.2 PRG响应消息(PRG Response Message)


 PRG响应消息是RC发给EP的消息,用于提示Function其请求的页已经准备好了(Pin在主存里了),EP可以采用ATS继续下一步操作了。PRG响应消息基于ID路由,路由到发出页请求的Function。对于PRG Index相同的一组页请求消息,RC只回复一次PRG响应消息,且RC在收到PRG最后一笔请求消息之前不会发送正常的请求响应消息(当然中间有可能收到响应出错的消息哇)。


2.2.1 PRG响应消息格式


062e39889dd4490188bede9e308135a5.png





图2 PRG Response Message


 PRG响应消息格式如图2所示,部分字段解释:


  •    Type:10010b,表示基于ID路由的Msg。


  •    Message Code:5,表示PRG响应消息。


  •    Response Code:用以指示页请求响应成功或失败,0000b -> 成功,0001 -> 无效请求,1111b -> 响应失败。


  •    Page Request Group Index:用以指示该响应消息所响应的PRG。




2.2.2 PRG响应顺序


 对于多组PRG请求的情况,PRS机制不保证页请求完成的顺序。若某个Function要求在某个页请求B之前必须完成页请求A,那么Function最好是在收到页请求A的完成响应消息之后再发送页请求B。



2.2.3 PRG响应未成功


 同一组内所有的页请求是同一根绳上的蚂蚱,旅进旅退。对于一组页请求消息,有可能部分页请求能够满足,部分页请求无法满足。对于这种情况,PRG响应消息统一判定为PRG请求失败,RC此时不会特意挑出满足页请求条件的页进行Pin。


页请求失败的原因大致有以下几点:


   页请求的未转换地址无效。


   开启了PASID TLP Prefix,但部分页请求未携带PASID TLP Prefix或PASID无效(例如超出capabilitiy设置的范围)。


   页请求TLP Prefix中指示请求执行,但页请求消息中指示页不可读(R=0)。


   所请求的页不具备所要求的访问属性。


   由于某些原因导致系统无法响应页请求。


 以上1~5点页请求失败跟系统动态运行有关,一次失败,重新发送一次是有可能成功的。如果PRG响应消息反馈了一笔预料之外的PRG Index,则把页请求能力结构页请求控制寄存器的对应位置1,便于软件发现并报告处理。



   ⚠️注意:


       Function在发出一系列页请求之后会等待RC反馈响应消息,此时在正常收发其他TLP的情况下该Function应有足够的能力处理来自RC的响应消息,确保不丢消息并正确解析,不然Function会一直等在那儿,会造成死锁。


       PRG响应消息TC=0,EP收到TC不为0的PRG响应消息,应当做畸形包处理,Switch等中间路由节点不必关注该消息的TC字段。




2.3 带有PASID TLP Prefix的PRS


 往期PASID TLP Prefix介绍请参考【PASID TLP Prefix介绍】。


2.3.1 PASID TLP Prefix使用


 支持PASID TLP Prefix的Function同样可以发送带有PASID TLP Prefix的页请求消息,PASID字段携带有所访问页的进程地址空间、执行请求指示位、特权模式请求指示位等信息。若PRG中某一页请求消息携带PASID TLP Prefix,那么该组所有页请求消息均需携带相同的PASID TLP Prefix,不允许有些携带有些不携带,也不允许携带不同的PASID TLP Prefix。


 若页请求消息携带TLP Prefix,正常情况下RC反馈的PRG响应消息也携带PASID TLP Prefix。PRG响应消息TLP Prefix的PASID与对应页请求消息的TLP Prefix PASID相同,执行请求和特权模式请求位预留。


 PASID TLP Prefix能力与ATS(Address Translation Services)及PRI(Page Request Interface)相互独立,具备PASID TLP Prefix能力的组件可以不支持ATS或PRI,支持ATS或PRI的组件也可以不支持PASID TLP Prefix。




2.3.2 PRG请求的PASID TLP Prefix管理


(1)启动


 开启PASID TLP Prefix能力的Function在发送页请求消息时会携带PASID TLP Prefix。


(2)结束


 带有PASID TLP Prefix的页请求消息发送过程中,打算关闭了PASID功能,此时还没收到响应消息,怎么办?两种方法——


 不发送停止消息。决定结束使用某PASID后,不能继续往待发送页请求消息队列中添加新的该PASID的页请求消息,发送L=1的该PASID页请求消息以结束发送,继续等待PRG响应消息并使用。(存疑,没太看懂)


 发送停止消息。决定结束使用某PASID后,不能继续往待发送页请求消息队列中添加新的该PASID的页请求消息,发送L=1的该PASID页请求消息以结束发送,当收到PRG响应消息后,只对信用量进行回收,但并不进行后续的ATS访问(请求了个寂寞),想要ATS访问该页需重新发送页请求。Function发送停止标志消息后,EP可以再次发送带有该PASID的页请求消息,RC再次接收到该PASID的页请求消息时,已经是另一个新故事了。


(存疑,没太看懂)




2.3.3 停止标记消息(Stop Marker Message)


 如果页请求消息W和R字段都为0,说明啥?正常理解便是:我要访问一个页,不读也不写。此处用这种特殊的页请求消息来表示停止指定PASID的页请求。


 停止标记消息用以指示Function已经发完所有某指定PASID的页请求消息,该消息子在该PASID页请求消息发送完之后发送,两者遵循强排序规则,确保停止标记消息在该PASID所有页请求消息之后到达RC。停止标记消息与页请求消息格式相同(图3),停止标记消息没有PRG Index,不占用页请求消息的信用量,RC在收到停止标志消息后不会回复任何响应消息。


 发送停止标记消息是带有PASID TLP Prefix的,TLP Prefix中开启ID 排序,关闭宽松排序,TC为0;消息主体部分L=1,W=0, R=0,地址域和PRG Index域预留,Marker Type字段为0表示该消息为停止标记消息。


4ae439c964aa4a77829f79dd2cc4480a.png




图3 Stop Marker Message


 停止标记消息出现以下几种异常情况时,至于RC作何反应,目前spec尚未做明确规定:


  •    RC在收到某PASID的停止标记消息之前未收到其最后一笔页请求消息


  •    Marker Typer非0


  •    未携带TLP Prefix


  •    TLP Prefix携带的PASID跟进行中页请求消息PASID不符




3. PRS配置


 实现了页请求扩展能力结构的组件才能使用页请求服务。页请求能力结构只能在EP或RCiEP中实现。在SR-IOV系统中,PF及其对应的所有VF公用一个页请求扩展能力结构,各Function发出的页请求消息通过不同的Function id进行区分。


 页请求扩展能力结构如图4所示,有扩展能力头标(图5)、页请求状态寄存器(图6)、页请求控制寄存器(图7)、outstanding的页请求能力及分配的outstanding页请求。各字段的意思从图中显而易见,不再赘述。


 PRS reset后,对于的信用量计数器归位,未发出的页请求消息不再发送,未收到的PRG响应消息也不再等待。



8c25a90797464dcdb9e881c7ecd66cee.png

图4 Page Request Extended Capability Structure

2e97947f448942b591bafc1fd1f5d171.png


图5 Page Request Extended Capability Header


55e2525bcdcc4441ad158e1d4b8877bc.png


图6 Page Request Control Register

43e7860ccdd84d6d89c8ee6bc598057e.png


图7 Page Request Status Register



4. 深入讨论


 关于【页请求服务】,大家在讨论些什么?【点击查看,欢迎跟帖讨论】




参考


   PCI Express Base Specification Revision 5.0 Version 1.0 (22 May 2019)


   ARM SMMU Spec 1


   ARM SMMU Spec 2



相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
目录
相关文章
|
4月前
|
网络协议 网络架构
熟记这十几个知识点,基本算是半只脚踏入网工了!
熟记这十几个知识点,基本算是半只脚踏入网工了!
|
6月前
|
监控 搜索推荐 安全
蓝易云 - 关于站群服务器,读过这一篇就够了!
总的来说,站群服务器是一种强大的工具,但需要谨慎使用。你应该始终确保你的站群遵守所有适用的搜索引擎指南,并且始终为用户提供高质量的内容。
158 2
|
7月前
|
运维 Kubernetes 监控
避免业务中断,K8s节点故障排查攻略,速来围观!
避免业务中断,K8s节点故障排查攻略,速来围观!
122 0
|
算法 物联网 开发者
分享一个近期开源火爆全网的额温枪方案(硬件+源码)
分享一个近期开源火爆全网的额温枪方案(硬件+源码)
189 1
|
Java 程序员 开发者
太卷了!这份Java性能调优手册仅上线1小时,竟被恶意封杀下架
在各大厂的面试中,性能优化的问题肯定不会缺席,这足以说明其重要性。今天给大家带来的便是由资深程序员葛一鸣老师写的《Java程序性能优化实战》,同样是没有开源版本,我会将领取方式放在文末 Java程序性能优化实战 我看过几篇讲解Java程序性能优化的图书,要么是内容不够深入,要么是过于晦涩难懂,不够浅显,而这本书却让我眼前一亮,很多困扰我的问题都能在书中找到答案。它涵盖了各种程序员所需的性能优化知识点,是Java开发者提升水平的必读佳作 来看看目录内容,里面一定有你想看的 亮个相吧(狗头.jpg) 想要更进一步的Java开发者一定不能
92 0
|
前端开发
给大家科普一泛二级程序前端几十套模板随机切换
​ 今天给大家分享几个小旋风蜘蛛池的泛二级程序网站站群模板,是无备案 新域名都可以用 老域名备案域名效果更好, 文章自动配图 关键词自动配图 泛二级程序模板是一款专门为了要从事相关工程方面工作的
129 0
|
缓存 监控 前端开发
项目维护几年了,为啥还这么卡?
前段时间有个客户问我,为啥你们项目都搞了好几年了,为啥线上还会经常反馈卡顿,呃呃呃。。
淘宝预售“买崩”程序员20分钟修复,全靠这份亿级流量并发手册
朋友们,今年双11电商大促即将到达,感受到四面八方激动的心情没有? 去年天猫淘宝在双十一中订单可是破了58.3万笔/秒,预测一波今年成交额又会打破去年记录。作为一名互联网民工,我关心的不是订单有多少,而是系统竟然没崩!以及这背后为了抗住这巨大的并发量的程序员同胞们……
下一篇
DataWorks