From: Mat Martineau <mathew.j.martineau@linux.intel.com>
To: Geliang Tang <geliang.tang@suse.com>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v4 05/11] mptcp: simplify push_pending
Date: Tue, 4 Oct 2022 17:33:49 -0700 (PDT) [thread overview]
Message-ID: <171d9a6f-9628-4989-677c-9a6ac38a5880@linux.intel.com> (raw)
In-Reply-To: <b0c832c5f1b3dfaf20a7ade32968c78eaf228482.1664720538.git.geliang.tang@suse.com>
On Sun, 2 Oct 2022, Geliang Tang wrote:
> This patch moves the duplicate code from __mptcp_push_pending() and
> __mptcp_subflow_push_pending() into a new helper function, named
> __subflow_push_pending(). And simplify __mptcp_push_pending() by
> invoking this helper.
>
> Signed-off-by: Geliang Tang <geliang.tang@suse.com>
> ---
> net/mptcp/protocol.c | 90 +++++++++++++++++++++++---------------------
> 1 file changed, 48 insertions(+), 42 deletions(-)
>
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 296b7135e9cf..66c97ac06a4e 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -1480,12 +1480,6 @@ struct sock *mptcp_subflow_get_send(struct mptcp_sock *msk)
> return ssk;
> }
>
> -static void mptcp_push_release(struct sock *ssk, struct mptcp_sendmsg_info *info)
> -{
> - tcp_push(ssk, 0, info->mss_now, tcp_sk(ssk)->nonagle, info->size_goal);
> - release_sock(ssk);
> -}
> -
> static void mptcp_update_post_push(struct mptcp_sock *msk,
> struct mptcp_data_frag *dfrag,
> u32 sent)
> @@ -1517,6 +1511,52 @@ void mptcp_check_and_set_pending(struct sock *sk)
> mptcp_sk(sk)->push_pending |= BIT(MPTCP_PUSH_PENDING);
> }
>
> +static int __subflow_push_pending(struct sock *sk, struct sock *ssk,
> + struct mptcp_sendmsg_info *info)
> +{
> + struct mptcp_sock *msk = mptcp_sk(sk);
> + struct mptcp_data_frag *dfrag;
> + int len, copied = 0;
> +
> + while ((dfrag = mptcp_send_head(sk))) {
> + info->sent = dfrag->already_sent;
> + info->limit = dfrag->data_len;
> + len = dfrag->data_len - dfrag->already_sent;
> + while (len > 0) {
> + int ret = 0;
> +
> + ret = mptcp_sendmsg_frag(sk, ssk, dfrag, info);
> + if (ret <= 0) {
> + if (ret == -EAGAIN)
> + continue;
In the older code, the scheduler got called again in the -EAGAIN case.
With this refactored code, this could get in a very tight loop if
mptcp_sendmsg_frag() returns. I think it's necessary to cleanly finish
this loop iteration and let the scheduler run again in this -EAGAIN case.
> + goto out;
> + }
> +
> + info->sent += ret;
> + copied += ret;
> + len -= ret;
> +
> + mptcp_update_post_push(msk, dfrag, ret);
> + }
> + WRITE_ONCE(msk->first_pending, mptcp_send_next(sk));
> +
> + if (msk->snd_burst <= 0 ||
> + !sk_stream_memory_free(ssk) ||
> + !mptcp_subflow_active(mptcp_subflow_ctx(ssk))) {
> + goto out;
> + }
> + mptcp_set_timeout(sk);
> + }
> +
> +out:
> + if (copied) {
> + tcp_push(ssk, 0, info->mss_now, tcp_sk(ssk)->nonagle,
> + info->size_goal);
> + }
> +
> + return copied;
> +}
> +
> void __mptcp_push_pending(struct sock *sk, unsigned int flags)
> {
> struct mptcp_sock *msk = mptcp_sk(sk);
> @@ -1524,48 +1564,14 @@ void __mptcp_push_pending(struct sock *sk, unsigned int flags)
> .flags = flags,
> };
> bool do_check_data_fin = false;
> - struct mptcp_data_frag *dfrag;
> struct sock *ssk;
> - int len;
>
> while (mptcp_send_head(sk) && (ssk = mptcp_subflow_get_send(msk))) {
> lock_sock(ssk);
> -
> - while ((dfrag = mptcp_send_head(sk))) {
> - info.sent = dfrag->already_sent;
> - info.limit = dfrag->data_len;
> - len = dfrag->data_len - dfrag->already_sent;
> - while (len > 0) {
> - int ret = 0;
> -
> - ret = mptcp_sendmsg_frag(sk, ssk, dfrag, &info);
> - if (ret <= 0) {
> - if (ret == -EAGAIN)
> - continue;
> - mptcp_push_release(ssk, &info);
> - goto out;
> - }
> -
> - do_check_data_fin = true;
> - info.sent += ret;
> - len -= ret;
> -
> - mptcp_update_post_push(msk, dfrag, ret);
> - }
> - WRITE_ONCE(msk->first_pending, mptcp_send_next(sk));
> -
> - if (msk->snd_burst <= 0 ||
> - !sk_stream_memory_free(ssk) ||
> - !mptcp_subflow_active(mptcp_subflow_ctx(ssk))) {
> - goto out;
> - }
> - mptcp_set_timeout(sk);
> - }
> -
> - mptcp_push_release(ssk, &info);
> + do_check_data_fin = __subflow_push_pending(sk, ssk, &info);
do_check_data_fin is a bool, but __subflow_push_pending() returns an
int (the number of bytes copied). Looking at the other patches, the int
value is needed. I suggest assigning the int return value to an int
variable:
copied = __subflow_push_pending(sk, ssk, &info);
and updating the 'if' statement below...
> + release_sock(ssk);
> }
>
> -out:
> /* ensure the rtx timer is running */
> if (!mptcp_timer_pending(sk))
> mptcp_reset_timer(sk);
> if (do_check_data_fin)
> __mptcp_check_send_data_fin(sk);
...like this:
if (copied > 0)
__mptcp_check_send_data_fin(sk);
Thanks,
--
Mat Martineau
Intel
next prev parent reply other threads:[~2022-10-05 0:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-02 14:25 [PATCH mptcp-next v4 00/11] refactor push pending Geliang Tang
2022-10-02 14:25 ` [PATCH mptcp-next v4 01/11] Squash to "mptcp: add get_subflow wrappers" Geliang Tang
2022-10-02 14:25 ` [PATCH mptcp-next v4 02/11] mptcp: add new argument ssk_first Geliang Tang
2022-10-05 0:16 ` Mat Martineau
2022-10-02 14:25 ` [PATCH mptcp-next v4 03/11] mptcp: move burst check out of subflow_get_send Geliang Tang
2022-10-05 0:20 ` Mat Martineau
2022-10-05 0:24 ` Mat Martineau
2022-10-02 14:25 ` [PATCH mptcp-next v4 04/11] mptcp: refactor push_pending logic Geliang Tang
2022-10-05 0:23 ` Mat Martineau
2022-10-02 14:25 ` [PATCH mptcp-next v4 05/11] mptcp: simplify push_pending Geliang Tang
2022-10-05 0:33 ` Mat Martineau [this message]
2022-10-02 14:25 ` [PATCH mptcp-next v4 06/11] mptcp: multi subflows push_pending Geliang Tang
2022-10-02 14:25 ` [PATCH mptcp-next v4 07/11] mptcp: use msk instead of mptcp_sk Geliang Tang
2022-10-02 14:25 ` [PATCH mptcp-next v4 08/11] mptcp: refactor subflow_push_pending logic Geliang Tang
2022-10-02 14:25 ` [PATCH mptcp-next v4 09/11] mptcp: simplify subflow_push_pending Geliang Tang
2022-10-02 14:25 ` [PATCH mptcp-next v4 10/11] mptcp: multi subflows subflow_push_pending Geliang Tang
2022-10-02 14:25 ` [PATCH mptcp-next v4 11/11] mptcp: multi subflows retrans support Geliang Tang
2022-10-06 15:43 ` mptcp: multi subflows retrans support: Tests Results MPTCP CI
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=171d9a6f-9628-4989-677c-9a6ac38a5880@linux.intel.com \
--to=mathew.j.martineau@linux.intel.com \
--cc=geliang.tang@suse.com \
--cc=mptcp@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.