RE: [PATCH 13/14] nvme: use the changed namespaces list log to clear ns data changed AENs

["Knight, Frederick" <Frederick.Knight@netapp.com>]

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

Section 5.2:

Asynchronous events are grouped into event types. The event type information is indicated in Dword 0 of the completion queue entry for the Asynchronous Event Request command. When the controller posts a completion queue entry for an outstanding Asynchronous Event Request command and thus reports an asynchronous event, subsequent events of that event type are automatically masked by the controller until the host clears that event. An event is cleared by reading the log page associated with that event using the Get Log Page command (refer to section 5.14).

The event is cleared by reading the log page associated with that event ...   I don't know how the event can be cleared if the associated log page is not supported (the masking of subsequent events of that type would turn it into a one-shot).  Interesting however, in the list (that reports "the following event types are defined"), there are several of the defined events missing.  Looks like an ECN opportunity to flush out that list of defined event types.

In addition, how is this bit set:

95:92   M       Optional Asynchronous Events Supported (OAES): This field indicates the optional asynchronous events supported by the controller. A controller shall not send optional asynchronous events before they are enabled by host software.

Bits 31:10 are reserved.
Bit 9 is set to '1' if the controller supports sending Firmware Activation Notices. If cleared to '0', then the controller does not support the Firmware Activation Notices event.

Bit 8 is set to '1' if the controller supports sending Namespace Attribute Notices and the associated Changed Namespace List log page. If cleared to '0', then the controller does not support the Namespace Attribute Notices event nor the associated Changed Namespace List log page.
Bits 7:0 are reserved.

Not sure how you set that bit if you support the AEN but not the log page.

        Fred

-----Original Message-----
From: Christoph Hellwig <hch@lst.de>
Sent: Saturday, May 26, 2018 8:22 AM
To: Popuri, Sriram <Sriram.Popuri@netapp.com>
Cc: Christoph Hellwig <hch@lst.de>; linux-nvme@lists.infradead.org; Knight, Frederick <Frederick.Knight@netapp.com>; Jens Axboe <axboe@kernel.dk>; Keith Busch <keith.busch@intel.com>; linux-block@vger.kernel.org; Sagi Grimberg <sagi@grimberg.me>; Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH 13/14] nvme: use the changed namespaces list log to clear ns data changed AENs

On Sat, May 26, 2018 at 12:05:02PM +0000, Popuri, Sriram wrote:
> Reading the spec it looks like ns log is alternate approach:
>
> "Namespace Attribute Changed: The Identify Namespace data structure for one or more namespaces, as well as the Namespace List returned when the Identify command is issued with the CNS field set to 02h, have changed. Host software may use this event as an indication that it should read the Identify Namespace data structures for each namespace to determine what has changed.
>
> Alternatively, host software may request the Changed Namespace List (Log Identifier 04h) to determine which namespaces in this controller have changed Identify Namespace information since the last time the log page was read."
>
> My question is: Does the target needs to implement log page 04h as this is an optional log page and the text above suggests its used in alternate way?

Section 5.2 clearly states that each AER comes with a log page to
clear it, and the above does not contain any language to explicitly
override it. So my reading of the spec is that to clear the event you need
to read the log page, but to find out what has changed you might issue
Identify commands instead.

> If target is not required to implement, then I guess your change should still work because if log page 04h fails, it fails back to rescan. Correct?

Independ of what the spec actually requires, the code tries to robust
as possible and falls back to doing the manual scan.

> I think you can optimize this by checking the "Log Page Identifier" field in your result and accordingly setting EVENT_NS_CHANGED. I assume target would clear this if log page 04h is not supported.

We can try that, but I'm not sure what it is going to buy us.


[-- Attachment #2: Type: text/html, Size: 6990 bytes --]