> -----Original Message-----
> From: David Miller <da...@davemloft.net>
> Sent: Tuesday, April 23, 2019 10:57 PM
> To: f...@strlen.de
> Cc: Vakul Garg <vakul.g...@nxp.com>; netdev@vger.kernel.org
> Subject: Re: ipsec tunnel performance degrade
>
> From: Florian Westphal <f...@strlen.de>
> Date: Tue, 23 Apr 2019 18:25:21 +0200
>
> > Vakul Garg <vakul.g...@nxp.com> wrote:
> >> > Vakul Garg <vakul.g...@nxp.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.
