Re: [SPDK] Is there any plan to add "quirk" mechanism to SPDK?

Re: [SPDK] Is there any plan to add "quirk" mechanism to SPDK?

[Walker, Benjamin]

[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]

We'd love to have you submit a patch to make nvme_intel.c generic (nvme_quirks.c). Please go ahead.

On Wed, 2016-09-28 at 10:16 +0800, Wang Weber wrote:

Thanks for the information.

Is there a plan to update nvme_intel.c to be geneirc? or may I modify
it and upload the patch to the community? Thanks.

2016-09-13 0:20 GMT+08:00 Daniel Verkamp <daniel.verkamp(a)intel.com<mailto:daniel.verkamp(a)intel.com>>:


On 09/09/2016 11:03 AM, Walker, Benjamin wrote:



Currently we have no mechanism for adding device-specific quirks to the
SPDK NVMe driver. We'd certainly consider adding quirks in the same
fashion as the Linux kernel driver though, and would welcome patches
that improved the applicability of SPDK to a wider range of (potentially
out of spec) devices. I'm sure over time the team at Intel working on
SPDK will add this, but it is not on our immediate roadmap, so patches
from the community would be the best way to get this going.

Thanks,
Ben




The SPDK NVMe driver does have a quirk system that is currently used only
for Intel-specific quirks (see lib/nvme/nvme_intel.c); however, the
structure used just matches against a PCI device ID in a generic way, so we
should be able to extend this for use with other devices.

I think the ideal first patch to add such a quirk would be to rename the
nvme_intel file and structures to be generic.  Then we could add new quirk
flags to describe whatever non-spec-compliant behavior is required to make
these devices work.

Thanks,
-- Daniel

_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org<mailto:SPDK(a)lists.01.org>
https://lists.01.org/mailman/listinfo/spdk


_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org<mailto:SPDK(a)lists.01.org>
https://lists.01.org/mailman/listinfo/spdk


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 2305 bytes --]

Re: [SPDK] Is there any plan to add "quirk" mechanism to SPDK?

[Wang Weber]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

Thanks for the information.

Is there a plan to update nvme_intel.c to be geneirc? or may I modify
it and upload the patch to the community? Thanks.

2016-09-13 0:20 GMT+08:00 Daniel Verkamp <daniel.verkamp(a)intel.com>:
> On 09/09/2016 11:03 AM, Walker, Benjamin wrote:
>>
>> Currently we have no mechanism for adding device-specific quirks to the
>> SPDK NVMe driver. We'd certainly consider adding quirks in the same
>> fashion as the Linux kernel driver though, and would welcome patches
>> that improved the applicability of SPDK to a wider range of (potentially
>> out of spec) devices. I'm sure over time the team at Intel working on
>> SPDK will add this, but it is not on our immediate roadmap, so patches
>> from the community would be the best way to get this going.
>>
>> Thanks,
>> Ben
>
>
> The SPDK NVMe driver does have a quirk system that is currently used only
> for Intel-specific quirks (see lib/nvme/nvme_intel.c); however, the
> structure used just matches against a PCI device ID in a generic way, so we
> should be able to extend this for use with other devices.
>
> I think the ideal first patch to add such a quirk would be to rename the
> nvme_intel file and structures to be generic.  Then we could add new quirk
> flags to describe whatever non-spec-compliant behavior is required to make
> these devices work.
>
> Thanks,
> -- Daniel
>
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk

Re: [SPDK] Is there any plan to add "quirk" mechanism to SPDK?

[Daniel Verkamp]

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

On 09/09/2016 11:03 AM, Walker, Benjamin wrote:
> Currently we have no mechanism for adding device-specific quirks to the
> SPDK NVMe driver. We'd certainly consider adding quirks in the same
> fashion as the Linux kernel driver though, and would welcome patches
> that improved the applicability of SPDK to a wider range of (potentially
> out of spec) devices. I'm sure over time the team at Intel working on
> SPDK will add this, but it is not on our immediate roadmap, so patches
> from the community would be the best way to get this going.
>
> Thanks,
> Ben

The SPDK NVMe driver does have a quirk system that is currently used 
only for Intel-specific quirks (see lib/nvme/nvme_intel.c); however, the 
structure used just matches against a PCI device ID in a generic way, so 
we should be able to extend this for use with other devices.

I think the ideal first patch to add such a quirk would be to rename the 
nvme_intel file and structures to be generic.  Then we could add new 
quirk flags to describe whatever non-spec-compliant behavior is required 
to make these devices work.

Thanks,
-- Daniel

Re: [SPDK] Is there any plan to add "quirk" mechanism to SPDK?

[Walker, Benjamin]

[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]

Currently we have no mechanism for adding device-specific quirks to the SPDK NVMe driver. We'd certainly consider adding quirks in the same fashion as the Linux kernel driver though, and would welcome patches that improved the applicability of SPDK to a wider range of (potentially out of spec) devices. I'm sure over time the team at Intel working on SPDK will add this, but it is not on our immediate roadmap, so patches from the community would be the best way to get this going.

Thanks,
Ben

On Thu, 2016-09-08 at 14:25 +0800, Wang Weber wrote:
Hi,

In online FW upgrade process, the memblaze Pblaze4 NVMe device requires an extra delay during controller reset process. The following patch email from HGST describes the similar issue in detail.



Subject: [PATCH v3] nvme/quirk: Add a delay before checking for adapter readiness



When disabling the controller, the specification says the register NVME_REG_CC should be written and then driver needs to wait the adapter to be ready, which is checked by reading another register bit (NVME_CSTS_RDY). There's a timeout validation in this checking, so in case this timeout is reached the driver gives up and removes the adapter from the system.



After a firmware activation procedure, the PCI_DEVICE(0x1c58, 0x0003) (HGST adapter) end up being removed if we issue a reset_controller, because driver keeps verifying the NVME_REG_CSTS until the timeout is reached. This patch adds a necessary quirk for this adapter, by introducing a delay before nvme_wait_ready(), so the reset procedure is able to be completed. This quirk is needed because just increasing the timeout is not enough in case of this adapter - the driver must wait before start reading NVME_REG_CSTS register on this specific device.


The standard Linux NVMe driver now has quirk “NVME_QUIRK_DELAY_BEFORE_CHK_RDY” for HGST and memblaze devices. Is there any plan to add this to SPDK?


Thanks,
-Wenbo

_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org<mailto:SPDK(a)lists.01.org>
https://lists.01.org/mailman/listinfo/spdk


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3345 bytes --]

[SPDK] Is there any plan to add "quirk" mechanism to SPDK?

[Wang Weber]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

Hi,



In online FW upgrade process, the memblaze Pblaze4 NVMe device requires an
extra delay during controller reset process. The following patch email from
HGST describes the similar issue in detail.





*Subject: [PATCH v3] nvme/quirk: Add a delay before checking for adapter
readiness*



*When disabling the controller, the specification says the register
NVME_REG_CC should be written and then driver needs to wait the adapter to
be ready, which is checked by reading another register bit (NVME_CSTS_RDY).
There's a timeout validation in this checking, so in case this timeout is
reached the driver gives up and removes the adapter from the system.*



*After a firmware activation procedure, the PCI_DEVICE(0x1c58, 0x0003)
(HGST adapter) end up being removed if we issue a reset_controller, because
driver keeps verifying the NVME_REG_CSTS until the timeout is reached. This
patch adds a necessary quirk for this adapter, by introducing a delay
before nvme_wait_ready(), so the reset procedure is able to be completed.
This quirk is needed because just increasing the timeout is not enough in
case of this adapter - the driver must wait before start reading
NVME_REG_CSTS register on this specific device.*





The standard Linux NVMe driver now has quirk
“NVME_QUIRK_DELAY_BEFORE_CHK_RDY” for HGST and memblaze devices. Is there
any plan to add this to SPDK?





Thanks,

-Wenbo

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 2261 bytes --]