From: Christoph Hellwig <hch@lst.de>
To: Kanchan Joshi <joshi.k@samsung.com>
Cc: Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@meta.com>,
axboe@kernel.dk, linux-block@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org,
io-uring@vger.kernel.org, sagi@grimberg.me,
asml.silence@gmail.com, anuj20.g@samsung.com,
Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCHv13 00/11] block write streams with nvme fdp
Date: Thu, 12 Dec 2024 07:05:58 +0100 [thread overview]
Message-ID: <20241212060558.GA5266@lst.de> (raw)
In-Reply-To: <bd53dbed-f6a9-4322-88b5-460f8e9885a0@samsung.com>
On Thu, Dec 12, 2024 at 11:21:07AM +0530, Kanchan Joshi wrote:
> On 12/11/2024 12:43 PM, Christoph Hellwig wrote:
> > The changes looks good to me. I'll ty to send out an API for querying
> > the paramters in the next so that we don't merge the granularity as dead
> > code
>
> What do you have in mind for this API. New fcntl or ioctl?
> With ability limited to querying only or....
Yes, new fcntl or ioctl, query the number of streams and (nominal)
stream granularity as a start. There is a few other things that
might be useful:
- check if the size is just nominal or not, aka if the device can
shorten it. FDP currently allows for that, but given that
notifications for that are out of bounds it makes a complete mess
of software actually trying to use it for more than simple hot/cold
separation like cachelib, so we find a way to query that in the
spec.
- reporting of the remaining capacity per stream, although I'm not
sure if that should be in the same ioctl/fcntl, or better done
using a separate interface that has the stream number as input
and the capacity as out, which would seem a lot simpler
next prev parent reply other threads:[~2024-12-12 6:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-10 19:47 [PATCHv13 00/11] block write streams with nvme fdp Keith Busch
2024-12-10 19:47 ` [PATCHv13 10/11] nvme: register fdp parameters with the block layer Keith Busch
2024-12-11 6:41 ` Nitesh Shetty
2024-12-11 9:30 ` John Garry
2024-12-11 15:55 ` Keith Busch
2024-12-11 11:23 ` Hannes Reinecke
2024-12-11 14:40 ` kernel test robot
2024-12-11 17:18 ` kernel test robot
[not found] ` <CGME20241211060149epcas5p4d16e78bd3d184e57465c3622a2c8e98d@epcas5p4.samsung.com>
[not found] ` <20241210194722.1905732-6-kbusch@meta.com>
2024-12-11 5:53 ` [PATCHv13 05/11] block: expose write streams for block device nodes Nitesh Shetty
[not found] ` <CGME20241211065235epcas5p2a233ac902da67bf2d755d21d98e6eb21@epcas5p2.samsung.com>
[not found] ` <20241210194722.1905732-7-kbusch@meta.com>
2024-12-11 6:44 ` [PATCHv13 06/11] io_uring: enable per-io write streams Nitesh Shetty
2024-12-11 7:13 ` [PATCHv13 00/11] block write streams with nvme fdp Christoph Hellwig
2024-12-12 5:51 ` Kanchan Joshi
2024-12-12 6:05 ` Christoph Hellwig [this message]
[not found] ` <20241210194722.1905732-5-kbusch@meta.com>
2024-12-11 8:46 ` [PATCHv13 04/11] block: introduce a write_stream_granularity queue limit John Garry
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=20241212060558.GA5266@lst.de \
--to=hch@lst.de \
--cc=anuj20.g@samsung.com \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.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).