NVM 控制器架构模型
控制器是主机和 NVM 子系统之间的接口。
3.1.1控制器模型
本规范定义了两种控制器模型。NVM 子系统可以支持静态或动态控制器模型。NVM 子系统中的所有控制器都应遵循相同的控制器模型。
在静态控制器模型中，可能分配给特定主机的控制器在建立关联时可能具有不同的状态。NVM 子系统中的控制器通过它们的controller id 来区分。所有基于内存的传输模型控制器都应支持静态控制器模型。
在动态控制器模型中，控制器由 NVM 子系统按需分配。在此模型中，分配给特定主机的所有控制器在建立关联时都具有相同的状态，包括附加的命名空间和Features设置。建立关联后对控制器的更改（例如，附加的命名空间、功能设置）不会影响其他动态控制器。
在 NVM 子系统中使用基于消息的传输模型的控制器可以使用动态或静态控制器模型。Discovery 控制器应支持动态控制器模型。
当主机使用 Fabrics Connect 命令连接到控制器的Admin Queue时，主机和控制器之间会建立关联（请参阅第 6.3 节）。在 Connect 命令中，主机指定 Host NQN、Host Identifier、NVM Subsystem NQN，并且可以请求特定的Controller ID 或可以请求与任何可用控制器的连接。控制器一次只有一个关联。
在动态控制器模型中，控制器由 NVM 子系统按需分配，不保留先前关联的状态（例如，Features设置）。在静态控制器模型中，主机可以根据Controller ID 请求特定控制器，其中状态（例如，功能设置）从先前的关联中保留。
虽然主机和控制器之间存在关联，但只有该主机可以通过在后续Connect命令中使用相同的Host NQN、Host Identifier、NVM Subsystem NQN 和Controller ID 来建立与该控制器的 I/O 队列的链接相同的 NVM 子系统端口、NVMe Transport类型和 NVMe Transport地址。
主机和控制器之间的关联在以下情况下终止：
-
如第 3.6.2 节所述，控制器已关闭；
-
发生 Controller Level Reset；
-
Admin Queue 或任何 I/O Queue 的主机和控制器之间的 NVMe Transport连接丢失；或
-
对于任何 I/O 队列，主机和控制器之间的 NVMe Transport连接丢失，并且主机或控制器不支持单独的 I/O 队列删除（请参阅第 3.3.2.4 节）。
没有明确的 NVMe 命令会破坏主机和控制器之间的 NVMe Transport关联。Disconnect 命令（请参阅第 6.3 节）提供了一种删除 NVMe I/O 队列的方法（请参阅第 3.3.2.4 节）。当控制器与主机关联时，该控制器正忙，并且不能与该控制器建立其他关联。 要使用动态控制器模型，主机应在使用 Fabrics Connect 命令（参见第 6.3 节）建立与 NVM 子系统的关联时指定 controller identifier FFFFh。
将静态控制器模型与 Fabric 连接的控制器一起使用时，跨关联持续存在的状态是跨 Controller Level Rese 持续存在的任何状态。此外，不同的控制器可能会向同一主机呈现不同的Feature设置或命名空间附加。NVM 子系统可以将特定的控制器分配给特定的主机。
虽然预计将静态控制器分配给主机是持久的（以便主机可以期望重复地形成与相同控制器关联（例如，在每次主机重新启动之后）），NVM 子系统可能会出于实现特定的原因（例如，控制器资源回收、子系统重新配置）删除主机分配的在任何时候未使用的控制器。
3.1.2Controller Types
如 Figure 20 所示，控制器分为三种类型。I/O 控制器（请参阅第 3.1.2.1 节）是一种控制器，它支持提供对存储在 NVM 子系统的非易失性存储介质上的用户数据的访问权限的命令，并且可能支持提供管理功能的命令。管理An Administrative 控制器（请参阅第 3.1.2.2 节）是一种控制器，它支持提供管理功能的命令，但不支持访问存储在 NVM 子系统的非易失性存储介质上的用户数据的 I/O 命令。Discovery 控制器（请参阅第 3.1.2.3 节）是 NVMe over Fabrics 中用于提供对 Discovery Log Page 的访问的控制器。
Identify Controller data structure中的Controller Type (CNTRLTYPE) 字段指示控制器的类型。无论控制器类型如何，所有控制器都实现一个Admin Submission Queue 和一个 Admin Completion Queue。根据控制器类型，控制器还可能支持一个或多个 I/O Submission Queues和 I/O Completion Queues。
当使用基于内存的传输实现（例如 PCIe）时，主机软件通过预先分配的 Submission Queues 向控制器提交命令。控制器通过 SQ Tail Doorbell 寄存器写入收到新提交的命令的警报。先前的门铃寄存器值与当前寄存器写入的差值表示已提交的命令数。 控制器从 Submission Queue(s) 中获取命令并处理它们。除了fused操作之外，在提交队列内或跨提交队列处理命令没有顺序限制。主机软件不应将命令提交到不能任意重新排序的提交队列。与命令处理相关的数据可能不按照提交命令的顺序提交到 NVM 子系统非易失性存储器存储介质。
主机软件将更高优先级的命令提交到相应的 Submission Queues。优先级与提交队列本身相关联，因此命令的优先级基于该命令被提交到的Submission Queue。控制器根据第 3.4.4 节中指定的仲裁方案基于公平性和优先级对 Submission Queues 进行仲裁。
在 NVM 子系统完成命令执行后，控制器通过适当的 Completion Queues 将完成队列条目呈现给主机。特定Transport方法（例如，PCIe 中断）用于通知主机完成队列条目要处理（请参阅适当的Transport 规范）。例如，如果正在使用 MSI-X 或多消息 MSI（请参阅 NVMe over PCIe Transport Specification 的中断部分），则中断向量指示完成队列，其中包含可能的新命令完成供主机处理。如果使用基于引脚的中断或单消息 MSI 中断，主机软件会询问完成队列 Completion Queue(s) 以获取新的完成队列条目。主机更新 CQ Head 门铃寄存器以向控制器释放完成队列条目并清除相关中断。
对主机的完成没有排序限制。每个完成队列条目标识相关命令的 Submission Queue Identifier 和 Command Identifier。主机软件使用此信息将完成与提交到 Submission Queue(s) 的命令相关联。
主机软件负责使用这些队列，在向控制器提交命令之前创建 I/O Submission Queues 和 I/O Completion Queues。I/O Submission Queues和 I/O Completion Queues是使用Create I/O Submission Queue（参见第 5.5 节）和 Create I/O Completion Queue命令（参见第 5.4 节）创建的。
3.1.2.1I/O Controller
I/O 控制器，支持使用 I/O 命令集提供对存储在 NVM 子系统的非易失性存储介质上的用户数据的访问的命令，并且可以支持提供管理功能的命令。
一个 I/O 控制器可以同时支持多个 I/O Command Sets。控制器支持的 I/O Command Sets和控制器同时支持的 I/O Command Sets在 Identify I/O Command Set data structure 中报告（请参阅第 5.17.2.21 节）。Identify I/O Command Set data structure 的内容不需要对于 NVM 子系统中的所有控制器都相同。
Figure 21 显示了具有三个 I/O 控制器的 NVM 子系统。I/O 控制器1有两个附加命名空间，私有命名空间 A 和共享命名空间 B。I/O 控制器2也有两个附加命名空间，私有命名空间 C 和共享命名空间 B。I/O 控制器3没有附加命名空间。在稍后的某个时间点，共享命名空间 B 可能会附加到 I/O 控制器3。
3.1.2.1.1Command Support
Figure 22 和Figure 23 定义了 I/O 控制器的强制、可选和禁止命令。I/O Command Set中特定的命令支持要求在各个 I/O Command Set 规范中进行了描述。
3.1.2.1.2Log Page Support
Figure 24 定义了 I/O 控制器的强制、可选和禁止的log pages。I/O Command Set特定的 log page支持情况要求在各个 I/O Command Set 规范中进行描述。
3.1.2.1.3Features Support
Figure 25 定义了 I/O 控制器的强制、可选和禁止的features。I/O Command Set特定Feature支持情况要求在各个 I/O Command Set规范中进行描述。
3.1.2.2Administrative Controller
Administrative控制器是旨在提供 NVM 子系统管理功能的控制器。虽然 I/O 控制器可能支持这些相同的管理功能，但Administrative控制器有更少的强制功能。与 I/O 控制器不同，Administrative控制器不支持访问存储在 NVM 子系统的非易失性存储介质上的user data的 I/O 命令。NVMe Transports可能支持传输特定机制，以允许Administrative控制器加载专用 NVMe 管理驱动程序而不是通用 NVMe 驱动程序（有关详细信息，请参阅适用的 NVMe Transport binding 规范）。
Administrative控制器可能支持的管理能力示例包括以下内容：
-
能够使用 NVMe-MI Send 和 NVMe-MI Receive 命令通过 NVMe-MI 有效轮询 NVM 子系统健康状态（请参阅 NVMe Management Interface 规范中的 NVM Subsystem Health Status Poll部分）；
-
能够使用 NVMe-MI Send 和 NVMe-MI Receive 命令通过 NVMe-MI 管理 NVMe 机箱；
-
能够使用 Namespace Attachment 和Namespace Management命令管理 NVM 子系统命名空间；
-
能够使用Virtualization Management命令执行虚拟化管理；且
-
如果支持，可以使用 NVM Subsystem Reset(NSSR) 寄存器重置整个 NVM 子系统。
-
能够使用 NVM Subsystem Shutdown(NSSD) 属性关闭整个 NVM 子系统。
Administrative 控制器不应支持 I/O 队列，命名空间不应 attach 到 Administrative 控制器。
需要一个Administrative控制器来支持Figure 28中列出的强制性Admin命令。一个Figure 28控制器可以支持一个或多个 I/O Command。当Figure 28控制器支持 I/O Command Set时，可能仅支持 I/O Command Set中特定的Admin命令，因为Figure 28控制器只有一个Admin Queue而没有 I/O Queues。
Figure 26 显示了一个 NVM 子系统，其中一个Administrative控制器和两个 I/O 控制器位于一个 NVM 子系统中，该 NVM 子系统包含一个非易失性存储介质和命名空间。I/O 控制器 1 有两个附加名称空间：私有名称空间 A 和共享名称空间 B。I/O 控制器 2 也有两个附加名称空间：私有名称空间 C 和共享名称空间 B。由于Administrative控制器不提供对存储在NVM 子系统的非易失性存储介质，故没有附加上去命名空间。此示例中的Administrative控制器可用于诸如 NVM 子系统命名空间管理和通过 NVMe-MI 有效轮询 NVM 子系统健康状态等任务。虽然此示例显示了单个Administrative控制器，但 NVM 子系统可能支持零个或多个Administrative控制器。
Figure 27 显示了一个 NVM 子系统，其中一个 NVM 子系统中包含一个Administrative控制器，该 NVM 子系统不包含非易失性存储介质或命名空间。此示例中的Administrative控制器可用于使用 NVMe-MI 管理 NVMe 机箱。由于Administrative控制器用于非常特定的专用目的，因此此类Administrative控制器的实施者可以选择仅实施强制功能以及 NVMe-MI Send和 NVMe-MI Receive命令。
3.1.2.2.1Command Support
Figure 28 定义了对Administrative控制器来说是强制的、可选的和禁止的命令。由于Administrative控制器不支持 I/O 队列，因此不支持非Admin命令的 NVM Command Set。主机可以利用 Commands Supported and Effects log page 来确定Administrative控制器支持的可选命令。
3.1.2.2.2Log Page Support
Figure 29 定义了对Administrative控制器来说是强制的、可选的和禁止的log pages。
3.1.2.3Discovery Controller
Discovery 控制器仅实现与 Discovery Log Pages 相关的功能，不实现 I/O 队列、I/O 命令或公开命名空间。Discovery 控制器支持的功能在第 3.1.2.3.4 节中定义。
主机在Connect命令（请参阅第 6.3 节）中使用众所周知的Discovery Service NQN(nqn.2014-08.org.nvmexpress.discovery) 到Discovery Service。主机用于获取连接到众所周知的Discovery Service所需的 NVMe Transport信息的方法是特定实现的。 Discovery 控制器提供的 Discovery Log Page 包含一个或多个条目。每个条目指定主机连接到 NVM 子系统所需的信息。条目可能与公开命名空间的 NVM 子系统相关联，或者与另一个Discovery Service的引用相关联。Discovery Log Page中的log page entries没有排序要求。
Discovery控制器可能会根据提供的Host NQN 提供不同的log page内容（例如，不同的主机可以访问不同的 NVM 子系统）。Discovery Log Page Entries集应包括与Discovery Service相同的fabric上的所有适用地址，并且可能包括其他fabric上的地址。 支持显式持久连接的Discovery控制器应Asynchronous Event Request和Keep Alive命令（分别参见第 5.2 节和第 5.18 节）。主机通过在 Connect 命令中指定一个非零的 Keep Alive Timer 值来请求与 Discovery 控制器的显式持久连接和来自该持久连接上的 Discovery 控制器的 Asynchronous Event Notifications。如果 Connect 命令指定了非零的 Keep Alive Timer 值并且发现控制器不支持 Asynchronous Events，则Discovery控制器应为 Connect 命令返回 Connect Invalid Parameters 的状态值（参见Figure 383）。Discovery控制器应在 Identify Controller Data Structure中指示对 Discovery Log Change Notifications 的支持（参见Figure 275）。
不支持显式持久连接的发现控制器不应支持 Keep Alive 命令，并且可以使用固定的Discovery控制器活动超时值（例如，2 分钟）。如果该Discovery控制器在该时间段内没有收到任何命令，则控制器可以执行第 3.9 节中定义的 Keep Alive Timer 到期的动作。
Discovery 控制器不应支持 Disconnect 命令。
具有相同 NVM 子系统的多个 Discovery Log Page Entries 的 Discovery Log Page 表明 NVM 子系统有多个fabric路径，和/或多个静态控制器可能共享一个fabric路径。主机可以使用此信息与 NVM 子系统内的控制器形成多个关联。
具有不同Port ID 值的同一 NVM 子系统的多个 Discovery Log Page Entries 表明生成的 NVMe Transport 连接独立于 NVM 子系统端口硬件故障。使用单个关联的主机应选择一条记录以附加到 NVM 子系统。使用多个关联的主机应该选择不同的端口。 可能存在一种特定传输的方法来指示对Discovery控制器的更改。
Discovery Log Page Entries中返回的Controller ID 值指示 NVM 子系统是否支持动态或静态控制器模型。FFFFh 的Controller ID 值是用于支持动态控制器模型的 NVM 子系统的特殊值，指示可以返回任何可用的控制器。FFFEh 的Controller ID 值是用于支持静态控制器模型的 NVM 子系统的特殊值，表示可以返回任何可用的控制器。如果 Discovery Log Page Entries 使用Controller ID 值 FFFFh，则 NVM 子系统支持动态控制器模型。如果 Discovery Log Page Entries 使用的Controller ID 值小于 FFFFh，则 NVM 子系统支持静态控制器模型。Identify Controller data structure 还指示 NVM 子系统是动态的还是静态的。
如果 NVM 子系统实现动态控制器模型，则可以在 Discovery Log Page 中为该 NVM 子系统返回多个Controller ID 设为 FFFFh 的 Discovery Log Page Entries（参见Figure 264）（例如，指示多个 NVM 子系统端口）。如果 NVM 子系统实现静态控制器模型，则可以在Discovery Lo g Page中为该 NVM 子系统返回指示不同Controller ID 值的多个Discovery Log Page Entries。如果实现静态控制器模型的 NVM 子系统包括任何指示Controller ID 为 FFFEh 的 Discovery Log Page Entries，则主机应记住从 Fabrics Connect 命令返回的Controller ID，并重新使用分配的Controller ID 以用于将来的关联那个特定的控制器。
3.1.2.3.1Discovery Controller Initialization
Figure 31 描述了 Discovery 控制器的初始化过程。
Notes:
- 参见第 6.3 节；
- 参考 5.2 节的异步事件请求命令；
- 参考 5.18节的Keep Alive命令；
- 请参阅本节中的以下步骤。
Connect Command以Successful Completion状态完成后，主机执行以下步骤：
-
如果需要，进行NVMe认证（参考8.13.2节）；
-
主机通过读取Controller Capabilities属性来判断控制器的capabilities；
-
主机通过写入Controller Configuration属性来配置控制器的设置，包括将CC.EN设置为’1’以enable命令处理；
-
主机等待控制器指示控制器准备好处理命令。当Controller Status属性中的 CSTS.RDY 设置为"1"时，控制器已准备好处理命令；和
-
主机通过发Identify命令确定控制器的features和capabilities，指定每个适用的控制器数据结构。
初始化 Discovery 控制器后，主机读取 Discovery Log Page。请参阅第 5.16.1.21 节。
3.1.2.3.2Command Support
Discovery 控制器支持所有强制的 Fabrics 命令，Discovery 控制器支持Figure 32中所示的 Admin 命令子集。
3.1.2.3.3Log Page Support
Discovery控制器应支持Discovery Log Page。Discovery 控制器可能支持的log pages如Figure 33所示。
3.1.2.3.4Features Support
这些features表示 Discovery 控制器的属性（参见Figure 34）。这是系统正常行为不需要的可选信息（参见Figure 316）。
3.1.2.3.4.1Asynchronous Event Configuration (Feature Identifier 0Bh), (Optional)
支持 Asynchronous Event Notifications 的Discovery控制器应实现 Get Features 和 Set Features 命令。如果在发送到该控制器的 Connect 命令（参见第 6.3 节）中接收到 Keep Alive Timeou(KATO) 值，则Discovery控制器应enable Asynchronous Discovery Log Event Notifications。
Figure 326 定义了Discovery controller Asynchronous Event Notifications。
3.1.2.3.4.2Discovery Controller Asynchronous Event Information – Requests and Notifications
如果Discovery控制器检测到主机已请求通知的事件，则控制器应发送一个 Asynchronous Event，其中包含：
-
Asynchronous Event Type 字段设为Notice（即，2h）；
-
Log Page Identifier 字段设为 Discovery（即 70h）；和
-
Figure 146 中定义的 Asynchronous Event Information 字段集。
当Discovery控制器更新 Discovery Log Page(s) 时，Discovery控制器应向已请求此类异步事件通知的每个主机发送 Discovery Log Page Change Asynchronous Event（Asynchronous Event Information F0h）（参见Figure 146）。
扫一扫
1503
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
