Assistance Requested: Integrating QAT with StrongSwan on Linux Kernel

[lucasvp]

Hello, Community,

I am currently working on integrating QAT (Quality and Acceleration Technology) with StrongSwan on the Linux kernel and have encountered a challenge that I hope you can help me overcome. We have successfully loaded the necessary modules for QAT operation, but we are facing an issue where, despite what seems to be a correct configuration, QAT is not being utilized when generating traffic through StrongSwan.

Here are the details of our current setup:

Loaded QAT Modules:

qat_api 565248 0
qat_c3xxx 20480 0
intel_qat 270336 3 qat_api,usdm_drv,qat_c3xxx
We confirmed that the modules are correctly loaded by using the lsmod | grep qat command, which returns the list of modules above.

Issue:
Despite the modules being loaded, when we generate traffic expecting QAT to be utilized, we observe that the counters located in /sys/kernel/debug/qat_c3xxx_0000:01:00.0/fw_counters do not increment, indicating that QAT is not effectively being used.

Steps Already Taken:

Verification of the correct loading of QAT modules.
Review of StrongSwan configuration to ensure it is set up to use hardware acceleration.
Checking system and QAT logs for potential errors, to no avail.
I am seeking guidance, insights, or shared experiences that might help me identify and solve this issue. Any advice on how to ensure that QAT is correctly utilized with StrongSwan would be immensely appreciated.

Thank you in advance for any support you can offer!

Sincerely,
Lucas Pereira

[tobiasbrunner]

I've no experience with QAT, so I can't really help you but...

Review of StrongSwan configuration to ensure it is set up to use hardware acceleration.

Which might not have anything to do with QAT. Hardware acceleration that is configurable in strongSwan requires support by the Linux kernel, the drivers and the hardware (network interfaces) as it uses the Linux kernel's recent hardware offload facilities. QAT might only accelerate specific algorithms (e.g. AES-GCM), which works completely independent of the offloading feature and only depends on the kernel's configuration (i.e. which modules it prefers over others for specific crypto algorithms).

[lucasvp]

Thank you for fast response Mr. Tobias.

Best regards.

[orottler]

See the same , that the QAT's are not used from kernel-netlink . Agree with Tobias, that the kernel is expected to handle all completely independent.
But the amount of implemented QAT drivers is limited , so I think a match is required between
-configured proposal,
-mapping kernel_algorithm_t encryption_algs and
-name in /proc/crypto

Having an esp_proposals = aes256-sha256-modp4096
kernel_netlink_ipsec.c kernel_algorithm_t encryption_algs maps {ENCR_AES_CBC, "aes" },
we have in /proc/crypto with the default driver and type cipher/ there is only one QAT driver with an other name and type skcipher:

name : cbc(aes)
driver : qat_aes_cbc
module : intel_qat
priority : 4001
refcnt : 1
selftest : passed
internal : no
type : skcipher
async : yes
blocksize : 16

skcipher for symmetric key ciphers
cipher for single block ciphers that may be used with an additional template

[orottler]

additional there a new methods like name : authenc(hmac(sha256),cbc(aes)) type aed, so it seems we need an extension in the code.
Attached my /proc/crypto

crypto.txt