From: Christoph Hellwig <hch@lst.de>
To: Anuj Gupta <anuj20.g@samsung.com>
Cc: axboe@kernel.dk, hch@lst.de, kbusch@kernel.org,
martin.petersen@oracle.com, asml.silence@gmail.com,
anuj1072538@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,
Kanchan Joshi <joshi.k@samsung.com>
Subject: Re: [PATCH v8 06/10] io_uring/rw: add support to send metadata along with read/write
Date: Thu, 7 Nov 2024 06:55:42 +0100 [thread overview]
Message-ID: <20241107055542.GA2483@lst.de> (raw)
In-Reply-To: <20241106121842.5004-7-anuj20.g@samsung.com>
> +enum io_uring_sqe_ext_cap_bits {
> + EXT_CAP_PI_BIT,
> + /*
> + * not a real extended capability; just to make sure that we don't
> + * overflow
> + */
> + EXT_CAP_LAST_BIT,
> +};
> +
> +/* extended capability flags */
> +#define EXT_CAP_PI (1U << EXT_CAP_PI_BIT)
This is getting into nitpicking, but is the a good reason to have that
enum, which is never used as a type and the values or only defined to
actually define the bit positions below? That's a bit confusing to
me.
Also please document the ABI for EXT_CAP_PI, right now this is again
entirely undocumented.
> +/* Second half of SQE128 for IORING_OP_READ/WRITE */
> +struct io_uring_sqe_ext {
> + __u64 rsvd0[4];
> + /* if sqe->ext_cap is EXT_CAP_PI, last 32 bytes are for PI */
> + union {
> + __u64 rsvd1[4];
> + struct {
> + __u16 flags;
> + __u16 app_tag;
> + __u32 len;
> + __u64 addr;
> + __u64 seed;
> + __u64 rsvd;
> + } rw_pi;
> + };
And this is not what I though we discussed before. By having a
union here you imply some kind of "type" again that is switched
on a value, and not flags indication the presence of potential
multiple optional and combinable features. This is what I would
have expected here based on the previous discussion:
struct io_uring_sqe_ext {
/*
* Reservered for please tell me what and why it is in the beginning
* and not the end:
*/
__u64 rsvd0[4];
/*
* Only valid when EXT_CAP_PI is set:
*/
__u16 pi_flags; /* or make this generic flags, dunno? */
__u16 app_tag;
__u32 pi_len;
__u64 pi_addr;
__u64 pi_seed;
__u64 rsvd1;
};
next prev parent reply other threads:[~2024-11-07 5:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20241106122631epcas5p2575c59b7634e0077f8e5c654b5fd5dbb@epcas5p2.samsung.com>
2024-11-06 12:18 ` [PATCH v8 00/10] Read/Write with meta/integrity Anuj Gupta
2024-11-06 12:18 ` [PATCH v8 01/10] block: define set of integrity flags to be inherited by cloned bip Anuj Gupta
2024-11-06 12:18 ` [PATCH v8 02/10] block: copy back bounce buffer to user-space correctly in case of split Anuj Gupta
2024-11-06 12:18 ` [PATCH v8 03/10] block: modify bio_integrity_map_user to accept iov_iter as argument Anuj Gupta
2024-11-06 12:18 ` [PATCH v8 04/10] fs, iov_iter: define meta io descriptor Anuj Gupta
2024-11-06 12:18 ` [PATCH v8 05/10] fs: introduce IOCB_HAS_METADATA for metadata Anuj Gupta
2024-11-06 12:18 ` [PATCH v8 06/10] io_uring/rw: add support to send metadata along with read/write Anuj Gupta
2024-11-07 5:55 ` Christoph Hellwig [this message]
2024-11-07 7:26 ` Anuj gupta
2024-11-07 7:38 ` Christoph Hellwig
2024-11-07 10:40 ` Anuj Gupta
2024-11-07 11:44 ` Christoph Hellwig
2024-11-12 0:54 ` Pavel Begunkov
2024-11-12 6:51 ` Anuj Gupta
2024-11-06 12:18 ` [PATCH v8 07/10] block: introduce BIP_CHECK_GUARD/REFTAG/APPTAG bip_flags Anuj Gupta
2024-11-06 12:18 ` [PATCH v8 08/10] nvme: add support for passing on the application tag Anuj Gupta
2024-11-06 12:18 ` [PATCH v8 09/10] scsi: add support for user-meta interface Anuj Gupta
2024-11-06 12:18 ` [PATCH v8 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=20241107055542.GA2483@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.