linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Nilay Shroff <nilay@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-nvme@lists.infradead.org, hare@suse.de, kbusch@kernel.org,
	sagi@grimberg.me, dwagner@suse.de, axboe@kernel.dk,
	gjoyce@ibm.com
Subject: Re: [RFC PATCHv3 1/6] block: expose blk_stat_{enable,disable}_accounting() to drivers
Date: Wed, 29 Oct 2025 22:10:43 +0530	[thread overview]
Message-ID: <fccc74b2-98af-41b3-a819-8f3f295937fe@linux.ibm.com> (raw)
In-Reply-To: <20251029093934.GB1066@lst.de>



On 10/29/25 3:09 PM, Christoph Hellwig wrote:
> On Mon, Oct 27, 2025 at 02:59:35PM +0530, Nilay Shroff wrote:
>> The functions blk_stat_enable_accounting() and
>> blk_stat_disable_accounting() are currently exported, but their
>> prototypes are only defined in a private header. Move these prototypes
>> into a common header so that block drivers can directly use these APIs.
> 
> That's because they are only used by I/O scheduler, which are the only
> valid users.  I don't think drivers should touch this, but I'll stay
> tuned..
> 

Well, these stat APIs are already exported by the block layer, so I assumed
the intention was to allow drivers to make use of them. If that’s not the case,
then perhaps they were exported unintentionally.

On a related note, I also looked into using nvme_req(rq)->start_time, which is
initialized using jiffies when the request is submitted to the device. However,
for my use case, I need timestamp data with nanosecond precision, which is why
I opted to use the blk-stat APIs instead.

Thanks,
--Nilay 



  reply	other threads:[~2025-10-29 16:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-27  9:29 [RFC PATCHv3 0/6] nvme-multipath: introduce adaptive I/O policy Nilay Shroff
2025-10-27  9:29 ` [RFC PATCHv3 1/6] block: expose blk_stat_{enable,disable}_accounting() to drivers Nilay Shroff
2025-10-29  9:39   ` Christoph Hellwig
2025-10-29 16:40     ` Nilay Shroff [this message]
2025-10-27  9:29 ` [RFC PATCHv3 2/6] nvme-multipath: add support for adaptive I/O policy Nilay Shroff
2025-10-27 11:34   ` Hannes Reinecke
2025-10-27 12:09     ` Nilay Shroff
2025-10-29  9:40   ` Christoph Hellwig
2025-10-29 14:21     ` Nilay Shroff
2025-10-27  9:29 ` [RFC PATCHv3 3/6] nvme: add sysfs attribute adp_ewma_shift Nilay Shroff
2025-10-27 11:54   ` Hannes Reinecke
2025-10-27  9:29 ` [RFC PATCHv3 4/6] nvme: add sysfs attribute adp_weight_timeout Nilay Shroff
2025-10-27 11:54   ` Hannes Reinecke
2025-10-27  9:29 ` [RFC PATCHv3 5/6] nvme: add generic debugfs support Nilay Shroff
2025-10-27 11:55   ` Hannes Reinecke
2025-10-27 12:02     ` Nilay Shroff
2025-10-27  9:29 ` [RFC PATCHv3 6/6] nvme-multipath: add debugfs attribute for adaptive I/O policy stat Nilay Shroff

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=fccc74b2-98af-41b3-a819-8f3f295937fe@linux.ibm.com \
    --to=nilay@linux.ibm.com \
    --cc=axboe@kernel.dk \
    --cc=dwagner@suse.de \
    --cc=gjoyce@ibm.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --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).