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

[Mikhail Malygin <m.malygin@yadro.com>]

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/

Thanks,
Mikhail

> On 28 Oct 2021, at 18:20, Jens Axboe <axboe@kernel.dk> wrote:
> 
> On 10/28/21 9:18 AM, Christoph Hellwig wrote:
>> On Thu, Oct 28, 2021 at 09:13:07AM -0600, Jens Axboe wrote:
>>> A couple of suggestions on this:
>>> 
>>> 1) Don't think we need an IOSQE flag, those are mostly reserved for
>>>   modifiers that apply to (mostly) all kinds of requests
>>> 2) I think this would be cleaner as a separate command, rather than
>>>   need odd adjustments and iov assumptions. That also gets it out
>>>   of the fast path.
>>> 
>>> I'd add IORING_OP_READV_PI and IORING_OP_WRITEV_PI for this, I think
>>> you'd end up with a much cleaner implementation that way.
>> 
>> Agreed.  I also wonder if we could do saner paramter passing.
>> E.g. pass a separate pointer to the PI data if we find space for
>> that somewhere in the SQE.
> 
> Yeah, the whole "put PI in the last iovec" makes the code really ugly
> dealing with it. Would be a lot cleaner to separate the two. IMHO this
> is largely a work-around that you'd apply to syscall interfaces that
> only take the iovec, but we don't need to work around it here if we can
> define a clean command upfront.
> 
> And if we don't need vectored requests for the data part, then even
> better. That one might not be feasible, but figured I'd toss it out
> there.
> 
> -- 
> Jens Axboe
>