mptcp.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Mat Martineau <mathew.j.martineau@linux.intel.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: mptcp@lists.linux.dev, Florian Westphal <fw@strlen.de>
Subject: Re: [RFC PATCH] tcp: consistently disable header prediction for mptcp
Date: Tue, 15 Jun 2021 15:45:19 -0700 (PDT)	[thread overview]
Message-ID: <39c13ca2-40db-5be2-732-f460d621943@linux.intel.com> (raw)
In-Reply-To: <982d258452274d2b165b07883307c01a44dbf7f7.1623434219.git.pabeni@redhat.com>

On Fri, 11 Jun 2021, Paolo Abeni wrote:

> The MPTCP receive path is hooked only into the TCP slow-path.
> The DSS presence allows plain MPTCP traffic to hit that
> consistently.
>
> Since commit e1ff9e82e2ea ("net: mptcp: improve fallback to TCP"),
> when and MPTCP socket falls back to TCP, we can the receive
> fast path, and delay or stop triggering the event notification.
>
> Address the issue explicitly disabling the header prediction
> for MPTCP sockets.
>
> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/200
> Fixes: e1ff9e82e2ea ("net: mptcp: improve fallback to TCP")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> I could not find a reliable way to disable header prediction
> touching the MPTCP code only: the TCP stack can flip header
> prediction on in a bunch of points and I could not find existing
> MPTCP hooks after such check to revert the change.
>
> So I opted for this TCP change, unless we are able to really
> drop TCP fast path ?!? (see commit
> 31770e34e43d6c8dee129bfee77e56c34e61f0e5)
>
> @Florian: WDYT?

I'm also interested in Florian's thoughts.

We need to fix MPTCP fallback whether regular TCP fast path is still 
present or not, so I'm in favor of this patch. Looking at Florian's 
comments on those previous patches (31770e34e43 and the patch it reverts), 
I wonder if anything in the last four years has changed tcp_ack() calls 
enough to affect performance.


Mat

> ---
> include/net/tcp.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index e668f1bf780d..17df9b047ee4 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -686,6 +686,10 @@ static inline u32 __tcp_set_rto(const struct tcp_sock *tp)
>
> static inline void __tcp_fast_path_on(struct tcp_sock *tp, u32 snd_wnd)
> {
> +	/* mptcp hooks are only on the slow path */
> +	if (sk_is_mptcp((struct sock *)tp))
> +		return;
> +
> 	tp->pred_flags = htonl((tp->tcp_header_len << 26) |
> 			       ntohl(TCP_FLAG_ACK) |
> 			       snd_wnd);
> -- 
> 2.26.3
>
>
>

--
Mat Martineau
Intel

  reply	other threads:[~2021-06-15 22:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-11 17:57 [RFC PATCH] tcp: consistently disable header prediction for mptcp Paolo Abeni
2021-06-15 22:45 ` Mat Martineau [this message]
2021-06-24 16:02 ` Matthieu Baerts

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=39c13ca2-40db-5be2-732-f460d621943@linux.intel.com \
    --to=mathew.j.martineau@linux.intel.com \
    --cc=fw@strlen.de \
    --cc=mptcp@lists.linux.dev \
    --cc=pabeni@redhat.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;
as well as URLs for NNTP newsgroup(s).