On 10/28/21 11:11 AM, Pavel Begunkov wrote:

On 10/28/21 17:22, Jens Axboe wrote:

quoted

On 10/28/21 9:56 AM, Pavel Begunkov wrote:

quoted

On 10/28/21 16:50, Jens Axboe wrote:

quoted

On 10/28/21 9:44 AM, Mikhail Malygin wrote:

quoted

Thanks for the feedback, we’ll submit and updated version of the series.

The only question is regarding uapi: should we add a separate opcodes
for read/write or use existing opcodes with the flag in the
io_uring_sqe.rw_flags field?

The flag was discussed in the another submission, where it was
considered to be a better approach over opcodes:
https://patchwork.kernel.org/project/linux-block/patch/20200226083719.4389-2-bob.liu@oracle.com/

Separate opcodes is, at least to me, definitely the way to go. Just
looking at the code needing to tap into weird spots for PI is enough to
make that call. On top of that, it also allows you to cleanly define
this command and (hopefully?) avoid that weirdness with implied PI in
the last iovec.

Reminds me struggles with writing encoded data to btrfs. I believe
Omar did go for RWF_ENCODED flag, right?

Exactly the same problem, yes. It ends up being pretty miserable, and
there's no reason to go through that misery when we're not bound by only
passing in an iovec.

I agree that a new opcode is better, at least we can keep the overhead
out of the common path, but RWF_ENCODED was having similar problems
(e.g. passing metadata in iov), so that's interesting why RWF was chosen
in the end. Is it only to support readv/writev(2) or something else?

To shoe horn it in via an existing interface, I don't think anybody
wanted to add yet another read/write API just to cater to that.

-- 
Jens Axboe