[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <db5ce3ae-d8a9-4d8d-acd8-d696654c77e7@flourine.local>
Date: Wed, 16 Apr 2025 13:37:53 +0200
From: Daniel Wagner <dwagner@...e.de>
To: Mohamed Khalfella <mkhalfella@...estorage.com>
Cc: Daniel Wagner <wagi@...nel.org>, Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>, Keith Busch <kbusch@...nel.org>, Hannes Reinecke <hare@...e.de>,
John Meneghini <jmeneghi@...hat.com>, randyj@...estorage.com, linux-nvme@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 1/3] nvmet: add command quiesce time
On Thu, Apr 10, 2025 at 02:00:22AM -0700, Mohamed Khalfella wrote:
> > --- a/drivers/nvme/target/nvmet.h
> > +++ b/drivers/nvme/target/nvmet.h
> > @@ -671,6 +671,7 @@ bool nvmet_subsys_nsid_exists(struct nvmet_subsys *subsys, u32 nsid);
> >
> > #define NVMET_KAS 10
> > #define NVMET_DISC_KATO_MS 120000
> > +#define NVMET_CQT 1
>
> Setting CQT to 1 is a promise to initiator that target will quiesce
> pending requests in 1ms after it detects loss of kato traffic. For
> initiator, it means these requests can be retried safely in 1m after
> kato delay. Is this guaranteed by target?
>
> I thought leaving the value 0 means CQT is not implemented, no?
I decided to go with the first clause (9.6.2 End of Controller
Processing of Outstanding Commands)
- If the CQT field (refer to Figure 312) is non-zero, wait for the
amount of time indicated in the CQT field to elapse; or
- If the CQT field is cleared to 0h, wait for an implementation specific
amount of time (e.g. 10 seconds). The host should allow this value to
be administratively configured.
The nvmet doesn't need the CQT thus set it to the smallest amount of
time. But yes this should be configurable for testing purposes with
blktests.
Powered by blists - more mailing lists