On Fri, Mar 25, 2016 at 22:43 +0100, Mark Kettenis wrote:
> > 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. 

I thought that it's not possible, but it looks like at least tdb_free
can be called anywhere and it will trigger freesession, which is a tad
unfortunate IMO, yet understandable.

> They would call
> SRPL_INSERT_HEAD_LOCKED() and SRPL_REMOVE_LOCKED(), which can only be
> called from process context.
>

Not process context though, but under a lock, which wouldn't save
us the mtx_enter anyway.

> > 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.

Well, it's not called from all subsystems, just those that use
IPL_BIO and IPL_NET for interrupts and IPL_HIGH just includes
AUDIO and CLOCK which don't call any crypto(9) code.  So what
are you trying to protect it from or is it just a placeholder
value?  I'm fine if it is, just curious.

Reply via email to