MPTCP upstreaming, week of 26-Sept-2022

MPTCP upstreaming, week of 26-Sept-2022

[Mat Martineau]

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]


Matthieu and Paolo -

I upstreamed the fastopen changes for net-next today, so those are in the 
patchwork queue for the netdev maintainers:

https://patchwork.kernel.org/project/netdevbpf/list/?series=680767


The other patch sets we discussed upstreaming in the meeting last week 
were:

     - Fixes for -net:

         - [6e827151a607] mptcp: factor out __mptcp_close() without socket lock (Menglong Dong)
         - [62b5536f77f6] mptcp: fix unreleased socket in accept queue (Menglong Dong):
             - can wait a bit more and can be sent next week


     - Features for net-next:

         - [ef4a93571133] mptcp: propagate fastclose error (Paolo Abeni)
         - [885cab8b5203] mptcp: use fastclose on more edge scenarios (Paolo Abeni)
         - [13c82c8b0d9f] selftests: mptcp: update and extend fastclose test-cases (Paolo Abeni):
             - can wait a bit, Paolo would like to have a look at the modification on packetdrill side


I'm planning to upstream the two -net patches on Tuesday unless someone 
objects.


The net-next patches are slightly more complicated:

  * They were updated with a squash-to patch today
  * Need to wait until fastopen patches are merged
  * There is a minor conflict with the -net patches (just diff context)
    in "mptcp: use fastclose on more edge scenarios".


Regarding the conflict, I could wait until Friday for a likely 
net/net-next sync.

Another option is to modify the patch slightly by moving 
mptcp_check_readable() before __mptcp_check_send_data_fin(), it doesn't 
make the diff any larger and avoids the -net conflict. What do you think?

--
Mat Martineau
Intel

Re: MPTCP upstreaming, week of 26-Sept-2022

[Matthieu Baerts]

Hi Mat, Paolo,

On 27/09/2022 02:10, Mat Martineau wrote:
> 
> Matthieu and Paolo -
> 
> I upstreamed the fastopen changes for net-next today, so those are in
> the patchwork queue for the netdev maintainers:
> 
> https://patchwork.kernel.org/project/netdevbpf/list/?series=680767

Thank you!

> The other patch sets we discussed upstreaming in the meeting last week
> were:
> 
>     - Fixes for -net:
> 
>         - [6e827151a607] mptcp: factor out __mptcp_close() without
> socket lock (Menglong Dong)
>         - [62b5536f77f6] mptcp: fix unreleased socket in accept queue
> (Menglong Dong):
>             - can wait a bit more and can be sent next week
> 
> 
>     - Features for net-next:
> 
>         - [ef4a93571133] mptcp: propagate fastclose error (Paolo Abeni)
>         - [885cab8b5203] mptcp: use fastclose on more edge scenarios
> (Paolo Abeni)
>         - [13c82c8b0d9f] selftests: mptcp: update and extend fastclose
> test-cases (Paolo Abeni):
>             - can wait a bit, Paolo would like to have a look at the
> modification on packetdrill side
> 
> 
> I'm planning to upstream the two -net patches on Tuesday unless someone
> objects.

Sounds good to me.

> The net-next patches are slightly more complicated:
> 
>  * They were updated with a squash-to patch today
>  * Need to wait until fastopen patches are merged

We should at least wait for the fastopen patches to be applied I suppose.

>  * There is a minor conflict with the -net patches (just diff context)
>    in "mptcp: use fastclose on more edge scenarios".
> 
> 
> Regarding the conflict, I could wait until Friday for a likely
> net/net-next sync.
> 
> Another option is to modify the patch slightly by moving
> mptcp_check_readable() before __mptcp_check_send_data_fin(), it doesn't
> make the diff any larger and avoids the -net conflict. What do you think?

We can also add a note in the commit and explain how to fix this
conflict. I think the function is at the right place but it can also be
moved if it eases stuff.

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

Re: MPTCP upstreaming, week of 26-Sept-2022

[Paolo Abeni]

On Tue, 2022-09-27 at 10:07 +0200, Matthieu Baerts wrote:
> Hi Mat, Paolo,
> 
> On 27/09/2022 02:10, Mat Martineau wrote:
> > 
> > Matthieu and Paolo -
> > 
> > I upstreamed the fastopen changes for net-next today, so those are in
> > the patchwork queue for the netdev maintainers:
> > 
> > https://patchwork.kernel.org/project/netdevbpf/list/?series=680767
> 
> Thank you!
> 
> > The other patch sets we discussed upstreaming in the meeting last week
> > were:
> > 
> >     - Fixes for -net:
> > 
> >         - [6e827151a607] mptcp: factor out __mptcp_close() without
> > socket lock (Menglong Dong)
> >         - [62b5536f77f6] mptcp: fix unreleased socket in accept queue
> > (Menglong Dong):
> >             - can wait a bit more and can be sent next week
> > 
> > 
> >     - Features for net-next:
> > 
> >         - [ef4a93571133] mptcp: propagate fastclose error (Paolo Abeni)
> >         - [885cab8b5203] mptcp: use fastclose on more edge scenarios
> > (Paolo Abeni)
> >         - [13c82c8b0d9f] selftests: mptcp: update and extend fastclose
> > test-cases (Paolo Abeni):
> >             - can wait a bit, Paolo would like to have a look at the
> > modification on packetdrill side
> > 
> > 
> > I'm planning to upstream the two -net patches on Tuesday unless someone
> > objects.
> 
> Sounds good to me.
> 
> > The net-next patches are slightly more complicated:
> > 
> >  * They were updated with a squash-to patch today
> >  * Need to wait until fastopen patches are merged
> 
> We should at least wait for the fastopen patches to be applied I suppose.
> 
> >  * There is a minor conflict with the -net patches (just diff context)
> >    in "mptcp: use fastclose on more edge scenarios".
> > 
> > 
> > Regarding the conflict, I could wait until Friday for a likely
> > net/net-next sync.
> > 
> > Another option is to modify the patch slightly by moving
> > mptcp_check_readable() before __mptcp_check_send_data_fin(), it doesn't
> > make the diff any larger and avoids the -net conflict. What do you think?
> 
> We can also add a note in the commit and explain how to fix this
> conflict. I think the function is at the right place but it can also be
> moved if it eases stuff.


I think there is no rush for that patches. If the net patches will land
upstream soon, they will be likely merged by EoW. If there will be
another RC, we can rebase the net-next and send out still for 6.1,
othewise the fastclose patches can wait IMHO a few more weeks.

Cheers,

Paolo

Re: MPTCP upstreaming, week of 26-Sept-2022

[Mat Martineau]

[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]

On Tue, 27 Sep 2022, Paolo Abeni wrote:

> On Tue, 2022-09-27 at 10:07 +0200, Matthieu Baerts wrote:
>> Hi Mat, Paolo,
>>
>> On 27/09/2022 02:10, Mat Martineau wrote:
>>>
>>>     - Features for net-next:
>>>
>>>         - [ef4a93571133] mptcp: propagate fastclose error (Paolo Abeni)
>>>         - [885cab8b5203] mptcp: use fastclose on more edge scenarios
>>> (Paolo Abeni)
>>>         - [13c82c8b0d9f] selftests: mptcp: update and extend fastclose
>>> test-cases (Paolo Abeni):
>>>             - can wait a bit, Paolo would like to have a look at the
>>> modification on packetdrill side
>>>
>>>
>>> The net-next patches are slightly more complicated:
>>>
>>>  * They were updated with a squash-to patch today
>>>  * Need to wait until fastopen patches are merged
>>
>> We should at least wait for the fastopen patches to be applied I suppose.
>>
>>>  * There is a minor conflict with the -net patches (just diff context)
>>>    in "mptcp: use fastclose on more edge scenarios".
>>>
>>>
>>> Regarding the conflict, I could wait until Friday for a likely
>>> net/net-next sync.
>>>
>>> Another option is to modify the patch slightly by moving
>>> mptcp_check_readable() before __mptcp_check_send_data_fin(), it doesn't
>>> make the diff any larger and avoids the -net conflict. What do you think?
>>
>> We can also add a note in the commit and explain how to fix this
>> conflict. I think the function is at the right place but it can also be
>> moved if it eases stuff.
>
>
> I think there is no rush for that patches. If the net patches will land
> upstream soon, they will be likely merged by EoW. If there will be
> another RC, we can rebase the net-next and send out still for 6.1,
> othewise the fastclose patches can wait IMHO a few more weeks.
>

Thanks Paolo.

With the net and net-next patches for MPTCP just merged today, and the 
backlog in netdev patchwork, I'll wait on the fastclose changes:

ee1e43f10dc5 mptcp: update misleading comments.
d1c02fee7732 selftests: mptcp: update and extend fastclose test-cases
61fc1bc2edeb mptcp: use fastclose on more edge scenarios
20af637811c9 mptcp: propagate fastclose error

And the recent TCP_FASTOPEN_NO_COOKIE changes:

de98c67ae3a9 mptcp: add TCP_FASTOPEN_NO_COOKIE support
a05c21ad4572 mptcp: sockopt: make 'tcp_fastopen_connect' generic
(plus "mptcp: sockopt: use new helper for TCP_DEFER_ACCEPT" that's still 
in patchwork).


It sounds like rc8 is unlikely 
(https://lore.kernel.org/lkml/CAHk-=wjc_CDPy5WbN=e_FtPrd0Yn2Wp4JcdRByeyDoM9azK1mA@mail.gmail.com/) 
but I can revisit next week if there isn't a final 6.0 on Sunday.

Thanks,

--
Mat Martineau
Intel

Re: MPTCP upstreaming, week of 26-Sept-2022

[Matthieu Baerts]

Hi Mat, Paolo,

On 30/09/2022 00:54, Mat Martineau wrote:
> On Tue, 27 Sep 2022, Paolo Abeni wrote:
> 
>> On Tue, 2022-09-27 at 10:07 +0200, Matthieu Baerts wrote:
>>> Hi Mat, Paolo,
>>>
>>> On 27/09/2022 02:10, Mat Martineau wrote:
>>>>
>>>>     - Features for net-next:
>>>>
>>>>         - [ef4a93571133] mptcp: propagate fastclose error (Paolo Abeni)
>>>>         - [885cab8b5203] mptcp: use fastclose on more edge scenarios
>>>> (Paolo Abeni)
>>>>         - [13c82c8b0d9f] selftests: mptcp: update and extend fastclose
>>>> test-cases (Paolo Abeni):
>>>>             - can wait a bit, Paolo would like to have a look at the
>>>> modification on packetdrill side
>>>>
>>>>
>>>> The net-next patches are slightly more complicated:
>>>>
>>>>  * They were updated with a squash-to patch today
>>>>  * Need to wait until fastopen patches are merged
>>>
>>> We should at least wait for the fastopen patches to be applied I
>>> suppose.
>>>
>>>>  * There is a minor conflict with the -net patches (just diff context)
>>>>    in "mptcp: use fastclose on more edge scenarios".
>>>>
>>>>
>>>> Regarding the conflict, I could wait until Friday for a likely
>>>> net/net-next sync.
>>>>
>>>> Another option is to modify the patch slightly by moving
>>>> mptcp_check_readable() before __mptcp_check_send_data_fin(), it doesn't
>>>> make the diff any larger and avoids the -net conflict. What do you
>>>> think?
>>>
>>> We can also add a note in the commit and explain how to fix this
>>> conflict. I think the function is at the right place but it can also be
>>> moved if it eases stuff.
>>
>>
>> I think there is no rush for that patches. If the net patches will land
>> upstream soon, they will be likely merged by EoW. If there will be
>> another RC, we can rebase the net-next and send out still for 6.1,
>> othewise the fastclose patches can wait IMHO a few more weeks.
>>
> 
> Thanks Paolo.
> 
> With the net and net-next patches for MPTCP just merged today, and the
> backlog in netdev patchwork, I'll wait on the fastclose changes:
> 
> ee1e43f10dc5 mptcp: update misleading comments.
> d1c02fee7732 selftests: mptcp: update and extend fastclose test-cases
> 61fc1bc2edeb mptcp: use fastclose on more edge scenarios
> 20af637811c9 mptcp: propagate fastclose error

Just in case you still see an opportunity to have this in the next 6.1,
that would be great to have it.
I say that because it is looking like a fix -- we were hesitating
between net and net-next -- and it seems needed for some use-cases to
mimic TCP + also it is only affecting MPTCP :)

But if it is too late, I understand :)

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