Hello Rao, On Tue, Mar 20, 2018 at 9:10 PM, Rao Shoaib <rao.shoaib(a)oracle.com&gt; wrote: That's a good idea! Note that recently, David Miller said he will not go there for unclear reasons. We don't know if it is his final answer. https://lists.01.org/pipermail/mptcp/2018-March/000379.html But most of the main NetDev contributors will be there! To be honest, I was also thinking about submitting a proposal for either a talk or a workshop. I also think it would be very interesting to join forces. It is maybe in my genes to propose that because the motto of my country is "Unity makes Strength" but I really think that it could help to have one single presentation about that. Note that in my country, we usually use this motto when we need to drink all available beers but that's something else :) I don't think I am wrong to say that we all want to upstream MPTCP without having to rework all the current implementation. Like you, our main concern is to adapt both TCP and MPTCP stacks to fit with NetDev maintainer's expectations. These expectations are not always clear and we agree that NetDevConf is a very good place to discuss about that. or more different ideas to make progress on this project of upstreaming MPTCP. But presenting them together will certainly indicate that we have different ideas to achieve our unique goal. What do you think about that? By chance, do you think you could join our weekly web conf tomorrow? https://lists.01.org/pipermail/mptcp/2018-March/000383.html It would be very nice to discuss about this topic and others with you! It is also possible to change the day and the time of these meetings! Best regards, 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-Louvai... -- ------------------------------ 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.

Hi Lorenzo, On Wed, Mar 21, 2018 at 5:14 PM, Lorenzo Colitti <lorenzo(a)google.com&gt; wrote: Thank you for the idea! Indeed, that seems to be the place to go if people want to meet David Miller. But it will be in November. https://www.linuxplumbersconf.org/2017/linux-plumbers-conference-2018-sit... At NetDevConf, most of the main netdev contributors will be there I guess. If the goal is to have "live" feedback and advices before November, it should still be interesting to go to NetDevConf in July. Cheers, 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-Louvai... -- ------------------------------ 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.

Hi Rao, Thank you for your answer! On Wed, Mar 21, 2018 at 9:59 PM, Rao Shoaib <rao.shoaib(a)oracle.com&gt; wrote: Sorry I was not clear, indeed we are co-operating in term of sharing code and info. I also understand why Christoph and Mat were not more supportive regarding your patch-set after their previous submission (TCP options framework). names if it is needed. I am very glad to see that you first asked some questions and you got answers from NetDev maintainer! I understand these guys would prefer to see code to comment it. But I don't know how to produce a very small version of MPTCP implementation. If it is not small, it seems it is very hard to get very interesting comments about implementation details. So indeed, it seems we have to produce code just to get comments. So what you are doing seems totally good :-) But I guess the message that was shared on this ML is that we need to be careful not to irritate NetDev community. We need to broach the subject of indirect function calls cautiously. I understand that after the previous reject regarding the TCP options framework, it was difficult to see a bunch of new callbacks in TCP. So that was good to see your question regarding this topic on NetDev ML before sending patches! Is okay for you to summarise these answers by saying that: NetDev community doesn't want a lot of new indirect function calls but they don't have alternatives (yet) and we need them to have a clean MPTCP implementation. The good thing is that they are certainly looking at alternatives as well and when a good one will be found, we can switch to this new solution. So they will not reject patches just because there are new abstractions, right? That's good to have someone who asks! And we need more info! I am very happy too! Feel free to come to our weekly meetings today to discuss about these technical topics :) Cheers, 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-Louvai... -- ------------------------------ 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.

Hi Rao, On Thu, Mar 22, 2018 at 7:02 PM, Rao Shoaib <rao.shoaib(a)oracle.com&gt; wrote: Here is what I know: before your submission, I tried to understand why the TCP options framework was rejected and at that time, I though it was because: * it seems we should not simplify the way devs can add TCP options to have them really think about the best way to do so. (yes, a bit surprising, not really supportive as you can see ; after that you really don't know what we can propose) * it seems we should reduce function pointers usage to only when it is really needed. Knowing that, I understand why at this time, some people here may have been confused about what to do because I was also maybe like them: surprised by the first point of this feedback and a bit annoyed by the second one :-/ The situation is no longer the same, patches can be now read with different preconceptions in mind. Also note that from what I have read, I understood there would be a new version of these RFC patches. I maybe misunderstood but maybe other people are also waiting for a new version before looking at the patches in details with the new info we recently got. May you clarify if a new version will be shared? OK, sorry, English is not my first language. From these discussions, I thought it was only discouraged to directly send big patches without asking these questions you asked first. But anyway, that's the past and we got clearer info from DaveM now. This sentence was linked to the next one. If we want to introduce new indirect functions calls, we certainly need to clearly document them and prepare questions from maintainers. That's a sensible subject, especially for the moment. We could think that by default, they will say no but it will depend of the context/justification. Without the questions you asked and without specific comments about that in the commit message and/or the code, I could understand why people would not look at them in details and only focus on these indirect functions calls. It will certainly help if they are documented and if there are some dedicated lines in the cover letter to prevent limiting the review to them. Yes I agree with you. Last month, at the time of your submission and after the feedback related to the TCP options framework, there were many questions about them. Now it is clearer: these indirect function calls are not forbidden but they need to be well justified. Indeed, sorry for the mistake, I didn't want to talk about NetDev community specifically here. The current issue boils down to the fact that we were not treated as an Again it is maybe because my English is not perfect but from what I understood, the patches were not rejected. Some comments have been posted and I thought a second version would come. If not, please simply mention that there is no expected new version for the moment. Also I think what could help is a diff between what you propose and what we can find in the current MPTCP implementation (regarding the TCP stack of course, not MPTCP itself which is not included in your patches). I think that would help us (or just me?) to know what to look at in more details as many here already know the current MPTCP implementation (I mean this one: https://github.com/multipath-tcp/mptcp) and the code you modify is quite big. But I can be wrong, maybe only useful for me. I just added this topic in the public notes. Feel free to add any other ones. That would indeed be very good to discuss them at these meetings. I think and hope face to face meetings help clarifying stuffs. Thanks to these emails, I can see I didn't understand some topics like you did, my bad. Certainly because there are here people from different areas, not with the same languages and expressions. But knowing that, that should be easy to fix, no? :) Cheers, 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-Louvai... -- ------------------------------ 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.