【NVMe2.0b 8】NVMe 队列仲裁机制

3.4命令Submission和Completion机制

本节介绍命令发出和完成的机制。它还描述了主机软件如何构建命令和命令完成处理。

只有在控制器状态属性 (CSTS.RDY) 中指示的控制器准备就绪并且已创建适当的 I/O Submission Queue(s) 和 I/O Completion Queue(s) 之后，主机才应提交命令。

3.4.1命令排序要求

不属于fused操作的命令（请参阅第 3.4.2) 节）并且符合atomic操作要求（请参阅第 3.4.3 节）作为独立条目处理，而不参考提交给同一 I/O Submission Queue或提交到其他 I/O Submission Queues 的命令。例如，控制器不负责检查 NVM Command Set Read或 Write 命令的 LBA 以确保命令之间的任何类型的排序。如果为 LBA x 提交了Read，并且还为 LBA x 提交了Write，则无法保证这些命令的完成顺序（Read可能先完成或Write可能先完成）。如果这些命令之间存在排序要求，则需要主机软件或相关应用程序来强制执行高于控制器级别的排序。

3.4.2Fused Operations

Fused操作通过将两个更简单的命令“融合”在一起来实现更复杂的命令。此feature是可选的；Figure 275 中的 Identify Controller data structure 中的 FUSES 字段中指示了对该feature的支持。在fused操作中，有如下要求：

• 命令应作为一个原子单元按顺序执行。控制器的行为就像在这两个命令之间没有执行其他操作一样；
• 操作在任一命令中遇到错误时结束。如果序列中的第一个命令失败，则序列中的第二个命令将被中止。如果序列中的第二个命令失败，则第一个命令的完成状态是特定于序列的，并在适用的 I/O Command Set规范的Fused Operation部分中定义；
• 命令应在同一个Submission Queue中彼此相邻插入。如果第一个命令在Submission Queue的最后一个槽中，那么第二个命令应该是Submission Queue中的第一个槽，作为环绕的一部分。在基于内存的传输队列模型中，Submission Queue Tail门铃指针更新应将两个命令指示为一个门铃更新的一部分。在基于消息的传输队列模型中，命令封装应按顺序提交。
• 要中止fused操作，主机应为每个命令分别提交一个Abort命令；
• 控制器为每个命令发布一个完成队列条目。

命令是否是fused操作的一部分在Figure 86 所示的命令 Dword 0 的 Fused Operation(FUSE) 字段中指示。FUSE 字段还指示每个命令是fused操作中的第一个命令还是第二个命令。如果 FUSE 字段设置为非0值并且控制器不支持请求的fused操作，则控制器应使用 Invalid Field in Command 状态码中止命令。

有关适用性和其他详细信息（如果有），请参阅每个 I/O Command Set 规范。

3.4.3Atomic Operations

原子操作的定义是特定于命令集的。有关适用性和其他详细信息（如果有），请参阅每个 I/O Command Set 规范。

3.4.4Command Arbitration

将命令提交给控制器后（请参阅第 1.5.13 节），控制器将提交的命令传输到控制器，以使用供应商特定的算法进行后续处理。

当命令正在访问或修改控制器和/或命名空间状态时正在处理命令（例如，正在访问或修改Feature设置或正在访问或修改逻辑块）。

当命令的完成队列条目已发布到相应的完成队列时，命令完成。完成后，该命令所做的所有控制器状态和/或命名空间状态修改对所有随后提交的命令都是全局可见的。

候选命令是一个已提交的命令，该命令已被传送到控制器认为已准备好进行处理的控制器。控制器从每个 Submission Queue 的提交命令池中选择要处理的命令。组成fused操作的命令应由控制器按顺序一起处理。控制器可以选择候选命令以任何顺序进行处理。选择命令进行处理的顺序并不意味着命令完成的顺序。

仲裁是用于确定控制器开始处理下一个候选命令的提交队列的方法。一旦使用仲裁选择了Submission Queue，仲裁突发设置将确定控制器在再次进行仲裁之前可以从该Submission Queue开始处理的命令的最大数量。一个fused操作可以被认为是控制器的一个或两个命令。

所有控制器都应支持轮询命令仲裁机制。控制器可以可选地实现具有紧急优先级等级和/或供应商特定仲裁机制的加权循环。Controller Capabilities 属性 (CC.AMS) 中的 Arbitration Mechanism Supported 字段表示控制器支持的可选仲裁机制。

为了有效利用非易失性存储器，并行执行来自Submission Queue的多个命令通常是有利的。对于使用具有紧急优先级等级的加权轮询或轮询仲裁的 Submission Queues，主机软件可以配置Arbitration Burst设置。Arbitration Burst设置指示控制器可以从特定Submission Queue一次启动的最大命令数。考虑到延迟要求，建议主机软件将Arbitration Burst设置配置为尽可能接近控制器的推荐值（在Figure 275 中Identify Controller data structure 的Recommended Arbitration Burst字段中指定）。请参阅第 5.27.1.1 节。

3.4.4.1Round Robin Arbitration(轮询仲裁)

如果选择了轮询仲裁机制，控制器应在所有Submission Queues（包括 Admin Submission Queue）之间执行轮询命令仲裁。在这种情况下，所有 Admin Submission Queue 都被同等优先处理。控制器可以根据 Arbitration Burst 设置从每轮的每个Submission Queue 中选择多个候选命令进行处理。

Figure 100: Round Robin Arbitration

3.4.4.2Weighted Round Robin with Urgent Priority Class Arbitration（带紧急优先级的加权轮询仲裁）

在这种仲裁机制中，存在三个严格优先级和三个加权循环优先级。如果 Submission Queue A 的严格优先级高于 Submission Queue B，则 Submission Queue A 中的所有候选命令应在 Submission Queue B 中的候选命令开始处理之前开始处理。

最高严格优先级是 Admin 类，它包括提交给 Admin Submission Queue 的任何命令。此类在提交到任何其他Submission Queue的命令相比，具有最高的严格优先级。

次高的严格优先级是Urgent类。任何分配给Urgent优先级的 I/O Submission Queue都会在命令提交到Admin Submission Queue之后，并且在任何命令提交到加权轮询优先级之前得到服务。主机软件在将任何Submission Queue分配给Urgent优先级时应小心，因为在加权轮询优先级中存在使 I/O Submission Queues“饿死”的可能性，因为在Urgent和非Urgent I/O Submission Queues之间没有公平协议. 最低严格优先级是加权轮询（Weighted Round Robin）类。此类由三个加权轮询优先级（High、Medium和Low）组成，它们使用加权轮询仲裁共享剩余带宽。主机软件通过Set Features命令控制高、中和低服务类别的权重。轮询法用于在分配给相同加权轮询级别的多个 Submission Queues 中进行仲裁。每轮可以从每个 Submission Queue 开始处理的候选命令的数量是 Arbitration Burst 设置或剩余加权轮询积分，以较小者为准。

Figure 101: Weighted Round Robin with Urgent Priority Class Arbitration

3.4.4.3供应商特定的仲裁方式

供应商可以选择实施特定于供应商的仲裁机制。他们机制不在本规范的范围。