On 9/25/2024 11:27 AM, Hannes Reinecke wrote:
>> @@ -98,6 +98,11 @@ struct io_uring_sqe {
>> __u64 addr3;
>> __u64 __pad2[1];
>> };
>> + struct {
>> + /* To send per-io hint type/value with write command */
>> + __u64 hint_val;
>> + __u8 hint_type;
>> + };
> Why is 'hint_val' 64 bits? Everything else is 8 bytes, so wouldn't it
> be better to shorten that?
Right, within kernel hint is stored as 8bits value.
But I chose not because how kernel stores hint internally (which may
change at any time) but how the existing F_SET_RW_HINT interface exposed
this to user space. It expects u64.
If we do 8bits interface here, application needs to learn that for the
same lifetime hint it needs u64 for fcntl interface, but u8 for io_uring
interface. That seems a bit confusing.
Also, in future if we do support another hint type, we may be able to
pass hint_val beyond what can be supported by u8.
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).
[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 */
};
