From: Geliang Tang <geliang.tang@suse.com>
To: Matthieu Baerts <matthieu.baerts@tessares.net>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v4 5/5] selftests: mptcp: add mp_fail testcases
Date: Wed, 9 Feb 2022 21:52:31 +0800 [thread overview]
Message-ID: <20220209135231.GA9987@bogon> (raw)
In-Reply-To: <79b19fe9-e576-c4fe-82bb-cb2ca88e1e4e@tessares.net>
Hi Matt,
On Wed, Feb 09, 2022 at 12:13:00PM +0100, Matthieu Baerts wrote:
> Hi Geliang,
>
> On 09/02/2022 11:55, Geliang Tang wrote:
> > On Wed, Feb 09, 2022 at 10:23:52AM +0100, Matthieu Baerts wrote:
> >> On 09/02/2022 09:57, Geliang Tang wrote:
> >>> +fail_tests()
> >>> +{
> >>> + # multiple subflows
> >>> + reset_with_fail 2
> >>> + pm_nl_set_limits $ns1 0 2
> >>> + pm_nl_set_limits $ns2 0 2
> >>> + pm_nl_add_endpoint $ns2 10.0.2.2 dev ns2eth2 flags subflow
> >>> + pm_nl_add_endpoint $ns2 10.0.3.2 dev ns2eth3 flags subflow
> >>> + run_tests $ns1 $ns2 10.0.1.1 3
> >>> + pedit_action_happened 2
> >>> + chk_join_nr "MP_FAIL MP_RST: $pedit_action pedit action" 2 2 2 \
> >>> + $pedit_action $pedit_action
> >>
> >> Related to my comment in the v2: we should not use $pedit_action in the
> >> args we need to verify I think. Instead we should probably then have:
> >>
> >> chk_join_nr "(...)" 2 2 2 1 1
> >
> > Thanks for your review and suggestions. I updated them in v5.
> >
> > We will get this failure in v5 in rare cases, about one percent
> > probability
>
> Do you know why?
>
> We invert a byte so it should always cause an issue, no? (we can always
> have 2 same hashes for two different sources but it is a very very rare
> case we don't have to consider I think, especially when the content is
> so close, no?)
>
> Or maybe we need to improve the IPTables and TC rules?
>
I think we should go back to the old version of this patch. We shouldn't
always expect getting 1 MP_FAIL. If no checksum failure occur, we should
expect no MP_FAIL. I just sent a squash-to patch to fix this.
Thanks,
-Geliang
> Cheers,
> Matt
> --
> Tessares | Belgium | Hybrid Access Solutions
> www.tessares.net
>
prev parent reply other threads:[~2022-02-09 13:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-09 8:57 [PATCH mptcp-next v4 0/5] add mp_fail testcases Geliang Tang
2022-02-09 8:57 ` [PATCH mptcp-next v4 1/5] Squash to "mptcp: infinite mapping receiving" Geliang Tang
2022-02-09 8:57 ` [PATCH mptcp-next v4 2/5] Squash to "selftests: mptcp: add infinite map mibs check" Geliang Tang
2022-02-09 8:57 ` [PATCH mptcp-next v4 3/5] mptcp: add mibs for MP_RST Geliang Tang
2022-02-09 8:57 ` [PATCH mptcp-next v4 4/5] selftests: mptcp: add MP_RST mibs check Geliang Tang
2022-02-09 8:57 ` [PATCH mptcp-next v4 5/5] selftests: mptcp: add mp_fail testcases Geliang Tang
2022-02-09 9:23 ` Matthieu Baerts
2022-02-09 10:55 ` Geliang Tang
2022-02-09 11:13 ` Matthieu Baerts
2022-02-09 13:52 ` 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=20220209135231.GA9987@bogon \
--to=geliang.tang@suse.com \
--cc=matthieu.baerts@tessares.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox