[PATCH v6 3/3] io_uring: enable per-io hinting capability
Pavel Begunkov
asml.silence at gmail.com
Wed Sep 25 05:23:14 PDT 2024
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.
> [1] On 64bit
> » union {
> » » struct {
> » » » __u64 addr3; /* 48 8 */
> » » » __u64 __pad2[1]; /* 56 8 */
> » » }; /* 48 16 */
> » » struct {
> » » » __u64 hint_val; /* 48 8 */
> » » » __u8 hint_type; /* 56 1 */
> » » }; /* 48 16 */
> » » __u64 optval; /* 48 8 */
> » » __u8 cmd[0]; /* 48 0 */
> » }; /* 48 16 */
>
> » /* size: 64, cachelines: 1, members: 13 */
>
> [2] On 32bit
>
> » union {
> » » struct {
> » » » __u64 addr3; /* 48 8 */
> » » » __u64 __pad2[1]; /* 56 8 */
> » » }; /* 48 16 */
> » » struct {
> » » » __u64 hint_val; /* 48 8 */
> » » » __u8 hint_type; /* 56 1 */
> » » }; /* 48 12 */
> » » __u64 optval; /* 48 8 */
> » » __u8 cmd[0]; /* 48 0 */
> » }; /* 48 16 */
>
> » /* size: 64, cachelines: 1, members: 13 */
> };
--
Pavel Begunkov
More information about the Linux-nvme
mailing list