From: Geliang Tang <geliang.tang@suse.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next] Squash to "selftests: mptcp: more stable join tests-cases"
Date: Thu, 13 Jan 2022 20:58:23 +0800 [thread overview]
Message-ID: <20220113125823.GA3195@bogon> (raw)
In-Reply-To: <06dfb6e37c6eeb34f4f9e0f23086486072e9c6ad.camel@redhat.com>
On Thu, Jan 13, 2022 at 11:52:20AM +0100, Paolo Abeni wrote:
> On Thu, 2022-01-13 at 18:35 +0800, Geliang Tang wrote:
> > On Tue, Jan 11, 2022 at 01:02:15PM +0100, Paolo Abeni wrote:
> > > On Tue, 2022-01-11 at 11:45 +0800, Geliang Tang wrote:
> > > > Hi Paolo,
> > > >
> > > > On Mon, Jan 10, 2022 at 12:11:38PM +0100, Paolo Abeni wrote:
> > > > > Hello,
> > > > >
> > > > > On Fri, 2022-01-07 at 17:51 +0800, Geliang Tang wrote:
> > > > > > IPv6 removing test failed on my test every time, this patch fixed it.
> > > > > >
> > > > > > 12 remove subflow and signal IPv6 syn[ ok ] - synack[fail] got 1 JOIN[s] synack expected 2
> > > > > > - ack[fail] got 1 JOIN[s] ack expected 2
> > > > > > Server ns stats
> > > > > > TcpPassiveOpens 2 0.0
> > > > > > TcpAttemptFails 1 0.0
> > > > > > TcpInSegs 54 0.0
> > > > > > TcpOutSegs 58 0.0
> > > > > > TcpRetransSegs 2 0.0
> > > > > > TcpExtEmbryonicRsts 1 0.0
> > > > > > TcpExtDelayedACKs 15 0.0
> > > > > > TcpExtTCPPureAcks 23 0.0
> > > > > > TcpExtTCPTimeouts 1 0.0
> > > > > > TcpExtTCPSynRetrans 2 0.0
> > > > > > TcpExtTCPOrigDataSent 24 0.0
> > > > > > TcpExtTCPDelivered 24 0.0
> > > > > > MPTcpExtMPCapableSYNRX 1 0.0
> > > > > > MPTcpExtMPCapableACKRX 1 0.0
> > > > > > MPTcpExtMPJoinSynRx 2 0.0
> > > > > > MPTcpExtMPJoinAckRx 1 0.0
> > > > > > MPTcpExtEchoAdd 1 0.0
> > > > > > MPTcpExtRmSubflow 1 0.0
> > > > > > Client ns stats
> > > > > > TcpActiveOpens 3 0.0
> > > > > > TcpInSegs 58 0.0
> > > > > > TcpOutSegs 53 0.0
> > > > > > TcpRetransSegs 1 0.0
> > > > > > TcpOutRsts 3 0.0
> > > > > > TcpExtDelayedACKs 3 0.0
> > > > > > TcpExtTCPPureAcks 29 0.0
> > > > > > TcpExtTCPTimeouts 1 0.0
> > > > > > TcpExtTCPSynRetrans 1 0.0
> > > > > > TcpExtTCPOrigDataSent 24 0.0
> > > > > > TcpExtTCPDelivered 26 0.0
> > > > > > TcpExtTcpTimeoutRehash 1 0.0
> > > > > > MPTcpExtMPCapableSYNTX 1 0.0
> > > > > > MPTcpExtMPCapableSYNACKRX 1 0.0
> > > > > > MPTcpExtMPJoinSynAckRx 1 0.0
> > > > > > MPTcpExtAddAddr 1 0.0
> > > > > > MPTcpExtRmAddr 1 0.0
> > > > > > MPTcpExtRmSubflow 1 0.0
> > > > > > add[ ok ] - echo [ ok ]
> > > > > > rm [fail] got 0 RM_ADDR[s] expected 1
> > > > > > - sf [ ok ]
> > > > > > Server ns stats
> > > > > > TcpPassiveOpens 2 0.0
> > > > > > TcpAttemptFails 1 0.0
> > > > > > TcpInSegs 54 0.0
> > > > > > TcpOutSegs 58 0.0
> > > > > > TcpRetransSegs 2 0.0
> > > > > > TcpExtEmbryonicRsts 1 0.0
> > > > > >
> > > > > > Signed-off-by: Geliang Tang <geliang.tang@suse.com>
> > > > > > ---
> > > > > > tools/testing/selftests/net/mptcp/mptcp_join.sh | 4 ++--
> > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> > > > > > index e48ce23d2386..41a2510e2f97 100755
> > > > > > --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
> > > > > > +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> > > > > > @@ -393,8 +393,8 @@ do_transfer()
> > > > > > do
> > > > > > id=${dump[$pos]}
> > > > > > rm_addr=$(rm_addr_count ${connector_ns})
> > > > > > - ip netns exec ${listener_ns} ./pm_nl_ctl del $id
> > > > > > wait_rm_addr ${connector_ns} ${rm_addr}
> > > > > > + ip netns exec ${listener_ns} ./pm_nl_ctl del $id
> > > > > > let counter+=1
> > > > > > let pos+=5
> > > > >
> > > > > Uhmm.... this is equivalent to replacing 'wait_rm_addr()' with 'sleep
> > > > > 1'. It defeats the purpouse of wait_rm_addr itself: reducing the delay
> > > > > required for 'del address' related operation. Additionally, an
> > > > > unconditional 'sleep 1' could impact negatively in other test-cases.
> > > > >
> > > > > Possibly some alike:
> > > > >
> > > > > ---
> > > > > diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh
> > > > > b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> > > > > index e48ce23d2386..b209a303d1fe 100755
> > > > > --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
> > > > > +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> > > > > @@ -366,7 +366,7 @@ do_transfer()
> > > > >
> > > > > # let the mptcp subflow be established in background before
> > > > > # do endpoint manipulation
> > > > > - [ $addr_nr_ns1 = "0" -a $addr_nr_ns2 = "0" ] || sleep 1
> > > > > + [ $addr_nr_ns1 = "0" -a $addr_nr_ns2 = "0" ] || sleep 2
> > > > >
> > > > > if [ $addr_nr_ns1 -gt 0 ]; then
> > > > > let add_nr_ns1=addr_nr_ns1
> > > > > ---
> > > >
> > > > This patch doesn't work on my test either. I changed it to "sleep 2",
> > > > the "remove subflow and signal IPv6" test still failed.
> > > >
> > > > >
> > > > > could be more appropriate, but 2secs to complete MPC + 2 MPJ HS looks
> > > > > really too much...
> > > > >
> > > > > Can you please capture a pcap trace with the failing test?
> > > >
> > > > The pcap is attached.
> > >
> > > Thank you!
> > >
> > > I'm really fail to understand why that happens, but the server replies
> > > to the subflow endpoint MPJ syn with more than 1s delay, and that
> > > causes the failure.
> > >
> > > The interesting part is that the ipv6 routing configuration is actually
> > > broken, as we lack an ipv6 route for the server on each link. The
> > > following addresses the issue here, but I don't see how things were
> > > somewhat working so far...
> > >
> > > ---
> > > diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> > > index e48ce23d2386..cdfb7da47384 100755
> > > --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
> > > +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
> > > @@ -76,6 +76,7 @@ init()
> > >
> > > # let $ns2 reach any $ns1 address from any interface
> > > ip -net "$ns2" route add default via 10.0.$i.1 dev ns2eth$i metric 10$i
> > > + ip -net "$ns2" route add default via dead:beef:$i::1 dev ns2eth$i metric 10$i
> > > done
> > > }
> > >
> > > @@ -1545,7 +1546,7 @@ ipv6_tests()
> > > ip netns exec $ns1 ./pm_nl_ctl limits 0 2
> > > ip netns exec $ns1 ./pm_nl_ctl add dead:beef:2::1 flags signal
> > > ip netns exec $ns2 ./pm_nl_ctl limits 1 2
> > > - ip netns exec $ns2 ./pm_nl_ctl add dead:beef:3::2 flags subflow
> > > + ip netns exec $ns2 ./pm_nl_ctl add dead:beef:3::2 dev ns2eth3 flags subflow
> > > run_tests $ns1 $ns2 dead:beef:1::1 0 -1 -1 slow
> > > chk_join_nr "remove subflow and signal IPv6" 2 2 2
> > > chk_add_nr 1 1
> > > ---
> >
> > Hi Paolo,
> >
> > This patch works on my test. Should we change this "single subflow IPv6" test too?
>
> In theory, yes...
> >
> > ---
> >
> > @@ -1654,7 +1655,7 @@ ipv6_tests()
> > reset
> > pm_nl_set_limits $ns1 0 1
> > pm_nl_set_limits $ns2 0 1
> > - pm_nl_add_endpoint $ns2 dead:beef:3::2 flags subflow
> > + pm_nl_add_endpoint $ns2 dead:beef:3::2 dev ns2eth3 flags subflow
> > run_tests $ns1 $ns2 dead:beef:1::1 0 0 0 slow
> > chk_join_nr "single subflow IPv6" 1 1 1
> >
> > ---
> >
> > This "single subflow IPv6" test passes every time with or without this
> > change,
>
> ... in pratice, as you noted, it's not needed.
>
> > but the "remove subflow and signal IPv6" test fails. What's the
> > difference between the two tests?
>
> I'm wild guessing, as I still fail to understand the full picture
> completely. In the "single subflow IPv6" test, is irrelevant if the
> additional subflow uses the "wrong" interface, because we just need to
> establish it.
>
> In the "remove subflow and signal IPv6" we have additional time
> constrains due to multiple subflow creation and removal, and the wrong
> routing setup causes the large delay I mentioned before, ence the
> failure.
>
> I'm very suprised the wrong routing setup casues a delay instead of an
> unreachable error and that puzzle me much.
>
> Do you prefer sending a new version of the squash-to patch, or do you
> prefer I'll go ahead with that?
>
> Please, let me know,
Hi Paolo,
Please send the new version. I'll test it if needed.
Thanks,
-Geliang
>
> /P
>
prev parent reply other threads:[~2022-01-13 12:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-07 9:51 [PATCH mptcp-next] Squash to "selftests: mptcp: more stable join tests-cases" Geliang Tang
2022-01-07 11:03 ` Matthieu Baerts
2022-01-10 7:43 ` Geliang Tang
2022-01-12 17:42 ` Matthieu Baerts
2022-01-10 11:11 ` Paolo Abeni
2022-01-11 3:45 ` Geliang Tang
2022-01-11 12:02 ` Paolo Abeni
2022-01-13 10:35 ` Geliang Tang
2022-01-13 10:52 ` Paolo Abeni
2022-01-13 11:36 ` Matthieu Baerts
2022-01-13 12:58 ` Geliang Tang [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=20220113125823.GA3195@bogon \
--to=geliang.tang@suse.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