> -----Original Message-----
> From: David Miller <[email protected]>
> Sent: Tuesday, April 23, 2019 10:57 PM
> To: [email protected]
> Cc: Vakul Garg <[email protected]>; [email protected]
> Subject: Re: ipsec tunnel performance degrade
>
> From: Florian Westphal <[email protected]>
> Date: Tue, 23 Apr 2019 18:25:21 +0200
>
> > Vakul Garg <[email protected]> wrote:
> >> > Vakul Garg <[email protected]> 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.
