netdev - RE: ipsec tunnel performance degrade

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: <DB8PR04MB66668B201A76F0C8CA5F1E918B3C0@DB8PR04MB6666.eurprd04.prod.outlook.com>
Date:   Wed, 24 Apr 2019 07:32:06 +0000
From:   Vakul Garg <vakul.garg@....com>
To:     David Miller <davem@...emloft.net>, "fw@...len.de" <fw@...len.de>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: ipsec tunnel performance degrade



> -----Original Message-----
> From: David Miller <davem@...emloft.net>
> Sent: Tuesday, April 23, 2019 10:57 PM
> To: fw@...len.de
> Cc: Vakul Garg <vakul.garg@....com>; netdev@...r.kernel.org
> Subject: Re: ipsec tunnel performance degrade
> 
> From: Florian Westphal <fw@...len.de>
> Date: Tue, 23 Apr 2019 18:25:21 +0200
> 
> > Vakul Garg <vakul.garg@....com> wrote:
> >> > Vakul Garg <vakul.garg@....com> wrote:
> >> > > > Do you use xfrm interfaces?
> >> > >
> >> > > I don't think so. I use setkey to create policies/SAs.
> >> > > Can you please give me some hint about it?
> >> >
> >> > Then you're not using ipsec interfaces.
> >> >
> >> Instead of creating policies/SA using setkey, I shifted to using 'ip xfrm'
> commands.
> >> With this, I get good performance improvement (20% better in one case).
> >> Now xfrm_state_find() function is not taking much cpu.
> >
> > Thats very strange, I have no explanation for this.
> > It would be good to find the cause, PF_KEY and 'ip xfrm'
> > are just different control plane frontends, they should have no impact
> > on data path performance.
> 
> I wonder if the masks and/or prefixes that end up being used are subtly
> different for some reason.

Thanks for the hint.
I figured out the reason why it made a difference. 

Basically with 'ip xfrm' commands, we passed 'reqid' parameter to
create linking between policies and states. With 'setkey' we didn't do same.
Adding '/unique:[n]' keywords in policy creation yielded same performance with both
setkey and 'ip xfrm' based interfaces.