[nvmewin] SCSI Translation Issues

[Chang, Alex]

Thanks a lot, Neal, for your feedback.

Regards,
Alex

________________________________
From: Neal Galbo (ngalbo) [mailto:ngalbo at micron.com]
Sent: Monday, March 11, 2013 10:55 AM
To: Judy Brock-SSI; Kong, Kwok; Chang, Alex; nvmewin at lists.openfabrics.org
Subject: RE: SCSI Translation Issues

Better late, then never.


è Would a SCSI expert please explain what the driver (or a SCSI device) is supposed to do when the number of request LBA is 0 ?

Depends upon the command. With SCSI READ/WRITE 6 command, a zero value means transfer 256 LBA's. For READ/WRITE (10, 12,16,32) the specs say the following:
A TRANSFER LENGTH field set to zero specifies that no logical blocks shall be read. This condition shall not be
considered an error.
... meaning the command completes successfully; just no data is transferred, as Judy mentioned.

A zero transfer length is common in loops of read/write commands where the remaining LBA transfer length is calculated and where the test for loop termination is done AFTER the command has been sent. SCSI programmers expect this behavior for zero length transfers.

-Neal


From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Judy Brock-SSI
Sent: Tuesday, March 05, 2013 11:09 PM
To: Kong, Kwok; Chang, Alex; nvmewin at lists.openfabrics.org
Subject: Re: [nvmewin] SCSI Translation Issues

I agree with Kwok regarding how to translate #2 below. For SCSI, requesting  a transfer of zero LBAs is not considered an error - it just means no LBAs will be transferred. Mapping this to simply returning 'OK' status for NVMe is the functional equivalent.

Judy

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Kong, Kwok
Sent: Tuesday, March 05, 2013 6:00 PM
To: Chang, Alex; nvmewin at lists.openfabrics.org
Subject: Re: [nvmewin] SCSI Translation Issues

Alex,

I think #1 and #3 are bugs in the driver and should be fixed according to your suggestion.  I am ok for you to fix them.

#2. CDB request 0 LBA.

NVMe requires the number of LBA requested to be 0's.  The minimum number of LBA requested is 1. A request of 0 LBA cannot be sent to a NVMe device.
In my view, the driver should return "OK" status to the port driver immediately without any further processing when the number of LBA requested is 0.
Since the request size is 0, the driver has completed the request with exactly 0 byte of data being transferred. (means no action is required).

Any other opinion on what the driver should do when the number of LBA requested is 0 ?

Would a SCSI expert please explain what the driver (or a SCSI device) is supposed to do when the number of request LBA is 0 ?

Thanks

-Kwok



From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Chang, Alex
Sent: Monday, March 04, 2013 5:03 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] SCSI Translation Issues

Hi all,

After reviewing the translation codes from SCSI to NVMe more carefully, it seems there are some potential issues we might want to address sooner than later:
1. We don't handle buffer over/under run cases for read/write commands. For example, when the number of LBAs coded in CDB requires larger buffer size than indicated in DataTransferLength of SRB, the driver needs to return Check Condition and proper status. In under-run case, driver needs to mark down the actual transfer size in DataTransferLength before completing the request back to Storport.
2. How do we handle the case when the number of LBAs coded in CDB is zero? I think the number of LBAs for read/write commands is 0's based defined in NVMe specification. Is it a valid case?
3. For Read6/Write6, there is only one byte (byte 4) in CDB to indicate the transfer length. When the value of byte 4 is zero, it indicates the number of LBAs to transfer is 256. In that case, what driver does is subtracting 1 from 0 and assigning 0xFFFF to DW12. Apparently, it's a known bug.

I can fix the potential issues mentioned above. However, I need you inputs regarding how we are going to handle #2.

Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20130311/edd80dbe/attachment.html>