Re: [PATCH 0/3] implement direct IO with integrity

[Pavel Begunkov <asml.silence@gmail.com>]

On 10/28/21 17:22, Jens Axboe wrote:
> On 10/28/21 9:56 AM, Pavel Begunkov wrote:
>> On 10/28/21 16:50, Jens Axboe wrote:
>>> On 10/28/21 9:44 AM, Mikhail Malygin wrote:
>>>> 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?

-- 
Pavel Begunkov