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, fwestpha@redhat.com
Subject: Re: [PATCH mptcp-next 0/7] mptcp: refactor active backup
Date: Thu, 8 Jul 2021 18:13:12 -0700 (PDT)	[thread overview]
Message-ID: <e6a391d0-13cc-edc6-958d-745b5d3ba29c@linux.intel.com> (raw)
In-Reply-To: <cover.1624895054.git.pabeni@redhat.com>

On Mon, 28 Jun 2021, Paolo Abeni wrote:

> This series addresses a bunch of issues somewhat related to active
> backup handling. The most visible functial issue addressed here is:
>
> https://github.com/multipath-tcp/mptcp_net-next/issues/191
>
> This series also add some specific self-tests, to cover both
> active-backup switch-over and proper usage of backup link.
>
> A new netns parameter is introduced:
>
> stale_loss_cnt - the max amount of mptcp rtx timeouts with no progresses
> 	and outstanding data over a single subflow needed to declare
> 	such subflow 'stale': no more data will be queue until some ack
> 	is observed.
>
> This parameter is currently not configurable: I'm undecited if it should
> stay under the pm_netlink APIs or under the sysfs. I've a slightly
> preference for the latter. Any opinion welcome!

I also lean toward sysfs/sysctl. If anyone has reasons to prefer netlink 
for this setting I'd like to hear them!

>
> This is only lightly (but painfully) tests, my proposal it to let
> it stage in the export branch for some time.
>

Yes, I agree on staging in the export branch. I had only a couple of small 
code changes to suggest (fixes could easily be squashed). I think the more 
important consideration is how noisy the tests would be in CI. The self 
tests did not consistently pass for me, there's more detail about that in 
my patch 7/7 reply. I would suggest having the mptcp_join.sh tests at 
least in a place of "intermittent failure" rather than "rare success" 
before adding to the export branch.


- Mat


> Paolo Abeni (7):
>  mptcp: more accurate timeout
>  mptcp: less aggressive retransmission stragegy
>  mptcp: handle pending data on closed subflow
>  mptcp: faster active backup recovery
>  mptcp: add mibs for stale subflows processing
>  mptcp: backup flag from incoming MPJ ack option
>  selftests: mptcp: add testcase for active-back
>
> net/mptcp/mib.c                               |   2 +
> net/mptcp/mib.h                               |   2 +
> net/mptcp/options.c                           |   9 +-
> net/mptcp/pm.c                                |  21 ++
> net/mptcp/pm_netlink.c                        |  40 ++++
> net/mptcp/protocol.c                          | 132 ++++++++++---
> net/mptcp/protocol.h                          |  19 +-
> net/mptcp/subflow.c                           |   6 +-
> .../testing/selftests/net/mptcp/mptcp_join.sh | 185 +++++++++++++++---
> 9 files changed, 352 insertions(+), 64 deletions(-)
>
> -- 
> 2.26.3
>
>
>

--
Mat Martineau
Intel

      parent reply	other threads:[~2021-07-09  1:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28 15:54 [PATCH mptcp-next 0/7] mptcp: refactor active backup Paolo Abeni
2021-06-28 15:54 ` [PATCH mptcp-next 1/7] mptcp: more accurate timeout Paolo Abeni
2021-06-28 15:54 ` [PATCH mptcp-next 2/7] mptcp: less aggressive retransmission stragegy Paolo Abeni
2021-06-28 15:54 ` [PATCH mptcp-next 3/7] mptcp: handle pending data on closed subflow Paolo Abeni
2021-07-09  0:44   ` Mat Martineau
2021-06-28 15:54 ` [PATCH mptcp-next 4/7] mptcp: faster active backup recovery Paolo Abeni
2021-06-28 15:54 ` [PATCH mptcp-next 5/7] mptcp: add mibs for stale subflows processing Paolo Abeni
2021-06-28 15:54 ` [PATCH mptcp-next 6/7] mptcp: backup flag from incoming MPJ ack option Paolo Abeni
2021-06-28 15:54 ` [PATCH mptcp-next 7/7] selftests: mptcp: add testcase for active-back Paolo Abeni
2021-07-09  0:51   ` Mat Martineau
2021-07-09  7:04     ` Paolo Abeni
2021-07-09  1:13 ` Mat Martineau [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=e6a391d0-13cc-edc6-958d-745b5d3ba29c@linux.intel.com \
    --to=mathew.j.martineau@linux.intel.com \
    --cc=fwestpha@redhat.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 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).