<div dir="ltr">Dear Matt, <div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 8, 2015 at 3:17 PM, Matt Caswell <span dir="ltr"><<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br><br>
</span>No. I think you are confusing two different things.<br>
<br>
1) How does an *application* perform asynchronous work (via libssl or<br>
libcrypto) using an asynchronous capable engine?<br></blockquote><div><br></div><div>Ok. There is an example an explanation you have provided.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
2) How does an asynchronous capable engine offload async work to its<br>
hardware?<br>
<br>
These patches solve the first problem only. It provides an API and<br>
mechanism for control to pass between the application and engine and<br>
back again (perhaps multiple times) during the invocation of a long<br>
running crypto operation. It also provides some mechanisms to enable an<br>
engine to signal the completion of work to the application.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
The second problem is entirely engine dependant. It will be a different<br>
solution for different hardware. These patches do not provide a solution<br>
to that problem.<br></blockquote><div><br></div><div>So I do not understand what you mean by "offload" :-(</div><div><br></div><div>I understand that it's an engine-dependent, but I can't imagine a corresponding pseudo code.</div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature">SY, Dmitry Belyavsky</div>
</div></div>