Linux Test Project
 help / color / mirror / Atom feed
From: Andrea Cervesato via ltp <ltp@lists.linux.it>
To: "Sebastian Chlad" <sebastianchlad@gmail.com>
Cc: Sebastian Chlad <sebastian.chlad@suse.com>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2 1/4] io_uring: Redesign common helpers to follow liburing API conventions
Date: Mon, 15 Jun 2026 12:58:15 +0000	[thread overview]
Message-ID: <6a2ff6e8.9499cc59.22cc5c.d648@mx.google.com> (raw)
In-Reply-To: <20260614174759.24546-1-sebastian.chlad@suse.com>

Hi Sebastian,

> +/*
> + * Generic SQE fill for read/write family operations.
> + * Does not touch user_data - caller sets it via io_uring_sqe_set_data64().
> + */
> +static inline void io_uring_prep_rw(struct io_uring_sqe *sqe, int opcode,
> +				    int fd, const void *addr, unsigned int len,
> +				    off_t offset)
> +{
> +	sqe->opcode = opcode;
> +	sqe->fd = fd;
> +	sqe->addr = (unsigned long)addr;
> +	sqe->len = len;
> +	sqe->off = offset;
> +}
> +
> +static inline void io_uring_prep_read(struct io_uring_sqe *sqe, int fd,
> +				      void *buf, size_t len, off_t offset)
> +{
> +	io_uring_prep_rw(sqe, IORING_OP_READ, fd, buf, len, offset);
> +}
> +
> +static inline void io_uring_prep_write(struct io_uring_sqe *sqe, int fd,
> +				       const void *buf, size_t len, off_t offset)
> +{
> +	io_uring_prep_rw(sqe, IORING_OP_WRITE, fd, buf, len, offset);
> +}
> +
> +static inline void io_uring_prep_readv(struct io_uring_sqe *sqe, int fd,
> +				       struct iovec *iovs, int nr_vecs,
> +				       off_t offset)
> +{
> +	io_uring_prep_rw(sqe, IORING_OP_READV, fd, iovs, nr_vecs, offset);
> +}
> +
> +static inline void io_uring_prep_writev(struct io_uring_sqe *sqe, int fd,
> +					struct iovec *iovs, int nr_vecs,
> +					off_t offset)
> +{
> +	io_uring_prep_rw(sqe, IORING_OP_WRITEV, fd, iovs, nr_vecs, offset);
> +}

I'm not an expert of liburing or io_uring in general, but aren't all
these functions quite redundant? They mostly do what we could simply
do inside test with 1 call and 1 argument difference.

> +
> +/*
> + * Set the user_data field of an SQE. user_data is returned verbatim in the
> + * corresponding CQE and must be unique per in-flight request to allow correct
> + * correlation of completions.
> + */
> +static inline void io_uring_sqe_set_data64(struct io_uring_sqe *sqe,
> +					   uint64_t data)
> +{
> +	sqe->user_data = data;
> +}

Uh? :-) same comment.

As I said, I'm not an expert on this technology, but I see that we are
overengineering something that is so simple as a 1-argument-difference
or 1 pointer assignment.

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

      parent reply	other threads:[~2026-06-15 12:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-14 17:47 [LTP] [PATCH v2 1/4] io_uring: Redesign common helpers to follow liburing API conventions Sebastian Chlad
2026-06-14 17:47 ` [LTP] [PATCH v2 2/4] io_uring01: Update to use new io_uring_common.h helpers Sebastian Chlad
2026-06-14 17:47 ` [LTP] [PATCH v2 3/4] io_uring03: " Sebastian Chlad
2026-06-14 17:47 ` [LTP] [PATCH v2 4/4] io_uring: Remove deprecated helpers Sebastian Chlad
2026-06-14 18:19 ` [LTP] io_uring: Redesign common helpers to follow liburing API conventions linuxtestproject.agent
2026-06-15 12:58 ` Andrea Cervesato via ltp [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6a2ff6e8.9499cc59.22cc5c.d648@mx.google.com \
    --to=ltp@lists.linux.it \
    --cc=andrea.cervesato@suse.com \
    --cc=sebastian.chlad@suse.com \
    --cc=sebastianchlad@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox