* [PATCH 1/2] lightnvm: add generic ocssd detection @ 2017-02-24 17:16 Matias Bjørling 2017-02-24 17:16 ` [PATCH 2/2] lightnvm: fix assert fixes and enable checks Matias Bjørling 2017-02-25 18:21 ` [PATCH 1/2] lightnvm: add generic ocssd detection Christoph Hellwig 0 siblings, 2 replies; 7+ messages in thread From: Matias Bjørling @ 2017-02-24 17:16 UTC (permalink / raw) To: linux-block, linux-kernel; +Cc: 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH 2/2] lightnvm: fix assert fixes and enable checks 2017-02-24 17:16 [PATCH 1/2] lightnvm: add generic ocssd detection Matias Bjørling @ 2017-02-24 17:16 ` Matias Bjørling 2017-02-25 18:21 ` [PATCH 1/2] lightnvm: add generic ocssd detection Christoph Hellwig 1 sibling, 0 replies; 7+ messages in thread From: Matias Bjørling @ 2017-02-24 17:16 UTC (permalink / raw) To: linux-block, linux-kernel; +Cc: 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] lightnvm: add generic ocssd detection 2017-02-24 17:16 [PATCH 1/2] lightnvm: add generic ocssd detection Matias Bjørling 2017-02-24 17:16 ` [PATCH 2/2] lightnvm: fix assert fixes and enable checks Matias Bjørling @ 2017-02-25 18:21 ` Christoph Hellwig 2017-02-25 19:16 ` Matias Bjørling 1 sibling, 1 reply; 7+ messages in thread From: Christoph Hellwig @ 2017-02-25 18:21 UTC (permalink / raw) To: Matias Bjørling; +Cc: linux-block, linux-kernel 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] lightnvm: add generic ocssd detection 2017-02-25 18:21 ` [PATCH 1/2] lightnvm: add generic ocssd detection Christoph Hellwig @ 2017-02-25 19:16 ` Matias Bjørling 2017-02-26 6:47 ` Christoph Hellwig 0 siblings, 1 reply; 7+ messages in thread From: Matias Bjørling @ 2017-02-25 19:16 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-block, linux-kernel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] lightnvm: add generic ocssd detection 2017-02-25 19:16 ` Matias Bjørling @ 2017-02-26 6:47 ` Christoph Hellwig 2017-02-27 18:35 ` Sagi Grimberg 0 siblings, 1 reply; 7+ messages in thread From: Christoph Hellwig @ 2017-02-26 6:47 UTC (permalink / raw) To: Matias Bjørling Cc: Christoph Hellwig, linux-block, linux-kernel, linux-nvme [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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] lightnvm: add generic ocssd detection 2017-02-26 6:47 ` Christoph Hellwig @ 2017-02-27 18:35 ` Sagi Grimberg 2017-02-27 18:50 ` Keith Busch 0 siblings, 1 reply; 7+ messages in thread From: Sagi Grimberg @ 2017-02-27 18:35 UTC (permalink / raw) To: Christoph Hellwig, Matias Bjørling Cc: linux-block, linux-kernel, linux-nvme > [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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] lightnvm: add generic ocssd detection 2017-02-27 18:35 ` Sagi Grimberg @ 2017-02-27 18:50 ` Keith Busch 0 siblings, 0 replies; 7+ messages in thread From: Keith Busch @ 2017-02-27 18:50 UTC (permalink / raw) To: Sagi Grimberg Cc: Christoph Hellwig, Matias Bjørling, linux-block, linux-kernel, linux-nvme 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-02-27 18:42 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-02-24 17:16 [PATCH 1/2] lightnvm: add generic ocssd detection Matias Bjørling 2017-02-24 17:16 ` [PATCH 2/2] lightnvm: fix assert fixes and enable checks Matias Bjørling 2017-02-25 18:21 ` [PATCH 1/2] lightnvm: add generic ocssd detection Christoph Hellwig 2017-02-25 19:16 ` Matias Bjørling 2017-02-26 6:47 ` Christoph Hellwig 2017-02-27 18:35 ` Sagi Grimberg 2017-02-27 18:50 ` Keith Busch
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).