[nvmewin] HwStorPassiveInitializeRoutine and StorPortNotification->RequestTimerCall

[Mike Berhan]

I've performed a detailed analysis of the NVMe initialization sequence, with
the OFA driver, and posted a video here:

 

http://www.bustrace.com/bustrace10/videos/NVMeBootCapture/

 

The NVMe passive initialization phase uses a background state machine to
initialize the NVMe controller after the controller has been enabled.  On my
two NUMA node system, with 16 logical processors, the passive initialization
phase takes ~1.859 seconds.  However, if I analyze the time spent
communicating with the NVMe controller, plus the time spent waiting for the
NVMe controller to process the request, I come up with less than 170
milliseconds.  The bulk of that 1.859 seconds is spent with an idle state
machine waiting for the next timer callback, and an idle passive
initialization phase waiting for the state machine to complete.  One of the
primary reasons for this is the use of StorPortNotification -
RequestTimerCall.  The miniport is using the value of STORPORT_TIMER_CB_us
for the delay which equals:

 

#define STORPORT_TIMER_CB_us        5000 /* .005 seconds */

 

Even though the miniport driver is requesting 5 msec, the actual time to
receive the callback is typically 15 msec.  The reason for this is noted in
the STORPORT documentation:

 

The system timer resolution is approximately 10 milliseconds.

 

This may not be a significant issue but I know some OEMs have concerns about
time to ready so I thought I would post my analysis.

 

Mike Berhan

busTRACE Technologies

 

ps:  If you notice the "Not in memory" for the PERF_CONFIGURATION_DATA
structure, that is caused by the miniport driver not setting the Version and
Size fields of the data structure.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20141007/9d9b73ca/attachment.html>