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: Thu, 9 Sep 2021 17:00:06 -0700 (PDT) [thread overview]
Message-ID: <4e24a896-b1bf-c6ee-2db9-4d1d572c99cd@linux.intel.com> (raw)
In-Reply-To: <7147f377124eaa4445aa11e8f8f4efbd72d69261.camel@redhat.com>
On Thu, 9 Sep 2021, Paolo Abeni wrote:
> On Thu, 2021-09-09 at 19:51 +0800, Geliang Tang wrote:
>> From: Geliang Tang <geliangtang@xiaomi.com>
>>
>> This patch added a "noncontiguous" flag in the msk to track whether the
>> data is contiguous on a subflow. When retransmission happens, we could
>> set this flag, and once all retransmissions are DATA_ACK'd that flag
>> could be cleared.
>>
>> When a bad checksum is detected and a single contiguous subflow is in
>> use, don't send RST + MP_FAIL, send data_ack + MP_FAIL instead.
>>
>> Signed-off-by: Geliang Tang <geliangtang@xiaomi.com>
>> ---
>> net/mptcp/protocol.c | 7 +++++++
>> net/mptcp/protocol.h | 2 ++
>> net/mptcp/subflow.c | 12 ++++++------
>> 3 files changed, 15 insertions(+), 6 deletions(-)
>>
>> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
>> index bb8a2a231479..81ea03b9fff6 100644
>> --- a/net/mptcp/protocol.c
>> +++ b/net/mptcp/protocol.c
>> @@ -1095,6 +1095,9 @@ static void __mptcp_clean_una(struct sock *sk)
>>
>> dfrag_uncharge(sk, delta);
>> cleaned = true;
>> +
>> + if (dfrag->resend_count == 0)
>> + WRITE_ONCE(msk->noncontiguous, false);
>> }
>>
>> /* all retransmitted data acked, recovery completed */
>> @@ -1171,6 +1174,7 @@ mptcp_carve_data_frag(const struct mptcp_sock *msk, struct page_frag *pfrag,
>> dfrag->overhead = offset - orig_offset + sizeof(struct mptcp_data_frag);
>> dfrag->offset = offset + sizeof(struct mptcp_data_frag);
>> dfrag->already_sent = 0;
>> + dfrag->resend_count = 0;
>> dfrag->page = pfrag->page;
>>
>> return dfrag;
>> @@ -2454,6 +2458,8 @@ static void __mptcp_retrans(struct sock *sk)
>> dfrag->already_sent = max(dfrag->already_sent, info.sent);
>> tcp_push(ssk, 0, info.mss_now, tcp_sk(ssk)->nonagle,
>> info.size_goal);
>> + dfrag->resend_count++;
>> + WRITE_ONCE(msk->noncontiguous, true);
>> }
>>
>> release_sock(ssk);
>> @@ -2872,6 +2878,7 @@ struct sock *mptcp_sk_clone(const struct sock *sk,
>> WRITE_ONCE(msk->fully_established, false);
>> if (mp_opt->suboptions & OPTION_MPTCP_CSUMREQD)
>> WRITE_ONCE(msk->csum_enabled, true);
>> + WRITE_ONCE(msk->noncontiguous, false);
>>
>> msk->write_seq = subflow_req->idsn + 1;
>> msk->snd_nxt = msk->write_seq;
>> diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
>> index d3e6fd1615f1..011f84ae1593 100644
>> --- a/net/mptcp/protocol.h
>> +++ b/net/mptcp/protocol.h
>> @@ -213,6 +213,7 @@ struct mptcp_data_frag {
>> u16 offset;
>> u16 overhead;
>> u16 already_sent;
>> + u16 resend_count;
>> struct page *page;
>> };
>
> Ouch, the above increases mptcp_data_frag size by 8 bytes, due to
> holes.
>
What about rearranging the struct to eliminate the holes? (Full
disclosure: I asked Geliang to add this, but am open to other solutions)
I was also thinking it could be useful to have this information around for
retransmission metrics, but that doesn't seem too important.
> Is this necessary? I think the packet scheduler never reinject with a
> single subflow. It used to do that, but it should not do anymore.
>
There may be a single subflow now, but multiple subflows (with
unacked reinjections) a very short time ago.
> Even if the scheduler re-inject with a single subflow, can we instead
> keep track of the last retrans sequence number - in __mptcp_retrans().
>
> 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.
--
Mat Martineau
Intel
next prev parent reply other threads:[~2021-09-10 0:00 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 [this message]
2021-09-10 15:08 ` Paolo Abeni
2021-09-10 16:49 ` Mat Martineau
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=4e24a896-b1bf-c6ee-2db9-4d1d572c99cd@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.