Yes, AF_ALG should work with Turris OS.
You may have to load af_alg, algif_hash and algif_skcipher manually.
To get the engine in OpenSSL you will have to compile the engine or OpenSSL yourself.
https://github.com/RidgeRun/af-alg-rr and https://github.com/sarnold/af_alg are among others possible sources. There may be some differences between different implementations.
I am not aware of any prepackaged build of any of these as most people prefer one of the conflicting cryptodev implementations.
In the end you could even use cryptodev in the container. There may be packages around for this.
I do not use any of the acceleration for anything in userspace because software is faster for the interesting packet sizes and the latency is lower. You may save at most 30% cpu time with big packets when using cesa. With small packages the cpu overhead for cesa may go well over 1000%.
Calculation assuming aes-128-cbc and rounded:
OpenSSL with CESA via AF_ALG:
730kbyte/s / 16byte = 45625/s
3000kbyte/s / 64byte = 46875/s
There can be at most about 45000 encryptions per second using AF_ALG and about 75% CPU usage.
OpenSSL without AF_ALG:
48Mbyte/s / 16byte = 3000000/s
55MByte/s / 64byte = 859375/s
We can get 859375 64byte packets per second encrypted using OpenSSL only. Restricting OpenSSL to 75% CPU usage gives the following:
859375/s / 100% * 75% = 644531.25/s
To get the same amount of data encoded as with AF_ALG you would need:
46875/s / 644531.25/s * 100% = 7.27% of the CPU time compared to hardware accelerated.
I took 64bytes as reference because there are quite some small packets like ICMP packets and TCP SYN/ACK that are around 64 bytes in size.