LGTM

I don't yet think ossl(4) is perhaps worth it. Just doing faster SHA is kind of a narrow case (you have to go out of your way to ask for it for GELI for example). If we expand ossl(4) to support AES algorithms and it is competitive (or outperforms) aesni(4) and/or armv8crypto(4), then I think we can revisit what to do about ossl(4).

Well, there are some gross ways. /dev/crypto consumers can request a specific driver by crid as can individual kernel consumers though I don't think any other in-kernel consumers provide a way to allow users to control the crid used to create sessions. Since opencrypto_if.m requires device_t objects, all drivers have device instances that can be detached or disabled via devctl(8). That's a bit of a weird way to do it, but 'devctl disable aesni0' would probably be the closest thing we have. On the other hand, that would only work if the device was idle (no active sessions). We don't have a way to forcefully remove a device and have sessions gracefully fail over to another driver. There's some notion of session failover in OCF, but only IPsec honors it, and it's kind of gross. What I'd rather do is make "user-facing" sessions a kind of mux where you can give a policy at session creation time of "exactly this crid, or use these class of drivers", perhaps via the existing crid option when creating a session and then allow a crypto "consumer session" to bind to 1 or more "driver sessions", and even allow a driver session to be detached, so e.g. "devctl detach -f aesni0" would work, or also things like a crypto accelerate going away due to a forceful detach (e.g. hotplug detach). You might also imagine performance-guided policies where small buffers use accelerated software and larger buffers use a co-processor that such an abstraction might permit. That would be a good pile of work to achieve though I think.

In D28100#628210, @jhb wrote:

Well, there are some gross ways. /dev/crypto consumers can request a specific driver by crid as can individual kernel consumers though I don't think any other in-kernel consumers provide a way to allow users to control the crid used to create sessions. Since opencrypto_if.m requires device_t objects, all drivers have device instances that can be detached or disabled via devctl(8). That's a bit of a weird way to do it, but 'devctl disable aesni0' would probably be the closest thing we have. On the other hand, that would only work if the device was idle (no active sessions). We don't have a way to forcefully remove a device and have sessions gracefully fail over to another driver. There's some notion of session failover in OCF, but only IPsec honors it, and it's kind of gross. What I'd rather do is make "user-facing" sessions a kind of mux where you can give a policy at session creation time of "exactly this crid, or use these class of drivers", perhaps via the existing crid option when creating a session and then allow a crypto "consumer session" to bind to 1 or more "driver sessions", and even allow a driver session to be detached, so e.g. "devctl detach -f aesni0" would work, or also things like a crypto accelerate going away due to a forceful detach (e.g. hotplug detach). You might also imagine performance-guided policies where small buffers use accelerated software and larger buffers use a co-processor that such an abstraction might permit. That would be a good pile of work to achieve though I think.

I didn't realize that one can use devctl with crypto devices. I think that's probably sufficient for the case that I'm worried about, where one has an embedded device and wants to disable some crypto driver to work around a problem.