Re: [MPTCP] [Weekly meetings] MoM - 16th of April 2018

[Christoph Paasch <cpaasch at apple.com>]

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

On 26/04/18 - 11:31:14, Rao Shoaib wrote:
> 
> 
> On 04/26/2018 10:27 AM, Matthieu Baerts wrote:
> > 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.
> > 
> > 
> I would like to point out that the statement made was that the code is
> littered with what is shown above. The patch that Oracle submitted has not
> such code in the fast path plus unlike the mptcp-dev implementation we have
> significantly reduced it.  Please take a look at the patch. I also do not
> see any maintenance issues with the code, the only issue is that it is an
> eye sore but not when used minimally and we have plans to clean it up.
> 
> rshoaib(a)caduceus5:/home/mptcp/upstream/net/ipv4(upstream)$grep bh_lock_sock
> tcp*.c | grep meta_sk | wc -l
> 5
> rshoaib(a)caduceus5:/home/mptcp/upstream/net/ipv4(upstream)$cd ../ipv6
> rshoaib(a)caduceus5:/home/mptcp/upstream/net/ipv6(upstream)$!grep
> rshoaib(a)caduceus5:/home/mptcp/upstream/net/ipv6(upstream)$grep bh_lock_sock
> tcp*.c | grep meta_sk | wc -l
> 1

This kind of lock-taking also causes trouble with RCU LOCKDEP debugging - as
I mentioned in a previous e-mail.

And beyond that, it requires that everytime a TCP-change is being done, one
needs to take MPTCP into account. E.g., when upstream added the SOCK_DESTROY
interface (and Samsung backported it to v4.4), there were panics on Android
devices (https://github.com/multipath-tcp/mptcp/issues/170).

Avoid taking the meta-socket lock on subflow-work allows for much easier
maintenance in the long-term.


Christoph