从一次内存读看透PCIe事务层：TLP、流量控制与路由全解析

老读者都知道我折腾PCIe有些年头了。每次有新人来问PCIe协议怎么入门我给的答案都差不多先把事务层Transaction Layer啃下来而啃事务层最好的切入点就是一次内存读Memory Read的完整旅程。原因很简单——读事务在PCIe里属于Non-Posted请求它有去有回一个MRd TLP过去一个或多个CplD TLP回来中间把事务层的核心机制几乎全部覆盖了TLP格式、Flow Control、地址路由、ID路由、Tag配对、Completion拆分。这篇就把这条旅程从头到尾走一遍顺便把那些看协议手册容易看晕、抓包时容易误判的细节一起说清楚。适合刚接触PCIe的嵌入式/驱动工程师也适合在FPGA上做PCIe IP却对内部报文一知半解的兄弟。1. 为什么我坚持用一次内存读来讲事务层1.1 事务层在PCIe协议栈里其实是个翻译官整个PCIe协议栈分成物理层、数据链路层、事务层三层。物理层管信号和链路训练数据链路层管可靠传输和重传而事务层是最接近软件意图的一层——它负责把我要读某个地址的数据这类意图翻译成标准格式的TLPTransaction Layer Packet也负责把对端发来的TLP解析回软件能理解的读写结果。事务层要做的事远不止拼一个报文头那么简单。它要管事务的发起和完成、要维护Flow Control信用、要做地址路由和ID路由、要管理Tag分配、要处理错误上报。很多人背TLP头字段表背得很熟但一抓实际报文就对不上号就是因为这些字段在真实事务里是相互配合的单独拎出来看永远是散的。用一次读请求串起来它们才有逻辑关系。1.2 读事务的特殊性有去程就有返程PCIe的事务分成两类Posted发布式和Non-Posted非发布式。内存写MWr是Posted发出去就完事不需要对方回复所以它在事务层走的是单向流程涉及的机制少。而内存读MRd是Non-Posted发出去之后必须等待目标设备返回一个Completion事务才算结束。就是必须等回复这一点让读事务带出了一大串隐藏机制请求方要记住自己发过什么Tag管理每一跳转发都要检查信用Flow Control目标设备要把读到的数据打包成完成包再原路找回来ID路由万一对方一直不回话还得有超时和错误处理机制。可以说读事务是事务层的全家桶。把一次内存读讲透MWr、CfgRd这些只是在它基础上做加减法而已。2. 旅程起点一条load指令是怎么变成MRd TLP的2.1 从CPU访问到Root Complex的地址解析故事从CPU执行一条load指令开始。比如驱动代码里写了一个readl(reg)这个地址在软件层面是虚拟地址经过MMU翻译后落到物理地址而物理地址恰好被系统固件映射到了某个PCIe设备的BAR窗口里。Root Complex收到这个内存访问时会先判断目标物理地址落在哪个PCIe窗口。如果命中的是某个设备的64位BARRC就会构造一个4DW头带完整64位地址的MRd如果命中32位BAR就用3DW头32位地址。这一步虽然发生在RC内部但它是整个读事务真正的起点——软件以为自己在读内存硬件实际在做的是发一个PCIe读请求包。对驱动开发来说这里有个最常见的混淆点ioread32(bar_addr)走的是MMIO方式的MRd而pci_read_config_dword()走的是配置空间的CfgRd事务两者报文格式不同、路由方式也不同。配置请求按ID路由内存读按地址路由排查问题的时候先分清这一层能省很多时间。2.2 MRd的TLP头拆解每个字段都是干什么的RC事务层拼出来的MRd TLP头以最常见的3DW头为例长这样TLP Header (MRd, 3DW, 32-bit Address) DW0: Fmt3DW-noData TypeMRd TC0 TD0 EP0 Attr00 Length0xN DW1: Requester ID Bus:Dev:Func Tag0xXX First/Last DW BE DW2: Address[31:0] 目标内存地址逐个说清楚这些字段的用途Fmt/Type表示这是一个3DW头、无数据负载的Memory Read Request。收到这个值的下游设备能立刻知道这是个读请求请求方不要数据跟着来数据会被放到之后的完成包里。Length以DW4字节为单位表示要读多少个数据字。比如读64字节Length就是160x10。这里一定要记住单位是DW不是字节初学经常在这算错。Requester ID发起方的Bus:Device:Function编号也就是BDF。它是整个事务的户口本后面完成包要靠它回家。Tag发起方给这个请求分配的标签用来区分多个还没完成的读请求。一个设备同一时间可以挂起多个读事务就是用Tag来区分的。First/Last DW BEByte Enable用于指示首尾两个DW里到底哪些字节有效。如果只读一个4字节寄存器的中间2个字节就可以用BE精确指出来。TCTraffic Class服务等级配合虚拟通道VC使用决定这个包走哪条优先级通道。Attr包括Relaxed Ordering、ID-Based Ordering等排序属性还有硬件一致性相关位。这里有一个值得展开的细节为什么Length用DW而不是字节因为PCIe的地址路由和缓冲区管理都以4字节为基本粒度DW对齐是最自然的单位。那么如果软件想读3个字节怎么办不是靠Length的分数而是靠Byte Enable。Length表示这个请求覆盖几个DWBE精确到每个DW里的哪几个字节有效。所以一次读请求可以覆盖地址从某个偏移开始的、带任意字节掩码的区域。2.3 还没发出去之前先过第一道闸非发布请求的代价MRd组装好之后并不是想发就能发。RC的事务层要先检查Flow Control信用——具体来说是无数据的Non-Posted Header信用NPH Credit。只有对端下一跳链路还有足够的NPH缓冲空间这个MRd才允许被送上数据链路层。这就是Non-Posted请求的第一个性能代价。如果接收缓冲区被占满了发送端就必须等着直到对端通过更新FC消息释放出新的信用。所以一次读请求还没离开RC可能就已经在FC这一关排队了。这也是为什么事务层协议里写读可以高并发和实际读很慢并不矛盾——并发能力取决于Tag数量和FC缓冲任何一个卡住读延迟都会肉眼可见地变差。另外提一个4KB边界的知识点PCIe规定一个TLP请求不能跨越4KB地址边界。如果软件请求的起始地址是0xFD000FFC要读64字节那就会跨到0xFD001000之后的空间。RC在组装TLP的时候会把这个请求拆成两个MRd分别发出。分析仪抓包时看到为什么我读64字节变成了两个请求往往就是这个原因。3. 事务层最大的隐形门槛Flow Control信用机制3.1 没有FC链路再快也会被自己堵死Flow Control流量控制通常简称FC是事务层最容易被忽略、却最容易出问题的机制。它的作用是发送端在发出每个TLP之前必须先确认接收端有足够的缓冲空间来接收它。为什么必须这样因为数据链路层的ACK/NAK重传机制只能保证传输过程中坏了能重发但接收端的事务层缓冲如果溢出包已经被物理层收走了数据链路层认为传输成功可事务层却无处安放这个包——这才是真正致命的。所以FC是在源头解决问题宁可让发送端等一下也不能让它把数据发到一个放不下的地方。打个比方数据链路层的重传像快递运输途中的保险丢了可以重新发货而FC更像是发件之前先给收货方打个电话确认对方仓库有空位才发车。没有这个电话再多的保险也治不了仓库爆仓。3.2 六个Credit池与一次读请求的对应关系每个链路的接收端都为对端维护着六种独立的信用池。这个数量经常把人绕晕其实记忆方法很简单按三类事务Posted、Non-Posted、Completion各分Header和Data两种池。Credit池服务对象一次内存读用到吗PHPosted HeaderMWr、Message等posted请求的头否PDPosted DataMWr、MessageD等posted请求的数据否NPHNon-Posted HeaderMRd、IORd、CfgRd等请求的头MRd用NPDNon-Posted DataIOWr、CfgWr等请求的数据否CHCompletion HeaderCpl、CplD完成包的头CplD用CDCompletion DataCplD完成包的数据CplD用这里有个容易误解的地方MRd本身没有数据负载所以只消耗NPH信用而目标设备返回的CplD自带数据消耗的是CH和CD信用。这也就是说读请求的去程和返程用的是完全不同的信用池两者互不挤占。设计成这样是有道理的否则大量读请求占满了NPH池完成包又被堵在门外很容易造成事务层死锁。3.3 InitFC、UpdateFC的握手过程与Credit卡死现场FC信用的建立过程是链路训练完成、数据链路层进入正常工作状态后接收方会通过数据链路层的DLLP报文把自己的缓冲能力广播给对端。这个广播分InitFC1和InitFC2两步打交道的双方在每个Virtual Channel上把每种Credit池的初始值告诉对方。之后每当接收方的事务层从缓冲区里取走一个TLP处理掉它就有空间释放出来了。但这个释放不是实时通知的而是由接收方的事务层周期性或按需发送UpdateFC DLLP告知对端我又腾出了多少空间。发送端维护着一个简单的记账逻辑已发送的TLP对应的信用减去对端已确认释放的信用差值不能超过初始信用。实际项目中我遇到过最典型的问题就是Credit卡死链路是UP的物理层和数据链路层都正常但就是有TLP发不出去。用协议分析仪一看MRd一直挂在FC等待状态对端却迟迟不发UpdateFC。这种多半是接收方向的事务层缓冲释放逻辑有bug或者FC初始化时credit值算错了。排查这种问题优先怀疑对方端点尤其是FPGA自研事务层而不是盲目改驱动。4. 去程路由地址是怎么一级一级找到目标的4.1 枚举时画的地址地图——BAR与桥窗口一个TLP从RC发出来它在链路上走的路径并不是随机的而是由系统枚举阶段建立起来的地址地图决定的。设备枚举时固件BIOS/ACPI或Bootloader/设备树会扫描整条PCIe总线树先给每个设备分配Bus号然后读取设备各BAR寄存器要求的内存空间大小再把系统物理地址空间里合适的窗口分配给这些BAR。分配完成之后每个设备都知道自己要监听哪段地址空间每个PCIe桥包括Switch内部的下行端口也都在配置空间里记录了我下游的子树一共占用了哪几段地址窗口对应PCI-to-PCI Bridge的Base/Limit寄存器。这就是地址路由能工作的基础。RC并不需要维护一张精确到每个设备的完整路由表它只要知道系统里一共有哪几段PCIe地址窗口然后把包发给对应窗口所在的下一级端口Switch再根据同样的地址窗口信息往下一级转。每一级只需要判断这个地址是不是在我管辖范围内这种逐级判断的设计让路由实现非常简单高效。4.2 逐跳解码RC、Switch、EP各管一段一次到达EP的MRd去程路径上的每一跳是这样处理的RC根据目标物理地址查找内部维护的PCIe地址窗口表找到该窗口对应的第一个Switch下行端口或直连EP把TLP发到那条链路上。Switch从上游端口收到MRd后查看TLP里的目标地址是否落在某个下行端口管辖的地址范围内。如果落在Port 2的范围内就转发给Port 2如果落在Port 5的范围就转发给Port 5。如果哪个都不落这个地址就属于Switch自己上游方向的其他域按规范不转发或做错误处理。EP收到MRd后事务层把目标地址和自己的BAR区间做比对。命中某个BAR就进入本地处理不命中任何BAR就要生成错误完成包。每一级只做局部判断这就是PCIe能支持复杂拓扑而不用维护全局路由表的原因。很多做FPGA EP的兄弟在调试时遇到读请求总是到不了我的EP第一反应是怀疑EP内部逻辑其实更常见的问题是Switch的地址窗口没有配置对或者RC侧的ACPI/DTS内存窗口写错了。先用上位机工具lspci确认BAR地址和实际访问地址一致再往下查。4.3 地址没人认领时Unsupported Request是怎么返程的地址路由还有一个很关键的错误场景如果MRd的地址到达某个EPEP发现地址不在自己的任何BAR范围内它不能假装没看见。按照规范EP需要把这个请求标记为Unsupported RequestUR并且对Non-Posted请求返回一个不带数据的Cpl包状态字段填UR。这个Cpl包会顺着ID路由原路回到RCRC收到后把它转成对软件可见的错误比如PCIe错误记录、AER日志极端情况下会触发MCE等。这里和写事务形成鲜明对比如果是MWr写请求走错了地址由于它是Posted事务目标设备无法用完成包通知请求方只能默默在本地错误寄存器里记录UR错误再通过错误消息上报。所以调试时如果发现读请求返回全F或者直接报总线错误而写请求看起来成功其实数据丢了十有八九是地址映射错了而不是设备坏了。5. 终点站EP收到请求后如何构造CplD完成包5.1 EP事务层的接收校验与内部数据访问MRd到达EP的事务层之后EP要做的第一件事不是立刻去读数据而是先做完整性校验。如果TLP头里的TD位TLP Digest被置位说明报文末尾带了ECRC校验值EP需要验证ECRC不一致就要按错误处理EP位Poisoned置位表示发送方标记了这个包有毒一般要丢弃或上报。校验没问题、FC信用归还之后EP的事务层就把这个读请求转换成内部总线事务。以FPGA实现为例MRd请求进入EP IP核后会被翻译成一次AXI读请求地址来自TLP头长度来自Length字段然后AXI master去访问用户逻辑或DDR控制器。用户逻辑如寄存器、状态内存返回数据后EP把数据拿回来准备拼CplD。这一步的延迟是整个读事务耗时的大头。EP内部访问DDR有延迟用户逻辑组合逻辑也可能很慢所以一次PCIe读的往返延迟往往比链路传输本身的延迟高一个数量级。这也是为什么在驱动里频繁做MMIO读是个性能反模式——每个读都要等这么长一圈。5.2 CplD头部拆解与Byte Count的反直觉语义EP拿到数据后开始构造Completion with DataCplD包。CplD头同样是3DW格式如下TLP Header (CplD, 3DW) DW0: Fmt3DW-withData TypeCplD TC0 Attr00 Length本次数据DW数 DW1: Completer ID 自己的BDF StatusSC BCM0 Byte Count0xXXX DW2: Requester ID 原样带回请求方BDF Tag原请求的Tag注意几个容易算错的地方Completer ID是EP自己的BDF表示这个完成包是谁生成的。Requester ID和Tag必须原样从MRd头里抄回来。它们是完成包回家的凭据绝对不能改。Status标记完成状态成功是SCSuccessful CompletionUR是前面说的地址不认领还有Completer AbortCA表示设备内部出了问题故意不完成这个事务。Byte Count字段这是全网最容易被误解的字段。它的语义是这个CplD发出之后原请求还有多少字节没返回而不是这个CplD携带了多少数据。举个例子请求读512字节EP分两个CplD返回每个带256字节。第一个CplD发出后还剩256字节Byte Count填256第二个CplD发出后还剩0字节Byte Count填0。最后一个完成包的Byte Count几乎总是0看到Byte Count 0不代表没数据而是代表这个事务到此结束。BCMByte Count Mismatch位当完成数据的字节计数和请求不完全匹配时EP要置位。比如因为地址对齐或长度限制实际返回的字节数和请求的原始字节数对不上就靠这个位告诉请求方我这个完成有问题别拿标准逻辑去算。还有一个细节CplD没有Byte Enable字段。EP返回数据时如果原请求的首尾DW里有部分字节不需要EP不需要也不能用BE字段标记它是把不需要的字节直接填充为0整个DW一起返回。所以部分字节读的完成包里数据是完整的DW对齐只是某些字节是0。这也能解释为什么某些调试场景下读寄存器会看到相邻字节被清零——那不是设备值就是0而是完成包的填充规则。5.3 请求太大时的拆分完成MPS与多包返回EP返回CplD时单个包能携带的数据量受限于Max Payload SizeMPS。MPS是整条链路上所有设备协商出来的最大数据负载常见值是128字节、256字节、512字节等。如果MRd请求的数据量超过了MPSEP不能违反MPS硬塞必须拆成多个CplD。每个CplD的Length字段表示我这个包带了几个DW。与此同时每个CplD的Byte Count按前面说的语义递减。请求方RC则把收到的多个CplD按顺序拼回完整数据。这里要注意MRd的请求长度本身却不受MPS限制它受另一个参数Max Read Request SizeMRRS限制。MRRS和MPS是两回事经常有人混。MPS限制的是携带数据的TLP的单包大小MRRS限制的是一次读请求最多请求多少数据。假设MRRS512BMPS128BRC可以发一个Length128DW512B的MRdEP则会返回4个CplD每个128字节。理解了这个拆包机制抓包时看到一个读请求跟了一串完成包就不会慌。6. 返程路由为什么完成包不按地址回家而是靠ID认路6.1 Tag是这个事务的身份证号去程的MRd靠地址找到目标返程的CplD却不能再靠地址了。原因很直观地址只能把包带到目标设备而完成包是要回到发起这个请求的源头。多个请求方可能同时对同一个地址发起读甚至同一个请求方自己都挂着几十个未完成的读事务完成包只说我来自地址X根本没法分辨该给谁。所以PCIe用Requester ID Tag作为事务的身份证。RC/EP在发起每个Non-Posted请求时都要从自己的Tag池里领一个未占用Tag并把Tag记录在未完成事务表里。CplD返回时只要看它的Requester ID和Tag就能精确知道它属于哪个请求、该唤醒哪个等待者。这也是为什么Tag数量是PCIe并发能力的重要指标。一个EP能同时挂起多少个读请求上限就写在它的Device Capability寄存器里通常是32或64。Tag用完了新的读请求就发不出去只能排队等前面的完成回来释放Tag。RC侧也一样RC要维护所有下游设备的未完成事务表Tag是稀缺资源不是想开多大就开多大。6.2 ID路由在Switch里的逐跳决策完成包在返回路径上走的是ID路由。整个返程逻辑和去程的地理解码完全不同——它不解析地址只解析目标BDF也就是Requester ID里的Bus:Dev:Func。在Switch内部每个下行端口都配置了我下游挂着哪段Bus号范围。打比方Switch的Port 2下游总线号是2~3Port 5下游是6~7。上传方向收到一个CplD时Switch先把目标的Bus号和自己所有下行端口的Bus范围比对找得到就转下去找不到说明目标在上游方向直接往上游端口转发。下行方向反过来每个下行端口收到CplD时如果目标Bus号落在自己管辖范围内就接收否则丢弃或上报。所以完成包不需要任何导航信息只要Request ID里的Bus号在枚举时被正确分配返程路线就是确定的。这也意味着如果系统里Bus号分配出现冲突比如热插拔导致总线重新枚举那么即使去程地址路由是好的完成包也可能迷路。实际中遇到读请求发出去了EP也处理了但RC就是等不到完成包很大概率是Bus号路由表的问题优先怀疑枚举和热插拔重扫描逻辑。6.3 如果完成永远不回来Completion Timeout与错误处理万事都有例外。MRd发出去之后如果CplD一直不回来怎么办PCIe不允许请求方无限期等待每个请求方都实现了一个Completion TimeoutCTO机制。超时值可以通过配置空间设置范围很宽从几十微秒到几十秒都能配。一旦超时请求方会认为这个事务失败记录超时错误释放Tag资源。这里有一个容易混淆的点Completion超时不一定代表EP没处理也可能是CplD在返程路上丢了或者被Switch错误路由了或者因为FC信用问题被堵在半路。所以排查超时问题时不要只盯着EP看还要看返程每跳的FC状态和路由配置。错误处理路径还有一个分支如果CplD回来但Status不是SC比如UR或CA请求方也要走错误上报流程。这些错误在配置了AERAdvanced Error Reporting的设备上会记录到详细错误寄存器里驱动或系统日志能看到具体是哪个事务出了什么错误。对开发而言AER日志是定位读失败原因的最快入口比盲目抓包高效得多。7. 实测视角抓一次读事务聊聊常见反直觉现象7.1 分析仪/驱动里看到的MRd与CplD长什么样纸上谈兵再多不如看一眼真实抓包。用协议分析仪或者FPGA内部ILA抓一条典型的大块读大致长这样MRd : TC0, RequesterID00:00.0, Tag0x1A, Length0x80(128DW512B), Addr0xFD001000 CplD: CompleterID03:00.0, StatusSC, Length0x40(64DW256B), ByteCount0x100(256B) CplD: CompleterID03:00.0, StatusSC, Length0x40(64DW256B), ByteCount0x000这个抓包对应的是RC发起一个512字节的读请求EP因为MPS限制是256字节分两个完成包返回每个带256字节。第一个CplD的Byte Count是256表示还有256字节没返回第二个是0表示没了事务完成。如果是抓一个单次4字节的寄存器读抓包会更简单MRd : RequesterID00:00.0, Tag0x02, Length0x001(1DW), Addr0xFD000000 CplD: CompleterID03:00.0, StatusSC, Length0x001(1DW), ByteCount0x000单读单回干净利落。7.2 Byte Count0是正常现象我第一次抓CplD时候看到Byte Count0第一反应是我抓包软件坏了怎么数据长度跟Byte Count完全对不上。后来啃规范才明白Byte Count根本不是这个包带了多少数据。重新强调一遍这个语义区别Length字段描述当前这个CplD本身携带了多少数据。Byte Count字段描述当前这个CplD发出之后原请求还剩多少数据没返回。所以在单包完成的事务里Length1、Byte Count0是完全正常的组合。在多包完成里Byte Count是逐包递减的最后一个包总是0。只有看到BCM位被置位时才需要警惕那才是EP在提示字节计数对不上别按常规逻辑计算。7.3 读请求为什么拉不满带宽有很多人拿PCIe跑带宽测试写方向轻松跑满读方向怎么都上不去怀疑是设备不行。其实这是协议特性决定的不是硬件bug。Non-Posted读事务的吞吐率受制于请求-完成的往返延迟。粗略算一下假设链路是Gen3 x4单向理论带宽约3.5GB/s。一次64字节的读请求如果往返延迟取一个常见值800纳秒链路传输几十纳秒大头在EP内部访问那么单次读的吞吐率只有64字节/800纳秒约80MB/s。即使靠多Tag并发挂起4个读也只有300MB/s左右。和写事务一个包飞过去就是满带宽相比差距是天生的。所以工程上的建议是流式大量数据传输尽量用写或者用DMA描述符批量读、预取大块数据靠CPU发单笔MMIO读去刷数据是绝对跑不起来的。CPU硬件预取器能部分缓解这个问题但驱动代码里还是要避免critical path上的频繁读操作。7.4 一个FPGA互通排查案例Credit与Completion超时最后分享一个我实际处理过的排查案例串起前面所有知识点。现象是FPGA板卡做PCIe EP驱动读版本寄存器返回全0xFF随后报超时或总线错误。常见排查链路如下先确认链路和枚举状态。lspci -vvv看EP有没有被正确枚举BAR0地址和大小是否符合预期。这个案例里BAR0实际分配地址是0xF8000000大小4KB和预期一致排除地址映射问题。确认配置空间可达。用setpci或内核API读配置空间的Device ID、Vendor ID配置读走CfgRd事务如果配置空间能读说明链路训练、ID路由、数据链路层都正常问题大概率在事务层的数据通路。在FPGA内部抓AXI接口。用ILA抓EP IP核发出的AXI读请求发现根本没有读请求到达用户逻辑。说明MRd卡在了EP的事务层内部或者压根没到EP。协议分析仪抓包确认。这时用分析仪挂在上游链路上看MRd确实发出来了目标地址也对但EP方向一直不回CplD。进一步看FC状态发现EP入口的NPH credit被耗尽而且长时间没有更新。定位到EP内部FC释放逻辑。最终查到是FPGA里EP事务层接口的用户逻辑没有把接收到的TLP及时从缓冲取走导致FC credit一直不释放。RC发了几次请求后把EP的NPH缓冲占满后续所有读请求全部排队等FC等到CTO超时直接报错。这个案例再次印证了排查顺序链路UP不等于事务层通畅先看credit再看packet最后才怀疑驱动和软件。如果你能亲手用分析仪或FPGA内部逻辑抓到一个MRd和对应的CplD那这章里讲的东西你就真正拥有了一半。剩下的一半就是多踩几次坑把每个字段和实际现象对上号。