<html><head><title>Samsung Enterprise Portal mySingle</title>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<style id="mysingle_style" type="text/css">P {
        MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
}
TD {
        MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
}
LI {
        MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
}
BODY {
        FONT-SIZE: 9pt; FONT-FAMILY: Arial, arial; MARGIN: 10px; LINE-HEIGHT: 1.4
}
</style>

<meta http-equiv="X-UA-Compatible" content="IE=5">
<meta http-equiv="X-UA-Compatible" content="IE=5">
<meta name="GENERATOR" content="MSHTML 10.00.9200.17267"></head>
<body>
<p><span style="font-family: Calibri; font-size: 11pt;">Hi Tom,<br><br>Sorry for the delay in reviewing your patch.</span></p>
<p><span style="font-family: Calibri; font-size: 11pt;"></span> </p>
<p><span style="font-family: Calibri; font-size: 11pt;">Please find below our review comments:</span></p>
<p><span style="font-family: Calibri; font-size: 11pt;">1) SCSIOP_PERSISTENT_RESERVE_IN and SCSIOP_PERSISTENT_RESERVE_OUT command opcodes needs to be added in SntiValidateNacaSetting().<br></span></p>
<p><span style="font-family: Calibri; font-size: 11pt;">2) For the default case in SntiValidateNacaSetting(), failure can be returned instead of success.  In future, if new command support is added, then that command opcode  needs to be added in SntiValidateNacaSetting(). If the support is not added in SntiValidateNacaSetting() and success is returned in default case, then this validation will be missed. Returning failure for the default case will catch these kind of issues.<br></span></p>
<p><span style="font-family: Calibri; font-size: 11pt;">3) For the DSM and Reservation commands, same memory buffer is used for both the commands.If both of these commands are issued in parallel, then synchronization issues may be observed.<br></span></p>
<p><span style="font-family: Calibri; font-size: 11pt;">4) NVMePreparePRPs() can be used in place of NVMeGetPhysAddr() in the function SntiTranslatePersistentReserveIn()[Line Number 3763]. NVMePreparePRPs() will take care of page alignment. So no need to check for page boundary crossing case of the memory buffer.[page boundary crossing verification is done in Line number 3777-3791]. The same can be applied in SntiTranslatePersistentReserveOut() [Line Number 4077]<br></span></p>
<p><span style="font-family: Calibri; font-size: 11pt;">5)  If the </span><font face="Consolas" size="2"><font face="Consolas" size="2"><span style="font-family: Calibri; font-size: 11pt;">SntiTranslatePersReserveInResponse() returns the </span><font face="Consolas" size="2"><font face="Consolas" size="2" style="font-family: Calibri; font-size: 11pt;">SNTI_SEQUENCE_IN_PROGRESS, then the SRB will not be completed. This value SNTI_SEQUENCE_IN_PROGRESS will be returned for default case.</font></font></font></font></p>
<p><span style="font-family: Calibri; font-size: 11pt;"></span> </p>
<p><span style="font-family: Calibri; font-size: 11pt;">Thanks,</span></p>
<p><span style="font-family: Calibri; font-size: 11pt;">Suman</span></p>
<p><span style="font-family: Calibri; font-size: 11pt;"></span> </p>
<p><br><br>------- Original Message -------<br>Sender : nvmewin-request@lists.openfabrics.org<nvmewin-request@lists.openfabrics.org> <br>Date   : Nov 26, 2015 04:21 (GMT+05:30)<br>Title  : nvmewin Digest, Vol 47, Issue 6<br><br>Send nvmewin mailing list submissions to<br> nvmewin@lists.openfabrics.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> http://lists.openfabrics.org/mailman/listinfo/nvmewin<br>or, via email, send a message with subject or body 'help' to<br> nvmewin-request@lists.openfabrics.org<br><br>You can reach the person managing the list at<br> nvmewin-owner@lists.openfabrics.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of nvmewin digest..."<br><br><br>Today's Topics:<br><br>   1. Re: Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out<br>      (Robles, Raymond C)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 25 Nov 2015 22:51:52 +0000<br>From: "Robles, Raymond C" <raymond.c.robles@intel.com><br>To: 'Thomas Freeman' <thomas.freeman@hgst.com>,<br> "'nvmewin@lists.openfabrics.org'" <nvmewin@lists.openfabrics.org><br>Subject: Re: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent<br> Reserve In/Out<br>Message-ID:<br> <49158E750348AA499168FD41D88983607253C236@fmsmsx117.amr.corp.intel.com><br> <br>Content-Type: text/plain; charset="us-ascii"<br><br><br>Hi Tom,<br><br>Sorry for the delay in retesting your updated patch. We have finished our review/tests and Intel approves this patch.<br><br>Now just need to wait approval from Samsung and PMC. Due to the holidays, we have a couple of options for this patch:<br><br><br>-          Wait for Samsung and PMC to come back with feedback/approval before pushing patch.<br><br>-          Push patch now (without approval from PMC and Samsung). Fix any remaining issues in future patches.<br><br>The second option allows us to move forward with the next patch from Intel for namespace management. The first option is still ideal as we would like to get as much feedback as possible.<br><br>Does anyone on this distribution have strong feelings for either option? Or an option I didn't describe?<br><br>Thanks,<br>Ray<br><br>From: Robles, Raymond C<br>Sent: Thursday, November 12, 2015 3:24 PM<br>To: Thomas Freeman; nvmewin@lists.openfabrics.org<br>Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out<br><br>Thanks Tom! We'll rerun our tests.<br><br>Thanks,<br>Ray<br><br>From: Thomas Freeman [mailto:thomas.freeman@hgst.com]<br>Sent: Thursday, November 12, 2015 3:23 PM<br>To: Robles, Raymond C; nvmewin@lists.openfabrics.org<mailto:nvmewin@lists.openfabrics.org><br>Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out<br><br>Hi Ray,<br>There were issues with the IEKEY, RACQA, RRELA, RREGA and RTYPE.<br>I'm attaching a new file with those fixes - SNTL15ResInOut111215.zip (password "nvmehgst").<br><br>The code passes Scsi compliance testing (reservation is not enabled)<br>As before, I am doing a manual validation of PERSISTENT RESERVATION IN/OUT.<br><br>Tom Freeman<br>Software Engineer, Device Manager and Driver Development<br>HGST, a Western Digital company<br>thomas.freeman@hgst.com<mailto:thomas.freeman@hgst.com><br>507-322-2311<br><br>[HGST_Logo_email]<br>3605 Hwy 52 N<br>Rochester, MN 55901<br>www.hgst.com<https://hgst.jiveon.com/external-link.jspa?url=http://www.hgst.com/><br><br>From: Thomas Freeman<br>Sent: Tuesday, November 10, 2015 4:52 PM<br>To: 'Robles, Raymond C' <raymond.c.robles@intel.com<mailto:raymond.c.robles@intel.com>>; nvmewin@lists.openfabrics.org<mailto:nvmewin@lists.openfabrics.org><br>Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out<br><br>Hi Ray,<br>I don't have hardware to support NVM Reservation Register. So, my testing was limited to issuing individual Scsi Persistent Reserve commands and manually verifying the Scsi to NVMe translation.<br>As you observed, I missed the IEKEY field. My implementation was based on table 6-35 in the SNTL 1.5. That doesn't mention IEKEY. But, I overlooked the information about IEKEY from table 4-16.<br>I'll make that change and submit a new patch.<br><br>Tom Freeman<br>Software Engineer, Device Manager and Driver Development<br>HGST, a Western Digital company<br>thomas.freeman@hgst.com<mailto:thomas.freeman@hgst.com><br>507-322-2311<br><br>[HGST_Logo_email]<br>3605 Hwy 52 N<br>Rochester, MN 55901<br>www.hgst.com<https://hgst.jiveon.com/external-link.jspa?url=http://www.hgst.com/><br><br>From: Robles, Raymond C [mailto:raymond.c.robles@intel.com]<br>Sent: Tuesday, November 10, 2015 3:59 PM<br>To: Thomas Freeman <thomas.freeman@hgst.com<mailto:thomas.freeman@hgst.com>>; nvmewin@lists.openfabrics.org<mailto:nvmewin@lists.openfabrics.org><br>Subject: RE: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out<br><br>Hi Tom,<br><br>Intel has finished their internal testing of this patch. All tests passed with the exception of the MS SCSI Compliance Tests for Persistent Reserve In/Out (see attached file).<br><br>We're not sure if the failures are due to IEKEY field not being handled in Persistent Reserve Out command. Was this something that was intentionally left out? Were you able to try the SCSI compliance test?<br><br>Thanks,<br>Ray<br><br>From: nvmewin-bounces@lists.openfabrics.org<mailto:nvmewin-bounces@lists.openfabrics.org> [mailto:nvmewin-bounces@lists.openfabrics.org] On Behalf Of Robles, Raymond C<br>Sent: Monday, November 02, 2015 4:25 PM<br>To: Thomas Freeman; nvmewin@lists.openfabrics.org<mailto:nvmewin@lists.openfabrics.org><br>Subject: Re: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out<br><br>Hello all,<br><br>I extended the review period for this patch to allow for more time. We're coming up on the end of the year and I'd like to wrap up all planned patches.<br><br>Intel is wrapping up our review of this patch and will send out our feedback by the end of the week. Still awaiting feedback from Samsung and PMC. In order to keep to our original schedule, I'd like to wrap this patch up as soon as possible. Intel will be next with the namespace management patch.<br><br>Thanks,<br>Ray<br><br>From: nvmewin-bounces@lists.openfabrics.org<mailto:nvmewin-bounces@lists.openfabrics.org> [mailto:nvmewin-bounces@lists.openfabrics.org] On Behalf Of Robles, Raymond C<br>Sent: Wednesday, October 07, 2015 12:54 PM<br>To: Thomas Freeman; nvmewin@lists.openfabrics.org<mailto:nvmewin@lists.openfabrics.org><br>Subject: Re: [nvmewin] Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out<br><br>Tom,<br><br>Thanks for volunteering to submit this patch while Intel is wrapping up the namespace management patch.<br><br>All Reviewers,<br><br>Please provide feedback on HGST's patch by October 21st, 2015. Thanks!<br><br>Thanks,<br>Ray<br><br>From: Thomas Freeman [mailto:thomas.freeman@hgst.com]<br>Sent: Wednesday, October 07, 2015 12:45 PM<br>To: nvmewin@lists.openfabrics.org<mailto:nvmewin@lists.openfabrics.org><br>Cc: Robles, Raymond C<br>Subject: Changes for SNTL 1.5 and SCSI Persistent Reserve In/Out<br><br>This patch includes changes to support SNTL version 1.5, SCSI Persistent Reserve In/Out and a variety of small fixes.<br><br>The following tests were successfully run on Windows 2008 R2, Windows 2012 and Windows 2012 R2<br>1 hour sdstress, 1 hour IOMETER, Quick and Slow format - MBR and GPT, Microsoft Scsi Compliance.<br><br>The above tests were run with an NVMe 1.1a compliant device that does not support NVMe Reservations.<br>Testing variations of Unit SN VPD page/Device ID Data Page (requiring V1.0 or NGUID support) and<br>SCSI Persistent Reserve In/Out, required setting breakpoints to manually alter the required Identify<br>data. At that point individual SCSI commands were issued and the driver's response (NVMe commands<br>issued and data returned) was manually verified.<br><br>The attached file, SNTL15ResInOut.zip, contains a Patch file, a copy of the source code and a Log file detailing the changes made.<br>The password for the file is "nvmehgst"<br><br>Tom Freeman<br>Software Engineer, Device Manager and Driver Development<br>HGST, a Western Digital company<br>thomas.freeman@hgst.com<mailto:thomas.freeman@hgst.com><br>507-322-2311<br><br>[HGST_Logo_email]<br>3605 Hwy 52 N<br>Rochester, MN 55901<br>www.hgst.com<https://hgst.jiveon.com/external-link.jspa?url=http://www.hgst.com/><br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20151125/a06d1c5b/attachment.html><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: image003.gif<br>Type: image/gif<br>Size: 1117 bytes<br>Desc: image003.gif<br>URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20151125/a06d1c5b/attachment.gif><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: image004.png<br>Type: image/png<br>Size: 4274 bytes<br>Desc: image004.png<br>URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20151125/a06d1c5b/attachment.png><br><br>------------------------------<br><br>_______________________________________________<br>nvmewin mailing list<br>nvmewin@lists.openfabrics.org<br>http://lists.openfabrics.org/mailman/listinfo/nvmewin<br><br><br>End of nvmewin Digest, Vol 47, Issue 6<br>**************************************<br><br><p>&nbsp;</p><p>&nbsp;</p></p></body></html><img src='http://ext.samsung.net/mailcheck/SeenTimeChecker?do=d1c4c6a24968fb2557bdd9fa89a0a3840ed0282b8eebaea87d9badbdf7e30042d1afaaba7860cdcd9564217c646641ad61e16949eaa607501b20909a04efd4d2748cfe1d4e847419cf878f9a26ce15a0' border=0 width=0 height=0 style='display:none'>