- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for bringing this to our attention, we are currently working on resolving this issue.
Thank You!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Leo_Yeh,
Great to know you solved this issue. Thanks for posting the solution!
Best regards,
Jimmy.
![](/skins/images/B7BA37F9CE4B52FF7CAE1FB0388839C8/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page