[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1476439212.31114.37.camel@sipsolutions.net>
Date: Fri, 14 Oct 2016 12:00:12 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Andy Lutomirski <luto@...capital.net>,
Stephen Rothwell <sfr@...b.auug.org.au>,
"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Network Development <netdev@...r.kernel.org>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
Linux Wireless List <linux-wireless@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jouni Malinen <j@...fi>
Subject: Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
> So why is the performance hit acceptable for ESP but not for WPA? We
> could easily implement the same thing, i.e.,
> kmalloc(GFP_ATOMIC)/kfree the aead_req struct rather than allocate it
> on the stack
Yeah, maybe we should. It's likely a much bigger allocation, but I
don't actually know if that affects speed.
In most cases where you want high performance we never hit this anyway
since we'll have hardware crypto. I know for our (Intel's) devices we
normally never hit these code paths.
But on the other hand, you also did your changes for a reason, and the
only reason I can see of that is performance. So you'd be the one with
most "skin in the game", I guess?
johannes
Powered by blists - more mailing lists