linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: John Meneghini <jmeneghi@redhat.com>
Cc: Bryan Gurney <bgurney@redhat.com>,
	linux-nvme@lists.infradead.org, hch@lst.de, sagi@grimberg.me,
	axboe@kernel.dk, james.smart@broadcom.com,
	dick.kennedy@broadcom.com, njavali@marvell.com,
	linux-scsi@vger.kernel.org, hare@suse.de
Subject: Re: [PATCH v8 7/8] nvme: sysfs: emit the marginal path state in show_state()
Date: Tue, 15 Jul 2025 14:03:50 -0600	[thread overview]
Message-ID: <aHa0JpsASqGuHdOA@kbusch-mbp> (raw)
In-Reply-To: <35738598-0733-408c-8597-20c3599a8973@redhat.com>

On Tue, Jul 15, 2025 at 03:42:32PM -0400, John Meneghini wrote:
> On 7/9/25 6:12 PM, Keith Busch wrote:
> > On Wed, Jul 09, 2025 at 05:19:18PM -0400, Bryan Gurney wrote:
> > > If a controller has received a link integrity or congestion event, and
> > > has the NVME_CTRL_MARGINAL flag set, emit "marginal" in the state
> > > instead of "live", to identify the marginal paths.
> > 
> > IMO, this attribute looks more aligned to report in the ana_state
> > instead of overriding the controller's state.
> > 
> 
> We can't really do this because the ANA state is a documented protocol state.
> 
> The linux controller state is purely a linux software defined state.  Unless I am wrong, there is nothing in the NVMe specification which defines the nvme_ctrl_state.

Totally correct.
 
> This is purely a linux definition and we should be able to change is any way we want.

My kneejerk reaction is against adding new controller states. We have
state checks sprinkled about, and special states just make that more
fragile.
 
> We debated adding a new NVME_CTRL_MARGINAL state to this data structure,
> 
> enum nvme_ctrl_state {
>         NVME_CTRL_NEW,
>         NVME_CTRL_LIVE,
>         NVME_CTRL_RESETTING,
>         NVME_CTRL_CONNECTING,
>         NVME_CTRL_DELETING,
>         NVME_CTRL_DELETING_NOIO,
>         NVME_CTRL_DEAD,
> };
> 
> If you don't like the flag we can do that. However, that doesn't seem worth the effort since Hannes has this working now with a flag.

What you're describing is a "path" state, not a controller state which
is why I'm suggesting the "ana_state" attribute since nothing else
represents the path fitness. If nvme can't describe this condition, then
maybe it should?

Where does this 'FPIN LI' message originate from? The end point or
something inbetween? If it's the endpoint (or if both sides get the same
message?), then an ANA state to non-optimal should be possible, no? And
we already have the infrastructure to react to changing ANA states, so
you can transition to optimal if something gets repaired.


  reply	other threads:[~2025-07-15 20:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-09 21:19 [PATCH v8 0/8] nvme-fc: FPIN link integrity handling Bryan Gurney
2025-07-09 21:19 ` [PATCH v8 1/8] fc_els: use 'union fc_tlv_desc' Bryan Gurney
2025-07-09 21:19 ` [PATCH v8 2/8] nvme: add NVME_CTRL_MARGINAL flag Bryan Gurney
2025-07-09 21:19 ` [PATCH v8 3/8] nvme-fc: marginal path handling Bryan Gurney
2025-07-09 21:19 ` [PATCH v8 4/8] nvme-fc: nvme_fc_fpin_rcv() callback Bryan Gurney
2025-07-09 21:19 ` [PATCH v8 5/8] lpfc: enable FPIN notification for NVMe Bryan Gurney
2025-07-09 21:19 ` [PATCH v8 6/8] qla2xxx: " Bryan Gurney
2025-07-09 22:01   ` John Meneghini
2025-07-09 21:19 ` [PATCH v8 7/8] nvme: sysfs: emit the marginal path state in show_state() Bryan Gurney
2025-07-09 22:12   ` Keith Busch
2025-07-15 19:42     ` John Meneghini
2025-07-15 20:03       ` Keith Busch [this message]
2025-07-16  6:07         ` Hannes Reinecke
2025-07-22  2:57           ` Keith Busch
2025-07-22  6:41             ` Hannes Reinecke
2025-07-23 16:58               ` John Meneghini
2025-07-09 22:05 ` [PATCH v8 0/8] nvme-fc: FPIN link integrity handling John Meneghini

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=aHa0JpsASqGuHdOA@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=bgurney@redhat.com \
    --cc=dick.kennedy@broadcom.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=james.smart@broadcom.com \
    --cc=jmeneghi@redhat.com \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=njavali@marvell.com \
    --cc=sagi@grimberg.me \
    /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;
as well as URLs for NNTP newsgroup(s).