Dear Matt, On Thu, Oct 8, 2015 at 1:56 PM, Matt Caswell <m...@openssl.org> wrote:
> > > The engine needs to have a way of offloading the work to "something > > else" so that it can come back and pick up the results later. > Typically > > for an engine this would mean some external hardware, but as I > suggested > > above it could be done using threads. > > > > From an engine perspective the work would be: > > - Receive a request to do some crypto work in the normal way via the > > engine API. > > - Offload the work to "something else" > > > > > > So what is a mechanism of such an offload? Can I, for example, get the > > (global) ASYNC_pool and add a job (function/pointer to context) to it? > > The offload mechanism is entirely engine specific. We do not know how > any specific engine works or how to interface to the hardware. An engine > will be called in exactly the same way as now. The job of the engine > will be to take the parameters passed to it and initiate the work in the > engine hardware. > > So in pseudo code it might look something like this: > > static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx, > unsigned char *out, const unsigned char *in, size_t inl) > { > int jobid; > > jobid = offload_cipher_to_hardware(ctx, out, in , inl); > > /* > * jobid holds a reference in the engine back to the work we just > * started > */ > > while(work_not_finished_yet(jobid)) { > /* Return control back to the calling application */ > ASYNC_pause_job(); > } > > return get_results_from_hardware(jobid); > } > > You will note that ASYNC_pause_job() does *not* do a "return" to return > control back to the user application...but calling ASYNC_pause_job() > will cause SSL_read (or whatever) to return with SSL_ERROR_WANT_ASYNC > nonetheless. The async job has its own private stack to enable this. > Recalling SSL_read from the user application will appear to the engine > like the function call ASYNC_pause_job() has returned. > > > > How will the SSL struct obtain a job id from the engine implementing, > > for example, "long" RSA_METHOD? > > It does not need to. The SSL object has a reference to the ASYNC_JOB. > The engine can manage its own job ids - see the pseudo code above. > I see. So am I correct supposing that pseudo code for offload_cipher_to_hardware looks like this: static int async_wrapper(void * args) { ... } static ASYNC_JOB *offload (void *args) { ASYNC_JOB *pjob = NULL; int funcret; size_t size = 0; int ret = ASYNC_start_job(&pjob, &funcret, async_wrapper, args, *args, size); if (ret != ASYNC_PAUSE) return NULL; return pjob; } ? Thank you! -- SY, Dmitry Belyavsky
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev