netdev - Re: [PATCH v2] net: ip/tnl: Set iph->id only when don't fragment is not set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b7b60950-532a-0d0d-d6b7-85ebd6a47e33@gmail.com>
Date:   Tue, 26 Nov 2019 16:23:17 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Oliver Herms <oliver.peter.herms@...il.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        David Miller <davem@...emloft.net>
Cc:     yoshfuji@...ux-ipv6.org, kuznet@....inr.ac.ru,
        netdev@...r.kernel.org
Subject: Re: [PATCH v2] net: ip/tnl: Set iph->id only when don't fragment is
 not set



On 11/26/19 3:32 PM, Oliver Herms wrote:
> Hi everyone,
> 
> On 26.11.19 23:45, Eric Dumazet wrote:
>>
>>
>> On 11/26/19 11:10 AM, Oliver Herms wrote:
>>>
>>> What do you think about making this configurable via sysctl and make the current
>>> behavior the default? I would also like to make this configurable for other 
>>> payload types like TCP and UDP. IMHO there the ID is unnecessary, too, when DF is set.
>>>
>>
>> Certainly not.
>>
>> I advise you to look at GRO layer (at various stages, depending on linux version)
>>
>> You can not 'optimize [1]' the sender and break receivers ( including old ones )
>>
>> [1] Look at ip_select_ident_segs() : the per-socket id generator makes
>> ID generation quite low cost, there is no real issue here.
>>
> 
> ip_select_ident_segs() is not the issue. The issue is with __ip_select_ident
> that calls ip_idents_reserve. That consumes significant amount of CPU time here
> while not adding any value (for my use case of company internal IPIP tunneling 
> in a well defined environment to be fair).
> 
> Here is a flame graph: https://tinyurl.com/s9qv9fx
> I'm curious for ideas on how to make this more efficient.
> Using a simple incrementation here, as with sockets, would solve my problem well enough.
> 
> Thoughts?
> 

Oliver, TCP flows do not call  __ip_select_ident()

Pleas do not touch TCP payload.

Thank you.