A library routine in a shared function definition and shared array of pointers

[Cheng_C_]

Dear all, 

I have 2 questions while programming for MIC in the shared model offload mode.

(1) If I define a _Cilk_shared function,inside which I used a routine in another library, for example, the RSA_public_encrypt routine provided in the openssl library. Do I have to install the library on MIC cards? Is there a method by which I can make the routine shareable between the target and host without compiling the library for target?

(2) I want to define a shared array of pointers pointing to shared memory. Is the following a correct way to do that?

char*_Cilk_shared en_m[1000];

for (int k=0; k<1000; k++){

        en_m = (_Cilk_shared char*) _Offload_shared_malloc(sizeof(char)*(201));

Thanks very much.

[Kevin_D_Intel]

Sorry, I'm having trouble following the description of the scenario in question 1. Could you elaborate further and clarify what routines are declared sharable and in which library and which library you are asking about that needs to be on the coprocessor?

In other words, I'm trying to understand if your app calls a library function, call that function A, which is declared _Cilk_shared and function A calls an openssl routine RSA_public_encrypt(), where the openssl library was built for native only with -mmic, and so the question about building/needing the library on the card relates to the openssl lib?

Regarding question 2, will en_m only be accessed on the host?

[Kevin_D_Intel]

Advice from Development is:

You should change the declaration to this:

_Cilk_shared char *_Cilk_shared en_m[1000];

This allocates en_m in shared memory and indicates that what each element refers to is also shared.

They further wrote about the for loop:

for (int k=0; k<1000; k++){
        en_m = (_Cilk_shared char*) _Offload_shared_malloc(sizeof(char)*(201));

Because of this, the change in the declaration is not meaningfully different, since when dereferenced, the pointed to memory will be there in shared anyway. But one should not rely on the current incorrect declaration, since someday we might optimize it away or something.

[Cheng_C_]

Greetings Kevin, Thanks very much for the reply.

needs to be accessed from mic target as well. I think your second reply solves the problem.

Regarding question 1, I defined a _Cilk_shared function like this:

_Cilk_shared void encrypt(void){

    RSA *rsa_pub_key = NULL;

    FILE *fpub = fopen("pub_key.bin","rb");

    PEM_read_RSAPublicKey(fpub, &rsa_pub_key, NULL, NULL);

    fclose(fpub);

    int i;

    #pragma omp parallel for shared(en_m, tm_m, rsa_pub_key) private(i) schedule(static)

    for(i=0; i<100; i++){

        RSA_public_encrypt(EN_SIZE, (unsigned char*)en_m, (unsigned char*)tm_m, rsa_pub_key, RSA_PKCS1_OAEP_PADDING);

    }

    RSA_free(rsa_pub_key);

}

Then in the main program, I offload the above function to mic target:

_Cilk_offload encrypt();

RSA_public_encrypt is a routine provided in openssl. So my question is I have to install the openssl library into target as well, right?

[Kevin_D_Intel]

If you built the openssl lib on the host using -mmic, then before running your app, add the path to the openssl library where it resides on the host to the MIC_LD_LIBRARY_PATH environment variable. The design of this variable is that needed libraries are automatically copied over to coprocessor and removed upon completion of the app.

[Kevin_D_Intel]

I don’t know whether you have been successful or not but I created a small mock-up based on your description to demonstrate how you could do what you described. The attached .tgz contains two scenarios.

Scenario 1 always calls the openssl library. The host-version of openssl is called when no coprocessor is available for offloading and encrypt() does not offload. When that function does offload, the MIC-version is called. In this case, openssl must be built for both the host and coprocessor.

Scenario 2 only calls the openssl library when encrypt() actually offloads. A conditional call into the MIC-side library is created using the __MIC__ predefine; therefore encrypt() only calls into the MIC-side library when it has actually offloaded. When it does not offload, the alternate host-side code path executes.

The execution demonstrates that you do not need to install the MIC-side openssl on the card but instead simply set the MIC_LD_LIBRARY_PATH to the host path where this MIC-side library resides. Transfer of the library is handled automatically. It also answers your earlier question about how openssl must be compiled depending on its use.

I hope it helps.

[Cheng_C_]

Kevin Davis (Intel) wrote:

I don’t know whether you have been successful or not but I created a small mock-up based on your description to demonstrate how you could do what you described. The attached .tgz contains two scenarios.

Scenario 1 always calls the openssl library. The host-version of openssl is called when no coprocessor is available for offloading and encrypt() does not offload. When that function does offload, the MIC-version is called. In this case, openssl must be built for both the host and coprocessor.

Scenario 2 only calls the openssl library when encrypt() actually offloads. A conditional call into the MIC-side library is created using the __MIC__ predefine; therefore encrypt() only calls into the MIC-side library when it has actually offloaded. When it does not offload, the alternate host-side code path executes.

The execution demonstrates that you do not need to install the MIC-side openssl on the card but instead simply set the MIC_LD_LIBRARY_PATH to the host path where this MIC-side library resides. Transfer of the library is handled automatically. It also answers your earlier question about how openssl must be compiled depending on its use.

I hope it helps.

Kevin, thank you so much. It's a great help!

[Kevin_D_Intel]

Great, glad to hear that.