Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1588190 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/2] lightnvm: add generic ocssd detection Christoph Hellwig <hch@infradead.org> - 2017-02-25 19:30 +0100
    Re: [PATCH 1/2] lightnvm: add generic ocssd detection Christoph Hellwig <hch@infradead.org> - 2017-02-26 09:20 +0100
      Re: [PATCH 1/2] lightnvm: add generic ocssd detection Keith Busch <keith.busch@intel.com> - 2017-02-27 19:50 +0100
      Re: [PATCH 1/2] lightnvm: add generic ocssd detection Sagi Grimberg <sagi@grimberg.me> - 2017-02-27 20:50 +0100

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

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.

[toc] | [next] | [standalone]

#1588300

[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.

[toc] | [prev] | [next] | [standalone]

#1588864

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.

[toc] | [prev] | [next] | [standalone]

#1588897

> [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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web