[PATCH v9 06/11] io_uring: introduce attributes for read/write and PI support

[Pavel Begunkov]

On 11/18/24 17:03, Christoph Hellwig wrote:
> On Mon, Nov 18, 2024 at 04:59:22PM +0000, Pavel Begunkov wrote:
>>>
>>> Can we please stop overdesigning the f**k out of this?  Really,
>>
>> Please stop it, it doesn't add weight to your argument. The design
>> requirement has never changed, at least not during this patchset
>> iterations.
> 
> That's what you think because you are overdesigning the hell out of
> it.  And at least for me that rings every single alarm bell about
> horrible interface design.

Well, and that's what you think, terribly incorrectly as far as
I can say.

>>> either we're fine using the space in the extended SQE, or
>>> we're fine using a separate opcode, or if we really have to just
>>> make it uring_cmd.  But stop making thing being extensible for
>>> the sake of being extensible.
>>
>> It's asked to be extendible because there is a good chance it'll need to
>> be extended, and no, I'm not suggesting anyone to implement the entire
>> thing, only PI bits is fine.
> 
> Extensibility as in having reserved fields that can be checked for
> is one thing.  "Extensibility" by adding indirections over indirections

I don't know where you found indirections over indirections.

> without a concrete use case is another thing.  And we're deep into the
> latter phase now.
> 
>> And no, it doesn't have to be "this or that" while there are other
>> options suggested for consideration. And the problem with the SQE128
>> option is not even about SQE128 but how it's placed inside, i.e.
>> at a fixed spot.
>>
>> Do we have technical arguments against the direction in the last
>> suggestion?
> 
> Yes.  It adds completely pointless indirections and variable offsets.

One indirection, and there are no variable offsets while PI remains
the only user around.

> How do you expect people to actually use that sanely without
> introducing bugs left right and center?

I've just given you an example how the user space can look like, I
have absolutely no idea what you're talking about.

> I really don't get why you want to make an I/O fast path as complicated
> as possible.

Exactly, _fast path_. PI-only handling is very simple, I don't buy
that "complicated". If we'd need to add more without an API expecting
that, that'll mean a yet another forest of never ending checks in the
fast path effecting all users.

-- 
Pavel Begunkov