Feature #11438
open
Allow multiple cryptographic accelerator modules to be loaded at the same time
Added by Grzegorz Krzystek about 3 years ago.
Updated about 3 years ago.
Category:
Hardware / Drivers
Description
not every service is able utilise QAT.
so it seems to be reasonable to do not unload AES-NI and bsdcrypto while QAT enabled, so nonQATenabled services can still offload some crypto operation on AES-NI cpu.
otherwise we have performanc penalty. on openVPN
- Tracker changed from Bug to Feature
- Subject changed from do not unload/disable as-ni and bsd crypto with QAT enabled devices. to Allow multiple cryptographic accelerator modules to be loaded at the same time
- Category changed from Configuration Backend to Hardware / Drivers
- Priority changed from Normal to Low
- Affected Version deleted (
2.5.0)
We're still testing whether it's useful/possible to have multiple modules enabled, so making them mutually exclusive is safer. Have you testing using both at once and seeing if there is a measurable (in a repeatable way) difference?
Applications do not need to specifically support QAT if they support the open crypto framework, which OpenVPN and OpenSSL do.
Historically, OpenVPN/OpenSSL are faster with AES-NI unloaded since they will use AES-NI directly and not through the open crypto framework middleman, but we haven't specifically tested that in a while.
You can always manually override the GUI module choice by setting your own variables to load the modules in /boot/loader.conf.local, e.g.:
cryptodev_load="YES"
aesni_load="YES"
qat_load="YES"
Good point Jim,
probably i got mislead by openvpn configuration menu, showing me no available crypto acceleration on my 4860, after I enabled QAT.
I will test all crypto modules when other "no go" bugs in 21.02 will be fixed (probably soon)
Anyway i was thinking more about change in GUI and add possiblity to select particular modules to be loaded (instead of menu selection):
[] Load/use AES-NI
[] Load/use BSD Crypto
[] Load/use QAT
that way user will be able to select best combination, or even exclude "problematic" module, leaving those that are usable in particular env.
I'ts only suggestion.
Historically i raised similar bug for 2.4 to add AESNI+cryptodev option as supplement to aes-ni , bsdcrypto selection, as in my setup ovpn was not able to offload directly on aesni, and bsdcrypto wans't exposing aes without aesni module loaded...
That was reason of my concerns now. (good memory ;) )
That OpenVPN option probably needs to go away. Historically it has been pretty much a no-op. You can pick an engine there but OpenVPN and OpenSSL will still use whatever they feel is best for a given algorithm.
Before we can add any kind of multi-select option there we need a lot of performance testing to figure out what combinations make sense to expose in the GUI, which should be compulsory, prevented, etc. We have the lab setup to do it, just a matter of it making its way up the queue eventually.
Also available in: Atom
PDF
Updated by 
Updated by