On Fri, May 03, 2019 at 06:13:22AM +0000, Vakul Garg wrote: > > > > -----Original Message----- > > From: Steffen Klassert <steffen.klass...@secunet.com> > > Sent: Friday, May 3, 2019 11:38 AM > > To: Florian Westphal <f...@strlen.de> > > Cc: Vakul Garg <vakul.g...@nxp.com>; netdev@vger.kernel.org > > Subject: Re: [RFC HACK] xfrm: make state refcounting percpu > > > > On Wed, Apr 24, 2019 at 12:40:23PM +0200, Florian Westphal wrote: > > > I'm not sure this is a good idea to begin with, refcount is right next > > > to state spinlock which is taken for both tx and rx ops, plus this > > > complicates debugging quite a bit. > > > > > > Hm, what would be the usecase where this could help? > > > > The only thing that comes to my mind is a TX state with wide selectors. In > > that case you might see traffic for this state on a lot of cpus. But in > > that case > > we have a lot of other problems too, state lock, replay window etc. It might > > make more sense to install a full state per cpu as this would solve all the > > other problems too (I've talked about that idea at the IPsec workshop). > > > > In fact RFC 7296 allows to insert multiple SAs with the same traffic > > selector, > > so it is possible to install one state per cpu. We did a PoC for this at > > the IETF > > meeting the week after the IPsec workshop. > > > > On 16-core arm64 processor, I am getting very high cpu usage (~ 40 %) in > refcount atomics. > E.g. in function dst_release() itself, I get 19% cpu usage in refcount api. > Will the PoC help here?
If your usecase is that what I described above, then yes. I guess the high cpu usage comes from cachline bounces because one SA is used from many cpus simultaneously. Is that the case? Also, is this a new problem or was it always like that?
