队列模型 - 📘 一、命令仲裁（Command Arbitration） (第117页)
继续深入分析 NVM Express® Base Specification, revision 2.0b 第 106 页，本页主要讨论了 命令仲裁（Command Arbitration） 机制，以及如何使用不同的仲裁方法来选择控制器处理命令的顺序。
📘 一、命令仲裁（Command Arbitration）
✅ 命令处理流程
- 命令提交：命令提交到控制器后，控制器使用供应商特定的算法将命令转移到内部处理。
- 命令处理：当命令涉及访问或修改控制器和/或命名空间状态时，命令就开始处理。例如，读取或写入特定的逻辑块，或更改某个特性的设置。
- 命令完成：命令完成时，控制器会将一个完成队列条目（Completion Queue Entry）发布到对应的完成队列中，表示命令的处理已经结束。
注释：命令的状态修改（如命名空间的元数据或控制器状态的更改）在命令完成后对后续提交的命令可见。
✅ 候选命令与处理顺序
- 候选命令：是指已经提交并转移到控制器、且控制器认为可以开始处理的命令。控制器从提交队列中选择候选命令进行处理。
- 处理顺序：命令的选择顺序并不意味着命令的完成顺序。即使命令是按照特定顺序选择进行处理的，它们的完成顺序仍然可能不同，特别是当命令之间没有依赖关系时。
✅ 仲裁机制
-
仲裁：决定了控制器从哪个提交队列开始处理下一个候选命令。一旦选择了一个提交队列，仲裁突发（Arbitration Burst） 设置决定了控制器在重新进行仲裁之前，可以从该提交队列中启动多少个命令的处理。
-
控制器支持的仲裁机制：
- 轮询仲裁（Round Robin Arbitration）：所有提交队列平等地被轮流处理，控制器每次从每个提交队列中选择一个命令进行处理。
- 加权轮询仲裁（Weighted Round Robin）：这是一种可选机制，允许对不同队列设置不同的优先级，某些队列可能在轮询时被赋予更高的优先级。
- 紧急优先级类（Urgent Priority Class）：如果支持加权轮询机制，控制器可以在某些命令上设置紧急优先级，确保紧急命令被优先处理。
- 供应商特定仲裁机制：控制器还可以实现特定于供应商的仲裁策略，具体取决于控制器的实现。
📘 二、轮询仲裁（Round Robin Arbitration）
✅ 轮询仲裁机制
-
轮询仲裁：当选择了轮询仲裁机制时，控制器在所有提交队列之间进行轮流处理，包括管理提交队列（Admin Submission Queue）。在每一轮中，控制器从每个提交队列中选择多个候选命令进行处理，具体数量由 仲裁突发 设置决定。
-
处理过程：控制器可以根据仲裁突发设置，从每个提交队列中同时启动多个命令的处理。
✅ 轮询仲裁的图示
在轮询仲裁机制下，控制器通过 ASQ（Admin Submission Queue） 和多个 I/O 提交队列（SQ） 进行轮流选择。控制器在每一轮中从所有队列中选择命令进行处理，并通过 RR（Round Robin） 标记表示轮询的过程。
📘 三、仲裁突发设置（Arbitration Burst）
✅ 仲裁突发设置
-
作用：仲裁突发设置表示控制器在一次轮询中可以从某个提交队列中启动的最大命令数。这个设置可以通过 主机软件 配置，以优化控制器的性能和延迟。
-
配置建议：建议主机软件根据控制器的推荐值配置仲裁突发设置，这个推荐值可以通过 Identify Controller 数据结构中的 Recommended Arbitration Burst 字段获取。
注释：仲裁突发设置的合理配置可以最大限度地提高控制器的处理效率，尤其是在多核 CPU 或多线程环境下。
🧠 总结与核心要点
| 要素 | 说明 |
|---|---|
| 命令处理流程 | 命令提交到控制器后，控制器开始处理并修改相关状态，最终通过完成队列指示命令完成。 |
| 候选命令与处理顺序 | 控制器从提交队列中选择候选命令进行处理，但命令的选择顺序与完成顺序无关。 |
| 仲裁机制 | 控制器使用 轮询仲裁、加权轮询仲裁 和 供应商特定仲裁机制 来选择命令的处理顺序。 |
| 仲裁突发设置 | 控制器可以在一次轮询中处理多个命令，仲裁突发设置决定了每次处理的最大命令数。 |
这些内容帮助我们理解 命令仲裁 和 命令处理顺序，并指导如何优化 提交队列的调度 和 控制器性能，尤其是在多线程和多核处理器环境中。
如果你有任何关于仲裁机制、队列管理或配置优化的疑问，随时告诉我！