From: Sagi Grimberg <sagi@grimberg.me>
To: Victor Gladkov <Victor.Gladkov@kioxia.com>,
Hannes Reinecke <hare@suse.de>
Cc: Keith Busch <kbusch@kernel.org>,
"Ewan D. Milne" <emilne@redhat.com>,
Christoph Hellwig <hch@lst.de>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
James Smart <james.smart@broadcom.com>
Subject: Re: [PATCH v7] nvme-fabrics: reject I/O to offline device
Date: Tue, 11 Aug 2020 13:56:04 -0700 [thread overview]
Message-ID: <ad7afffa-40b5-6cf8-6dff-21a32328c552@grimberg.me> (raw)
In-Reply-To: <45d34d7927354b6393859048c257cb86@kioxia.com>
>> Commands get stuck while Host NVMe controller (TCP or RDMA) is in
>> reconnect state. NVMe controller enters into reconnect state when it
>> loses connection with the target. It tries to reconnect every 10
>> seconds (default) until successful reconnection or until reconnect
>> time-out is reached. The default reconnect time out is 10 minutes.
>>
>> To fix this long delay due to the default timeout we introduce new
>> session parameter "fast_io_fail_tmo". The timeout is measured in
>> seconds from the controller reconnect, any command beyond that
>> timeout is rejected. The new parameter value may be passed during
>> 'connect'.
>> The default value of 0 means no timeout (similar to current behavior).
>
> I'd like to remind you that this improvement is pending for commit.
> Pay attention, please.
I think we still have a question to why is this fabrics specific, and
if this is needed in fabrics, why is it not needed in pci as well.
Keith? Personally speaking, I also share Chirstoph's opinion that
if it's not clearly fabrics specific, we should try to make pci
and fabrics unified.
Your thoughts on this?
_______________________________________________
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-11 20:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-08 15:07 [PATCH v7] nvme-fabrics: reject I/O to offline device Victor Gladkov
2020-07-09 20:34 ` James Smart
2020-07-10 4:50 ` Sagi Grimberg
2020-07-10 6:58 ` Hannes Reinecke
2020-07-14 11:04 ` Christoph Hellwig
2020-07-22 22:57 ` Sagi Grimberg
2020-08-09 15:32 ` Victor Gladkov
2020-08-11 20:56 ` Sagi Grimberg [this message]
2020-08-12 14:09 ` Victor Gladkov
2020-08-13 15:00 ` James Smart
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=ad7afffa-40b5-6cf8-6dff-21a32328c552@grimberg.me \
--to=sagi@grimberg.me \
--cc=Victor.Gladkov@kioxia.com \
--cc=emilne@redhat.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=james.smart@broadcom.com \
--cc=kbusch@kernel.org \
--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 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.