[PATCH v6 3/3] io_uring: enable per-io hinting capability

[Pavel Begunkov]

On 9/25/24 14:21, Kanchan Joshi wrote:
> On 9/25/2024 5:53 PM, Pavel Begunkov wrote:
>> On 9/25/24 12:09, Kanchan Joshi wrote:
>>> On 9/25/2024 11:27 AM, Hannes Reinecke wrote:
>> ...
>>> As it stands the new struct will introduce
>>>> a hole of 24 bytes after 'hint_type'.
>>>
>>> This gets implicitly padded at this point [1][2], and overall size is
>>> still capped by largest struct (which is of 16 bytes, placed just above
>>> this).
>>
>> For me it's about having hardly usable in the future by anyone else
>> 7 bytes of space or how much that will be. Try to add another field
>> using those bytes and endianess will start messing with you. And 7
>> bytes is not that convenient.
>>
>> I have same problem with how commands were merged while I was not
>> looking. There was no explicit padding, and it split u64 into u32
>> and implicit padding, so no apps can use the space to put a pointer
>> anymore while there was a much better option of using one of existing
>> 4B fields.
> 
> How would you prefer it. Explicit padding (7 bytes), hint_type as u16 or
> anything else?

Explicit padding is better than the current version. Ideally,
I'd like the new fields gone (e.g. if it goes in the direction
of per file hints) or prefer to minimise the size and make the
leftover padding reusable, but that depends on what the feature
needs to be extendable.

And what hint types do we expect in the future? Another question,
don't we want an apui that allows to pass multiple hints? Quite
similar to what I asked about "meta" rw, and it might actually
make a lot of sense to combine them into common infra, like what
cmsg is for networking.

meta[] = [ {INTEGRITY, integrity_params},
            {write_hint, ...},
            ...];

Even though an actual impl would need to be a bit more elaborated.

-- 
Pavel Begunkov