All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Begunkov <asml.silence@gmail.com>
To: Anuj gupta <anuj1072538@gmail.com>
Cc: Anuj Gupta <anuj20.g@samsung.com>,
	axboe@kernel.dk, hch@lst.de, kbusch@kernel.org,
	martin.petersen@oracle.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 v10 06/10] io_uring: introduce attributes for read/write and PI support
Date: Wed, 27 Nov 2024 10:35:46 +0000	[thread overview]
Message-ID: <5f77cc2b-d589-42db-9985-e56bac1da569@gmail.com> (raw)
In-Reply-To: <CACzX3AtBc-Vio1H28MM2tRvcLzTYBTFJt8CKgF5NeGTniKFUbQ@mail.gmail.com>

On 11/26/24 16:23, Anuj gupta wrote:
> On Tue, Nov 26, 2024 at 9:14 PM Pavel Begunkov <asml.silence@gmail.com> wrote:
...
>> This example would be incorrect. Even if it's just one attribute
>> the user would be wasting space on stack. The only use for it I
>> see is having ephemeral pointers during parsing, ala
>>
>> void parse(voud *attributes, offset) {
>>          struct io_uring_attr *attr = attributes + offset;
>>
>>          if (attr->type == PI) {
>>                  process_pi(&attr->pi);
>>                  // or potentially fill_pi() in userspace
>>          }
>> }
>>
>> But I don't think it's worth it. I'd say, if you're leaving
>> the structure, let's rename it to struct io_uring_attr_type_pi
>> or something similar. We can always add a new one later, it
>> doesn't change the ABI.
>>
> 
> In that case I can just drop the io_uring_attr_pi structure then. We can
> keep the mask version where we won't need the type and attributes would go
> in the array in order of their types as you suggested here [1]. Does that
> sound fine?

That should work, the approach in this patchset is fine as well.
I'll take a look at the path a bit later today.

> [1] https://lore.kernel.org/io-uring/37ba07f6-27a5-45bc-86c4-df9c63908ef9@gmail.com/

-- 
Pavel Begunkov

  reply	other threads:[~2024-11-27 10:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20241125071431epcas5p3a3d9633606d2f0b46de2c144bb7f3711@epcas5p3.samsung.com>
2024-11-25  7:06 ` [PATCH v10 00/10] Read/Write with meta/integrity Anuj Gupta
2024-11-25  7:06   ` [PATCH v10 01/10] block: define set of integrity flags to be inherited by cloned bip Anuj Gupta
2024-11-25  7:06   ` [PATCH v10 02/10] block: copy back bounce buffer to user-space correctly in case of split Anuj Gupta
2024-11-25  7:06   ` [PATCH v10 03/10] block: modify bio_integrity_map_user to accept iov_iter as argument Anuj Gupta
2024-11-25  7:06   ` [PATCH v10 04/10] fs, iov_iter: define meta io descriptor Anuj Gupta
2024-11-25  7:06   ` [PATCH v10 05/10] fs: introduce IOCB_HAS_METADATA for metadata Anuj Gupta
2024-11-25  7:06   ` [PATCH v10 06/10] io_uring: introduce attributes for read/write and PI support Anuj Gupta
2024-11-25 14:58     ` Pavel Begunkov
2024-11-26 10:40       ` Anuj Gupta
2024-11-26 12:53         ` Pavel Begunkov
2024-11-26 13:01     ` Pavel Begunkov
2024-11-26 13:04       ` Pavel Begunkov
2024-11-26 13:54       ` Anuj Gupta
2024-11-26 15:45         ` Pavel Begunkov
2024-11-26 16:23           ` Anuj gupta
2024-11-27 10:35             ` Pavel Begunkov [this message]
2024-11-27  9:46           ` Anuj Gupta
2024-11-27 11:24             ` Pavel Begunkov
2024-11-25  7:06   ` [PATCH v10 07/10] block: introduce BIP_CHECK_GUARD/REFTAG/APPTAG bip_flags Anuj Gupta
2024-11-25  7:06   ` [PATCH v10 08/10] nvme: add support for passing on the application tag Anuj Gupta
2024-11-25  7:06   ` [PATCH v10 09/10] scsi: add support for user-meta interface Anuj Gupta
2024-11-25  7:06   ` [PATCH v10 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=5f77cc2b-d589-42db-9985-e56bac1da569@gmail.com \
    --to=asml.silence@gmail.com \
    --cc=anuj1072538@gmail.com \
    --cc=anuj20.g@samsung.com \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=gost.dev@samsung.com \
    --cc=hch@lst.de \
    --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.