SOP, PQI and NVMe Relationship in Host Driver Stack Ie-Wei Njoo, PMC-Sierra (IeWei_Njoo@pmc-sierra.com) 20 May, 2011

Reference and acknowledgement Microsoft Windows is a registered trademark of Microsoft Corporation All references to PQI descriptions are based on PQI draft proposal T10/11-157r6 All references to SOP descriptions are based on SOP draft proposal T10/11-158r4

Introduction Discuss on the impact of HW differences in PQI and NVMe in the host driver stack Example diagrams are presented to clarify the related items in the context of a host driver A Windows Storport miniport is used as an example Focus on delineation between SOP, queuing layer and other part of miniport driver No detail Windows driver: SRB, SRB extension, LU Extension, CARD extension, etc. Skip some detail such as memory location, I/O flow and initialization Discuss some of the gray areas that may be classified as either part of SOP specification, or PQI specification (include future NVMe specification) the circular queue indices who allocates of additional buffer for response data chaining count wrapper-around condition of circular queue whether or not SOP would need administrator commands that are related to queuing (such as queue hinting)

Current Goal and Assumption Focus on location of definitions The example diagram does not preclude the driver writer from creating a combo driver that work with both PQI and NVMe based hardware. But it is not the goal of the PQI/SOP specification to assume that a combo driver shall be written, resulting with a single SOP driver that work with both PQI and NVMe HW.

Option 2 - Not Current Goal Diagram

Option 2 - Not Current Goal Additional description This option is not optimized for performance Required translation in every I/O Require additional SOP IU definitions for administrator and configuration functions Require additional works in defining the SW driver interfaces Complexity in designating the owner the SOP driver Add more compatibility requirement for SOP supporting different PQI/NVMe HWs A larger scope of project

Current model- some observation Part 1 of 2 All IU (including SOP IU) may need a queuing specific header to allow SOP module to be written to work on both PQI and NVMe Allow queuing differences to be encapsulated to the queuing layer header SOP is not aware of circular queue wrapped-around condition, nor it is aware of the circular queue indexes (PQI PI/CI and NVMe head/tail) All memory allocation related to queuing is defined by the queuing layer and allocated by miniport during initialization All memory allocation and initialization of the data descriptor (SGL and PRP) defined by the queuing layer and allocated and initialized during I/O by miniport driver The SOP data descriptor is written in native SGL/PRD format by the driver, no translation during I/O

Current model- some observation Part 2 of 2 All additional memory for additional response data could be defined by either the queuing layer or SOP Could be specified by PQI as index based physical address in SOP IU Could be part of SOP IU definition specified as response data physical address in SOP IU The queue hinting (hinting the HW for queues that are likely to be used for fast path, for performance optimization) could either defined in SOP or PQI May be part of PQI as part of the queue initialization May be more consistent with the current scope of PQI (see diagram in slide 4) May be part of SOP, but it would require SOP administrator function to manage additional queue properties