Re: [Ocf-linux-users] [Openswan Users] IPSec L2tpv3 throughput low using Netkey kernel stack

[Vasanth R. <rag...@gm...>]

On Fri, May 20, 2011 at 12:20 PM, Kim Phillips
<kim...@fr...>wrote:

> On Thu, 19 May 2011 20:18:40 -0700
> Vasanth Ragavendran <rag...@gm...> wrote:
>
> > On Wed, May 18, 2011 at 7:02 PM, David McCullough <
> > dav...@mc...> wrote:
> > > Jivin Paul Wouters lays it down ...
> > > > On Tue, 17 May 2011, Kim Phillips wrote:
> > > >
> > > > > Known working (to me at least) IPsec offload configuration for the
> > > > > 8315 should be NETKEY with CONFIG_CRYPTO_DEV_TALITOS configured in
> > > > > a vanilla kernel.  To be able to tell whether h/w crypto offload is
> > > > > in operation, see 'grep talitos /proc/interrupts' run.
> > >
> > As Kim had mentioned I had loaded the CONFIG_CRYPTO_DEV_TALITOS as a
> module
> > with the module in the kernel i am getting a lower throughput! I am
> getting
> > only 13.4Mbps however without the module inserted i get 14.7Mbps how
> could
> > this be possible and the results sounds really ridiculous to me! And when
> > the CONFIG_CRYPTO_DEV_TALITOS is loaded i am able to view it using grep
> > talitos /proc/interrupts. so the hardware accelerator is getting used
> > however resulting in a lower throughput! That's absurd am I missing
> > something here?
>
> Is this a *vanilla* kernel CONFIG_CRYPTO_DEV_TALITOS driver, or is
> it from the freescale BSP?  If the latter, please forward your
> inquiry to the standard freescale BSP support channels.
>
> No this is the vanilla kernel's and not from the freescale.

> Otherwise (vanilla kernel), sounds like too little crypto
> payload and/or rate - so little that sending it to the accelerator
> and waiting for results takes longer than s/w crypto on the core.
> Can you benchmark using the 'null' cipher algorithm to make sure
> this is the case?
>
Will check on the 'null' cipher part. But why is the thruput lower when
using Klips, ocf and cryptodev and the rest of the settings being the same i
achieve only around 11Mbps. Thank u so much and sorry for the late reply.

>
> Kim
>
>


-- 
Thanks and Regards
R.Vasanth Ragavendran