On Thu, Aug 25, 2022 at 10:34:11AM +0100, Pavel Begunkov wrote:
>On 8/22/22 12:33, Kanchan Joshi wrote:
>>On Mon, Aug 22, 2022 at 11:58:24AM +0100, Pavel Begunkov wrote:
>[...]
>>>>diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
>>>>index 1463cfecb56b..80ea35d1ed5c 100644
>>>>--- a/include/uapi/linux/io_uring.h
>>>>+++ b/include/uapi/linux/io_uring.h
>>>>@@ -203,6 +203,7 @@ enum io_uring_op {
>>>>     IORING_OP_SOCKET,
>>>>     IORING_OP_URING_CMD,
>>>>     IORING_OP_SENDZC_NOTIF,
>>>>+    IORING_OP_URING_CMD_FIXED,
>>>
>>>I don't think it should be another opcode, is there any
>>>control flags we can fit it in?
>>
>>using sqe->rw_flags could be another way.
>
>We also use ->ioprio for io_uring opcode specific flags,
>e.g. like in io_sendmsg_prep() for IORING_RECVSEND_POLL_FIRST,
>might be even better better.
>
>>But I think that may create bit of disharmony in user-space.
>>Current choice (IORING_OP_URING_CMD_FIXED) is along the same lines as
>>IORING_OP_READ/WRITE_FIXED.
>
>And I still believe it was a bad choice, I don't like this encoding
>of independent options/features by linearising toggles into opcodes.
>A consistent way to add vectored fixed bufs would be to have a 4th
>opcode, e.g. READV_FIXED, which is not great.
>
>>User-space uses new opcode, and sends the
>>buffer by filling sqe->buf_index. So must we take a different way?
>
>I do think so

I see. Will change this in next iteration.