From: Keith Busch <kbusch@kernel.org>
To: Tokunori Ikegami <ikegami.t@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>, linux-nvme@lists.infradead.org
Subject: Re: [PATCH v3 2/2] nvme: initialize known effects to set ns_mgmt NCC and ns_attach NIC
Date: Wed, 29 Apr 2026 09:48:40 +0100 [thread overview]
Message-ID: <afHF6FJAPbDXAniR@kbusch-mbp.client.m3-hotspots.de> (raw)
In-Reply-To: <56500e42-51c6-4be9-aff1-f11b45c47b13@gmail.com>
On Wed, Apr 29, 2026 at 03:08:59PM +0900, Tokunori Ikegami wrote:
> On 2026/04/28 15:51, Keith Busch wrote:
> > I suppose that's why the "known_effects" exists, but it'd be
> > dissappointing if we really need this. The other opcodes in there
> > existed before the Command Effects Log was created, so understandable
> > that controllers may not implement it. But NS management/attach were
> > introduced after the log, and there is also the AEN that the driver
> > could rescan on receipt, so it's doubly bad if a controller
> > implementation really needs this.
>
> Just rechecked the specification again then the log page identifier:
> commands supported and effects mentioned is optional for NVM express
> revision 1.4 and earlier then for the older controller the changes not bad I
> think.
Yes, but the namespace management commands are also optional, so it
sounds weird to me for an implementation to choose to support the
optional command that's more difficult to do and skip the easy log page
that advertises support for it.
> By the way about the scan_work executions for the command effects log and
> AEN I thought it is better to be handled only once but I do not have an
> actual idea for the exclusive control.
You can attach namespaces to controllers driven by a different host, so
the AEN is the only way to trigger a rescan in such a scenario without
admin intervention. An extra scan_work is otherwise harmless, I don't
see a particular need to introduce a mechanism to avoid it.
next prev parent reply other threads:[~2026-04-29 8:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-25 13:04 [PATCH v3 0/2] scan_work improvement Tokunori Ikegami
2026-04-25 13:04 ` [PATCH v3 1/2] nvme: delete unnecessary empty lines Tokunori Ikegami
2026-04-25 13:04 ` [PATCH v3 2/2] nvme: initialize known effects to set ns_mgmt NCC and ns_attach NIC Tokunori Ikegami
2026-04-28 6:51 ` Keith Busch
2026-04-29 6:08 ` Tokunori Ikegami
2026-04-29 8:48 ` Keith Busch [this message]
2026-04-29 12:49 ` Tokunori Ikegami
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=afHF6FJAPbDXAniR@kbusch-mbp.client.m3-hotspots.de \
--to=kbusch@kernel.org \
--cc=hch@infradead.org \
--cc=ikegami.t@gmail.com \
--cc=linux-nvme@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox