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

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

[Rao Shoaib]

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



On 04/26/2018 01:52 PM, Christoph Paasch wrote:
>
> This kind of lock-taking also causes trouble with RCU LOCKDEP debugging - as
> I mentioned in a previous e-mail.
I have not looked into it so I can not comment. I am sure we will find a 
way to address it.
>
> 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.
The bug that you have pointed out is a run of the mill bug that we see 
everyday, there is nothing special about it.

Taking meta lock actually simplifies things a lot and has reduced 
maintainable cost, not taking the meta lock will create timing issues 
left and right. So we are just trading one headache with another.

Holding meta lock should not be piped up unnecessarily. Yes, if possible 
if should be changed, plus our patch has only 6 cases in TCP.

Shoaib.

[1] If MPTCP is built on top of TCP, any change in TCP will always have 
to worry about MPTCP particularly in the control path. There is a 
overhead of adding MPTCP on TCP and no one can argue against it.

>
>
> Christoph
>

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

[Rao Shoaib]

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



On 04/30/2018 09:34 AM, Christoph Paasch wrote:
> On 26/04/18 - 17:43:44, Rao Shoaib wrote:
>>
>> On 04/26/2018 03:20 PM, Christoph Paasch wrote:
>>> On 26/04/18 - 14:25:24, Rao Shoaib wrote:
>>>> On 04/26/2018 01:52 PM, Christoph Paasch wrote:
>>>>> This kind of lock-taking also causes trouble with RCU LOCKDEP debugging - as
>>>>> I mentioned in a previous e-mail.
>>>> I have not looked into it so I can not comment. I am sure we will find a way
>>>> to address it.
>>>>> 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.
>>>> The bug that you have pointed out is a run of the mill bug that we see
>>>> everyday, there is nothing special about it.
>>> Euh, you mean the issue #170 is happening frequently?
>>>
>>> It shouldn't! If it does, that's a big concern.
>> No we have not encountered the bug. What I meant to say was that when
>> changes or enhancements are made to the code it is quite common that
>> something breaks.
> This is exactly what should be avoided. See my below comment on
> maintainability.
>
>> That is the case in the bug that you pointed.
>>>> Taking meta lock actually simplifies things a lot and has reduced
>>>> maintainable cost, not taking the meta lock will create timing issues left
>>>> and right. So we are just trading one headache with another.
>>>>
>>>> Holding meta lock should not be piped up unnecessarily. Yes, if possible if
>>>> should be changed, plus our patch has only 6 cases in TCP.
>>> I think, you are taking the MPTCP point-of-view here. Yes, taking the
>>> meta-level lock does reduce maintainability of MPTCP (which is why we did it
>>> that way in the first place ;-))
>>>
>>> However, for upstreaming we have to think the other way around. TCP is the
>>> common-case, and MPTCP is the exotic corner-case only few care about.
>>>
>>> So, TCP-maintainability is of outmost importance. Way more important than
>>> MPTCP's.
>> I agree that TCP stability and maintainability is of extreme importantance.
>> However, this code causes no instability or maintainability issues to TCP
>> code. Consider the bug that you pointed out, MPTCP fails not TCP. We have to
>> accept the fact that TCP changes will break  MPTCP no matter what the
>> implementation is because TCP maintainers may or may not test MPTCP. So this
>> is nothing out of the extraordinary.
>> Our patch tries to maintain the stability of TCP. We have reduced MPTCP code
>> within TCP and anything that is left is under #ifdef MPTCP so that TCP
>> developers can enhance, build and test TCP without worrying about MPTCP. Not
>> only that, we have tried to limit any performance impact to pure TCP when
>> MPTCP is enabled.
> The point-of-view you take here is that introducing bugs in MPTCP is more
> acceptable. Unfortunately, that's not the case once the code is upstream.
> Because, the upstream maintainers are responsible that the code is stable
> and has no security holes.
No, that is not what I said, it is how you interpreted it. I said

"implementation is because *TCP maintainers may or may not test MPTCP*. 
So this is nothing out of the extraordinary."

Maybe maintainers should be "submitters".

If the submission rules require that all features should be tested, 
MPTCP will be tested and MPTCP will be just fine.
It is very common to see a change break a feature, such breakage is 
caught during review or testing and in some cases after the release. 
There is nothing special here. Following are some examples on how things 
get broken/caught/fixed.

https://www.spinics.net/lists/netdev/msg470389.html
https://www.spinics.net/lists/netdev/msg474372.html
https://www.spinics.net/lists/netdev/msg469607.html
https://marc.info/?l=linux-netdev&m=152453932929411&w=2
https://marc.info/?l=linux-netdev&m=152345771702029&w=2
> So, the MPTCP code should be designed in such a way that it does not require
> extensive MPTCP-testing for simple TCP-changes. That's what I mean with TCP
> maintainability is of high importance.
> #ifdefs don't protect against any such issues as distributions typically
> enable all kernel-configs.
Simple is subjective. If there is an MPTCP test suite, running it is the 
most easiest way to ensure MPTCP is not broken.
However a locking change is not simple with or without MPTCP and even a 
test suite may not expose the bug.

This is again coming down to the usual nit picking and that I know what 
the correct thing to do is.

I prefer upstream make the call, however that would require sharing the 
code and asking.

Shoaib

>
>
> Christoph
>
>
>> I really do not see any maintainability or stability issues for TCP. TCP
>> will work and behave as it does today without MPTCP.
>>
>> Rao.
>>
>>> Christoph
>>>
>>>> Shoaib.
>>>>
>>>> [1] If MPTCP is built on top of TCP, any change in TCP will always have to
>>>> worry about MPTCP particularly in the control path. There is a overhead of
>>>> adding MPTCP on TCP and no one can argue against it.
>>>>
>>>>> Christoph
>>>>>


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 7825 bytes --]

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

[Christoph Paasch]

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

On 26/04/18 - 17:43:44, Rao Shoaib wrote:
> 
> 
> On 04/26/2018 03:20 PM, Christoph Paasch wrote:
> > On 26/04/18 - 14:25:24, Rao Shoaib wrote:
> > > 
> > > On 04/26/2018 01:52 PM, Christoph Paasch wrote:
> > > > This kind of lock-taking also causes trouble with RCU LOCKDEP debugging - as
> > > > I mentioned in a previous e-mail.
> > > I have not looked into it so I can not comment. I am sure we will find a way
> > > to address it.
> > > > 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.
> > > The bug that you have pointed out is a run of the mill bug that we see
> > > everyday, there is nothing special about it.
> > Euh, you mean the issue #170 is happening frequently?
> > 
> > It shouldn't! If it does, that's a big concern.
> No we have not encountered the bug. What I meant to say was that when
> changes or enhancements are made to the code it is quite common that
> something breaks.

This is exactly what should be avoided. See my below comment on
maintainability.

> That is the case in the bug that you pointed.
> > 
> > > Taking meta lock actually simplifies things a lot and has reduced
> > > maintainable cost, not taking the meta lock will create timing issues left
> > > and right. So we are just trading one headache with another.
> > > 
> > > Holding meta lock should not be piped up unnecessarily. Yes, if possible if
> > > should be changed, plus our patch has only 6 cases in TCP.
> > I think, you are taking the MPTCP point-of-view here. Yes, taking the
> > meta-level lock does reduce maintainability of MPTCP (which is why we did it
> > that way in the first place ;-))
> > 
> > However, for upstreaming we have to think the other way around. TCP is the
> > common-case, and MPTCP is the exotic corner-case only few care about.
> > 
> > So, TCP-maintainability is of outmost importance. Way more important than
> > MPTCP's.
> I agree that TCP stability and maintainability is of extreme importantance.
> However, this code causes no instability or maintainability issues to TCP
> code. Consider the bug that you pointed out, MPTCP fails not TCP. We have to
> accept the fact that TCP changes will break  MPTCP no matter what the
> implementation is because TCP maintainers may or may not test MPTCP. So this
> is nothing out of the extraordinary.
> Our patch tries to maintain the stability of TCP. We have reduced MPTCP code
> within TCP and anything that is left is under #ifdef MPTCP so that TCP
> developers can enhance, build and test TCP without worrying about MPTCP. Not
> only that, we have tried to limit any performance impact to pure TCP when
> MPTCP is enabled.

The point-of-view you take here is that introducing bugs in MPTCP is more
acceptable. Unfortunately, that's not the case once the code is upstream.
Because, the upstream maintainers are responsible that the code is stable
and has no security holes.

So, the MPTCP code should be designed in such a way that it does not require
extensive MPTCP-testing for simple TCP-changes. That's what I mean with TCP
maintainability is of high importance.
#ifdefs don't protect against any such issues as distributions typically
enable all kernel-configs.


Christoph


> 
> I really do not see any maintainability or stability issues for TCP. TCP
> will work and behave as it does today without MPTCP.
> 
> Rao.
> 
> > 
> > Christoph
> > 
> > > Shoaib.
> > > 
> > > [1] If MPTCP is built on top of TCP, any change in TCP will always have to
> > > worry about MPTCP particularly in the control path. There is a overhead of
> > > adding MPTCP on TCP and no one can argue against it.
> > > 
> > > > 
> > > > Christoph
> > > > 
> 

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

[Rao Shoaib]

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



On 04/26/2018 03:20 PM, Christoph Paasch wrote:
> On 26/04/18 - 14:25:24, Rao Shoaib wrote:
>>
>> On 04/26/2018 01:52 PM, Christoph Paasch wrote:
>>> This kind of lock-taking also causes trouble with RCU LOCKDEP debugging - as
>>> I mentioned in a previous e-mail.
>> I have not looked into it so I can not comment. I am sure we will find a way
>> to address it.
>>> 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.
>> The bug that you have pointed out is a run of the mill bug that we see
>> everyday, there is nothing special about it.
> Euh, you mean the issue #170 is happening frequently?
>
> It shouldn't! If it does, that's a big concern.
No we have not encountered the bug. What I meant to say was that when 
changes or enhancements are made to the code it is quite common that 
something breaks. That is the case in the bug that you pointed.
>
>> Taking meta lock actually simplifies things a lot and has reduced
>> maintainable cost, not taking the meta lock will create timing issues left
>> and right. So we are just trading one headache with another.
>>
>> Holding meta lock should not be piped up unnecessarily. Yes, if possible if
>> should be changed, plus our patch has only 6 cases in TCP.
> I think, you are taking the MPTCP point-of-view here. Yes, taking the
> meta-level lock does reduce maintainability of MPTCP (which is why we did it
> that way in the first place ;-))
>
> However, for upstreaming we have to think the other way around. TCP is the
> common-case, and MPTCP is the exotic corner-case only few care about.
>
> So, TCP-maintainability is of outmost importance. Way more important than
> MPTCP's.
I agree that TCP stability and maintainability is of extreme 
importantance. However, this code causes no instability or 
maintainability issues to TCP code. Consider the bug that you pointed 
out, MPTCP fails not TCP. We have to accept the fact that TCP changes 
will break  MPTCP no matter what the implementation is because TCP 
maintainers may or may not test MPTCP. So this is nothing out of the 
extraordinary.
Our patch tries to maintain the stability of TCP. We have reduced MPTCP 
code within TCP and anything that is left is under #ifdef MPTCP so that 
TCP developers can enhance, build and test TCP without worrying about 
MPTCP. Not only that, we have tried to limit any performance impact to 
pure TCP when MPTCP is enabled.

I really do not see any maintainability or stability issues for TCP. TCP 
will work and behave as it does today without MPTCP.

Rao.

>
> Christoph
>
>> Shoaib.
>>
>> [1] If MPTCP is built on top of TCP, any change in TCP will always have to
>> worry about MPTCP particularly in the control path. There is a overhead of
>> adding MPTCP on TCP and no one can argue against it.
>>
>>>
>>> Christoph
>>>

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

[Christoph Paasch]

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

On 26/04/18 - 14:25:24, Rao Shoaib wrote:
> 
> 
> On 04/26/2018 01:52 PM, Christoph Paasch wrote:
> > 
> > This kind of lock-taking also causes trouble with RCU LOCKDEP debugging - as
> > I mentioned in a previous e-mail.
> I have not looked into it so I can not comment. I am sure we will find a way
> to address it.
> > 
> > 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.
> The bug that you have pointed out is a run of the mill bug that we see
> everyday, there is nothing special about it.

Euh, you mean the issue #170 is happening frequently?

It shouldn't! If it does, that's a big concern.

> Taking meta lock actually simplifies things a lot and has reduced
> maintainable cost, not taking the meta lock will create timing issues left
> and right. So we are just trading one headache with another.
> 
> Holding meta lock should not be piped up unnecessarily. Yes, if possible if
> should be changed, plus our patch has only 6 cases in TCP.

I think, you are taking the MPTCP point-of-view here. Yes, taking the
meta-level lock does reduce maintainability of MPTCP (which is why we did it
that way in the first place ;-))

However, for upstreaming we have to think the other way around. TCP is the
common-case, and MPTCP is the exotic corner-case only few care about.

So, TCP-maintainability is of outmost importance. Way more important than
MPTCP's.


Christoph

> 
> Shoaib.
> 
> [1] If MPTCP is built on top of TCP, any change in TCP will always have to
> worry about MPTCP particularly in the control path. There is a overhead of
> adding MPTCP on TCP and no one can argue against it.
> 
> > 
> > 
> > Christoph
> > 
> 

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

[Christoph Paasch]

[-- 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

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

[Rao Shoaib]

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



On 04/26/2018 10:27 AM, Matthieu Baerts wrote:
>
> 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)
Can someone point me to it.
>
>
>
> 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
What is a lot ? Our patch has 14 instances...

rshoaib(a)caduceus5:/home/mptcp/upstream/net/ipv4(upstream)$sed -n '{/if 
*(mptcp/p}' tcp_*.c
                 if (mptcp(tp))
                 if (mptcp(tp)) {
                 if (mptcp(tp))
         if (mptcp(tp))
                                 if (mptcp(tp))
         if (mptcp(tp))
                 if (mptcp(tp)) {
                         if (mptcp_init_tw_sock(sk, tcptw)) {
         if (mptcp(tcp_sk(child)))
         if (mptcp_is_data_fin(skb))
         if (mptcp_is_data_fin(skb))
                         if (mptcp(tcp_sk(sk)))
                 if (mptcp(tcp_sk(sk)))
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 "if 
(mptcp" *.c
tcp_ipv6.c:     if (mptcp(tp))
tcp_ipv6.c:                     if (mptcp(tp))

And all of this code is under #ifdef MPTCP --- Does MD5 have any such code ?
Here is a better comparison of intrusiveness.

rshoaib(a)caduceus5:/home/mptcp/upstream/net/ipv4(upstream)$grep MD5 
tcp_*.c | wc -l
73
rshoaib(a)caduceus5:/home/mptcp/upstream/net/ipv4(upstream)$grep MPTCP 
tcp_*.c | wc -l
39

Once again note, any MPTCP specific code is under #ifdef MPTCP. Our 
patch allows tcp to be built with MPTCP and does not require any mptcp 
file including header files.

>     - 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.

The trunk version is irrelevant as we are not going to keep up with what 
mptcp-dev does. Having said that, I believe any changes to MPTCP code 
should just work.

Even though I do not think sentiments towards our patch will change. I 
wanted to point out the facts as the comments were made without truly 
evaluating the changes.

Shoaib

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

[Rao Shoaib]

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



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

Shoaib.

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

[Matthieu Baerts]

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

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.

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

[Matthieu Baerts]

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

Hi Rao,

On Mon, Apr 23, 2018 at 10:13 PM, Rao Shoaib <rao.shoaib(a)oracle.com> wrote:

> For the next meeting on the 26th can you add discussion of Oracle's patch.
>

Just added in the "pad".

Matthieu
-- 
[image: Tessares SA] <http://www.tessares.net> 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
<https://www.google.com/maps?q=1+Avenue+Jean+Monnet,+1348+Ottignies-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.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3321 bytes --]

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

[Rao Shoaib]

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

Hi Matthieu,

For the next meeting on the 26th can you add discussion of Oracle's patch.

Thanks,

Shoaib


On 04/16/2018 10:18 AM, Matthieu Baerts wrote:
> 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/6ba7f217d3a69a88152a3fbee8b9dfc47c77bf4d
>     - 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

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

[Matthieu Baerts]

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

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/6ba7f217d3a69a88152a3fbee8b9dfc47c77bf4d
     - 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.