From: Paolo Abeni <pabeni at redhat.com>
To: mptcp at lists.01.org
Subject: [MPTCP] [PATCH v1 0/4] mptcp: fallback socket cleanup
Date: Tue, 10 Dec 2019 00:52:06 +0100 [thread overview]
Message-ID: <cover.1575934525.git.pabeni@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]
This is a rebase on top of last rebased by Florian.
The old patch 2/5 has been dropped - obsoleted by Florian's patches - and the
following patches has been reworked a bit, due to mptcp_subflow_tcp_socket() ->
mptcp_subflow_tcp_sock() change.
Last patch now also deal with mptcp_copy_inaddrs() in order to remove the lock
from mptcp_finish_connect() we must move that to connect() and calling it also
from bind(), listen() allows simplifying mptcp_getname(), too.
From the original cover letter:
---
After all the above, performance for connection fallen back to plain TCP should
be almost the same of TCP connection on unpacked kernel.
Addittionally 'nc' and 'netperf' now run successfully when forced to MPTCP.
The latter still report a non fatal error at connection closing time as it
performs:
getsockopt(4, SOL_TCP, TCP_MAXSEG, //...);
getsockopt(4, SOL_TCP, TCP_INFO, //...);
which is still unsupported after that the mp capable handshake is started.
For the records on the debug build I'm using netperf scores better result
with MPTCP that with plain TCP ;) [agreed, completely irrelevant, still nice]
The series applies at selftests and is unsquashed - will require quite a bit
of work there and more work to rebase/adjust the patches after kselftest.
I'll start that after the pending patches are in.
_Any_ feedback _very_ welcome!
Paolo Abeni (4):
mptcp: clear 'is_tcp' socket flag when the MP_CAPABLE handshake fails
imptcp: cleanup fallback handling
mptcp: add subflow to conn_list early
mptcp: avoid acquiring the msk lock in mptcp_finisch_connect()
net/mptcp/options.c | 3 +
net/mptcp/protocol.c | 320 +++++++++++++++++++++----------------------
net/mptcp/subflow.c | 2 +
3 files changed, 163 insertions(+), 162 deletions(-)
--
2.21.0
reply other threads:[~2019-12-09 23:52 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=cover.1575934525.git.pabeni@redhat.com \
--to=unknown@example.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.