[PATCH 1/2] lightnvm: add generic ocssd detection

[PATCH 1/2] lightnvm: add generic ocssd detection

[Matias Bjørling]

More implementations of OCSSDs are becoming available. Adding each using
pci ids are becoming a hassle. Instead, use a 16 byte string in the
vendor-specific area of the identification command to identify an
Open-Channel SSD.

The large string should make the collision probability with other
vendor-specific strings to be near nil.

Signed-off-by: Matias Bjørling <matias@cnexlabs.com>
---
 drivers/nvme/host/lightnvm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index 4ea9c93..e37b432 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -986,6 +986,9 @@ int nvme_nvm_ns_supported(struct nvme_ns *ns, struct nvme_id_ns *id)
 	/* XXX: this is poking into PCI structures from generic code! */
 	struct pci_dev *pdev = to_pci_dev(ctrl->dev);
 
+	if (!strncmp((char *)id->vs, "open-channel ssd", 16))
+		return 1;
+
 	/* QEMU NVMe simulator - PCI ID + Vendor specific bit */
 	if (pdev->vendor == PCI_VENDOR_ID_CNEX &&
 				pdev->device == PCI_DEVICE_ID_CNEX_QEMU &&
-- 
2.9.3

[PATCH 2/2] lightnvm: fix assert fixes and enable checks

[Matias Bjørling]

The asserts in _nvme_nvm_check_size are not compiled due to the function
not begin called. Make sure that it is called, and also fix the wrong
sizes of asserts for nvme_nvm_addr_format, and nvme_nvm_bb_tbl, which
checked for number of bits instead of bytes.

Reported-by: Scott Bauer <scott.bauer@intel.com>
Signed-off-by: Matias Bjørling <matias@cnexlabs.com>
---
 drivers/nvme/host/lightnvm.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index e37b432..b6a67ad 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -241,9 +241,9 @@ static inline void _nvme_nvm_check_size(void)
 	BUILD_BUG_ON(sizeof(struct nvme_nvm_l2ptbl) != 64);
 	BUILD_BUG_ON(sizeof(struct nvme_nvm_erase_blk) != 64);
 	BUILD_BUG_ON(sizeof(struct nvme_nvm_id_group) != 960);
-	BUILD_BUG_ON(sizeof(struct nvme_nvm_addr_format) != 128);
+	BUILD_BUG_ON(sizeof(struct nvme_nvm_addr_format) != 16);
 	BUILD_BUG_ON(sizeof(struct nvme_nvm_id) != 4096);
-	BUILD_BUG_ON(sizeof(struct nvme_nvm_bb_tbl) != 512);
+	BUILD_BUG_ON(sizeof(struct nvme_nvm_bb_tbl) != 64);
 }
 
 static int init_grps(struct nvm_id *nvm_id, struct nvme_nvm_id *nvme_nvm_id)
@@ -797,6 +797,8 @@ int nvme_nvm_register(struct nvme_ns *ns, char *disk_name, int node)
 	struct request_queue *q = ns->queue;
 	struct nvm_dev *dev;
 
+	_nvme_nvm_check_size();
+
 	dev = nvm_alloc_dev(node);
 	if (!dev)
 		return -ENOMEM;
-- 
2.9.3

Re: [PATCH 1/2] lightnvm: add generic ocssd detection

[Christoph Hellwig]

On Fri, Feb 24, 2017 at 06:16:48PM +0100, Matias Bj�rling wrote:
> More implementations of OCSSDs are becoming available. Adding each using
> pci ids are becoming a hassle. Instead, use a 16 byte string in the
> vendor-specific area of the identification command to identify an
> Open-Channel SSD.
> 
> The large string should make the collision probability with other
> vendor-specific strings to be near nil.

No way in hell.  vs is vendor specific and we absolutely can't overload
it with any sort of meaning.  Get OCSSD support properly standardized and
add a class code for it.  Until then it's individual PCI IDs.

Re: [PATCH 1/2] lightnvm: add generic ocssd detection

[Matias Bjørling]

On 02/25/2017 07:21 PM, Christoph Hellwig wrote:
> On Fri, Feb 24, 2017 at 06:16:48PM +0100, Matias Bj�rling wrote:
>> More implementations of OCSSDs are becoming available. Adding each using
>> pci ids are becoming a hassle. Instead, use a 16 byte string in the
>> vendor-specific area of the identification command to identify an
>> Open-Channel SSD.
>>
>> The large string should make the collision probability with other
>> vendor-specific strings to be near nil.
>
> No way in hell.  vs is vendor specific and we absolutely can't overload
> it with any sort of meaning.  Get OCSSD support properly standardized and
> add a class code for it.  Until then it's individual PCI IDs.
>

You are right, that is the right way to go, and we are working on it. In 
the meantime, there are a couple of reasons I want to do a pragmatic 
solution:

1. Enabling open-channel SSDs on NVMeoF. Customers are asking to use 
OCSSDs with NVMoeF. I do not think detection of PCI ids works with that.

2. Some vendors are circumventing the OCSSD detection by utilizing the 
CNEX Labs PCI ids. That is not very helpful and shows that there is a 
need for a generic approach. When they become public and will use their 
PCI id (if they will do that...), it is cumbersome to backport their PCI 
ids back to previous kernel versions to detect support.

3. Things are not a technical issue for why this is not adopted today. 
It will be soon enough one way or another, but until then, a pragmatic 
approach would go a long way.

If identify VS is too specific, is there another combination that solves 
the above in a generic and practical way that would satisfy you and the 
above?

-Matias

Re: [PATCH 1/2] lightnvm: add generic ocssd detection

[Christoph Hellwig]

[adding linux-nvme to Cc as the patch changes the nvme driver, despite
the subject line]

On Sat, Feb 25, 2017 at 08:16:04PM +0100, Matias Bj=F8rling wrote:
> On 02/25/2017 07:21 PM, Christoph Hellwig wrote:
> > On Fri, Feb 24, 2017 at 06:16:48PM +0100, Matias Bj=F8rling wrote:
> > > More implementations of OCSSDs are becoming available. Adding each us=
ing
> > > pci ids are becoming a hassle. Instead, use a 16 byte string in the
> > > vendor-specific area of the identification command to identify an
> > > Open-Channel SSD.
> > > =

> > > The large string should make the collision probability with other
> > > vendor-specific strings to be near nil.
> > =

> > No way in hell.  vs is vendor specific and we absolutely can't overload
> > it with any sort of meaning.  Get OCSSD support properly standardized a=
nd
> > add a class code for it.  Until then it's individual PCI IDs.
> > =

> =

> You are right, that is the right way to go, and we are working on it. In =
the
> meantime, there are a couple of reasons I want to do a pragmatic solution:

Reasonable reaosons, but that's just not how standard interfaces work.
Either you standardize the behaviour and have a standardized trigger
for it, or it is vendor specific and needs to be keyed off a specific
vendor/device identification.

> 1. Enabling open-channel SSDs on NVMeoF. Customers are asking to use OCSS=
Ds
> with NVMoeF. I do not think detection of PCI ids works with that.

To use NVMoeF your protocol needs to be NVMe.  Get it standardized.

> 2. Some vendors are circumventing the OCSSD detection by utilizing the CN=
EX
> Labs PCI ids. That is not very helpful and shows that there is a need for=
 a
> generic approach. When they become public and will use their PCI id (if t=
hey
> will do that...), it is cumbersome to backport their PCI ids back to
> previous kernel versions to detect support.

Sue them.

> 3. Things are not a technical issue for why this is not adopted today. It
> will be soon enough one way or another, but until then, a pragmatic appro=
ach
> would go a long way.

It's not a pragmatic approach, it's broken so please don't use these
whitewashing words.

> If identify VS is too specific, is there another combination that solves =
the
> above in a generic and practical way that would satisfy you and the above?

Standardize your interface and get a I/O command set bit for it
standardized in the NVMe spec.  You've had a year and a half since
the lightnvm code hit the kernel tree to do this.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: [PATCH 1/2] lightnvm: add generic ocssd detection

[Sagi Grimberg]

> [adding linux-nvme to Cc as the patch changes the nvme driver, despite
> the subject line]
>
> On Sat, Feb 25, 2017 at 08:16:04PM +0100, Matias Bj=F8rling wrote:
>> On 02/25/2017 07:21 PM, Christoph Hellwig wrote:
>>> On Fri, Feb 24, 2017 at 06:16:48PM +0100, Matias Bj=F8rling wrote:
>>>> More implementations of OCSSDs are becoming available. Adding each usi=
ng
>>>> pci ids are becoming a hassle. Instead, use a 16 byte string in the
>>>> vendor-specific area of the identification command to identify an
>>>> Open-Channel SSD.
>>>>
>>>> The large string should make the collision probability with other
>>>> vendor-specific strings to be near nil.
>>>
>>> No way in hell.  vs is vendor specific and we absolutely can't overload
>>> it with any sort of meaning.  Get OCSSD support properly standardized a=
nd
>>> add a class code for it.  Until then it's individual PCI IDs.
>>>
>>
>> You are right, that is the right way to go, and we are working on it. In=
 the
>> meantime, there are a couple of reasons I want to do a pragmatic solutio=
n:
>
> Reasonable reaosons, but that's just not how standard interfaces work.
> Either you standardize the behaviour and have a standardized trigger
> for it, or it is vendor specific and needs to be keyed off a specific
> vendor/device identification.

I agree, I don't see how we're allowed to use vs for that.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

Re: [PATCH 1/2] lightnvm: add generic ocssd detection

[Keith Busch]

On Mon, Feb 27, 2017 at 08:35:06PM +0200, Sagi Grimberg wrote:
> > On Sat, Feb 25, 2017 at 08:16:04PM +0100, Matias Bj�rling wrote:
> > > On 02/25/2017 07:21 PM, Christoph Hellwig wrote:
> > > > No way in hell.  vs is vendor specific and we absolutely can't overload
> > > > it with any sort of meaning.  Get OCSSD support properly standardized and
> > > > add a class code for it.  Until then it's individual PCI IDs.
> > > > 
> > > 
> > > You are right, that is the right way to go, and we are working on it. In the
> > > meantime, there are a couple of reasons I want to do a pragmatic solution:
> > 
> > Reasonable reaosons, but that's just not how standard interfaces work.
> > Either you standardize the behaviour and have a standardized trigger
> > for it, or it is vendor specific and needs to be keyed off a specific
> > vendor/device identification.
> 
> I agree, I don't see how we're allowed to use vs for that.

>From personal experience, some OEMs will put whatever they want in the
VS region for their rebranded device, making it an unreliable place to
check for a capability.