Re: [MPTCP] TCP options framework and MD5 patch set

Re: [MPTCP] TCP options framework and MD5 patch set

[Christoph Paasch]

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

Hello,

On 25/01/18 - 14:46:00, Mat Martineau wrote:
> On Thu, 25 Jan 2018, Christoph Paasch wrote:
> > On 25/01/18 - 11:41:53, Mat Martineau wrote:
> > > Thanks again for posting the RFC patch set to netdev in December. In case
> > > folks on this mailing list missed it, here's the link:
> > > 
> > > https://www.spinics.net/lists/netdev/msg472988.html
> > > 
> > > Other than the license information change, are you considering any other
> > > modifications?
> > 
> > no, not really. I was planning to get some performance numbers. But couldn't
> > get to it because of other unrelated urgencies that took my time.
> > 
> > > I suggest modifying the last section of the cover letter (the part starting
> > > with "One point of discussion...") for the next round:
> > > 
> > > """
> > > There is still work to be done to more efficiently check for extra TCP
> > > options in performance-sensitive code paths. A rate-limited static key would
> > > nearly eliminate overhead if no extra TCP options are in use system-wide, or
> > > a flag in a likely-hot cache line could work well.
> > > 
> > > For now we opted for a simple if (unlikely(!hlist_empty(...)) check.
> > > """
> > 
> > That sounds good!
> > 
> > 
> > What do you suggest - should we simply resubmit the RFCs as v2 with the
> > minor changes? (the timing of the first submission was probably fairly bad
> > as most people were out on Christmas vacation)
> > 
> 
> Yes, v2 with the minor changes is the way to go. The timing should be better
> - Eric has been reviewing patches and recent RFCs in the archives seem to
> have a few replies.

Indeed! I wanted to get to this here right after the vacation, but things
have been crazy here in the office.

> I looked around the git history to see if anyone would obviously be
> interested from a TCP md5sig perspective. The only recent contributor I
> found (besides Eric) was Ivan Delalande, see commit c03fa9bcac. Maybe he
> would be good for the cc list.

Good point, I will add him to the CC-list.


Christoph

Re: [MPTCP] TCP options framework and MD5 patch set

[Mat Martineau]

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


On Thu, 25 Jan 2018, Christoph Paasch wrote:

> Hello Mat,
>
> On 25/01/18 - 11:41:53, Mat Martineau wrote:
>>
>> Hi Christoph -
>>
>> Thanks again for posting the RFC patch set to netdev in December. In case
>> folks on this mailing list missed it, here's the link:
>>
>> https://www.spinics.net/lists/netdev/msg472988.html
>>
>> Other than the license information change, are you considering any other
>> modifications?
>
> no, not really. I was planning to get some performance numbers. But couldn't
> get to it because of other unrelated urgencies that took my time.
>
>> I suggest modifying the last section of the cover letter (the part starting
>> with "One point of discussion...") for the next round:
>>
>> """
>> There is still work to be done to more efficiently check for extra TCP
>> options in performance-sensitive code paths. A rate-limited static key would
>> nearly eliminate overhead if no extra TCP options are in use system-wide, or
>> a flag in a likely-hot cache line could work well.
>>
>> For now we opted for a simple if (unlikely(!hlist_empty(...)) check.
>> """
>
> That sounds good!
>
>
> What do you suggest - should we simply resubmit the RFCs as v2 with the
> minor changes? (the timing of the first submission was probably fairly bad
> as most people were out on Christmas vacation)
>

Yes, v2 with the minor changes is the way to go. The timing should be 
better - Eric has been reviewing patches and recent RFCs in the archives 
seem to have a few replies.

I looked around the git history to see if anyone would obviously be 
interested from a TCP md5sig perspective. The only recent contributor I 
found (besides Eric) was Ivan Delalande, see commit c03fa9bcac. Maybe he 
would be good for the cc list.

--
Mat Martineau
Intel OTC

Re: [MPTCP] TCP options framework and MD5 patch set

[Christoph Paasch]

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

Hello Mat,

On 25/01/18 - 11:41:53, Mat Martineau wrote:
> 
> Hi Christoph -
> 
> Thanks again for posting the RFC patch set to netdev in December. In case
> folks on this mailing list missed it, here's the link:
> 
> https://www.spinics.net/lists/netdev/msg472988.html
> 
> Other than the license information change, are you considering any other
> modifications?

no, not really. I was planning to get some performance numbers. But couldn't
get to it because of other unrelated urgencies that took my time.

> I suggest modifying the last section of the cover letter (the part starting
> with "One point of discussion...") for the next round:
> 
> """
> There is still work to be done to more efficiently check for extra TCP
> options in performance-sensitive code paths. A rate-limited static key would
> nearly eliminate overhead if no extra TCP options are in use system-wide, or
> a flag in a likely-hot cache line could work well.
> 
> For now we opted for a simple if (unlikely(!hlist_empty(...)) check.
> """

That sounds good!


What do you suggest - should we simply resubmit the RFCs as v2 with the
minor changes? (the timing of the first submission was probably fairly bad
as most people were out on Christmas vacation)


Christoph

[MPTCP] TCP options framework and MD5 patch set

[Mat Martineau]

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


Hi Christoph -

Thanks again for posting the RFC patch set to netdev in December. In case 
folks on this mailing list missed it, here's the link:

https://www.spinics.net/lists/netdev/msg472988.html

Other than the license information change, are you considering any other 
modifications?

I suggest modifying the last section of the cover letter (the part 
starting with "One point of discussion...") for the next round:

"""
There is still work to be done to more efficiently check for extra TCP 
options in performance-sensitive code paths. A rate-limited static key 
would nearly eliminate overhead if no extra TCP options are in use 
system-wide, or a flag in a likely-hot cache line could work well.

For now we opted for a simple if (unlikely(!hlist_empty(...)) check.
"""

Regards,

--
Mat Martineau
Intel OTC