[nvmewin] ***UNCHECKED*** Aug 28 - Patch (NVMe 1.0c Compliance and others) --- Intel Feedback

[Chang, Alex]

Hi Raymond,

Please see my comments in red...

Thanks,
Alex

________________________________
From: Robles, Raymond C [mailto:raymond.c.robles at intel.com]
Sent: Thursday, September 06, 2012 5:25 PM
To: nvmewin at lists.openfabrics.org; Chang, Alex
Subject: ***UNCHECKED*** Aug 28 - Patch (NVMe 1.0c Compliance and others) --- Intel Feedback

Alex,

Here is Intel's feedback on your patch.  Let us know if you need any more info on our comments/questions.


-          nvme.h:

o    ADMIN_SET_FEATURES_LBA_COMMAND_RANGE_TYPE_ENTRY Structure: GUID field (changed from ULONGLONG to UCHAR [16]) - what was the reason for this change?

To match the size of GUID defined in NVMe spec, which is 16 bytes in length. If I understand it right that ULONGLONG is only 8-byte long.

o    General Comment: With the 1.0c changes, will the driver be backward compatible with 1.0b? If not, do we need a mechanism to do so or have you thought about what we should be doing in this case?  Did you attempt any testing of this?

No, I don't think it's backward compatible with 1.0b. The only thing I can think of as compatibility issue is the 0's based NUMD of Firmware Image download and Get Log Page command. In 1.0b, the spec did not indicate it clearly. Now, 1.0c clarifies it. I don't mind to add an ifdef to differenciate them.


-          nvmeInit.c:

o    NVMeResetAdapter:

§  What is the use case for having a check for RDY already being 0 (we can never have nested resets so it would seem this would never be the case but not totally sure)?

The code is checking the RDY bit to find out if the controller had already been reset. If so, there is no point to write 0 to EN bit of CC register again.

o    NVMeNormalShutdown:

§  Same comment as above for reset adapter (same check is performed here).

§  The comment on line 2469 states that the code is waiting for all queues to be deleted, but really you are just checking to see that the RDY bit has been set to 0 indicating the transition of the EN bit from 1 to 0.

Per NVMe specification, when RDY bit becomes 0 due to a reset, it indicates the created queues have been deleted.

o    NvmeCheckPendingCpl:

§  "unsigned int" is used for a variable declaration. We always use typedef types... should be ULONG.

Will change it.

§  General Comment: There is already a function to detect if commands are pending... NVMeDetectPendingCmds in nvmeIo.c. This was done as part of the S3/S4 work that Rick/Arpit (LSI) did. Did you take a look at this function and see if it was similar to your new function? Was there something specific that you needed differently than what was already coded in the existing function?

I think they are for different purposes. NVMeDetectPendingCmds is called to ensure there is no pending IO before enterring power saving modes. NVMeCheckPendingCpl is called to see if we have any pending completed entries in any one of the created completion queues to determine if we do own the INTx interrupt. In other words, pending IOs don't mean they had just been completed when INTx interrupt happens.


-          nvmeStd.c:

o    Line 1657: Paul removed all support for CHATHAM in a previous patch (but left in CHATHAM2 support). Please remove the CHATHAM check from the code.

Will do it.

Thanks,
Ray

[Description: cid:image001.png at 01CB3870.4BB88E70]
Raymond C. Robles
Attached Platform Storage Software
Datacenter Software Division
Intel Corporation
Desk: 480.554.2600
Mobile: 480.399.0645

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20120907/9d82a21e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1756 bytes
Desc: image001.png
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20120907/9d82a21e/attachment.png>