<br>On Fri, Oct 14, 2011 at 9:47 AM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, 14 Oct 2011, satpal parmar wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, if you want openssl (and openssl linked apps) or openswans pluto to<br>
use the drivers (no point for openswan in my opinion). <br>
</blockquote>
<br></div>
If the device is an embedded system, and the HW driver can deliver entropy via OCF,<br>
then there is a very good reason to use it!</blockquote><div><font class="Apple-style-span" color="#006600">OK. But I think adding OCF just for entropy will too taxing for a embeded system.</font></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you use klips, OCF is the best way to accelerate it. If you use netkey<br>
then you do not need OCF at all.<br>
</blockquote>
<br></div>
netkey does not split 1 IPsec SA over multiple CPU's. When using 1 single tunnel<br>
with over then 1 CPU's worth of crypto, it will actually be faster to use<br>
KLIPS with OCF and cryptosoft.<br></blockquote><div><font class="Apple-style-span" color="#009900">OK</font> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
You would also need OCF if there is an OCF hardware driver, but no native cryptoapi<br>
or async hardware driver that netkey could use.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> No plans for KLIPS. My kernel is KLIPS virgin.<br>
<br>
Then you do not need OCF unless you want userspace to use your HW drivers.<br>
</blockquote>
<br></div>
Correct.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Well I was not very lucky. I tried pinging after removing OCF completely. Still getting the same crash.<br>
</blockquote>
<br></div>
Guess it means it was not OCF. So very lucky :)</blockquote><div><font class="Apple-style-span" color="#006600">I see David smiling :)</font> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, I may have confused you earlier, I thought you had an OCF driver for<br>
some reason. I was wrong, its a cryptoAPI driver that you have and it has<br>
very little to do with OCF really, except that OCF can use it via cryptosoft ;-)<br>
<br>
So we can conclude our discussion as: H/w accelerator drivers I am using are based on 2.6 native crypto API. Since this<br>
crypto API is designed to be used with in-kernel IPsec stack Netkey I do not need anything extra to glue things.<br>
This arrangement should work on its own. They introduce OCF to test it from userspace using Openssl/Cryptotest tool which<br>
uses Cryptodev.<br>
</blockquote>
<br></div>
Yes.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cryptosoft do many thing one of them is translation for userland utilities so that they can talk<br>
with scatter list based Native Crypto API used to support NETKEY the default IP stack in 2.6 kernel. <br>
</blockquote>
<br></div>
You mean "cryptodev" here, not "cryptosoft"?</blockquote><div><font class="Apple-style-span" color="#006600">Well I meant cryptosoft. I maybe wrong. So you mean cryptosoft only do emulation?</font></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From my testing we have:<br>
<br>
1. cryptotest--->cryptodev---><u></u>cryptosoft--->Native crypto API--->driver--->H/W accelerator path working.<br>
<br>
2. Ping--->netkey---->native crypto API---> drivers ----> H/W accelerators path crashing. Its crashing even when I ping<br>
from other machine to this machine. <br>
</blockquote>
<br></div>
That's something for the driver writers or the kernel people....<br></blockquote><div> </div><div><font class="Apple-style-span" color="#006600">I made some progress in my investigation here. It seems there is a bug in driver (drivers/crypto/nss-sham.c)</font></div>
<div><font class="Apple-style-span" color="#006600"><br></font></div><div><font class="Apple-style-span" color="#006600">static int nss_sham_update_cdma_start(struct nss_sham_dev *dd)</font></div><div><font class="Apple-style-span" color="#006600">{</font></div>
<div><font class="Apple-style-span" color="#006600"> struct nss_sham_reqctx *ctx = ahash_request_ctx(dd->req);</font></div><div><font class="Apple-style-span" color="#006600"> unsigned int length, final, tail;</font></div>
<div><font class="Apple-style-span" color="#006600"> struct scatterlist *sg;</font></div><div><font class="Apple-style-span" color="#006600"><br></font></div><div><font class="Apple-style-span" color="#006600"> if (!ctx->total)</font></div>
<div><font class="Apple-style-span" color="#006600"> return 0;</font></div><div><font class="Apple-style-span" color="#006600"><br></font></div><div><font class="Apple-style-span" color="#006600"> if (ctx->bufcnt || ctx->offset)</font></div>
<div><font class="Apple-style-span" color="#006600"> </font><span class="Apple-style-span" style="color: rgb(0, 102, 0); ">return nss_sham_update_cdma_slow(dd); ---------------------->True for OCF/cryptodev/crptosoft path.T</span><span class="Apple-style-span" style="color: rgb(0, 102, 0); ">his uses dma_single mapping instead of scatterlist.</span><span class="Apple-style-span" style="color: rgb(0, 102, 0); ">But in case of netkey/IPsec this is not true and we hit case </span></div>
<div><span class="Apple-style-span" style="color: rgb(0, 102, 0); "><br></span></div><div><span class="Apple-style-span" style="color: rgb(0, 102, 0); "> </span><font class="Apple-style-span" color="#006600"> if (!dma_map_sg(dd->dev, ctx->sg, 1, DMA_TO_DEVICE)) {</font></div>
<div><font class="Apple-style-span" color="#006600"> dev_err(dd->dev, "dma_map_sg error\n");</font></div><div><font class="Apple-style-span" color="#006600"> return -EINVAL;</font></div>
<div><font class="Apple-style-span" color="#006600"> which is scatter list DMA implementation and crashes in the end of this path (as seen in crash dump). I am yet to explore why we got two different paths and why it crashing but I think this is the right direction to investigate.</font></div>
<div><font class="Apple-style-span" color="#006600"><br></font></div><div><font class="Apple-style-span" color="#006600">@David </font></div><div><font class="Apple-style-span" color="#006600">I know its much to ask but if you can spare some time to see the code and confirm it would be great help. You can find code </font><a href="http://processors.wiki.ti.com/index.php/Installing_AM389x_C6A816x_DM816x_Crypto_Support"><font class="Apple-style-span" color="#006600">here.</font></a></div>
<div><font class="Apple-style-span" color="#006600"> </font> </div><div><div><font class="Apple-style-span" color="#006600">Thanks in advance.</font></div><div><font class="Apple-style-span" color="#006600">SP</font> </div>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">
<br>
Paul<br></font></blockquote><div><br></div><div><br></div></div>