One approach to indirect call optimization
by Mat Martineau
I noticed this patch on netdev to avoid an indirect call to md5_lookup,
which was accepted. It is mitigating the cost of an existing indirect call
rather than adding a new one, but shows how the maintainers are looking at
the problem.
--
Mat Martineau
Intel OTC
---------- Forwarded message ----------
Date: Mon, 23 Apr 2018 14:46:25
From: Eric Dumazet <edumazet(a)google.com>
To: David S . Miller <davem(a)davemloft.net>
Cc: netdev <netdev(a)vger.kernel.org>, Eric Dumazet <edumazet(a)google.com>,
Eric Dumazet <eric.dumazet(a)gmail.com>
Subject: [PATCH net-next] tcp: md5: only call tp->af_specific->md5_lookup() for
md5 sockets
RETPOLINE made calls to tp->af_specific->md5_lookup() quite expensive,
given they have no result.
We can omit the calls for sockets that have no md5 keys.
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
---
net/ipv4/tcp_output.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 383cac0ff0ec059ca7dbc1a6304cc7f8183e008d..95feffb6d53f8a9eadfb15a2fffeec498d6e993a 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -585,14 +585,15 @@ static unsigned int tcp_syn_options(struct sock *sk, struct sk_buff *skb,
unsigned int remaining = MAX_TCP_OPTION_SPACE;
struct tcp_fastopen_request *fastopen = tp->fastopen_req;
+ *md5 = NULL;
#ifdef CONFIG_TCP_MD5SIG
- *md5 = tp->af_specific->md5_lookup(sk, sk);
- if (*md5) {
- opts->options |= OPTION_MD5;
- remaining -= TCPOLEN_MD5SIG_ALIGNED;
+ if (unlikely(rcu_access_pointer(tp->md5sig_info))) {
+ *md5 = tp->af_specific->md5_lookup(sk, sk);
+ if (*md5) {
+ opts->options |= OPTION_MD5;
+ remaining -= TCPOLEN_MD5SIG_ALIGNED;
+ }
}
-#else
- *md5 = NULL;
#endif
/* We always get an MSS option. The option bytes which will be seen in
@@ -720,14 +721,15 @@ static unsigned int tcp_established_options(struct sock *sk, struct sk_buff *skb
opts->options = 0;
+ *md5 = NULL;
#ifdef CONFIG_TCP_MD5SIG
- *md5 = tp->af_specific->md5_lookup(sk, sk);
- if (unlikely(*md5)) {
- opts->options |= OPTION_MD5;
- size += TCPOLEN_MD5SIG_ALIGNED;
+ if (unlikely(rcu_access_pointer(tp->md5sig_info))) {
+ *md5 = tp->af_specific->md5_lookup(sk, sk);
+ if (*md5) {
+ opts->options |= OPTION_MD5;
+ size += TCPOLEN_MD5SIG_ALIGNED;
+ }
}
-#else
- *md5 = NULL;
#endif
if (likely(tp->rx_opt.tstamp_ok)) {
--
2.17.0.484.g0c8726318c-goog
3 years, 1 month
[PATCH 00/12] Make subflow establishment lockless
by Christoph Paasch
The most recent TCP stack supports lockless listeners. For MPTCP, we
however are still taking the meta-lock when creating new subflows (cfr.,
tcp_v4_rcv and mptcp_lookup_join).
This patchset makes subflow establishment lockless by using lockless
procedures in the stack, RCU-lists, atomic operations,...
Christoph Paasch (12):
mptcp: Cleanup
mptcp: Improved debugging
mptcp: Use correct tcp_queue when calling mptcp_fragment
mptcp: Use mptcp_can_new_subflow where possible
mptcp: Render mptcp_sub_inherit_sockopts lockless
mptcp: Make mptcp_set_new_pathindex lockless
mptcp: Remove cnt_subflows
mptcp: Remove cnt_established
mptcp: Rename tw_lock to mpcb_list_lock
mptcp: Make subflow-list an RCU-list
mptcp: Don't take meta-lock when receiving third ACK
mptcp: Make mptcp_do_join_short and mptcp_lookup_join lockless
include/net/mptcp.h | 120 ++++++++++-----------------
net/ipv4/af_inet.c | 9 ++-
net/ipv4/ip_sockglue.c | 7 +-
net/ipv4/tcp.c | 31 ++++---
net/ipv4/tcp_ipv4.c | 41 +---------
net/ipv4/tcp_minisocks.c | 9 ++-
net/ipv6/tcp_ipv6.c | 41 +---------
net/mptcp/mctcp_desync.c | 22 ++---
net/mptcp/mptcp_balia.c | 21 ++---
net/mptcp/mptcp_binder.c | 23 +++++-
net/mptcp/mptcp_coupled.c | 52 +++++-------
net/mptcp/mptcp_ctrl.c | 187 ++++++++++++++++++++++++++++---------------
net/mptcp/mptcp_fullmesh.c | 30 ++++---
net/mptcp/mptcp_input.c | 150 ++++++++++++----------------------
net/mptcp/mptcp_ipv4.c | 34 +++-----
net/mptcp/mptcp_ipv6.c | 15 ++--
net/mptcp/mptcp_ndiffports.c | 17 +++-
net/mptcp/mptcp_olia.c | 28 ++++---
net/mptcp/mptcp_output.c | 50 ++++++++----
net/mptcp/mptcp_redundant.c | 151 +++++++++++++++++++++++++++-------
net/mptcp/mptcp_rr.c | 22 +++--
net/mptcp/mptcp_sched.c | 32 ++++----
net/mptcp/mptcp_wvegas.c | 5 +-
23 files changed, 586 insertions(+), 511 deletions(-)
--
2.16.2
3 years, 8 months
Call for ideas for a presentation about MPTCP Upstream project at NetDev 0x12 in July
by Matthieu Baerts
Hello,
NetDev 0x12 is coming to Montréal this summer: July 11th to 13th, 2018.
We already talked about this event on this ML and at our weekly meetings
but here is a summary of the discussions we had:
- we would like to have a presentation there mainly to get feedback
and advice from other kernel developers
- a presentation would clearly indicate that this MPTCP Upstream
project exists and we could get help from more developers
- we would like to indicate that having MPTCP upstream is asked by
different companies, some are even ready to contribute ; it is then
important to have MPTCP upstream
Also note that:
- David Miller will not be present in Montréal [1] but other main
contributors should be there (we don't have a list)
- A presentation by Octavian Purdila about "MPTCP Upstreaming" has
already been given in 2015 (NetDev 0.1) [2]
- 3 types of presentation are available: talks, tutorials and
workshops [3]
- Call for Presentation Proposals closes on May 1st, 2018.
The current idea we briefly discussed during our weekly meetings is to
give a tutorial:
- It is not useful to give almost the same presentation as the one of
Octavian
- It will allow us more flexibility somehow to explain what is MPTCP,
the different use-cases, why it is important to have it upstream and
what problems we are currently facing.
- David Miller and many other kernel developers will go to LPC in
November: a good place to give a talk this time.
Do you have any ideas on what we could show in this tutorial?
I recently discussed with my colleague Olivier Bonaventure who has a lot
of experiences in giving different introductions and more about MPTCP
and here is what he suggests:
- A first part about a basic introduction of MPTCP
- Indicate different use-cases -- if possible with a "closed demo" to
be sure it is working -- asking people to setup something is not easy in
1h, max 1h30.
- Then trying to have interactive discussions or explanations about
how MPTCP is currently implemented or should be implemented if it goes
upstream, e.g.: for MPTCP, we need to have extra TCP Options, we need to
support middleboxes, we need to link subflows of the same connection
together, we need a scheduler, a PM, etc.
- Of course, we should focus our discussions on the upstreaming
aspect, e.g. reducing the footprint of MPTCP in the current TCP stack:
what are we allow to do, what not. It is linked to many previous
discussions we had on this ML, e.g. why we need more indirect function
calls and how to reduce the impact, etc.
- If we have time, we could discuss about how users could interact
with MPTCP: enable it per connection, control the path manager, maybe
the scheduler, etc.
What do you think about this? Feel free to comment and even propose
completely different ideas!
Cheers,
Matthieu
[1] https://lists.01.org/pipermail/mptcp/2018-March/000379.html
[2] https://www.youtube.com/watch?v=wftz2cU5SZs
[3] https://www.netdevconf.org/0x12/submit-proposal.html
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
--
DISCLAIMER.
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited.
3 years, 8 months
[Weekly meetings] MoM - 16th of April 2018
by Matthieu Baerts
Hello,
We just had our 7th meeting with Mat, Peter, Ossama (Intel OTC),
Christoph (Apple), Rao (Oracle) and myself (Tessares).
Thanks again for this new meeting!
Here are the minutes of the meeting:
Progress from last week:
- the wiki is ready and need to be kept updated
- there is an update in the mptcp_net-next branch (sync with net-next)
- discussions about NetDev tutorial presentations have started.
Netdev:
From what has been shared on the ML:
- https://lists.01.org/pipermail/mptcp/2018-April/000540.html
We cannot only count on discussions: we need a backup plan if
nobody is expressing something.
Show different approaches:
- current implementation where any app can benefit from MPTCP
- only on demand + API
(and respecting impact on the TCP code)
We could get more attention by talking about APIs.
Who will be there:
Christoph for sure
Maybe Mat, Peter and Matthieu, waiting for more details from
their manager(s)
Matthieu: write a proposal for the netdev conf on the ML.
Important: Discussions will continue there. We need to send
something on Monday!
Wiki:
The base is there, we need to maintain it.
It is indexed by Google and others, that's good!
Approach to indirect call optimization by Eric Dumazet:
that's one example, it is a bit specific to MD5 but the idea is
there. That's what we had in mind (but the solution is not generic)
Discussion of Oracle's patches:
- Rao is asking what to do next with these patches
- (Matthieu: I got disconnected, I maybe missed something
important, feel free to comment)
- One main concerning point raised during the call is that we will
still have a big intrusiveness with a lot of "if(mptcp)" in the code
- Rao would prefer not to rewrite the current MPTCP implementation
as much as proposed here during the meetings. Propose this first
implementation based on a previous mptcp_trunk version.
- By Christoph: this kind of code should be avoided for
maintainability reasons:
struct inet_connection_sock *icsk = from_timer(icsk, t,
icsk_delack_timer);
struct sock *sk = &icsk->icsk_inet.sk;
+#ifndef CONFIG_MPTCP
+ struct sock *meta_sk = sk;
+#else
+ struct sock *meta_sk = mptcp(tcp_sk(sk)) ?
mptcp_meta_sk(sk) : sk;
+#endif
- bh_lock_sock(sk);
+ bh_lock_sock(meta_sk);
- Discussions will continue next week.
Next steps:
- Matthieu: write a proposal for the netdev conf on the ML.
Discussions will continue there. We need to send something on Monday!
- As usual, update the wiki if there is new stuff to put in
- at the meeting next week, continue the discussions about Oracle's
patches / First implementation.
- some people will be busy on other topics during the coming days,
discussions could be "slow" on the ML like the previous days.
Next meeting:
- proposition: the 3rd of May at 9am PDT - 16:00 UTC (9am PDT, 6pm
CEST)
- open to everyone!
- https://annuel2.framapad.org/p/mptcp_upstreaming_20180503
Feel free to comment these points and propose new ones for the next
meeting!
Talk to you next week,
Matthieu
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
--
DISCLAIMER.
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited.
3 years, 8 months
MPTCP Upstreaming wiki
by Mat Martineau
Hello -
I've set up a wiki for our project:
https://github.com/multipath-tcp/mptcp_net-next/wiki
To start with I've added some information that was otherwise buried in our
mailing list archives. This includes a summary of what the community has
shared so far, meeting information, and pointers to relevant resources.
Regards,
--
Mat Martineau
Intel OTC
3 years, 8 months
Weekly meeting - 26 April 2018 16:00 UTC (9am PDT, 6pm CEST)
by Matthieu Baerts
Hello,
Our public MPTCP upstreaming weekly web conference is scheduled for
tomorrow.
The list of topics is here:
https://annuel2.framapad.org/p/mptcp_upstreaming_20180426
Feel free to add/modify topics!
Meeting link: https://talky.io/mptcp_upstreaming
Speak to you tomorrow!
Matthieu
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
--
DISCLAIMER.
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited.
3 years, 8 months
[Weekly meetings] MoM - 16th of April 2018
by Matthieu Baerts
Hello,
We just had our 6th meeting with Mat (Intel OTC), Christoph (Apple) and
myself (Tessares).
Thanks again for this new good meeting!
Please note that this meeting was exceptionally on Monday because it was
not possible to have it at the end of last week nor at the end of this
week. We propose to have the next meeting next Thursday (26th of April).
Feel free to propose other dates if needed.
Here are the minutes of the meeting:
Progress from last week:
- as expected, many people off or busy with other stuffs, not so
much new to share.
- Mat has updated the mptcp_net-net repo (see below)
- Mat is dealing with issue on the client side (version from
github.com/multipath-tcp/mptcp) when using it with a modified server
(having his patches). More discussions will continue later with a pcap.
- Matthieu finished the review of Christoph's patches (Note for
myself: not the review of Christoph's Paasch, that's different...). Do
not hesitate to review the two last commits.
mptcp_net-next merge:
- Mat started the work:
https://github.com/multipath-tcp/mptcp_net-next/
- one fix has been done (related to checksum and gso), seems OK,
feel free to comment if not:
https://github.com/multipath-tcp/mptcp_net-next/commit/6ba7f217d3a69a8815...
- Christoph will try to launch some tests using this branch
- Could be good to merge with net-next once per week to reduce the
amount of conflicts we need to fix in once
- Could be good to have two branches:
- one close to net-next and the current mptcp_trunk
- one where we have a minimal implementation → focus on the
client, simple version.
netdevconf:
- tutorial ideas: more should come. Feel free to propose any idea.
- Matthieu is trying to get more ideas
- Matthieu: will start a dedicated discussion on the ML (should do
that on Wednesday (or short after) after having collected more ideas)
topgit to manage patch sets, maybe not needed now, maybe later
- looks like a good tool for what we have to do
- could be good to have a look:
https://github.com/mackyle/topgit (new version -- recommended)
https://github.com/greenrd/topgit (original version)
- Matthieu has some experiences with it if you need some support.
- Feel free to try it, instructions are in the README
LPC:
- From Mat: still not clear what it will be.
- it is possible that they will have more miniconferences and they
will prefer that
- but will be a lot of people there (davem), very interesting to
participate, get feedback, help, advises, etc.
- the networking track submission deadline for LPC is July 11:
http://vger.kernel.org/lpc-networking.html → 350 word proposal for a 40
minute talk plus 2-10 page paper.
Next steps:
- Mat: wiki update: with links, etc. (could be good, when the base
is there, to have some help to maintain that, at least reporting
outdated links, etc.
- Christoph: will first look at the lockless patches then maybe
look at the net-next branch
- Peter will also look at mptcp-net-next branch + continue to work
on the patch-set with Mat
- Matthieu: update Netlink PM patches.
Next meeting:
- proposition: the 26th of April at 9am PDT - 16:00 UTC (9am PDT,
6pm CEST)
- open to everyone!
- https://annuel2.framapad.org/p/mptcp_upstreaming_20180426
Feel free to comment these points and propose new ones for the next meeting!
Talk to you next week,
Matthieu
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
--
DISCLAIMER.
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited.
3 years, 8 months
Weekly meeting - 16 April 2018 16:00 UTC (9am PDT, 6pm CEST)
by Matthieu Baerts
Hello,
Our public MPTCP upstreaming weekly web conference is scheduled for
tomorrow.
The list of topics is here:
https://annuel2.framapad.org/p/mptcp_upstreaming_20180416
Feel free to add/modify topics!
Meeting link: https://talky.io/mptcp_upstreaming
Speak to you tomorrow!
Matthieu
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
--
DISCLAIMER.
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited.
3 years, 9 months
Initial net-next merge
by Mat Martineau
Hello -
I've pushed a merge of mptcp_trunk and net-next to
https://github.com/multipath-tcp/mptcp_net-next/commits/master . The
intent (as discussed in the 05-April-2018 meeting) is to work toward an
upstreamable implementation by:
* Removing features and optimizations not strictly necessary for a
baseline MPTCP server
* Integrating architectural changes that are reviewed and accepted on
this mailing list
* Keeping up with net-next
While this repository is hosted on github, we will be conducting patch
review on this mailing list (and not using the github pull request
workflow).
I'll be handling the net-next merges and pushing those directly to the
repository. In the future I will push proposed merges to a separate (TBD)
branch and notify the mailing list before updating master so people have
an opportunity to review the changes.
Specifics about this merge:
I did minimal conflict resolution in the merge commit itself, and made the
build fixes and code changes in a follow-up commit.
There was a significant TCP change where GSO (generic segmentation
offload) is now always enabled (see
https://github.com/multipath-tcp/mptcp_net-next/commit/0a6b2a1dc2a2105f17...)
This led to some new assumptions, like only supporting CHECKSUM_PARTIAL
skbs for TCP transmission.
Christoph, you might want to look at the checksum change in
mptcp_skb_entail(). I did some simple tests with and without the DSS
checksum enabled that seemed to work fine.
There may be opportunity to simplify mptcp_select_size() too, since the
TCP select_size() has been cut down to only a few lines. I kept the
current MPTCP behavior for now.
--
Mat Martineau
Intel OTC
3 years, 9 months