Commit logs update request

Commit logs update request

[Geliang Tang]

Hi Matt,

As I mentioned in the weekly meeting, I noticed some of the commit logs
of my patches on the export branch became mismatch since changes have
squashed to them.

Here I send a list of new commit logs. Please help me to update them.
Thank you very much.

1. mptcp: don't send RST for single subflow 

'''
When a bad checksum is detected and a single subflow is in use, don't
send RST + MP_FAIL, send data_ack + MP_FAIL instead.

So invoke tcp_send_active_reset() only when mptcp_has_another_subflow()
is true.
'''

2. mptcp: add the fallback check 

'''
This patch adds the fallback check in subflow_check_data_avail(). Only
do the fallback when the msk hasn't fallen back yet.
'''

3. mptcp: track and update contiguous data status

'''
This patch adds a new member allow_infinite_fallback in mptcp_sock,
which is initialized to 'true' when the connection begins and is set
to 'false' on any retransmit or successful MP_JOIN. Only do infinite
mapping fallback if there is a single subflow AND there have been no
retransmissions AND there have never been any MP_JOINs.
'''

4. mptcp: infinite mapping sending

'''
This patch adds the infinite mapping sending logic.

Add a new flag send_infinite_map in struct mptcp_subflow_context. Set
it true when a single contiguous subflow is in use and the
allow_infinite_fallback flag is true in mptcp_pm_mp_fail_received().

In mptcp_sendmsg_frag(), if this flag is true, call the new function
mptcp_update_infinite_map() to set the infinite mapping.

Add a new flag infinite_map in struct mptcp_ext, set it true in
mptcp_update_infinite_map(), and check this flag in a new helper
mptcp_check_infinite_map().

In mptcp_update_infinite_map(), set data_len to 0, and clear the
send_infinite_map flag, then do fallback.

In mptcp_established_options(), use the helper mptcp_check_infinite_map()
to let the infinite mapping DSS can be sent out in the fallback mode.
'''

5. mptcp: infinite mapping receiving

'''
This patch adds the infinite mapping receiving logic. When the infinite
mapping is received, set the map_data_len of the subflow to 0.

In subflow_check_data_avail(), only reset the subflow when the map_data_len
of the subflow is non-zero.
'''

6. mptcp: add mib for infinite map sending

'''
This patch adds a new mib named MPTCP_MIB_INFINITEMAPTX, increase it
when a infinite mapping has been sent out.
'''

7. selftests: mptcp: add infinite map mibs check

'''
This patch adds a function chk_infi_nr() to check the mibs for the
infinite mapping. Invoke it in chk_join_nr() when validate_checksum
is set.
'''

8. selftests: mptcp: add the MP_FAIL testcases

'''
Add the test cases for MP_FAIL, the multiple subflows test for the
MP_RST case and the single subflow one for the infinite mapping case.
The former uses the test_linkfail value to make 1024KB test files,
and the latter 128KB.

Add a new function reset_with_fail(), in it use 'iptables' and 'tc
action pedit' rules to produce the bit flips to trigger the checksum
failures. Add a new function pedit_action_pkts() to get the numbers
of the packets edited by the tc pedit actions. Set validate_checksum
to enable checksums for the MP_FAIL tests without passing the '-C'
argument.

Also add the needed kernel configures in the selftests config file.
'''

9. mptcp: add MP_FAIL response support

'''
This patch adds a new struct member mp_fail_response_expect in struct
mptcp_subflow_context to support MP_FAIL response. In the single subflow
with checksum error and contiguous data special case, a MP_FAIL is sent
in response to another MP_FAIL.
'''

10. mptcp: reset subflow when MP_FAIL doesn't respond

'''
This patch adds a new msk->flags bit MPTCP_FAIL_NO_RESPONSE, then reuses
sk_timer to trigger a check if we have not received a response from the
peer after sending MP_FAIL. If the peer doesn't respond properly, reset
the subflow.
'''

11. selftests: mptcp: check MP_FAIL response mibs

'''
This patch extends chk_fail_nr to check the MP_FAIL response mibs.

Add a new argument invert for chk_fail_nr to allow it can check the
MP_FAIL TX and RX mibs from the opposite direction.

When the infinite map is received before the MP_FAIL response, the
response will be lost. A '-' can be added into fail_tx or fail_rx to
represent that MP_FAIL response TX or RX can be lost when doing the
checks.
'''

Thanks,
-Geliang

Re: Commit logs update request

[Matthieu Baerts]

Hi Geliang,

On 31/03/2022 17:46, Geliang Tang wrote:
> Hi Matt,
> 
> As I mentioned in the weekly meeting, I noticed some of the commit logs
> of my patches on the export branch became mismatch since changes have
> squashed to them.
> 
> Here I send a list of new commit logs. Please help me to update them.

Thank you for noticing that!

@Mat: because your RvB tag is on some of them, are you also OK with the
modification?

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

Re: Commit logs update request

[Mat Martineau]

On Thu, 31 Mar 2022, Matthieu Baerts wrote:

> Hi Geliang,
>
> On 31/03/2022 17:46, Geliang Tang wrote:
>> Hi Matt,
>>
>> As I mentioned in the weekly meeting, I noticed some of the commit logs
>> of my patches on the export branch became mismatch since changes have
>> squashed to them.
>>
>> Here I send a list of new commit logs. Please help me to update them.
>
> Thank you for noticing that!
>
> @Mat: because your RvB tag is on some of them, are you also OK with the
> modification?
>

The updated commit messages are all ok, thanks!

--
Mat Martineau
Intel

Re: Commit logs update request

[Matthieu Baerts]

Hi Geliang, Mat,

On 31/03/2022 19:09, Mat Martineau wrote:
> On Thu, 31 Mar 2022, Matthieu Baerts wrote:
> 
>> Hi Geliang,
>>
>> On 31/03/2022 17:46, Geliang Tang wrote:
>>> Hi Matt,
>>>
>>> As I mentioned in the weekly meeting, I noticed some of the commit logs
>>> of my patches on the export branch became mismatch since changes have
>>> squashed to them.
>>>
>>> Here I send a list of new commit logs. Please help me to update them.
>>
>> Thank you for noticing that!
>>
>> @Mat: because your RvB tag is on some of them, are you also OK with the
>> modification?
>>
> 
> The updated commit messages are all ok, thanks!

Thank you for having checked!

I just modified a bunch of commit messages. I didn't add Mat's RvB tag
where it was missing but I guess Mat will add a SoB anyway when sending
them upstream.

New patches for t/upstream:
- 45bd4e88d059: tg:msg: update from 'Commit logs update request'
- 608979779671: tg:msg: update from 'Commit logs update request'
- ff5034728c57: tg:msg: update from 'Commit logs update request'
- 26d0a0be59de: tg:msg: update from 'Commit logs update request'
- d681b1dfbe3c: tg:msg: update from 'Commit logs update request'
- 001e9d359899: tg:msg: update from 'Commit logs update request'
- 4ea8489f01ce: tg:msg: update from 'Commit logs update request'
- f86dbe52aa55: tg:msg: update from 'Commit logs update request'
- 99fe1bfb5fdd: tg:msg: update from 'Commit logs update request'
- d0167e625579: tg:msg: update from 'Commit logs update request'
- 3cecfdde5dc3: tg:msg: update from 'Commit logs update request'
- Results: 7ee50b5fce5a..c56ab3a9d998 (export)

Builds and tests are now in progress:

https://cirrus-ci.com/github/multipath-tcp/mptcp_net-next/export/20220401T135831
https://github.com/multipath-tcp/mptcp_net-next/actions/workflows/build-validation.yml?query=branch:export

(but it is the same content)

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net