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. >> 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 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. How do you expect people to actually use that sanely without introducing bugs left right and center? I really don't get why you want to make an I/O fast path as complicated as possible.
