On 2/10/22 6:08 AM, Alexander V. Buev wrote:
> Added new READV_PI/WRITEV_PI operations to io_uring.
> Added new pi_addr & pi_len fields to SQE struct.
> Added new pi_iter field and IOCB_USE_PI flag to kiocb struct.
> Make corresponding corrections to io uring trace event.
>
> Signed-off-by: Alexander V. Buev <a.buev@xxxxxxxxx>
> ---
> fs/io_uring.c | 209 ++++++++++++++++++++++++++++++++
> include/linux/fs.h | 2 +
> include/trace/events/io_uring.h | 17 +--
> include/uapi/linux/io_uring.h | 6 +-
> include/uapi/linux/uio.h | 3 +-
> 5 files changed, 228 insertions(+), 9 deletions(-)
>
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 2e04f718319d..6e941040f228 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -563,6 +563,19 @@ struct io_rw {
> u64 len;
> };
>
> +struct io_rw_pi_state {
> + struct iov_iter iter;
> + struct iov_iter_state iter_state;
> + struct iovec fast_iov[UIO_FASTIOV_PI];
> +};
> +
> +struct io_rw_pi {
> + struct io_rw rw;
> + struct iovec *pi_iov;
> + u32 nr_pi_segs;
> + struct io_rw_pi_state *s;
> +};
One immediate issue I see here is that io_rw_pi is big, and we try very
hard to keep the per-command payload to 64-bytes. This would be 88 bytes
by my count :-/
Do you need everything from io_rw? If not, I'd just make io_rw_pi
contain the bits you need and see if you can squeeze it into the
existing cacheline.
--
Jens Axboe
