From: Keith Busch <kbusch@kernel.org>
To: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Cc: hch@lst.de, linux-nvme@lists.infradead.org, sagi@grimberg.me
Subject: Re: [PATCH 0/4] nvmet: add set feature based timestamp support
Date: Wed, 19 Feb 2020 08:10:07 +0900 [thread overview]
Message-ID: <20200218231007.GA18306@redsun51.ssa.fujisawa.hgst.com> (raw)
In-Reply-To: <20200218214338.25088-1-chaitanya.kulkarni@wdc.com>
On Tue, Feb 18, 2020 at 01:43:34PM -0800, Chaitanya Kulkarni wrote:
> This is a small patch-series which implements set-feature based
> controller timestamp feature support for NVMeOF Target controller.
> This allows host to set the timestamp using set feature and read it
> with get feature commands when controllers are distributed across
> different systems. We return the value set with a Set Features
> command for the current value plus the elapsed time since being set.
> NVMe [1].
>
> Regards,
> Chaitanya
>
> [1] NVMExpress Revision 1.4 (Page 220) Set Timestamp Origin -> 001b.
>
> Chaitanya Kulkarni (4):
> nvmet: use nvmet_feat_data_len consistently
> nvmet: add support for set-feat-timestamp cmd
> nvmet: add support for get-feat-timestamp cmd
> nvmet: update ctrl oncs values for timestamp
Patch 1 looks good.
The last three ought to be a single patch IMO since those should really
from an inseparable package deal for this feature.
My only comment on the implementation is you need to initialize nvmet_ctrl
'ts' and 'local_ts' on each reset so that we have correct values to
report in case the host never sets the timestamp.
As to why we'd support this feature, the spec says "The use of the
Timestamp is outside the scope of this specification". Is there anything
interesting we can do with 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-02-18 23:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 21:43 [PATCH 0/4] nvmet: add set feature based timestamp support Chaitanya Kulkarni
2020-02-18 21:43 ` [PATCH 1/4] nvmet: use nvmet_feat_data_len consistently Chaitanya Kulkarni
2020-02-19 14:59 ` Christoph Hellwig
2020-02-18 21:43 ` [PATCH 2/4] nvmet: add support for set-feat-timestamp cmd Chaitanya Kulkarni
2020-02-18 21:43 ` [PATCH 3/4] nvmet: add support for get-feat-timestamp cmd Chaitanya Kulkarni
2020-02-18 21:43 ` [PATCH 4/4] nvmet: update ctrl oncs values for timestamp Chaitanya Kulkarni
2020-02-18 23:10 ` Keith Busch [this message]
2020-02-19 14:59 ` [PATCH 0/4] nvmet: add set feature based timestamp support Christoph Hellwig
2020-02-19 15:49 ` Chaitanya Kulkarni
2020-02-20 7:48 ` Sagi Grimberg
2020-02-20 16:36 ` Chaitanya Kulkarni
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=20200218231007.GA18306@redsun51.ssa.fujisawa.hgst.com \
--to=kbusch@kernel.org \
--cc=chaitanya.kulkarni@wdc.com \
--cc=hch@lst.de \
--cc=linux-nvme@lists.infradead.org \
--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;
as well as URLs for NNTP newsgroup(s).