| Message ID | 20170224171649.27409-1-matias@cnexlabs.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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
[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ørling wrote: > 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: 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 OCSSDs > 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 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. 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 approach > 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.
> [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ørling wrote: >> 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: > > 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.
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.
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 &&
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(+)