mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Christoph Hellwig <hch@lst.de>, Maximilian Heyne <mheyne@amazon.de>
Cc: Amit Shah <aams@amazon.de>, Keith Busch <keith.busch@intel.com>,
	Jens Axboe <axboe@fb.com>, Sagi Grimberg <sagi@grimberg.me>,
	linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] nvme: add per-device io and admin timeouts
Date: Fri, 29 Mar 2019 10:29:25 +0000	[thread overview]
Message-ID: <b6fd1c99f0a718033ee44ba8ff233dacd7247f15.camel@infradead.org> (raw)
In-Reply-To: <20190329094440.GA27315@lst.de>

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

On Fri, 2019-03-29 at 10:44 +0100, Christoph Hellwig wrote:
> On Fri, Mar 29, 2019 at 09:39:20AM +0000, Maximilian Heyne wrote:
> > Some NVMe devices require specific io and admin timeouts that are
> > different from the default, for instance local vs. remote storage.
> > 
> > This patch adds per-device admin and io timeouts to the nvme_ctrl
> > structure and replaces all usages of the module parameters in the PCI
> > NVMe driver with the per-device timeouts.
> 
> I'm not all against a per-controller override, but if you controllers
> really _require_ a different timeout this is not the way to go.
> 
> Please talk to the nvme technical working group about exposing a
> default timeout in the controller as that is the only way to make
> these things work out of box.


Yeah, that's a good idea and would work well on top of these patches
when it eventually gets through the process.

In the meantime, people running Linux in certain environments are
having to hack their kernel to change the default timeout. Being able
to do it through sysfs is much saner.

Max, we should probably also implement this for at least the TCP back
end, which is going to want it for much the same reasons we do, and it
really does want to be tunable by the user there (and should probably
remain so in the general case even when we do improve the spec).


Note that this isn't strictly "required" but if your transport has a
SLA which permits outages of a certain period of time (for example
however long it takes a switch to restart), then having the NVMe
timeout exceed that value is kind of nice.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]

      reply	other threads:[~2019-03-29 10:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-29  9:39 Maximilian Heyne
2019-03-29  9:39 ` [PATCH 2/2] nvme: add sysfs controls for " Maximilian Heyne
2019-03-29  9:44 ` [PATCH 1/2] nvme: add per-device " Christoph Hellwig
2019-03-29 10:29   ` David Woodhouse [this message]

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=b6fd1c99f0a718033ee44ba8ff233dacd7247f15.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=aams@amazon.de \
    --cc=axboe@fb.com \
    --cc=hch@lst.de \
    --cc=keith.busch@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=mheyne@amazon.de \
    --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

all inboxes | Powered by JetHome®