From: Matthieu Baerts <matthieu.baerts@tessares.net>
To: Mat Martineau <mathew.j.martineau@linux.intel.com>,
Paolo Abeni <pabeni@redhat.com>
Cc: mptcp@lists.linux.dev
Subject: Re: MPTCP upstreaming, week of 26-Sept-2022
Date: Tue, 27 Sep 2022 10:07:42 +0200 [thread overview]
Message-ID: <2d24f789-9fc1-0229-4b37-ff570c4be080@tessares.net> (raw)
In-Reply-To: <57e168ae-9de0-c986-cab1-a130e72e4e95@linux.intel.com>
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
next prev parent reply other threads:[~2022-09-27 8:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 0:10 MPTCP upstreaming, week of 26-Sept-2022 Mat Martineau
2022-09-27 8:07 ` Matthieu Baerts [this message]
2022-09-27 14:11 ` Paolo Abeni
2022-09-29 22:54 ` Mat Martineau
2022-09-30 14:13 ` Matthieu Baerts
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=2d24f789-9fc1-0229-4b37-ff570c4be080@tessares.net \
--to=matthieu.baerts@tessares.net \
--cc=mathew.j.martineau@linux.intel.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.