Completion

Completion

协议中小写的completion翻译过来为完成，首字母大写的Completion才是TLP包

Non Flit Completion格式

Non Flit模式下的Completion格式如下:

Completions是通过ID路由的，使用3DW的Header。routing ID字段直接对应于与相应请求提供的Requester ID，因此，对于completions而言，这些字段会直接参考Requester ID,而不是用通常的ID路由用作区分的字段。其每个域的作用见TLP基本格式

一些约束

• Fmt
  • 为0x0(000,010),
• TH
  • 字段必须保留，
• AT[1:0]
  • 必须为00，接收机不要求或者不鼓励检查该项
• length
  • 带data payload的Completion必须在Completion中声明数组的长度,并且必须包含指定数量大小的data,如果收到的data超过或者少于length字段指定的值，形成的TLP是Malformed TLP
• Completion Header中的Requester ID，Tag和Traffic Class必须要跟响应的Request中保持一致
• Completion Header中的Attr必须跟响应的Request header中的一致，除非显式声明
  • 当使用了IDO
  • 当在传输的Completion时使用了RO
• Tag[9:0]
  • 跟Requester ID绑定，对应于Transaction ID.在Non Flit模式下，Tag字段是10 比特

Flit Completion格式

Flit模式下的Completion具有如下格式(没有包含OHC具体内容)

对于非UIO Completions时，规则同Non Flit模式一样，但是在Flit模式时，Completions Header跟Non Flit模式不一样。在Flit模式下

• Tag是14比特，
• 不支持BCM
• 具有OHC字段

带有Completion Status而不是Successful Completion的UIO Write Completions和UIO Read Completions必须使用下属格式的Header

带data的UIO Read Completions必须使用下面的UIO Completion Header

OHC

如果有如下情况，则需要OHC-A5:

• 未完成的Completion. (Unsuccessful Completions)
• Lower Address[1:0]不等于00b的Non-UIO Completions
• Completer捕获的Requester Segment与相关联的Non-Posted Reqeust中不匹配，因此Completion需要Destination Segment。

当OHC-A5不存在时，意味着Completion Status为Successful，Completer Segment和Destination Segment不需要明确指示,并且对于non-UIO Completions而言，Lower Address[1:0]为00b。

当OHC-A5存在时：

• Completion Status和non-UIO Completion, Lower Address[1:0]必须包含有效的值
  • 对于UIO Completions, Lower Address[1:0]是保留的
• Completer Segment段必须包含Function捕获的Segment值,如果捕获的Segment被清理了，Completer Segment段必须是00h
• 如果相关联的Request不包含Request Segment，Destination Segment段必须是00h并且DSV比特必须清掉。如果相关联的Requests包含Requester Segment,Destination Segment段必须反应Requester Segment的值，并且DSV比特必须设置。

Attr[2:0]

在non-UIO Memory Request中，相关联的IDO,RO和NS是保留的

EP

该段对于UIOWrCpl和UIORdCpl是保留的

其它字段

跟Flit Mode下Header保持一致

UIO Completions

• Read Completion边界和Write Completion边界具有一定的规则，必须遵守
• Length[9:0]表明该Completion携带数据的DW数
  • 无论Completion Status是啥，Complter返回UIO Request相对应的Completions中，DW总数必须跟length[9:0]一致
  • 当决定UIO Completions的Length value时，Byte Enables禁止考虑在内
    • 对于0长度的UIO Write（在request中，Length[9:0]是00_0000_0001b并且First Byte Enable是0000b）,必须认为已经写入了一个DW。
• Tag域值必须符合相符合的UIO Request(s)的Tag域值
  • 对于给定的Transaction ID,如果所有DW的Completion是持准确的，UIO Write Completions允许合并或者分裂
  • 对于给定的Transaction ID,如果所有DW的Completion是持准确的，UIO Write Read允许合并或者分裂
• Lower Address[1:0]是保留的
• 对于不带数据的UIO Completions,Lower Address[6:2]是保留的
• 对于带数据的UIO Completions,Lower Address[11:2]必须存在
• CDL[1:0]域是拿给CXL使用的，如果当前不是使用CXL，则改域必须保留
• UIO Requesters必须接受任何顺序的UIO Completions
• 只有所都DW都完成后，特定Transaction ID的UIO Memory Requeste(s)才算完成,Completions的长度由length[9:0]指定，等于相关联Requets的所有总的DW和
  • 对于同一个Transaction ID，只有UIO Memory Writes允许多笔outstanding Requests(未完成的请求)。对于Requester而言，给定一个特定的Transaction ID,确保UIO Memory Write Requests已完成是必须的, 请求者必须延迟使用该事务ID发出额外的请求，直到它收到了使用该事务ID的所有未完成的UIO内存写请求的Completions
• 当完全完成时，与相同事务ID关联的所有请求都由相同的完成状态表示。然而，单个UIO请求的完成可能指示不同的完成状态值。在合并io完成的任何点，包括在请求端，总的Completion Status是根据以下规则确定的：
  • 如果任何UIO Completions有UR Completions Status或者保留的Completion Status时，则合并的Completion Status为UR
  • 如果所有的UIO Completions都没有UR Completion Status,并且任意一个有CA Completion Status，则合并的Completion Status为UR
  • 如果所有的UIO Completions都没有UR或者CA Completion Status,并且任意一个有RRSS Completion Status，则合并的Completions Status为PRS
  • 所有所有的UIO Completions的Completion Status都是Successful，则合并的Completion Status为SC.
• UIO Read Request对应的UIO Completions，如果其Completion Status不是SC(Successful Completion),则必须使用UIORdCpl类型
  • UIORdCpl的length值不受到Max Payload Size或者Max Read Request Size的限制

处理收到的Completion

当设备收到了一个Completion,并且改笔Completion中的Transaction ID跟设备自己发出的Requests中的不一致，该笔Completion称为Unexpected Completion(不支持的回复)。接收到Unexpected Completion是一种错误，接收机必须丢掉改Completion，并且上报错误，错误需要跟port绑定。

如果收到了一个Completion，Completion中的Transaction Id跟发出去中request中的Transaction Id一致。但是TLP中的其它field跟Request不符合，在Flit模式下，接收机必须把这样的Completion视为一个Unexpected Completion。但是接收机不允许检查IDO属性，(Attribute bit2)，因为Completer不会将Request中的IDO复制到Completion中。虽然TLP中的其它field跟Request中的不一致，但是TLP以其它正确的格式形成，允许接收机将这个Completion处理为Malformed TLP

当Switch的Ingress port收到不能转发的Completion，Ingress port必须将改Completion当作Unexpected Completion。不能转发的Completion包括:

• 跟Upstream Port关联的device中不存在某个function
• 跟Upstream Port关联的Bus上不存在某个device
• 在switch内部不存在某个device或者function
• Downstream port没有声明Upstream port中的某个bus number

收到非预期的Completion是一个错误，并且必须按如下规则处理：

• 收到非预期的Completion的设备需要将对应的completion丢掉
• 改错误需要跟接受的端口绑定并上报该错误

非预期的Completion通常认为是switch错误的转发了Completion，在这种情况下，Requester发出去的Request可能不会收到Completion，这时就需要用到Requester’s Completion超时机制来终止该笔Request

如果收到了Completion，但是Compltion Status不是SC，或者RRS(相对应的为Configuration Request)，Requester需要采取下列行为来处理：

• 释放跟发出去的Request相关联的completion缓存空间和其它资源
• 通过Requester自定义的机制处理该错误
  • 如果本端在发起FLR前发送了Completion，且目标function已经完成了FLR，目标function在这段事件中收到了Completion，则允许目标function将Completion处理为UC（Unexpected Completion）或者是静静丢掉(接着应该流控credits)，丢到后不需要上报或者用某个信号来记录错误。一旦FLR完成，在FLR之前收到某笔request对应的Completions必须处理为UC，除非相应的function重新使能了提到的那笔Requests。

RC处理Configuration请求对应带有RRS状态的Completions是基于具体实现，除非经理系统复位。 对于支持配置 RRS 软件可见性的RC，有如下规则：

• 如果配置RRS软件可见性没有使能，RC必须重新记录Configuration请求是一个新请求。
• 如果配置RRS软件可见性使能了
  • 如果一个Configuration请求包含了设备function的配置空间头中包含Vendor ID字段，则RC必须完成一笔请求给host，具体方式为返回一个0001h的vendor ID，并且该笔请求中的其它所有字段都是1，此读取数据值已由 PCI-SIG 专门保留用于此用途，并且不对应于任何分配的供应商 ID。
  • 对于Configuration写或者任何Configuration读请求，RC必须重新发出配置请求作为新的请求。
• RC实现可以选择在确定请求的目标有问题并采取适当的措施（例如，将对系统软件的请求作为失败的事务完成）之前限制配置请求/RRS 完成状态循环的数量。
• 在单个独立的RC上，为了控制RC的行为，可以通过设置Root Control寄存器中的bit[5] (Configuration RRS Software Visibility Enable)来启用配置 RRS 软件可视性或者是设置RCRB中的”Configuration RRS Software Visibility Enable”比特，允许一个比特来控制一个或者多个RC或者RCiEPs的行为。对于这种替代情况，RP(Root Port)或者 RCiEP 通过Root Complex Link Declaration Capability中的 RCRB 头关联声明其与特定启用位的关联。每个RP或 RCiEP 最多只能由一个使能位控制。例如，如果RP的寄存器Root Control包含使能位，则禁止其声明与另一个在其 RCRB 头功能中也包含使能位的 RCRB 建立 RCRB 头关联。RP或 RCRB 头功能中启用位的存在由相应的配置 RRS 软件可见性位指示.
• 带有保留的Completion Status的Completions被当成Completion Status为UR（Unsupported Request）处理
• Completion Status为Unsupported Request或者Completer Abord的Completions，错误上报是采用的传统的PCI上报机制
  • 触发生成此类Completion的错误条件由Completer报告
• 当收到Read，AtomicoOp或者DWRr的Completion且Completion Status表示Successful Competion时，根据如下情况处理：
  • Completion中不包含数据，收到的应该是Cpl(或者CplLK)编码而不是CplD（或者CplDLK）
  • 本次Completion是Request的最后Completion
    • Requester必须考虑中断请求，并且不期望收到额外的Completions，先前收到Completion的处理是特定于实现的

Completion超时机制

在任何分片传输协议中，都存在一种风险，那就是接受没收到预期的completion。在标准的行为中，为了允许接收者可以尝试从这种情况中恢复出来，定义了Completion超时机制。改机制只有在没有收到合理的Completion时生效，并且在正常工作情况下从不应该发生。注意，这里指定的值不反映预期的服务延迟，并且不能用于估计典型的响应时间。

实现Requests(除开Configuration Requests)的PCIe Device Functions必须实现Completion超时机制。当发送了一笔Requets时，如果需要一笔或者更多笔Completions，超时机制必须激活。因为Switch不会主动发起需要completion的Requests，所以Completion超时机制只适用于Root Complexs,PCI Express-PCI Bridges和Endpoints。软件通过配置Device Control 2寄存器中的bit[4] Completion Timeout Disable来禁用Completion超时机制。

Completion超时值来源于Device Control 2寄存器中的bit[1] Completion Timeout Value段,如果发生Completion Timeout，改错误需要跟requester funtion绑定。如果Completion超时机制被编程成不支持，则此function在Flit模式下必须实现40ms-50ms的超时值，当Flit Mode Supported被清掉后，function必须实现50us-50ms的超时值，并且强烈推荐超时值至少大于10ms。

有多笔Completion的Request只有在请求方收到所有Completions时才被认为已完成。对于Memory Read Request，如果在完成超时计时器到期之前返回了部分（但不是全部）请求的数据，则允许请求者保留或丢弃在计时器到期之前返回的数据。

UIO请求的完成超时过期并不一定表明请求或部分请求成功或失败。对于使用相同事务ID的一系列UIO请求，必须为发出的每个UIO请求重新启动完成超时机制。

如果支持PCI Express to PCI/PCI-X桥,配置请求需要的Completions超时有特殊的要求，PCI Express到PCI/PCI-X桥，默认情况下，不启用向桥后的PCI/PCI-X设备返回配置请求的请求重试状态（Request Retry Status， RRS）。这可能导致长时间的完成延迟，必须通过根复合体中的完成超时值来理解。系统软件可以使PCI Express到PCI/PCI-X网桥对配置请求返回RRS，方法是Device Control寄存器中的Bridge Configuration Retry Enable比特,在”PCIe-to-PCI-PCI-X-Bridge”中有更高价严格的说明。

×

感谢您的支持，请扫码打赏