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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux