netdev - RE: [RFC HACK] xfrm: make state refcounting percpu

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <VE1PR04MB6670F77D42F9DA342F8E58238B350@VE1PR04MB6670.eurprd04.prod.outlook.com>
Date:   Fri, 3 May 2019 06:13:22 +0000
From:   Vakul Garg <vakul.garg@....com>
To:     Steffen Klassert <steffen.klassert@...unet.com>,
        Florian Westphal <fw@...len.de>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [RFC HACK] xfrm: make state refcounting percpu



> -----Original Message-----
> From: Steffen Klassert <steffen.klassert@...unet.com>
> Sent: Friday, May 3, 2019 11:38 AM
> To: Florian Westphal <fw@...len.de>
> Cc: Vakul Garg <vakul.garg@....com>; netdev@...r.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?

> One problem that is not solved completely is that, from userland point of
> view, a SA consists of two states (RX/TX) and this has to be symetic i.e.
> both ends must have the same number of states.
> So if both ends have a different number of cpus, it is not clear how many
> states we should install.
> 
> We are currently discuss to extend the IKEv2 standard so that we can
> negotiate the 'optimal' number of (per cpu) SAs for a connection.