From: Christoph Hellwig <hch@lst.de>
To: Kanchan Joshi <joshi.k@samsung.com>
Cc: Christoph Hellwig <hch@lst.de>,
Anuj gupta <anuj1072538@gmail.com>,
Anuj Gupta <anuj20.g@samsung.com>,
axboe@kernel.dk, kbusch@kernel.org, martin.petersen@oracle.com,
asml.silence@gmail.com, brauner@kernel.org, jack@suse.cz,
viro@zeniv.linux.org.uk, io-uring@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
gost.dev@samsung.com, linux-scsi@vger.kernel.org,
vishak.g@samsung.com, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v7 06/10] io_uring/rw: add support to send metadata along with read/write
Date: Tue, 5 Nov 2024 17:00:51 +0100 [thread overview]
Message-ID: <20241105160051.GA7599@lst.de> (raw)
In-Reply-To: <b52ecf88-1786-4b6f-b8f3-86cccaa51917@samsung.com>
On Tue, Nov 05, 2024 at 09:21:27PM +0530, Kanchan Joshi wrote:
> Can add the documentation (if this version is palatable for Jens/Pavel),
> but this was discussed in previous iteration:
>
> 1. Each meta type may have different space requirement in SQE.
>
> Only for PI, we need so much space that we can't fit that in first SQE.
> The SQE128 requirement is only for PI type.
> Another different meta type may just fit into the first SQE. For that we
> don't have to mandate SQE128.
Ok, I'm really confused now. The way I understood Anuj was that this
is NOT about block level metadata, but about other uses of the big SQE.
Which version is right? Or did I just completely misunderstand Anuj?
> 2. If two meta types are known not to co-exist, they can be kept in the
> same place within SQE. Since each meta-type is a flag, we can check what
> combinations are valid within io_uring and throw the error in case of
> incompatibility.
And this sounds like what you refer to is not actually block metadata
as in this patchset or nvme, (or weirdly enough integrity in the block
layer code).
> 3. Previous version was relying on SQE128 flag. If user set the ring
> that way, it is assumed that PI information was sent.
> This is more explicitly conveyed now - if user passed META_TYPE_PI flag,
> it has sent the PI. This comment in the code:
>
> + /* if sqe->meta_type is META_TYPE_PI, last 32 bytes are for PI */
> + union {
>
> If this flag is not passed, parsing of second SQE is skipped, which is
> the current behavior as now also one can send regular (non pi)
> read/write on SQE128 ring.
And while I don't understand how this threads in with the previous
statements, this makes sense. If you only want to send a pointer (+len)
to metadata you can use the normal 64-byte SQE. If you want to send
a PI tuple you need SEQ128. Is that what the various above statements
try to express? If so the right API to me would be to have two flags:
- a flag that a pointer to metadata is passed. This can work with
a 64-bit SQE.
- another flag that a PI tuple is passed. This requires a 128-byte
and also the previous flag.
>
>
>
>
>
---end quoted text---
next prev parent reply other threads:[~2024-11-05 16:00 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20241104141427epcas5p2174ded627e2d785294ac4977b011a75b@epcas5p2.samsung.com>
2024-11-04 14:05 ` [PATCH v7 00/10] Read/Write with meta/integrity Anuj Gupta
2024-11-04 14:05 ` [PATCH v7 01/10] block: define set of integrity flags to be inherited by cloned bip Anuj Gupta
2024-11-04 14:05 ` [PATCH v7 02/10] block: copy back bounce buffer to user-space correctly in case of split Anuj Gupta
2024-11-05 10:03 ` Christoph Hellwig
2024-11-05 13:15 ` Anuj gupta
2024-11-04 14:05 ` [PATCH v7 03/10] block: modify bio_integrity_map_user to accept iov_iter as argument Anuj Gupta
2024-11-04 14:05 ` [PATCH v7 04/10] fs, iov_iter: define meta io descriptor Anuj Gupta
2024-11-05 9:55 ` Christoph Hellwig
2024-11-04 14:05 ` [PATCH v7 05/10] fs: introduce IOCB_HAS_METADATA for metadata Anuj Gupta
2024-11-04 14:05 ` [PATCH v7 06/10] io_uring/rw: add support to send metadata along with read/write Anuj Gupta
2024-11-05 9:56 ` Christoph Hellwig
2024-11-05 13:04 ` Anuj gupta
2024-11-05 13:56 ` Christoph Hellwig
2024-11-05 15:51 ` Kanchan Joshi
2024-11-05 16:00 ` Christoph Hellwig [this message]
2024-11-05 16:23 ` Keith Busch
2024-11-05 16:50 ` Kanchan Joshi
2024-11-06 5:29 ` Christoph Hellwig
2024-11-06 6:00 ` Kanchan Joshi
2024-11-06 6:12 ` Christoph Hellwig
2024-11-05 16:38 ` Kanchan Joshi
2024-11-06 5:33 ` Christoph Hellwig
2024-11-04 14:05 ` [PATCH v7 07/10] block: introduce BIP_CHECK_GUARD/REFTAG/APPTAG bip_flags Anuj Gupta
2024-11-04 14:05 ` [PATCH v7 08/10] nvme: add support for passing on the application tag Anuj Gupta
2024-11-04 14:06 ` [PATCH v7 09/10] scsi: add support for user-meta interface Anuj Gupta
2024-11-04 14:06 ` [PATCH v7 10/10] block: add support to pass user meta buffer Anuj Gupta
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=20241105160051.GA7599@lst.de \
--to=hch@lst.de \
--cc=anuj1072538@gmail.com \
--cc=anuj20.g@samsung.com \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=gost.dev@samsung.com \
--cc=io-uring@vger.kernel.org \
--cc=jack@suse.cz \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=viro@zeniv.linux.org.uk \
--cc=vishak.g@samsung.com \
/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.