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@xxxxxxxxxx/ Thanks, Mikhail > On 28 Oct 2021, at 18:20, Jens Axboe <axboe@xxxxxxxxx> 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 >
