All of lore.kernel.org
 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
Subject: Re: [PATCH v2 0/5] mptcp: improve mptcp-level window tracking
Date: Thu, 21 Apr 2022 17:04:00 -0700 (PDT)	[thread overview]
Message-ID: <fae0eb5d-34ea-55f6-6bc8-035e4a6c7b3@linux.intel.com> (raw)
In-Reply-To: <cover.1650550242.git.pabeni@redhat.com>

On Thu, 21 Apr 2022, Paolo Abeni wrote:

> I've been chasing bad/unstable performances with multiple subflows
> on very high speed links.
>
> It looks like the root cause is due to the current mptcp-level
> congestion window handling. There are apparently a few different
> sub-issues:
>
> - the rcv_wnd is not effectively shared on the tx side, as each
>  subflow takes in account only the value received by the underlaying
>  TCP connection. This is addressed in patch 1/4
>
> - The mptcp-level offered wnd right edge is currently allowed to shrink.
>  Reading section 3.3.4.:
>
> """
>   The receive window is relative to the DATA_ACK.  As in TCP, a
>   receiver MUST NOT shrink the right edge of the receive window (i.e.,
>   DATA_ACK + receive window).  The receiver will use the data sequence
>   number to tell if a packet should be accepted at the connection
>   level.
> """
>
> I read the above as we need to reflect window right-edge tracking
> on the wire, see patch 3/4.
>
> - The offered window right edge tracking can happen concurrently on
>  multiple subflows, but there is no mutex protection. We need an
>  additional atomic operation - still patch 3/4
>
> This series additionally bump a few new MIBs to track all the above
> (ensure/observe that the suspected races actually take place).
>
> I could not access again the host where the issue was su much
> noticeable, still in the current setup the tput changes from
> [6-18] Gbps to 19Gbps very stable.
>
> v1 -> v2:
> - pass only the TCP header to tcp_options_write (Mat)
> - fix build issues on some 32 bit arches (intel bot)

v2 looks good for the export branch, thanks Paolo.

Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>

>
> RFC -> v1:
> - added patch 3/5 to address Mat's comment, and rebased the
>   following on top of it - I hope Eric may tolerate that, it's
>   more an hope than guess ;)
>
> Paolo Abeni (5):
>  mptcp: really share subflow snd_wnd
>  mptcp: add mib for xmit window sharing
>  tcp: allow MPTCP to update the announced window.
>  mptcp: never shrink offered window
>  mptcp: add more offered MIBs counter.
>
> include/net/mptcp.h   |  2 +-
> net/ipv4/tcp_output.c | 14 ++++++-----
> net/mptcp/mib.c       |  4 +++
> net/mptcp/mib.h       |  6 +++++
> net/mptcp/options.c   | 58 +++++++++++++++++++++++++++++++++++++------
> net/mptcp/protocol.c  | 32 +++++++++++++++---------
> net/mptcp/protocol.h  |  2 +-
> 7 files changed, 90 insertions(+), 28 deletions(-)
>
> -- 
> 2.35.1
>
>
>

--
Mat Martineau
Intel

  parent reply	other threads:[~2022-04-22  0:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21 14:20 [PATCH v2 0/5] mptcp: improve mptcp-level window tracking Paolo Abeni
2022-04-21 14:20 ` [PATCH v2 1/5] mptcp: really share subflow snd_wnd Paolo Abeni
2022-04-21 14:20 ` [PATCH v2 2/5] mptcp: add mib for xmit window sharing Paolo Abeni
2022-04-21 14:20 ` [PATCH v2 3/5] tcp: allow MPTCP to update the announced window Paolo Abeni
2022-04-21 14:20 ` [PATCH v2 4/5] mptcp: never shrink offered window Paolo Abeni
2022-04-21 14:20 ` [PATCH v2 5/5] mptcp: add more offered MIBs counter Paolo Abeni
2022-04-21 16:08   ` mptcp: add more offered MIBs counter.: Tests Results MPTCP CI
2022-04-22  0:04 ` Mat Martineau [this message]
2022-04-22 15:18 ` [PATCH v2 0/5] mptcp: improve mptcp-level window tracking 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=fae0eb5d-34ea-55f6-6bc8-035e4a6c7b3@linux.intel.com \
    --to=mathew.j.martineau@linux.intel.com \
    --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 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.