public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: David Wei <[email protected]>, [email protected]
Cc: Pavel Begunkov <[email protected]>
Subject: Re: [PATCH v2 1/2] io_uring/zcrx: add single shot recvzc
Date: Fri, 21 Feb 2025 17:08:02 -0700	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

Just a few minor drive-by nits.

> @@ -1250,6 +1251,12 @@ int io_recvzc_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>  	zc->ifq = req->ctx->ifq;
>  	if (!zc->ifq)
>  		return -EINVAL;
> +	zc->len = READ_ONCE(sqe->len);
> +	if (zc->len == UINT_MAX)
> +		return -EINVAL;
> +	/* UINT_MAX means no limit on readlen */
> +	if (!zc->len)
> +		zc->len = UINT_MAX;

Why not just make UINT_MAX allowed, meaning no limit? Would avoid two
branches here, and as far as I can tell not really change anything in
terms of API niceness.

> @@ -1269,6 +1276,7 @@ int io_recvzc_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
>  int io_recvzc(struct io_kiocb *req, unsigned int issue_flags)
>  {
>  	struct io_recvzc *zc = io_kiocb_to_cmd(req, struct io_recvzc);
> +	bool limit = zc->len != UINT_MAX;
>  	struct socket *sock;
>  	int ret;

Doesn't seem to be used?

> @@ -1296,6 +1304,13 @@ int io_recvzc(struct io_kiocb *req, unsigned int issue_flags)
>  		return IOU_OK;
>  	}
>  
> +	if (zc->len == 0) {
> +		io_req_set_res(req, 0, 0);
> +
> +		if (issue_flags & IO_URING_F_MULTISHOT)
> +			return IOU_STOP_MULTISHOT;
> +		return IOU_OK;
> +	}
>  	if (issue_flags & IO_URING_F_MULTISHOT)
>  		return IOU_ISSUE_SKIP_COMPLETE;
>  	return -EAGAIN;

Might be cleaner as:

	ret = -EAGAIN;
	if (!zc->len) {
		io_req_set_res(req, 0, 0);
		ret = -IOU_OK;
	}
  	if (issue_flags & IO_URING_F_MULTISHOT)
  		return IOU_ISSUE_SKIP_COMPLETE;
  	return ret;

rather than duplicate the flag checking.


>  static int io_zcrx_tcp_recvmsg(struct io_kiocb *req, struct io_zcrx_ifq *ifq,
>  				struct sock *sk, int flags,
> -				unsigned issue_flags)
> +				unsigned issue_flags, unsigned int *outlen)
>  {
> +	unsigned int len = *outlen;
> +	bool limit = len != UINT_MAX;
>  	struct io_zcrx_args args = {
>  		.req = req,
>  		.ifq = ifq,
>  		.sock = sk->sk_socket,
>  	};
>  	read_descriptor_t rd_desc = {
> -		.count = 1,
> +		.count = len,
>  		.arg.data = &args,
>  	};
>  	int ret;
>  
>  	lock_sock(sk);
>  	ret = tcp_read_sock(sk, &rd_desc, io_zcrx_recv_skb);
> +	if (limit && ret)
> +		*outlen = len - ret;
>  	if (ret <= 0) {
>  		if (ret < 0 || sock_flag(sk, SOCK_DONE))
>  			goto out;
> @@ -930,7 +937,7 @@ static int io_zcrx_tcp_recvmsg(struct io_kiocb *req, struct io_zcrx_ifq *ifq,
>  		ret = IOU_REQUEUE;
>  	} else if (sock_flag(sk, SOCK_DONE)) {
>  		/* Make it to retry until it finally gets 0. */
> -		if (issue_flags & IO_URING_F_MULTISHOT)
> +		if (!limit && (issue_flags & IO_URING_F_MULTISHOT))
>  			ret = IOU_REQUEUE;
>  		else
>  			ret = -EAGAIN;

In the two above hunks, the limit checking feels a bit hackish. For
example, why is it related to multishot or not? I think the patch would
benefit from being split into separate patches for singleshot and length
support. Eg one that adds singleshot support, and then one that adds
length capping on top. That would make it much easier to reason about
hunks like the above one.

> @@ -942,7 +949,7 @@ static int io_zcrx_tcp_recvmsg(struct io_kiocb *req, struct io_zcrx_ifq *ifq,
>  
>  int io_zcrx_recv(struct io_kiocb *req, struct io_zcrx_ifq *ifq,
>  		 struct socket *sock, unsigned int flags,
> -		 unsigned issue_flags)
> +		 unsigned issue_flags, unsigned int *len)
>  {
>  	struct sock *sk = sock->sk;
>  	const struct proto *prot = READ_ONCE(sk->sk_prot);

Shouldn't recv support it too?

-- 
Jens Axboe

  reply	other threads:[~2025-02-22  0:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-21 20:51 [PATCH v2 0/2] io_uring zc rx fixed len recvzc David Wei
2025-02-21 20:51 ` [PATCH v2 1/2] io_uring/zcrx: add single shot recvzc David Wei
2025-02-22  0:08   ` Jens Axboe [this message]
2025-02-22  1:01     ` Pavel Begunkov
2025-02-22  1:07       ` Jens Axboe
2025-02-23 22:35         ` David Wei
2025-02-24 12:49           ` Pavel Begunkov
2025-02-23 22:39     ` David Wei
2025-02-22  0:40   ` Pavel Begunkov
2025-02-22  0:52     ` Jens Axboe
2025-02-22  1:06       ` Pavel Begunkov
2025-02-22  1:09         ` Jens Axboe
2025-02-22  1:15           ` Pavel Begunkov
2025-02-22  1:09         ` Pavel Begunkov
2025-02-23 22:43     ` David Wei
2025-02-22  0:56   ` Pavel Begunkov
2025-02-23 22:44     ` David Wei
2025-02-22  8:54   ` lizetao
2025-02-24  0:17     ` David Wei
2025-02-21 20:51 ` [PATCH v2 2/2] io_uring/zcrx: add selftest case for " David Wei

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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