On 9/15/21 10:47 PM, Al Viro wrote: > Jens, may I politely inquire why is struct io_rw playing > these games with overloading ->rw.addr, instead of simply having > struct io_buffer *kbuf in it? Very simply to avoid growing the union command part of io_kiocb beyond a cacheline. We're pretty sensitive to io_kiocb size in general, and io_rw is already the biggest member in there. > Another question: what the hell are the rules for > REQ_F_BUFFER_SELECT? The first time around io_iov_buffer_select() > will > * read iovec from ->rw.addr > * replace iovec.iov_base with value derived from > ->buf_index > * cap iovec.iov_len with value derived from ->buf_index > Next time around it will use the same base *AND* replace the > length with the value used to cap the original. > Is that deliberate? Probably not strictly needed, but doesn't harm anything. The buffer is being consumed (and hence removed) at completion anyway, it's not a persistent change. Selected buffers must be re-provided by the application as the kernel has no way of knowing when the application would otherwise be ready for it to get reused, and that's done by issuing a new provide buffers request for the buffers that can get recycled. -- Jens Axboe
