Summary: The documentation is still somewhat vague on the best use of the "HardwareAccel" option.
*HardwareAccel* *0*|*1*
If non-zero, try to use built-in (static) crypto hardware acceleration when available. (Default: 0)
I could not find a definitive answer in the archives or in https://gitweb.torproject.org/tor.git/log/?qt=grep&q=hardwareaccel&s... .
https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration claims no intervention is needed in regards of aes-ni accelaration, but I would like to add an explanation or source to this recommendation.
Question_1: If my CPU supports and have loaded aesni_intel on linux with OpenSSL is 1.0.1.j-1, should I leave HardwareAccel off or explicitly enable it?
Question_2: What does "*built-in (static) crypto hardware acceleration*" refer to? Dedicated hardware, CPU-support or...?
Best regards
On 1/3/15, usprey usprey@gmail.com wrote:
Summary: The documentation is still somewhat vague on the best use of the "HardwareAccel" option.
you could submit a patch ;)
*HardwareAccel* *0*|*1*
If non-zero, try to use built-in (static) crypto hardware acceleration when available. (Default: 0)
in OpenSSL land, there are two types of crypto offload / hw engines: built-in (static), and dynamically loaded (dynamic).
the "HardwareAccel 1" option says to enable the built-in / static engines. you may have a patched OpenSSL that will automatically try dynamic engines without explicitly attempting to load them by name (as libengine.so dlopen'ed implementations).
https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration claims no intervention is needed in regards of aes-ni accelaration, but I would like to add an explanation or source to this recommendation.
in some versions of OpenSSL, you will need to enable HardwareAccel (but not use a dynamic engine - aesni is built-in / static).
you will need to consult the distribution of OpenSSL you are using to be sure - it varies by version and pkg maintainers.
Question_1: If my CPU supports and have loaded aesni_intel on linux with OpenSSL is 1.0.1.j-1, should I leave HardwareAccel off or explicitly enable it?
leave HardwareAccel 1, but do not bother with a dynamic named engine opt.
On 3 January 2015 at 13:34, coderman coderman@gmail.com wrote:
On 1/3/15, usprey usprey@gmail.com wrote:
Summary: The documentation is still somewhat vague on the best use of the "HardwareAccel" option.
you could submit a patch ;)
I will be glad to, but will have to know what to write first. =)
*HardwareAccel* *0*|*1*
If non-zero, try to use built-in (static) crypto hardware acceleration when available. (Default: 0)
in OpenSSL land, there are two types of crypto offload / hw engines: built-in (static), and dynamically loaded (dynamic).
the "HardwareAccel 1" option says to enable the built-in / static engines. you may have a patched OpenSSL that will automatically try dynamic engines without explicitly attempting to load them by name (as libengine.so dlopen'ed implementations).
https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration claims no intervention is needed in regards of aes-ni accelaration, but I would like to add an explanation or source to this recommendation.
in some versions of OpenSSL, you will need to enable HardwareAccel (but not use a dynamic engine - aesni is built-in / static).
you will need to consult the distribution of OpenSSL you are using to be sure - it varies by version and pkg maintainers.
ty, will research further.
Question_1: If my CPU supports and have loaded aesni_intel on linux with OpenSSL is 1.0.1.j-1, should I leave HardwareAccel off or explicitly enable it?
leave HardwareAccel 1, but do not bother with a dynamic named engine opt.
k, ty very much sir! =)
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
coderman -
usprey