On 27/04/2020 23:02, Jens Axboe wrote: > On 4/27/20 12:22 PM, Jann Horn wrote: >> On Mon, Apr 27, 2020 at 5:56 PM Jens Axboe <axboe@xxxxxxxxx> wrote: >>> On 4/27/20 9:40 AM, Clay Harris wrote: >>>> I was excited to see IORING_OP_SPLICE go in, but disappointed that tee >>>> didn't go in at the same time. It would be very useful to copy pipe >>>> buffers in an async program. >>> >>> Pavel, care to wire up tee? From a quick look, looks like just exposing >>> do_tee() and calling that, so should be trivial. >> >> Just out of curiosity: >> >> What's the purpose of doing that via io_uring? Non-blocking sys_tee() >> just shoves around some metadata, it doesn't do any I/O, right? Is >> this purely for syscall-batching reasons? (And does that mean that you >> would also add syscalls like epoll_wait() and futex() to io_uring?) Or >> is this because you're worried about blocking on the pipe mutex? > > Right, it doesn't do any IO. It does potentially block on the inode > mutex, but that's about it. I think the reasons are mainly: Good catch, the waiting probably can happen with splice as well. I need to read it through, but looks strange that it just ignores O_NONBLOCK, is there some upper bound for holding it or something? > > - Keep the interfaces the same, instead of using both sync and async > calls. > - Bundling/batch reasons, either in same submission, or chained. > > Some folks have talked about futex, and epoll_wait would also be a > natural extension as well, since we already have the ctl part. -- Pavel Begunkov
