From: Sagi Grimberg <sagi@grimberg.me>
To: Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <kbusch@kernel.org>,
James Smart <james.smart@broadcom.com>,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH 1/3] nvme-fabrics: only reserve a single tag
Date: Mon, 15 Mar 2021 10:12:43 -0700 [thread overview]
Message-ID: <fc357ebb-f1a9-f927-1cf3-838330f57770@grimberg.me> (raw)
In-Reply-To: <20210306070944.GA28323@lst.de>
>>> Fabrics drivers currently reserve two tags on the admin queue. But
>>> given that the connect command is only run on a freshly created queue
>>> or after all commands have been force aborted we only need to reserve
>>> a single tag.
>>
>> Umm, I think this would be an issue for non-mpath fabrics devices...
>>
>> When we teardown the controller, we iterate over all tags
>> and cancel them, however for non-mpath devices these actually
>> stick around until they exhaust the retrys counter (with the
>> hope that the controller will reconnect again) unlike the mpath
>> case where the requests are failed-over.
>>
>> Now if the admin queue is absolutely full during a reset, we won't
>> have a keep-alive command.
>>
>> One possible solution is to make sure that
>> nvme_decide_disposition to complete a request for admin
>> commands. However note that this means that admin commands
>> would fail immediately when the controller resets, which is
>> a regression from the existing behavior and we may piss off
>> users with that...
>
> We never retry admin commands! And the reserved tags are set aside
> and not relevant to the "normal" commands.
You're right, admin commands will be noretry commands. this looks
good to me.
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2021-03-15 17:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-03 12:53 reserved tag allocation fixups Christoph Hellwig
2021-03-03 12:53 ` [PATCH 1/3] nvme-fabrics: only reserve a single tag Christoph Hellwig
2021-03-03 21:03 ` Daniel Wagner
2021-03-03 21:26 ` Chaitanya Kulkarni
2021-03-04 7:02 ` Hannes Reinecke
2021-03-05 20:51 ` Sagi Grimberg
2021-03-06 7:09 ` Christoph Hellwig
2021-03-15 17:12 ` Sagi Grimberg [this message]
2021-03-03 12:53 ` [PATCH 2/3] nvme: merge nvme_keep_alive into nvme_keep_alive_work Christoph Hellwig
2021-03-03 21:01 ` Daniel Wagner
2021-03-03 21:24 ` Chaitanya Kulkarni
2021-03-03 21:53 ` Chaitanya Kulkarni
2021-03-04 7:02 ` Hannes Reinecke
2021-03-15 17:13 ` Sagi Grimberg
2021-03-03 12:53 ` [PATCH 3/3] nvme: allocate the keep alive request using BLK_MQ_REQ_NOWAIT Christoph Hellwig
2021-03-03 21:00 ` Daniel Wagner
2021-03-03 21:22 ` Chaitanya Kulkarni
2021-03-04 7:03 ` Hannes Reinecke
2021-03-15 17:13 ` Sagi Grimberg
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=fc357ebb-f1a9-f927-1cf3-838330f57770@grimberg.me \
--to=sagi@grimberg.me \
--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.