On 10/28/21 11:11 AM, Pavel Begunkov wrote: > 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@xxxxxxxxxx/ >>>> >>>> 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
