MPTCP Linux Development
 help / color / mirror / Atom feed
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
> 


      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