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: Geliang Tang <geliangtang@gmail.com>,
	mptcp@lists.linux.dev,  Geliang Tang <geliangtang@xiaomi.com>
Subject: Re: [PATCH mptcp-next v2 1/9] mptcp: add noncontiguous flag
Date: Fri, 10 Sep 2021 09:49:13 -0700 (PDT)	[thread overview]
Message-ID: <8f5469f2-c25f-31f-d562-da5f1d6b6a2e@linux.intel.com> (raw)
In-Reply-To: <4300fcede93507b5d6c8d3e743007e31985ce84b.camel@redhat.com>

On Fri, 10 Sep 2021, Paolo Abeni wrote:

> On Thu, 2021-09-09 at 17:00 -0700, Mat Martineau wrote:
>>> On Thu, 9 Sep 2021, Paolo Abeni wrote:
>>> msk stream is 'continuous' if and only if 'before64(last_retrnas_seq,
>>> msk->snd_una)'
>>>
>>
>> If last_retrans_seq is checked only when msk->noncontiguous is true, I
>> think that works out. Otherwise the last_retrans_seq is stale/invalid if
>> retransmission never happened, or any retransmissions have been fully
>> acked.
>
> I think can we just init 'last_retrans_seq' to intial_seq - 1 at msk
> creation time and we could always use the above check:
>
> 	if (before64(last_retrnas_seq, msk->snd_una))
>
> WDYT?
>

Ah, ok. Initialize it like that, and then keep moving last_retrans_seq 
ahead when updating snd_una and the MPTCP stream *is* contiguous, so we 
don't run in to problems when snd_una wraps around relative to 
last_retrans_seq.

And be sure to set last_retrans_seq to the sequence number for the end of 
the retransmitted data when entering recovery as well as in 
__mptcp_retrans().

--
Mat Martineau
Intel

  reply	other threads:[~2021-09-10 16:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 11:51 [PATCH mptcp-next v2 0/9] The infinite mapping support Geliang Tang
2021-09-09 11:51 ` [PATCH mptcp-next v2 1/9] mptcp: add noncontiguous flag Geliang Tang
2021-09-09 13:25   ` Paolo Abeni
2021-09-10  0:00     ` Mat Martineau
2021-09-10 15:08       ` Paolo Abeni
2021-09-10 16:49         ` Mat Martineau [this message]
2021-09-09 11:51 ` [PATCH mptcp-next v2 2/9] mptcp: add MPTCP_INFINITE_DONE flag Geliang Tang
2021-09-09 13:31   ` Paolo Abeni
2021-09-09 11:51 ` [PATCH mptcp-next v2 3/9] mptcp: add MAPPING_INFINITE mapping status Geliang Tang
2021-09-09 13:39   ` Paolo Abeni
2021-09-10  0:21     ` Mat Martineau
2021-09-10 15:23       ` Paolo Abeni
2021-09-10 17:22         ` Mat Martineau
2021-09-09 11:51 ` [PATCH mptcp-next v2 4/9] mptcp: add start_seq in the msk Geliang Tang
2021-09-10  0:39   ` Mat Martineau
2021-09-09 11:51 ` [PATCH mptcp-next v2 5/9] mptcp: infinite mapping sending Geliang Tang
2021-09-09 13:54   ` Paolo Abeni
2021-09-09 11:51 ` [PATCH mptcp-next v2 6/9] mptcp: infinite mapping receiving Geliang Tang
2021-09-09 13:55   ` Paolo Abeni
2021-09-09 11:51 ` [PATCH mptcp-next v2 7/9] mptcp: add a mib for the infinite mapping sending Geliang Tang
2021-09-09 11:51 ` [PATCH mptcp-next v2 8/9] selftests: mptcp: add infinite map mibs check Geliang Tang
2021-09-09 11:51 ` [PATCH mptcp-next v2 9/9] DO-NOT-MERGE: mptcp: mp_fail test Geliang Tang
2021-09-09 14:23   ` Paolo Abeni
2021-09-22  3:50     ` Geliang Tang

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=8f5469f2-c25f-31f-d562-da5f1d6b6a2e@linux.intel.com \
    --to=mathew.j.martineau@linux.intel.com \
    --cc=geliangtang@gmail.com \
    --cc=geliangtang@xiaomi.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.