Not sure how much I can test here, but my tunnels are up. As well as my bgp sessions (this is "ART box” now) on top.
I use aes-128-gcm. This is vmware. //mxb > On 26 mars 2016, at 16:25, Mike Belopuhov <m...@belopuhov.com> wrote: > > 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.
