> From: Mike Belopuhov <m...@belopuhov.com> > Date: Thu, 24 Mar 2016 21:33:25 +0100 > > On 24 March 2016 at 20:53, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > Diff below makes aesni crypto "mpsafe". It adds a CRYPTOCAP_F_MPSAFE > > flag that makes the crypto framework dispatch to an mpsafe taskq if it > > is set. In order to make the aesni_process() function that does the > > actual crypto work mpsafe, it moves the code over to a per-session > > working buffer. This obviously increases the cost of setting up a > > session a bit. Directly invoked crypto operations remain locked. My > > main laptop seem to do ipsec fine with this, but I'm not sure if there > > is an actual performance gain. So it would probably be good if > > somebody could benchmark this. > > > > Comments? > > It should be fairly simple to use SRP for the session list so that you > don't have to take the mutex in the aesni_process. Other than that I > think this should go in once tests are made and people a happy with > the results.
Actually, I'm not sure that's possible. I think aesni_newsession() and aesni_freesession() can be called from interrupt context, or at least are not supposed to sleep. They would call SRPL_INSERT_HEAD_LOCKED() and SRPL_REMOVE_LOCKED(), which can only be called from process context. > Another question I have is why are you using an IPL_HIGH mutex? The crypto code may be called from any subsystem, so that is the only safe choice.
