netdev - Re: [PATCH net-next 0/10] xfrm: remove flow cache

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: <CAKfDRXgL+KHsO78fpD12t1o_P3LZV_RAkOPdzW26f4DXH7PoMA@mail.gmail.com>
Date:   Tue, 12 Jun 2018 21:42:47 +0200
From:   Kristian Evensen <kristian.evensen@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     Florian Westphal <fw@...len.de>,
        Network Development <netdev@...r.kernel.org>,
        Steffen Klassert <steffen.klassert@...unet.com>,
        ilant@...lanox.com
Subject: Re: [PATCH net-next 0/10] xfrm: remove flow cache

Hello,

On Tue, Jul 18, 2017 at 8:15 PM, David Miller <davem@...emloft.net> wrote:
> Steffen, I know you have some level of trepidation about this because
> there is obviously some performance cost immediately for removing this
> DoS problem.

In a project I am involved in, we are running ipsec (Strongswan) on
different mt7621-based routers. Each router is configured as an
initiator and has around ~30 tunnels to different responders (running
on misc. devices). Before the flow cache was removed (kernel 4.9), we
got a combined throughput of around 70Mbit/s for all tunnels on one
router. However, we recently switched to kernel 4.14 (4.14.48), and
the total throughput is somewhere around 57Mbit/s (best-case). I.e., a
drop of around 20%. Reverting the flow cache removal restores, as
expected, performance levels to that of kernel 4.9.

Carrying around a fairly large revert patch is not something we want,
we are more interested in trying to fix at least some of the
performance problems. However, we are not very experienced when it
comes to profiling the kernel code or the xfrm-code itself. Are there
any known areas we should take a special look at, or should we just
read-up on different profiling tools and get started?

Also, the revert went very smooth, which always makes me a bit
nervous. Are there any parts of the flow cache removal that should or
would require a bit of special care when reverted?

Thanks in advance for any help.

BR,
Kristian