QAT with openssl patch

[idata]

Hi Everyone,

I got a problem with QAT.

First of all, I can install QAT software successfully.

Then I installed the patch of openssl, the QAT status will be down.

I got the error messages like this:

The relevant environment is:

OS: fedora 17 x64

kernel: 3.3.4

CPU: ATOM C2358、C2518

QAT ver: QAT1.5.L.1.3.0_92

openssl ver: openssl-1.0.1c

openssl patch: libcrypto-openssl-1.0.1c-async.L.0.4.4-008

libcrypto-openssl-1.0.1c-qat.L.0.4.4-008

And I also tried the newest version of QAT (1.8.0) and openssl patch (0.4.7-010), but I got same error messages.

Please HELP.

Thanks a lot !

Best Regards,

[idata]

Hello Leo Yeh,

Welcome to the Intel® Embedded Community.

We are working on getting an answer to your question. Have a great day and we'll be talking with you soon!

Regards,

Leon

[idata]

Hello Leo Yeh,

I saw this on the release notes of the openssl patch 0.4.7-010.

This release was validated on the following:

* Operating system: Fedora 16 64-bit version

* Kernel: GNU/Linux 3.1

More information about software requirements can be found in Chapter 1.4 of the Application Note.

https://www-ssl.intel.com/content/www/us/en/embedded/technology/quickassist/libcrypto-open-ssl-qat-sample-patch-stable-release-0-4-7-010.html?wapkw=libcrypto*+%28openssl*%29+sample+patch+for+intel%c2%ae+quickassist+technology libcrypto* Sample Patch for Intel® QuickAssist Technology

Regards,

Leon

[idata]

Hi Leon,

Thanks first.

Actually I tried this environment (fedora 17 x64 with 3.3.4 kernel) on the platform (C2758) before, and it works !

So I just moved the HDD to the platform (C2518), and it doesn't work...

So I don't get it...

Maybe it is a hardware issue or BIOS ?

Best regards,

Leo

[idata]

Hello Leo Yeh,

Awesome!

It's great to hear that you managed to have it working on this environment (Fedora 17 x64, Kernel 3.3.4).

I would think that the issue would be more on the hardware rather that the BIOS let's say if they have the same BIOS.

The fact is both chips are still different even though both of them fall in the same family.

Regards,

Leon

[idata]

Hi Leon,

Yeah I know.

According to the Intel website, the chip C2518 should support QAT , is that right ?

In fact, my point is why it doesn't work once we install the openssl patch...

Best regards,

Leo

[idata]

Hi Leo Yeh,

Yes, C2518 support QAT and according to the application notes in https://www-ssl.intel.com/content/www/us/en/embedded/technology/quickassist/libcrypto-open-ssl-qat-sample-patch-stable-release-0-4-7-010.html?wapkw=libcrypto*+%28openssl*%29+sample+patch+for+intel%c2%ae+quickassist+technology libcrypto* Sample Patch for Intel® QuickAssist Technology

Successful operation of this release requires a software tool chain that supports OpenSSL 1.0.1async, for example, Fedora 16. This release was

validated on the following:

* Operating system: Fedora 16 64-bit version

* Kernel: GNU/Linux 3.1

* OpenSSL 1.0.1 asynch branch (based on OpenSSL 1.0.1j)

* Intel® Communications Chipset 89xx Series Software for Linux*: QATmux version 1.1 / QAT1.5 version 1.5 / QAT1.6 version 2.0

* Intel® Atom™ Processor C2000 Product Family for Communications Infrastructure Software for Linux* version 1.1

Have tried running it under this environment?

Regards,

Leon

[idata]

Hi Leon,

I remember that I have tried you said.

However, I will double check and retry this environment.

If I get something, I will update the situation at here.

Thanks a lot !

Best regards,

Leo

[FSkal1]

Hi,

two weeks ago, i applied for privileged access for our company.

In the meantime i read the openssl patch and have some questions. (Hope this will be answered when having privileged access)

I have setup the exact environment, which should be support for the openssl patch, but ...

I read the README, which tells me to disable async_prf and enable

openssl speed works

Linking a third party works, but:

whenever a cipher will be initialized, the program will hang and the libcrypto call will fail, with active qat engine.

A thread problem then will be reported and the program terminates. (EINVAL (22) on pthread_mutex_lock)

There are some # define tweaks in the qat engine. e_qat.c shows, that there must be some threading issue:

# USE_PTHREAD_YIELD is commented. etc. etc.

Will try some combinations.

It would be great to have privileged access to ask some more questions about threading, polling etc.

Rgds.

Franz

[FSkal1]

Hi again,

please explain, why the Configure Script will be patched to disable ASYNCH and SYNCH DIGESTS ! (After Patch)

For me, it's pretty uselesse, when disabling the DIGEST functions.

What's the intention ?

Snip from the Configure (patched)

$cflags .= ' -I'.$icp_eng_qat_dir.' -I'.$icp_api_dir.' -I'.$icp_lac_api_dir.' -DOPENSSL_QAT_ASYNCH -DOPENSSL_DISABLE_QAT_DIGEST_ASYNCH -DOPENSSL_DISABLE_QAT_DIGEST_SYNCH -DOPENSSL_DISABLE_QAT_OFFLOAD_RAND -DOPENSSL_DISABLE_QAT_PRF_ASYNCH';

Rgds.

Franz

[Natalie_Z_Intel]

Hi, Franz! You now have Privileged account on the EDC which allows you to access Intel Confidential content that is posted on the EDC. Hope this helps!

LynnZ

[idata]

Thanks for bringing this to our attention, we are currently working on resolving this issue.

Thank You!

[STEVEN_L_Intel]

Hi FranzCC,

Thankyou for the question regarding why Digest offload operations are disabled by default in the QAT OpenSSL patch.

Currently there are several reasons why digests are disabled by default:

1) The sort of small digest operations that make up typical SSL streams are quite efficient to perform on core, as such there is only marginal payback from offloading them to an accelerator.

2) There are some issues with the asynch stack implementation around performing cipher operations followed by digest operations. There is a section towards the end of the README.txt file supplied with the QAT OpenSSL patch that describes why digest operations have been disabled.

If you are running synchronously then it is perfectly safe to re-enable synchronous digest offload via the OPENSSL_ENABLE_QAT_DIGEST_SYNCH flag, although I would suggest you measure performance/cpu usage before and after enablement in order to determine whether you see any benefit from the digest offload in your use case.

Also if your application links straight to libCrypto and is not using the libSSL interfaces then it is perfectly safe to enable either synchronous or asynchronous digests as the issue lies in the libSSL asynchronous stack and not in the engine code.

One other point to note is that if you use ciphers AES128-SHA or AES256-SHA these result in calling more efficient implementations of what are called chained ciphers. In these particular cases you'll end up using:

NID_aes_128_cbc_hmac_sha1

NID_aes_256_cbc_hmac_sha1

In our engine these chained ciphers will offload both the cipher and digest operations in one go so are far more efficient (see qat_chain.c for further details).

Chained operations are unaffected by the issues above and will still be used whether offloaded digests are enabled or disabled as you cannot separate them from the cipher operation.

Hope that information is useful.

Kind Regards,

Steve.

[idata]

Hi everyone,

i got the root cause.

that is, the C2358 has only one QAT engine for only one instance.

In the original conf, it uses cy0 and cy1 which is not matching in C2358 case.

so, just modified the file named c2xxx_qa_dev0.conf, and now it works!

thanks all !

Best Regards,

[idata]

Hi Leo_Yeh,

Great to know you solved this issue. Thanks for posting the solution!

Best regards,

Jimmy.