[nvmewin] SCSI Translation Issues

Robles, Raymond C raymond.c.robles at intel.com
Tue Mar 5 19:37:37 PST 2013


Alex/Kwok,

For READ 6, a zero transfer length indicates 256 LBAs must be read. For READ 10/12/16/32, the SBC-3 spec states that a zero transfer length field "specifies that no logical blocks shall be read. This condition shall not be considered an error...".  The correct behavior is to return a no data for the READ and return SRB_STATUS_SUCCESS for the SCSI READ request. For WRITEs, the behavior is the same (only no data is transferred to the device). In either case, the SRB is completed successfully.

[cid:image003.jpg at 01CE19E1.41893490]


To answer Alex's question, in this case of a zero transfer length for READ/WRITE (other than READ 6 and WRITE 6), this is a valid case, there should be no NVMe command sent to the device (SCSI target), and the SRB should complete successfully.
Thanks,
Ray

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

Sure. I will go ahead fix them and let's see if anyone have different ideas about #2...

Thanks,
Alex
________________________________
From: Kong, Kwok
Sent: Tuesday, March 05, 2013 5:59 PM
To: Chang, Alex; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: 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/20130306/06a80b54/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 29048 bytes
Desc: image003.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20130306/06a80b54/attachment.jpg>


More information about the nvmewin mailing list