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]

Date:   Wed, 27 Nov 2019 00:32:56 +0100
From:   Oliver Herms <oliver.peter.herms@...il.com>
To:     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

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?

Thanks
Oliver