Intel® Integrated Performance Primitives
Community support and discussions relating to developing high-performance vision, signal, security, and storage applications.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.

Is sgx_aes_ctr reentrant?

Joongun_P_
Beginner
154 Views

In my enclave.cpp code, there is sgx_aes_ctr function calls.

When I executes my program, it works well but the execution time is not proportional to the 1 / (number of threads).

I tested with 7700k cpu and 1, 2, 4 threads.

Without sgx_aes_ctr calls, execution results are proportional to 4, 2, 1 times well.

I am using sgx sdk version 1.8 and I realize that the fuction is lapping of ippsAESEncryptCTR.

https://github.com/01org/linux-sgx/blob/1115c195cd60d5ab2b80c12d07e21663e5aa8030/sdk/tlibcrypto/sgx_...

https://software.intel.com/sites/default/files/managed/f6/6f/ippcp_0.pdf

 

Is sgx_aes_ctr reentrant?

Why my programs execution time looks it doesn't?

0 Kudos
1 Solution
Juan_d_Intel
Employee
154 Views

It looks like you're not concerned about reentrancy but multithreading scalability, right?

Could you describe (or even better post) your code here showing how you measure sgx_aes_ctr  and ippsAESEncryptCTR execution times?

If your program is calling sgx_aes_ctr multiple times, the lack of scalability might be caused by the malloc/free calls. Since you're using the 1.8 Linux SGX SDK, you could use the tcmalloc library, instead of the default memory allocator included in sgx_tstdc. If that's not the reason, I'd like to see the test program to better understand what the issue might be.

View solution in original post

2 Replies
Juan_d_Intel
Employee
155 Views

It looks like you're not concerned about reentrancy but multithreading scalability, right?

Could you describe (or even better post) your code here showing how you measure sgx_aes_ctr  and ippsAESEncryptCTR execution times?

If your program is calling sgx_aes_ctr multiple times, the lack of scalability might be caused by the malloc/free calls. Since you're using the 1.8 Linux SGX SDK, you could use the tcmalloc library, instead of the default memory allocator included in sgx_tstdc. If that's not the reason, I'd like to see the test program to better understand what the issue might be.

Joongun_P_
Beginner
154 Views

After I replaced malloc to tcmalloc, execution times became scalable.

Thank you, Juan!

 

 

Reply