[nvmewin] LBA range types

[Luse, Paul E]

Yeah, maybe the better way to handle this is to instead get rid of the code that exists now that considers it a fatal error if get features for LBA range type fails as it is optional in both 1b and 1c and then update qemu to reject the command correctly.  I'll look into a bit more before submitting a patch

Thx
Paul

From: Chang, Alex [mailto:Alex.Chang at idt.com]
Sent: Tuesday, April 03, 2012 2:14 PM
To: Luse, Paul E; nvmewin at lists.openfabrics.org
Subject: RE: LBA range types

Paul,

Per NVMe specification, multiple LBA range types can be supported. However, the current driver supports only one for the time being.
Apparently, only TYPE Filesystem is supported, which is agreed by all of us. If it's Reserved, Set Features command is issued to change it to Filesystem with Hidden as FALSE and Readonly as FALSE. My thinking for this is it can be pretty complex and it's really up to certain specific needs. Based on what the driver is implemented, it's still compliant with the 1b specification.
I am fine with the change you are adding. However, I wonder if it will be defined in 1c or just a proprietary assumption?

Thanks,
Alex

________________________________
From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org]<mailto:[mailto:nvmewin-bounces at lists.openfabrics.org]> On Behalf Of Luse, Paul E
Sent: Tuesday, April 03, 2012 1:36 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] LBA range types
Alex,

I think you and Kwok were the last ones paying attention to range type discussions in the NVMe WG, so I'll ask you.  I have a change I'm planning on submitting in the next few weeks that has SNTI honor the hidden attribute however when I added it I quickly discovered that QEMU doesn't report any info for LBA range type and our existing code (on the left below) see the mismatch between range LBAs an namespace size as an indication that there are multiple ranges when in this case it really just means the device gave us all 0's for LBA range info.  I notice 1.0c has the device reporting the number of range types in DW0 of the completion entry and since its zero based a device saying 0 now still works so I replaced the size check with that and added a size check to see if the device is reporting the LBA range as size 0 I assume it doesn't support range types at all and just expose it.

Can you fill us all in on the latest thoughts wrt range types and how we're supposed to deal with the various scenarios (multiples, un-configured, etc).  Also, let me know if you think the changes below are reasonable and I'll include them in my next patch.

Thx
Paul


[cid:image002.jpg at 01CD11A9.A7DEBCB0]

____________________________________
Paul Luse
Sr. Staff Engineer
PCG Server Software Engineering
Desk: 480.554.3688, Mobile: 480.334.4630

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20120403/c264755e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 408874 bytes
Desc: image002.jpg
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20120403/c264755e/attachment.jpg>