[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fe5f7ae2-ccd2-4b5c-abb6-a5619813ed5b@flourine.local>
Date: Tue, 7 Jan 2025 15:40:18 +0100
From: Daniel Wagner <dwagner@...e.de>
To: Sagi Grimberg <sagi@...mberg.me>
Cc: Hannes Reinecke <hare@...e.de>, James Smart <james.smart@...adcom.com>,
Keith Busch <kbusch@...nel.org>, Christoph Hellwig <hch@....de>, Paul Ely <paul.ely@...adcom.com>,
linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/3] nvme: handle connectivity loss in
nvme_set_queue_count
On Tue, Dec 24, 2024 at 12:35:23PM +0200, Sagi Grimberg wrote:
> On 17/12/2024 10:35, Daniel Wagner wrote:
> > On Fri, Nov 29, 2024 at 12:10:33PM +0100, Hannes Reinecke wrote:
> > > > + /*
> > > > + * It's either a kernel error or the host observed a connection
> > > > + * lost. In either case it's not possible communicate with the
> > > > + * controller and thus enter the error code path.
> > > > + */
> > > > + if (status < 0 || status == NVME_SC_HOST_PATH_ERROR)
> > > > return status;
> > > > /*
> > > >
> > > Hmm. Maybe checking for NVME_SC_DNR, too?
> > if no one complains I'll update the check to:
> >
> > if (status < 0 || (status > 0 && (status & NVME_STATUS_DNR)) ||
> > status == NVME_SC_HOST_PATH_ERROR)
> > return status;
> >
> > okay?
> Why do we care about the DNR? are you going to retry based on it?
I don't know if we should care. Hannes brought this up.
Powered by blists - more mailing lists