2操作理论

NVM Express 可扩展接口旨在满足使用基于 PCI Express 的固态驱动器或光纤连接设备的存储系统的需求。该接口提供了优化的命令提交和完成路径。它通过支持多达 65,535 个 I/O 队列和每个 I/O 队列多达 64 Ki - 1 个未完成的命令来支持并行操作。此外，还添加了对许多企业级功能的支持，例如端到端数据保护（兼容SCSI 保护信息，通常称为 T10 DIF 和 SNIA DIX 标准）、增强的错误报告和虚拟化。

该接口具有以下关键属性：

不需要在命令提交或完成路径中读取不可缓存/MMIO 寄存器；
命令提交路径最多需要1个MMIO寄存器写入或1个64B消息；
支持多达 65,535 个 I/O 队列，每个 I/O 队列支持多达 65,535个未完成的命令；
与每个 I/O Queue 关联的优先级，具有明确的仲裁机制；
完成 4 KiB 读取请求的所有信息都包含在 64B 命令本身中，确保高效的小型 I/O 操作；
高效且精简的Command Set ；
支持MSI/MSI-X和中断聚合；
支持多个命名空间；
高效支持 SR-IOV 等 I/O 虚拟化架构；
强大的错误报告和管理能力；和
支持multi-path I/O 和命名空间共享。

该规范定义了一组简化的属性，用于配置低级控制器属性并获得低级控制器状态。这些属性具有用于定义访问的传输特定机制（例如，Memory Mapped项使用寄存器，而 Fabrics 使用 Property Get 和 Property Set 命令）。以下是属性中定义的功能示例：

控制器 capabilities；
控制器故障状态（命令状态直接通过CQ处理）；
Admin Queue 配置（通过 Admin 命令处理的 I/O Queue 配置）；和
可扩展数量的 Submission 和 Completion Queues的Doorbell 寄存器。

主机和 NVM 子系统之间的通信有两种已定义的结构，即基于内存的传输模型和基于消息的传输模型。所有 NVM 子系统都需要底层 NVMe 传输来提供可靠的 NVMe 命令和数据传输。NVMe 传输是独立于任何物理互连属性的抽象协议层。Figure 4 显示了 NVMe 传输的分类和示例。NVMe 传输可以公开基于内存的传输模型或基于消息的传输模型。基于消息的传输模型有两个子类型：仅消息传输模型和消息/内存传输模型。基于内存的传输模型是一种通过执行显式内存读取和写入操作在一个host和一个NVM subsystem 之间传输命令、响应和数据的模型。基于消息的传输模型是在一个host和一个NVM subsystem 之间发送包含命令封装和响应封装的消息的模型。基于消息的传输模型的两种子类型通过在一个host和一个NVM subsystem 之间发送数据的方式来区分。在仅消息传输模型中，数据仅使用胶囊或消息在一个host和一个NVM subsystem 之间发送。基于消息/内存的传输模型使用消息和显式内存读写操作的组合在一个host和一个NVM subsystem 之间传输命令胶囊、响应胶囊和数据。数据可以可选地包含在命令胶囊和响应胶囊中。当描述适用于这两个子类型时，仅消息传输模型和基于消息/内存的传输模型在整个规范中都被称为基于消息的传输模型。

NVM 子系统由单个域或多个域组成，如第 3.2.4 节所述。NVM子系统可以可选地包括非易失性存储介质，以及NVM子系统的控制器和非易失性存储介质之间的接口。控制器通过命名空间向主机公开这种非易失性存储介质。NVM 子系统不需要将相同的命名空间附加到所有控制器。支持 Discovery 控制器的 NVM 子系统不支持任何其他控制器类型。Discovery Service 是仅支持 Discovery 控制器的 NVM 子系统（请参阅第 3.1 节）。

Figure 4: Taxonomy of Transport Models

应用于 NVM Express 控制器的 capabilities 和设置在 Controller Capabilities (CAP) 属性和 Identify Controller data structure 中指示（请参见Figure 275）。

命名空间是可以被主机访问的格式化数量的非易失性内存。与每个命名空间相关联的是一个在该命名空间上运行的 I/O Command Set。NVM Express 控制器可能支持使用命名空间 ID 引用的多个命名空间。可以使用 Namespace Managemen 和 Capacity Management commands命令创建和删除命名空间。Identify Namespace data structure, I/O Command Set specific Identify Namespace data structure, 和I/O Command Set Independent Identify Namespace data structure指示特定于特定命名空间的 capabilities 和设置。

NVM Express 接口基于成对的 Submission 和 Completion Queue 机制。主机软件将命令放入Submission Queue中。控制器将完成放入相关的 Completion Queue 中。

NVM Express 中定义了三种类型的命令：Admin 命令、I/O 命令和 Fabrics 命令。Figure 5 显示了这些不同的命令类型。

Figure 5: Types of NVMe Command Sets

Admin Submission Queue 和相关的 Completion Queue 的存在是为了控制器管理和控制（例如，创建和删除 I/O Submission 和 Completion Queues、中止命令等）。只有属于Admin Command Set或 Fabrics Command Set 的命令可以提交到 Admin Submission Queue。

I/O Command Set 与 I/O 队列对一起使用。本规范定义了常用的 I/O 命令。I/O Command Set 在 NVMe I/O Command Set 规范中定义（例如，NVM Command Set 、Key Value Command Set 或Zoned Namespace Command Set ）。

Fabrics Command Set 特定于 NVMe over Fabrics。Fabrics Command Set 命令用于特定于 NVMe over Fabrics 的操作，包括建立连接、NVMe 带内身份验证以及获取或设置属性。所有 Fabrics 命令都可以在 Admin Submission Queue 上提交，并且一些 Fabrics 命令也可以在 I/O Submission Queue 上提交。与 Admin 和 I/O 命令不同，Fabrics 命令由控制器处理，无论控制器是否enable（即，无论 CC.EN 的状态如何）。

2.1基于内存的传输模型

在基于内存的模型中，Submission 和 Completion Queues分配在内存中。

主机软件创建队列，达到控制器支持的最大值。通常，创建的命令队列的数量取决于系统配置和预期的工作负载。例如，在基于四核处理器的系统上，每个核可能有一个队列对以避免锁定并确保在适当的处理器内核的缓存中创建数据结构。Figure 6 提供了队列对机制的图形表示，显示了Submission Queues 和 Completion Queues之间的 1:1 映射。Figure 7 显示了一个示例，其中多个 I/O Submission Queues 在 Core B 上使用相同的 I/O Completion Queue。Figure 6 和 Figure 7 显示 Admin Submission Queue 和 Admin Completion Queue 之间始终存在 1:1 映射。

Figure 6: Queue Pair Example, 1:1 Mapping

Figure 7: Queue Pair Example, n:1 Mapping

Submission Queue (SQ) 是一个具有固定槽大小的循环缓冲区，主机软件使用它来提交命令以供控制器执行。当有 1 到 n 个新命令要执行时，主机软件会更新相应的 SQ Tail 门铃寄存器。当有新的门铃寄存器写入时，之前的 SQ Tail 值在控制器中被覆盖。控制器按顺序从 Submission Queue 中获取 SQ 条目，并且可以按任何顺序执行这些命令。

每个 Submission Queue 条目都是一个命令。命令大小为 64 字节。内存中用于数据传输的物理内存位置是使用 Physical Region Page (PRP) 条目或 Scatter Gather Lists(SGL) 指定的。每个命令可能包括两个 PRP Entry或一个 Scatter Gather List 段。如果需要两个以上的 PRP Entry来描述数据缓冲区，则提供指向描述 PRP Entry列表的 PRP List的指针。如果需要多个 SGL 段来描述数据缓冲区，则 SGL 段提供指向下一个 SGL 段的指针。

Completion Queue (CQ) 是一个具有固定槽大小的循环缓冲区，用于发布已完成命令的状态。完整的命令由相关的 SQ 标识符和主机软件分配的命令标识符的组合唯一标识。在基于内存的传输模型中，多个Submission Queues 可能与单个完成队列相关联。此功能可用于单个工作线程通过一个完成队列处理所有命令完成的情况，即使这些命令源自多个 Submission Queues。CQ Head指针在处理完成队列条目后由主机软件更新，指示最后一个空闲 CQ 槽。在完成队列条目中定义了一个Phase Tag (P) 位，以指示是否在未咨询寄存器的情况下新发布了一个条目。这使主机软件能够确定新条目是作为前一轮还是当前轮完成通知的一部分发布的。具体来说，通过完成队列条目的每一轮，控制器都会反转P位。

2.2Message-Based Transport Model

NVMe over Fabrics 使用的基于消息的传输模型与基于内存的传输模型有以下区别： - I/O Submission Queues 和 I/O Completion Queues之间存在一对一的映射关系。NVMe over Fabrics 不支持将多个 I/O Submission Queues 映射到单个 I/O Completion Queues；

NVMe over Fabrics 没有定义允许控制器生成主机中断的中断机制。主机fabric接口（例如Host Bus Adapter）负责生成主机中断；
NVMe over Fabrics 使用不同的机制来创建和删除 I/O Submission Queues 和 I/O Completion Queues（请参阅第 3.5 节）；
NVMe over Fabrics 不支持从单独的缓冲区传输元数据（例如，不支持元数据指针字段，请参阅Figure 87）；
NVMe over Fabrics 不支持 PRP，但需要将 SGL 用于Admin、I/O 和 Fabrics 命令。这与基于内存的传输模型不同，后者不支持 SGL 用于Admin命令并且对于 I/O 命令是可选的；
NVMe over Fabrics 不支持 Completion Queue 流控制（参考3.3.1.2.1节）。这要求主机在提交新命令之前确保有可用的完成队列插槽；和
NVMe over Fabrics 允许在主机和控制器同意禁用 Submission Queue 流控制的情况下禁用它。如果 Submission Queue 流控制被禁用，则要求主机在提交新命令之前确保有可用的 Submission Queue 插槽。

2.2.1Fabrics and Transports

NVMe over Fabrics 利用Figure 8所示的协议分层。该规范定义了独立于 NVMe Transport架构的核心方面。NVMe Transport binding规范用于描述任何 NVMe Transport特定的专业化以及 NVMe 接口所需的服务如何映射到相应的 NVMe Transport。NVMe 接口和 NVMe 传输（例如，Figure 8 中的 Fabric Protocol和 Fabric Physical 层）使用的本地fabric通信服务和其他功能超出了 NVMe 系列规范的范围。

Figure 8: NVMe over Fabrics Layering

2.2.2NVM Subsystem Ports

NVM 子系统提供1~ (64Ki - 16) 个控制器的集合，这些控制器用于访问命名空间。控制器可以通过 1 ~64Ki NVM 子系统端口与主机相关联。

NVM 子系统端口是 NVM 子系统和 fabric 之间的协议接口。NVM 子系统端口是一个或多个物理 fabric接口的集合，它们共同充当单个协议接口。当使用链路聚合（例如以太网）时，聚合链路组的物理端口构成单个 NVM 子系统端口。

NVM 子系统包含一个或多个 NVM 子系统端口。

每个 NVM 子系统端口都有一个 16 位的端口标识符（Port ID）。NVM 子系统端口由 NVM 子系统中的 NVMe Qualified Name (NQN) 和Port ID 标识。NVM 子系统的 NVM 子系统端口可以支持不同的 NVMe Transports。如果底层 fabric存在多个 NVMe Transport binding规范，则 NVM 子系统端口可以支持多个 NVMe Transports（例如，由Port ID 标识的 NVM 子系统端口可能同时支持 iWARP 和 RoCE）。NVM 子系统可以将特定控制器绑定到特定 NVM 子系统端口，或者允许在 NVM 子系统端口之间灵活分配控制器，但是，一旦连接，每个特定控制器都绑定到单个 NVM 子系统端口。

控制器一次只与一个主机相关联。NVMe over Fabrics 允许多个主机通过同一个 NVM 子系统端口连接到 NVM 子系统中的不同控制器。NVMe over Fabrics 多路径 I/O 和命名空间共享（请参阅第 2.4.1 节）的所有其他方面都与基于内存的传输模型等效。

2.2.3Discovery Service

NVMe over Fabrics 定义了一种发现机制，主机使用该机制来确定公开主机可以访问的命名空间的 NVM 子系统。Discovery Service 为主机提供以下功能： - 发现具有主机可访问命名空间的 NVM 子系统清单的能力；

发现 NVM 子系统的多路径的能力；
发现静态配置的控制器的能力；
与 Discovery controller 建立显式持久连接的可选能力；和
从 Discovery controller 接收 Asynchronous Event Notifications 的可选功能

Discovery Service 是一个 NVM 子系统，仅支持 Discovery 控制器（请参阅第 3.1.2.3 节），不应支持任何其他控制器类型。主机用于获取连接到初始 Discovery Service 所需信息的方法是特定实现的。可以使用主机配置文件、管理程序或 OS 属性或一些其他机制来确定此信息。

2.2.4胶囊与数据传输

胶囊是 NVMe over Fabrics 中使用的 NVMe 信息交换单元。胶囊可以分类为命令胶囊或响应胶囊。命令胶囊包含一个命令（格式为提交队列条目），并且可以选择包含 SGL 或数据。响应胶囊包含响应（格式化为完成队列条目），并且可以选择包含数据。这里的数据是指在主机和 NVM 子系统之间的 NVMe 层传输的任何数据（例如，逻辑块数据或与命令关联的数据结构）。胶囊独立于任何底层 NVMe 传输单元（例如，packet、message或 frame 以及相关的headers和footers），并且可能由多个此类单元组成。

命令胶囊从主机传输到 NVM 子系统。SQE 包含 Admin 命令、I/O 命令或 Fabrics 命令。命令胶囊的最小大小是 NVMe Transport binding 特定的，但至少应为 64B。命令胶囊的最大大小是 NVMe Transport binding 特定的。命令胶囊的格式如Figure 9 所示。

Figure 9: Command Capsule Format

响应胶囊从 NVM 子系统传输到主机。CQE 与先前发出的 Admin 命令、I/O 命令或 Fabrics 命令相关联。响应胶囊的大小是NVMe Transport binding 特定的，但至少应为 16B。响应胶囊的最大大小是NVMe Transport binding特定的。响应胶囊的格式如Figure 10 所示。

Figure 10: Response Capsule Format

使用仅消息传输模型和消息/内存传输模型的 NVMe Transports 要求从主机发送到控制器的所有 SGL 在命令中传输。它们可以可选地支持在命令和响应胶囊内传输部分或全部数据。

NVMe over Fabrics 需要所有命令（Fabrics、Admin 和 I/O）的 SGL。SGL 可以指定数据包内的数据放置或使用 NVMe Transports 特定数据传输机制传输数据所需的信息（例如，通过 RDMA 中的内存传输）。每个 NVMe Transport binding 规范定义了特定 NVMe Transport 使用的 SGL，以及任何胶囊 SGL 和数据放置限制。

2.2.5身份验证

NVMe over Fabrics 支持包含身份验证的fabric安全通道（请参阅第 8.13.1 节）和 NVMe 带内身份验证。NVM 子系统可能需要主机使用fabric安全通道、NVMe 带内身份验证或两者兼而有之。Discovery Service指示fabric安全通道是否应用于 NVM 子系统。Connect 响应指示 NVMe 带内身份验证是否应与该控制器一起使用。

与需要fabric安全通道的 NVM 子系统关联的控制器在建立安全通道之前，不得接受 NVMe Transport 上的任何命令（即，Fabrics 命令、Admin 命令或 I/O 命令）。在 Connect 命令之后，需要 NVMe 带内身份验证的控制器在 NVMe 带内身份验证完成之前，不应接受由该 Connect 命令创建的队列上除身份验证命令之外的任何命令。请参阅第 8.13 节。

2.3NVM存储模型

2.3.1存储实体

NVM 存储模型包括以下实体： - NVM subsystems/NVM 子系统（参考 1.5.40 节）

Domains /域（请参阅第 3.2.4 节）
Endurance Groups/ Endurance Group （请参阅第 3.2.3 节）
NVM Sets（请参阅第 3.2.2 节）
Namespaces/命名空间（请参阅第 3.2.1 节）

如下图所示，每个域包含在单个 NVM 子系统中，每个 Endurance Group 包含在单个域中，每个 NVM Set 包含在单个 Endurance Group 中，每个命名空间包含在单个 NVM Set 中。每个 Media Unit 都包含在一个单一的 Endurance Group。每个 Endurance Group 由存储介质组成，称为介质单元/Media Units（请参阅第 8.3.2 节）。为清楚起见，介质单元未在以下示例中显示。

Figure 11 显示了这些实体在一个简单的 NVM 子系统中的层次关系，该子系统具有一个域、一个 Endurance Group、一个 NVM Set和一个命名空间：

Figure 11: NVM Storage Hierarchy

Figure 12 显示了这些实体在复杂 NVM 子系统中的关系，该子系统具有多个域、每个域多个 Endurance Group、每个 Endurance Group 多个 NVM Set 以及每个 NVM Set 多个命名空间：

Figure 12: Complex NVM Storage Hierarchy

实体命名方式（Abc）：
A: Domain (大写字母)
b: Endurance Group (数字)
c: NVM Set (小写字母)

Endurance Group 或 NVM Set 的报告是可选的，但存储模型支持这些概念。NVM 子系统可以由供应商定义，并配置其存储实体，或者它可以由客户配置或重新配置。对配置的典型更改是创建和删除命名空间。

不支持多个 NVM Sets 的 NVM 子系统不需要报告 NVM Set。不支持多个 Endurance Group 的 NVM 子系统不需要报告 Endurance Group。

2.3.2I/O Command Sets

I/O 命令对命名空间执行操作，每个命名空间都与一个I/O Command Set 相关联。例如，NVM command set 访问命名空间中表示为逻辑块的数据，Key Value Command set访问命名空间中表示为键值对的数据。

命名空间与I/O Command Set 的关联是在创建命名空间时指定的，并且在命名空间的生命周期内是固定的。

控制器可以支持一个或多个I/O Command Set，并且可以附加到与不同I/O Command Set 关联的命名空间。主机向命名空间发出命令，这些命令根据与该命名空间关联的I/O Command Set 进行解释。

2.3.3NVM Subsystem Examples

Figure 13 展示了一个简单的 NVM 子系统，它具有每个存储实体的单个实例。

Figure 13: Single-Namespace NVM Subsystem

NVM 子系统由一个Port和一个Domain组成。
Domain包含控制器和存储介质。
所有存储介质都包含在一个 Endurance Group 中。
该 Endurance Group 中的所有存储介质都组织成一个 NVM Set。
该 NVM Set包含一个命名空间。

Figure 14 展示了带两个命名空间的NVM 子系统

Figure 14: Two-Namespace NVM Subsystem

一个 NVM 子系统可以有多个域、多个命名空间、多个控制器和多个端口，如Figure 15所示。

Figure 15: Complex NVM Subsystem

2.4Extended Capabilities Theory

2.4.1Multi-Path I/O and Namespace Sharing

本节概述了多路径 I/O 和命名空间共享。多路径 I/O 是指单个主机和命名空间之间的两个或多个完全独立的路径，而命名空间共享是指两个或多个主机使用不同的 NVM Express 控制器访问公共共享命名空间的能力。多路径 I/O 和命名空间共享都要求 NVM 子系统包含两个或多个控制器。支持多路径 I/O 和命名空间共享的 NVM 子系统也可能支持非对称控制器行为（请参阅第 2.4.2 节）。两个或多个主机对共享命名空间的并发访问需要主机之间某种形式的协调。用于协调这些主机的过程超出了本规范的范围。

Figure 16 显示了一个 NVM 子系统，它包含一个通过 PCI Express 实现的 NVM Express 控制器和一个 PCI Express 端口。由于这是一个单一的功能 PCI Express 设备，NVM Express 控制器应与 PCI Function 0 相关联。一个控制器可以支持多个命名空间。Figure 16 中的控制器支持标记为 NS A 和 NS B 的两个命名空间。与每个控制器命名空间相关联的是一个namespace ID，标记为 NSID 1 和 NSID 2，控制器使用它来引用特定的命名空间。namespace ID 与 namespace 本身不同，它是主机和控制器用于在命令中指定特定命名空间的句柄。控制器命名空间 ID 的选择超出了本规范的范围。在这个例子中，命名空间 ID 1 与命名空间 A 相关联，命名空间 ID 2 与命名空间 B 相关联。这两个命名空间都是控制器私有的，并且此配置既不支持多路径 I/O，也不支持命名空间共享。

Figure 16: NVM Express Controller with Two Namespaces

Figure 17 显示了具有单个 PCI Express 端口的多Function NVM 子系统，该端口包含两个实现 NVMe over PCIe 的控制器。一个控制器与 PCI Function 0 相关联，另一个控制器与 PCI Function 1 相关联。每个控制器支持单个私有命名空间和对共享命名空间 B 的访问。特定共享命名空间的命名空间 ID 在所有控制器相同，并都有权访问。在这个例子中，两个控制器都使用命名空间 ID 2 来访问共享命名空间 B。

Figure 17: NVM Subsystem with Two Controllers and One Port

每个控制器都有一个或多个Identify Controller data structure，每个命名空间有一个或多个 Identify Namespace data structures（参见Figure 273）。有权访问共享命名空间的控制器返回与该共享命名空间关联的 Identify Namespace data structure（即，所有有权访问同一共享命名空间的控制器返回相同的数据结构内容）。有一个与命名空间本身关联的全局唯一标识符，可用于确定何时有多个路径指向同一个共享命名空间。请参阅第 4.5.1 节。

与共享命名空间关联的控制器可以同时在命名空间上操作。单个控制器执行的操作在命令提交到的控制器的写入原子性级别上对共享命名空间是原子的（请参阅第 3.4.3 节）。共享命名空间的控制器之间的写入原子性级别不需要相同。如果向访问共享命名空间的不同控制器发出的命令之间存在任何排序要求，则需要主机软件或相关应用程序来强制执行这些排序要求。

Figure 18 显示了一个具有两个 PCI Express 端口的 NVM 子系统，每个端口都有一个相关的控制器来实现 NVMe over PCIe。两个控制器都映射到相应端口的 PCI Function 0。本例中的每个 PCI Express 端口都是完全独立的，并且有自己的 PCI Express Fundamental Reset 和参考时钟输入。端口的重置只会影响与该端口关联的控制器，并且不会影响其他控制器、共享命名空间或其他控制器在共享命名空间上执行的操作。此示例的其他功能行为与Figure 17 中所示的相同。

Figure 18: NVM Subsystem with Two Controllers and Two Ports

Figure 18 中所示的两个端口可能与相同/不相同的 Root Complex 关联，并可用于实现多路径 I/O 和 I/O 共享架构。系统级架构方面和 PCI Express 结构中多个端口的使用超出了本规范的范围。

Figure 19 展示了一个 NVM 子系统，它支持Single Root I/O Virtualization (SR-IOV)，并具有一个 Physical Function 和四个Virtual Functions。实现 NVMe over PCIe 的 NVM Express 控制器与每个Function相关联，每个控制器具有一个私有命名空间并可以访问所有控制器共享的命名空间，标记为 NS F。此示例中控制器的行为与此示例中的其他示例相似部分。有关 SR-IOV 的更多信息，请参阅第 8.26.4 节。

Figure 19: PCI Express Device Supporting Single Root I/O Virtualization (SR-IOV)

本节中提供的示例旨在说明概念，并非旨在列举所有可能的配置。例如，一个 NVM 子系统可能包含多个 PCI Express 端口，每个端口都支持 SR-IOV。

2.4.2Asymmetric Controller Behavior

非对称控制器行为发生在 NVM 子系统中，其中命名空间访问特征（例如，performance）可能因以下因素而异：

NVM子系统的内部配置；或
哪个控制器用于访问命名空间（例如，Fabrics）。

提供非对称控制器行为的 NVM 子系统可能支持 Asymmetric Namespace Access Reporting，如第 8.1 节所述。

【NVMe2.0b 2】NVMe 结构理论相关推荐

【NVMe2.0b 15】NVMe SR-IOV
NVMe SR-IOV PCIe SR-IOV 系列导航基于 PCIe 的 NVM transport 实施结构关键词定义支持 SR-IOV 的 NVM Subsystem 结构 Virtual ...
【NVMe2.0b 8】NVMe 队列仲裁机制
NVMe 队列仲裁机制 3.4命令Submission和Completion机制 3.4.1命令排序要求 3.4.2Fused Operations 3.4.3Atomic Operations 3. ...
【NVMe2.0b 7】NVMe 基本队列数据结构
NVMe 队列数据结构与命令仲裁机制 3.3.3Queueing Data Structures 3.3.3.1Submission Queue Entry 3.3.3.2Common Complet ...
【NVMe2.0b 14】NVMe Admin Command Set
5Admin Command Set Admin Command Set 定义了可以提交到 Admin Submission Queue 的命令. 提交队列条目 (submission queue e ...
【NVMe2.0b 13】NVMe 标准数据结构
NVMe 标准数据结构 4数据结构 4.1数据布局 4.1.1Physical Region Page Entry and List 4.1.2Scatter Gather List (SGL) 4. ...
【NVMe2.0b 6】NVMe 队列模型
NVMe 队列模型 3.3NVM Queue Models 3.3.1基于内存的传输队列模型 3.3.1.1队列设置与初始化 3.3.1.2Queue的使用 3.3.1.2.1Completion Q ...
【NVMe2.0b 3】NVM 控制器架构模型
NVM 控制器架构模型 3.1.1控制器模型 3.1.2Controller Types 3.1.2.1I/O Controller 3.1.2.1.1Command Support 3.1.2.1. ...
【NVMe2.0b 14-8】Set Features（下篇）
Set Features 5.27.1.13Host Controlled Thermal Management (Feature Identifier 10h), (可选) 5.27.1.14Non ...
【NVMe2.0b 9】控制器初始化过程
控制器初始化过程 3.5控制器初始化 3.5.1基于内存传输的控制器初始化 3.5.2基于消息传输的控制器初始化 3.5.3Controller Ready Modes During Initiali ...

【NVMe2.0b 2】NVMe 结构理论