From: Christoph Hellwig <hch@lst.de>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, Chao Leng <lengchao@huawei.com>,
axboe@fb.com, sagi@grimberg.me, linux-nvme@lists.infradead.org,
linux-block@vger.kernel.org, kbusch@kernel.org
Subject: Re: [PATCH 2/3] nvme-core: delete the dependency on blk status
Date: Thu, 13 Aug 2020 17:47:57 +0200 [thread overview]
Message-ID: <20200813154757.GA14486@lst.de> (raw)
In-Reply-To: <20200812202829.GA586@redhat.com>
On Wed, Aug 12, 2020 at 04:28:30PM -0400, Mike Snitzer wrote:
> On Wed, Aug 12 2020 at 11:10am -0400,
> Christoph Hellwig <hch@lst.de> wrote:
>
> > On Wed, Aug 12, 2020 at 04:18:44PM +0800, Chao Leng wrote:
> > > nvme should not depend on blk status, just need check nvme status.
> > > Just need do translating nvme status to blk status for returning error.
> >
> > While this doesn't look wrong it also doesn't save us a single
> > instruction and actually adds more lines of code. Do you have a good
> > reason for this change?
>
> It certainly saves nvme_error_status(nvme_req(req)->status if
> nvme_req_needs_retry().
Yeah, but the retry path isn't exactly the fast path, is it?
Not that I really care too much about this one..
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Mike Snitzer <snitzer@redhat.com>
Cc: linux-block@vger.kernel.org, sagi@grimberg.me,
linux-nvme@lists.infradead.org, axboe@fb.com,
Chao Leng <lengchao@huawei.com>,
kbusch@kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 2/3] nvme-core: delete the dependency on blk status
Date: Thu, 13 Aug 2020 17:47:57 +0200 [thread overview]
Message-ID: <20200813154757.GA14486@lst.de> (raw)
In-Reply-To: <20200812202829.GA586@redhat.com>
On Wed, Aug 12, 2020 at 04:28:30PM -0400, Mike Snitzer wrote:
> On Wed, Aug 12 2020 at 11:10am -0400,
> Christoph Hellwig <hch@lst.de> wrote:
>
> > On Wed, Aug 12, 2020 at 04:18:44PM +0800, Chao Leng wrote:
> > > nvme should not depend on blk status, just need check nvme status.
> > > Just need do translating nvme status to blk status for returning error.
> >
> > While this doesn't look wrong it also doesn't save us a single
> > instruction and actually adds more lines of code. Do you have a good
> > reason for this change?
>
> It certainly saves nvme_error_status(nvme_req(req)->status if
> nvme_req_needs_retry().
Yeah, but the retry path isn't exactly the fast path, is it?
Not that I really care too much about this one..
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-08-13 15:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-12 8:18 [PATCH 2/3] nvme-core: delete the dependency on blk status Chao Leng
2020-08-12 8:18 ` Chao Leng
2020-08-12 15:10 ` Christoph Hellwig
2020-08-12 15:10 ` Christoph Hellwig
2020-08-12 20:28 ` Mike Snitzer
2020-08-12 20:28 ` Mike Snitzer
2020-08-13 15:47 ` Christoph Hellwig [this message]
2020-08-13 15:47 ` Christoph Hellwig
2020-08-13 3:53 ` Chao Leng
2020-08-13 3:53 ` Chao Leng
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=20200813154757.GA14486@lst.de \
--to=hch@lst.de \
--cc=axboe@fb.com \
--cc=kbusch@kernel.org \
--cc=lengchao@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=snitzer@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.