From: Christoph Hellwig <[email protected]>
To: Kanchan Joshi <[email protected]>
Cc: Christoph Hellwig <[email protected]>,
Anuj gupta <[email protected]>,
Anuj Gupta <[email protected]>,
[email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected]
Subject: Re: [PATCH v7 06/10] io_uring/rw: add support to send metadata along with read/write
Date: Wed, 6 Nov 2024 06:33:03 +0100 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On Tue, Nov 05, 2024 at 10:08:46PM +0530, Kanchan Joshi wrote:
> We both mean the same. Currently read/write don't [need to] use big SQE
> as all the information is there in the first SQE.
> Down the line there may be users fighting for space in SQE. The flag
> (meta_type) may help a bit when that happens.
IFF we ever have a fight we need to split command or add an even bigger
SQE.`
> What I rather meant in this statement was - one can setup a ring with
> SQE128 today and send IORING_OP_READ/IORING_OP_WRITE. That goes fine
> without any processing/error as SQE128 is skipped completely. So relying
> only on SQE128 flag to detect the presence of PI is a bit fragile.
Maybe the right answer is to add
READ_LARGE/WRITE_LARGE (better names welcome) commands that are defined
to the entire 128-byte SQE, and then we have a bitmap of what extra
features are supported in it, with descriptive names for each feature.
Not trying to have one command for 64 vs 128 byte SQE might also be
useful to have a more straight forward layout in general (although I
haven't checked for that, just speaking from experience in other
protocols).
next prev parent reply other threads:[~2024-11-06 5:33 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
[not found] ` <CGME20241104141445epcas5p3fa11a5bebe88ac2bb3541850369591f7@epcas5p3.samsung.com>
2024-11-04 14:05 ` [PATCH v7 01/10] block: define set of integrity flags to be inherited by cloned bip Anuj Gupta
[not found] ` <CGME20241104141448epcas5p4179505e12f9cf45fd792dc6da6afce8e@epcas5p4.samsung.com>
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
[not found] ` <CGME20241104141451epcas5p2aef1f93e905c27e34b3e16d89ff39245@epcas5p2.samsung.com>
2024-11-04 14:05 ` [PATCH v7 03/10] block: modify bio_integrity_map_user to accept iov_iter as argument Anuj Gupta
[not found] ` <CGME20241104141453epcas5p201e4aabfa7aa1f4af1cdf07228f8d4e7@epcas5p2.samsung.com>
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
[not found] ` <CGME20241104141456epcas5p38fef2ccde087de84ffc6f479f50e8071@epcas5p3.samsung.com>
2024-11-04 14:05 ` [PATCH v7 05/10] fs: introduce IOCB_HAS_METADATA for metadata Anuj Gupta
[not found] ` <CGME20241104141459epcas5p27991e140158b1e7294b4d6c4e767373c@epcas5p2.samsung.com>
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
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 [this message]
[not found] ` <CGME20241104141501epcas5p38203d98ce0b2ac95cc45e02a142e84ef@epcas5p3.samsung.com>
2024-11-04 14:05 ` [PATCH v7 07/10] block: introduce BIP_CHECK_GUARD/REFTAG/APPTAG bip_flags Anuj Gupta
[not found] ` <CGME20241104141504epcas5p47e46a75f9248a37c9a4180de8e72b54c@epcas5p4.samsung.com>
2024-11-04 14:05 ` [PATCH v7 08/10] nvme: add support for passing on the application tag Anuj Gupta
[not found] ` <CGME20241104141507epcas5p161e39cef85f8fa5f5ad59e959e070d0b@epcas5p1.samsung.com>
2024-11-04 14:06 ` [PATCH v7 09/10] scsi: add support for user-meta interface Anuj Gupta
[not found] ` <CGME20241104141509epcas5p4ed0c68c42ccad27f9a38dc0c0ef7628d@epcas5p4.samsung.com>
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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