所有章节请对应 NCB-PCI_Express_Base_5.0r1.0-2019-05-22.pdf
概述
事务描述符是一种在Requester和Completer之间携带事务信息的机制。 事务描述符由三个字段组成：
- Transaction ID - 识别未完成的事务
- Attributes字段 - 指定事务特征
- Traffic Class(TC) 字段 - 将事务与所需服务的类型相关联
图1显示了事务描述符的字段。 请注意，这些字段在这里连在一起显示，只是突出它们作为单个逻辑实体的一部分的关系。 实际上这些字段在packet header中是不连续的。
Transaction ID
Transaction ID含两个子字段：Requester ID，Tag。如图2所示：
[PCIe-4.0] 中引入的 10-Bit Tag capability 将总 Tag 字段大小从 8 位增加到 10 位。 两个额外的 Tag 位，Tag[8] (T8) 和 Tag[9] (T9)，与 TLP Header 中的其他 Tag[7:0] 位不连续。 在本规范的先前版本中，这两个位是 Reserved。
-
Tag[9:0] 是每个 Requester 生成的 10 bit 字段，对于该 Requester 需要 Completion 的所有未完成的Requests，它必须唯一。 不支持 10-Bit Tag Requester capability 的 Requesters 必须将 Tag[9:8] 设置为 00b。
- 支持 16.0 GT/s 或更高数据速率的 Function（包括Switches中的）必须支持 10-Bit Tag Completer capability。 如果一个 Function 支持 10-Bit Tag Completer capability，它可以选择支持 10-Bit Tag Requester capability。 请参阅第 7.5.3.15 节和本节后面的“实现 10-Bit Tag Capabilities 的注意事项”。
- 包含指示支持 10-Bit Tag Completer capability 元素的 RC 必须正确处理所有寄存器和作为 PCIe Requesters 的目标所支持的内存区域的 10-Bit Tag Requests；例如，DMA Requests 的目标 host memory 或 RCiEP 中的 MMIO 区域。
- 每个表示支持的 RP 必须处理其 Ingress Port 收到的此类请求。
- 每个表示支持的 RCiEP 必须处理来自支持的内部路径的此类 Requests，包括通过 RP 的请求。
- 如果 RC 包含支持 10-Bit Tag Requester capability 的 RCiEP，则 RC 必须正确处理来自这些 RCiEP 的 10-Bit Tag Requests，所有寄存器和内存区域支持作为这些 RCiEP 的目标； 例如，以 DMA Requests 为目标的 host memory 或 RCiEP 中的 MMIO 区域。
- 无论其 Extended Tag Field Enable 位的设置如何（参见第 7.5.3.4 节），Receivers/Completers 必须正确处理 8-bit Tag 值。 有关 extended tags 的 bridge 处理的详细信息，请参阅 PCI Express to PCI/PCI-X Bridge Specification。
- 无论其 10-Bit Tag Requester Enable 位设置如何，支持 10-Bit Tag Completer capability 的 Receivers/Completers 必须正确处理 10-Bit Tag 值。请参阅第 7.5.3.16 节。
- 10-Bit Tag capability 不适用于 PCI Express to PCI/PCI-X Bridges，它们不得指示 10-Bit Tag Requester capability 或 10-Bit Tag Completer capability。
- 如果 10-Bit Tag Requester Enable bit 是Clear，Extended Tag Field Enable bit 也是Clear，则每个 Function 的未完成 Requests 的最大数量应限制为 32，并且仅使用 Tag 字段的低 5 位，其余高 5 位要求为 0 0000b。
- 如果 10-Bit Tag Requester Enable bit 是Clear，Extended Tag Field Enable bit 是Set，最大值增加到 256，只使用 Tag 字段的低 8 位，其余高 2 位要求为 00b .
- 如果设置了 10-Bit Tag Requester Enable 位，则针对单个 Completer 的最大值增加到 768。Requester 在向其认为合适的 Completers 发送 10-Bit Tag Requests 时，允许使用 Tag 字段的所有 10 位，但 Requester 仍然被允许向其他 Completers 发送更小的 Tag Requests。以下适用于 10-Bit Tag Requester Enable 被Set的支持 10-Bit Tag 的 Requesters。
- 如果 Endpoint 支持向其他 Endpoints 发送 Requests（而不是 host memory），除非特定实现的机制确定 Endpoint 支持 10-Bit Tag Completer capability，Endpoint 不得向另一个给定 Endpoint 发送 10-Bit Tag Requests。对于某些实现，完全不向其他 Endpoint 发送 10-Bit Tag Requests 可能是可以接受的。更复杂的机制超出了本规范的范围。
- 如果 PIO Requester 具有 10-Bit Tag Requester capability，那么 Requester 如何确定何时使用 10-Bit Tags 而不是更小的 Tags 超出了本规范的范围。
- 对于 10-Bit Tags ，有效的 Tag[9:8] 值为 01b、10b 或 11b，Tag[9:8] 等于 00b 是无效的，并且不得由 Requester 生成。这使 Requester 能够确定它收到的应该具有 10-Bit Tag 的 Completion 是否包含无效的完成，这通常是由 Completer 不支持 10-Bit Tag Completer capability引起的。
- 如果 Requester 向缺少 10-Bit Completer capability 的 Completer 发送 10-Bit Tag Request，则返回的 Completion(s) 将具有 Tag[9:8] 等于 00b 的 Tags。由于Requester被禁止为 10-Bit Tags 生成这些 Tag 值，因此此类 Completions 将作为 Unexpected Completions 处理，默认情况下是 Advisory Non-Fatal Errors。Requester必须遵循标准 PCI Express 错误处理要求。
- 当Requester将带有无效 10-Bit Tag 的 Completion 作为 Unexpected Completion 处理时，原始 Request 可能会导致 Completion Timeout。如果请求者以某种特定设备的方式处理 Completion Timeout 条件以避免数据损坏，则允许 Requester 按其他要求不通过标准 PCI Express 错误处理机制处理 Completion Timeout。
- 如果 Requester 支持同时向一些 Completers 发送 10-Bit Tag Requests 和向其他 Completers 发送 smaller-Tag Requests，则 Requester 必须遵守 smaller-Tag Requests 的 Extended Tag Field Enable 位设置。 即如果该位为Clear，则只有Tag字段的低5位可能为非0； 如果该位被Set，则只有 Tag 字段的低 8 位可能是非0的。
- 如果 Requester 支持同时向一些 Completers 发送 10-Bit Tag Requests 和向其他 Completers 发送 smaller-Tag Requests，如果任何 10-Bit Tag Request 由缺少 10-Bit Tag Completer capability 的 Completer 完成，Requester 必须确保没有未完成的 10-Bit Tags 可以别名为未完成的 smaller Tag。请参阅本节后面的“同时使用 10-Bit Tags 和 Smaller Tags”实施说明。
- Extended Tag Field Enable 位的默认值是特定于实现的。10-Bit Tag Requester Enable 位的默认值为 0b。
- 如果多个未完成的 Requests 发出非唯一 Tag 值，则 Receiver/Completer 行为未定义。
- 如果 Phantom Function Numbers 用于扩展未完成请求的数量，则 Phantom Function Numbers 和 Tag 字段的组合对于该 Requester 需要所有未完成 Requests 的Completion 必须是唯一的。
-
对于 Posted Requests, Tag [9:8] 是 Reserved。
-
对于 Set 了 TH 位的 Posted Requests，Tag[7:0] 字段重新用于 ST[7:0] 字段（有关详细信息，请参阅第 2.2.7.1 节）。 对于 TH 位清0的 Posted Requests，Tag[7:0] 字段未定义并且可以包含任何值。 （有关某些此规则例外情况的 Vendor_Defined Messages，请参阅表 F-1）。
- 对于 TH 字段为 Clear 的 Posted Requests，Tag[7:0] 字段中的值不得影响 Receiver 对 Request 的处理。
- 对于 Set 了 TH 位的 Posted Requests，ST[7:0] 字段中的值可能会影响 Request 的 Completer 处理（详见 2.2.7.1）。
-
Requester ID 和 Tag 组合形成一个全局标识符，即 PCIe 层级中每个 Transaction 的Transaction ID。
-
在所有 Requests 和 Completions 中包含Transaction ID。
-
Requester ID 是一个 16 位的值，它在同一个PCIe 层级中的每个 PCIe Function 都是唯一的。
-
Functions 必须捕获与 Function 完成的 Type 0 Configuration Write Requests 一起提供的 Bus 和 Device Number（在 ARI 设备中，Functions 只需捕获 Bus Number。ARI 设备可按 Device 或按 Function 保留捕获的 Bus Number。如果按 Device 保留捕获的 Bus Number，则所有 Functions 都必须更新和使用这个公用的 Bus Number。），并在 Device/Function 发起的所有请求的 Requester ID 的 Bus 和 Device Number 字段中提供这些编号(ARI Requester ID 不含 Device Number)。建议仅为成功完成的请求获取编号。
例外： Bus Number 和 Device Number 分配给 Root Complex 内的设备，以及 Device Numbers 分配给 Switch 内的 Downstream Ports，可按具体实施方式进行。
注意： Bus Number 和 Device Number 可能会在运行时更改(ARI Devices, 只有 Bus Number 会变)，因此有必要在每次 Configuration Write Request 时重新获取这些信息。
建议：Configuration Write Requests 到未实施的 Function 不要影响捕获的 Bus Number 和 Device Number。 -
Switches 代表自己生成请求时（例如，用于错误报告），必须使用与 Port 逻辑关联的 Bridge 初级侧关联的 Request ID（参阅第 7.1 节），以生成请求。
-
在 Function 初始化 Configuration Write 之前，Function 禁止发起 Non-Posted Requests。(需要有效的 Request ID 才能正确路由所产生的完成）。
例外： 允许 Root Complex 内的 Function 在软件初始化配置之前发起请求，以访问系统引导设备。
注意，本规则和例外情况与现有 PCI 系统初始化和配置模型一致。 -
与 Device 相关的每个 Function 都必须设计为响应针对该 Device 的配置请求的唯一 Function Number。
注意：每个非 ARI Device 最多可包含 8 个 Functions。每个 ARI Devices 最多可包含 256 个Functions。 -
Switch 必须在不修改 Transaction ID 的情况下转发请求
-
在某些情况下，PCI Express 至 PCI/PCI-X 桥接器需要为从 PCI 或 PCI-X 总线转发的请求生成 Transaction ID。
实施说明
利用虚拟的 Functions 增加未处理请求数量
为了增加需要完成的未处理请求的最大数量，使其超过仅使用 Tag 位所能达到的数量，如果 Phantom Functions Enable 位被设置（参阅第 7.5.3.4 节）， Device 可以使用未分配给已实施 Function 的 Function Numbers 来逻辑扩展 Tag 标识符。对于单 Function 的 Device，这可使最大未处理请求数增加 8 倍。
无人认领的 Function 编号被称为 Phantom Function Numbers。
Phantom Functions 在结构上有许多限制，包括 ARI Device、Virtual Functions (VF) 和 enable VF 的 Physical Functions (PF) 不支持 Phantom Functions。此外，地址转换服务（ATS）和 ID-Based Ordering（IDO）也不能识别 Phantom Functions。因此，对于许多实施方案来说，使用 10-Bit Tags 是增加 Non-Posted Requests 请求数量的更好方法。实施 10-Bit Tags Function 的注意事项
使用 10-Bit Tags 可使 Requester 将其未处理的 Non-Posted Requests（NPR）数量从 256 个增加到 768 个，从而避免标签可用性成为瓶颈。以下公式给出了有效载荷带宽、未处理 NPR 数量和其他因素之间的基本关系：
BW = S * N / RTT，其中
BW= 有效负载带宽
S = 事务有效载荷大小
N = 未处理的 NPR 数量
RTT = 事务往返时间
一般来说，只有在高速链路上使用相对较小事务的高速请求者才会受益于将其未完成 NPR 的数量增加到 256 个以上，尽管这也有助于在事务往返时间较长的配置中保持性能。
在具有 10-Bit Tag Requester 能力的 Requester 需要针对多个 Completers 的配置中，需要确保 Requester 只向具有 10-Bit Tag Completer 能力的 Completers 发送 10-Bit Tag Requestes。如果所有 Completers 都具备这种能力，就能大大简化这项工作。
为了在整个行业启用 10-Bit Tags，强烈建议所有 Functions 都支持 10-Bit Tag Completer 功能。通过新的实施，不需要同时对更多 NPR 进行操作的 Completers 通常可以在内部跟踪 10-Bit Tags，并在 Completions 中返回这些标签，只需少量的增量投资。
实际并发处理更多 NPR 的Completer 可能需要大量额外硬件资源，但除非 Completer 实际并发处理更多 NPR，否则一般无法实现 10-Bit Tag 的全部性能优势。
对于 RC 支持 10-Bit Tag Completer 功能的平台，强烈建议配置 PCIe 层次结构的平台固件或操作软件在具有 10-Bit Tag Requester 功能的端点中自动设置 10-Bit Tag Requester Enable 位。这将启用仅向主机内存发送 Memory Read Requests 的 10-Bit Tag 适配器这一重要类别。
对于 RCiEP 以外的端点，可以通过检查其关联 RP 中的 10-Bit Tag Completer 支持位来确定每个 RC 是否支持 10-Bit Tag Completer 功能。RCiEP 没有关联的 RP，因此，除非 RC 支持 10-Bit Tag Completer 功能，否则不允许设置其 10-Bit Tag Requester Supported 位。因此，软件无需对 RCiEP 执行单独检查。
没有 10-Bit Tag Completer 功能的 Switches 仍能正确转发携带 10-Bit Tags 的 NPR 和 Completion，因为这两个新标签位位于以前保留的 TLP Header 中，但是 Switch 必须不加修改地转发 Reserved TLP Header。但是，如果 Switch 检测到携带 10-Bit Tags 的 NPR 发生错误，而 Switch 作为 NPR 的完成者处理了该错误，则由此产生的完成将带有无效的 10-Bit Tags 。因此，强烈建议使用 10-Bit Tags 的组件之间的 Switchs 支持 10-Bit Tag Completer 功能。注意，支持 16.0 GT/s 或更高数据速率的 Switch 必须支持 10-Bit Tag Completer 功能。
对于具有 10-Bit Tag Requester 能力的 Requester 以 Completers 为目标的配置，其中有些 Completers 具有 10-Bit Tag Completer 能力，有些不具有 10-Bit Tag Completer 能力，Requester 如何确定哪些 NPR 包括 10-Bit Tags 不属于本规范的范围。使用 10-Bit Tags 兼容 更小的 Tags
如本节前文所述，如果 Requester 支持同时向某些 Completers 发送 10-Bit Tag Request 和向其他Completers 发送较小 Tag 请求，则 Requester 必须确保，如果任何 10-Bit Tag Request 由缺乏 10-Bit Tag Completer 能力的 Completers 完成，则任何未完成的 10-Bit Tags 都不能别名为未完成的较小Tags。
一种实现方法是让 Requester 将其 8-bit Tag 空间划分为两个区域：一个区域只用于较小的 Tag（8 位或 5 位 tags），另一个区域只用于 10-Bit Tags 的较低 8 位。注意，这需要在 10-Bit Tags 和较小 Tags 的可用 tags 空间之间做出权衡。
例如，如果 Requester 将其 8-bit Tag 空间划分为只使用最低 4 位的较小Tags，则最多可支持 16 个未处理的较小Tags，并将 10-Bit Tag 空间减少 316 个值，从而支持 768-48=720 个未处理的 10-Bit Tag。还可以有许多其他分区选项，所有这些选项都能减少未处理请求的总数。一般来说，为较小 Tags 保留 N 个值会使 10-Bit Tag 空间减少 3N 个值，较小Tags 加上 10-Bit Tags 的总和最终为 768 - 2*N。
Attributes 字段
Attributes 字段用于提供附加信息，以便修改事务的默认处理方式。这些修改适用于系统内事务处理的不同方面，如
- Ordering（排序）
- 硬件一致性管理（Snoop）
灵活排序 和 ID排序
定义了灵活排序（Relaxed Ordering）和基于ID排序（ID-Based Ordering）属性字段的状态。注意，灵活排序和基于ID排序属性的位置并不相邻。
| Attribute Bit [2] | Attribute Bit [1] | Ordering Type | Ordering Model |
|---|---|---|---|
| 0 | 0 | Default Ordering | PCI Strongly Ordered Model |
| 0 | 1 | Relaxed Ordering | PCI-X Relaxed Ordering Model |
| 1 | 0 | ID-Based Ordering | Independent ordering based on Requester/Completer ID |
| 1 | 1 | Relaxed Ordering plus ID-Based Ordering | Logical “OR” of Relaxed Ordering and IDO |
Attribute bit [1] 不适用于 Configuration Requests, I/O Requests, 消息信号中断的 Memory Requests, 和 Message Requests（特别允许的情况除外），必须清零。
Attribute bit [2]，IDO，对 Configuration Requests 和 I/O Requests 保留。IDO 对所有 Memory Requests，包括消息信号中断 (MSI/MSI-X)， 都不是保留字段。除非特别禁止，否则 IDO在 Message Requests不是保留字段。只有当 Device Control 2 寄存器中的 IDO Request Enable 位被设置时，才允许 Requester 设置 IDO。
接收者在确定 TLP 是否为 Malformed Packet 时，不考虑 IDO 位的值。
只有当 Device Control 2 寄存器中的 IDO Completion Enable 位被设置时，才允许 Completer 设置 IDO。Completer 无需将 IDO 值从 Request 复制到该 Request 的 Completion(s) 中。如果 Completer 已启用 IDO，建议 Completer 为所有完成设置 IDO，除非有特殊原因（参见附录 E）。
支持在 Root Complex 之间点对点转发 TLP 的 Root Ports 无需保留从入口端口到出口端口的 IDO 位。
入口端口：接受入站流量的接收端口
出口端口：发送出站流量的传递端口
No Snoop 属性
表 2 定义了 No Snoop 属性字段，No Snoop 属性不改变事务排序。
| No Snoop Attribute (b) | 缓存一致性管理类型 | 一致性模型 |
|---|---|---|
| 0 | Default | 预期硬件强制缓存一致性 |
| 1 | No Snoop | 不预期硬件强制缓存一致性 |
该属性不适用于 Configuration Requests、 I/O Requests、属于消息信号中断的 Memory Requests 和 Message Requests（特别允许的情况除外），且必须清为0。
Traffic Class 字段
流量类别 (Traffic Class，TC) 是一个 3 位字段，可将事务区分为 8 个流量类别。
与 PCIe 虚拟通道支持一起，TC 机制是实现差异化流量服务的基本要素。每个 PCIe Transaction Layer Packet 都使用 TC 信息作为不变标签，在 PCIe结构中端到端传输。当数据包在结构中穿行时，每个链路和每个交换机元件都会使用该信息，以做出适当的流量服务决策。服务的一个关键方面是根据数据包的 TC 标签，通过相应的虚拟通道对数据包进行路由。后面会详细介绍虚拟通道机制。
表3 定义了 TC 编码:
| TC Field Value(b) | 定义 |
|---|---|
| 000 | TC0： 尽最大努力服务类型（通用 I/O）（默认 TC - 每个 PCI Express 设备都必须支持） |
| 001 到 111 | TC1 至 TC7： 差异化服务等级(基于加权轮循 (WRR) 和/或优先级的区分） |
系统软件负责确定 TC 标签和 TC/VC 映射，以提供符合目标平台要求的差异化服务。
流量类别的概念仅适用于 PCI Express 互连结构。
扫一扫
25
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
