ocf-linux-users — Anything and everything ocf-linux related

Re: [Ocf-linux-users] openssl version in patches

[David M. <dav...@mc...>]

Jivin Matthew Lear lays it down ...
> Hi,
> 
> I'm currently working with openssl version 1.0.0d and kernel 2.6.32. I'd
> like to hook in ocf for my project. In the latest ocf package
> (ocf-linux-20110720), I notice that the openssl patches only go up to
> 0.9.8 (openssl-0.9.8r.patch). Do you intend on providing patches for newer
> versions of openssl?

A lot of the OCF patches are already integrated into the 1.0 branch.
I don't currently use it though so I really can't comment on its stability
or its functionality.

At some point any needed patches for 1.0 will be part of OCF,  but I don't
think it will be any time soon unless someone else contributes them ;-)

> The 2.6.32 kernel tree I'm using is based on the kernel.org long-term
> stable tree. I should be able to use / backport the ocf 2.6.33 patch for
> this I expect, though.

What you want is the 2.6.33 only portion of the patch and the latest OCF
files.

If you do:

	make patch
	cat patches/linux-2.6.38-ocf.patch ocf-linux-base.patch > my-kernel.patch

Then use my-kernel.patch to patch your 2.6.32 kernel.  If you have any
problems with 2.6.32 let me know and I can go back and generate a specific
2.6.32 patch.

Cheers,
Davidm


-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

[Ocf-linux-users] openssl version in patches

[Matthew L. <li...@bu...>]

Hi,

I'm currently working with openssl version 1.0.0d and kernel 2.6.32. I'd
like to hook in ocf for my project. In the latest ocf package
(ocf-linux-20110720), I notice that the openssl patches only go up to
0.9.8 (openssl-0.9.8r.patch). Do you intend on providing patches for newer
versions of openssl?

The 2.6.32 kernel tree I'm using is based on the kernel.org long-term
stable tree. I should be able to use / backport the ocf 2.6.33 patch for
this I expect, though.

Cheers,
--  Matt

Re: [Ocf-linux-users] EXPORT_SYMBOL(find_task_by_vpid) not needed for kernel <= 2.6.30

[David M. <dav...@mc...>]

Jivin Hauke Mehrtens lays it down ...
> In the patch linux-2.6.30-ocf.patch the adding of
> EXPORT_SYMBOL(find_task_by_vpid) is wrong, because kernel <= 2.6.30
> already have this and adding it twice causes a compiler error.
> 
> kernel/pid.c:395:1: error: redefinition of '__kstrtab_find_task_by_vpid'
> kernel/pid.c:386:1: note: previous definition of
> '__kstrtab_find_task_by_vpid' was here
> kernel/pid.c:395:1: error: redefinition of '__ksymtab_find_task_by_vpid'
> kernel/pid.c:386:1: note: previous definition of
> '__ksymtab_find_task_by_vpid' was here

What kernel version do you have ?
Which OCF release are you using ?

There are quite a lot of patches in the patches directory,  perhaps there is
a better choice.  Perhaps your kernel has already been patched once ?

If your kernel already supports it just undo that portion of the patch.
Its a fairly simple change.

> Why don't you have patches for every major kernel version and why is the
> ordering of the changes different from patch to patch.

We don't have every version for a number of reasons,  at the end of the day
thats just the way it is.  In a lot of cases the patch doesn't need updating
from release to release.  If you ask nicely it is possible for me to generate
a patch specific to just about any kernel revision, but it's not something I
do for fun.  Whenever I do generate one I add it to the patches directory
for others to use.

> This makes it hard to find the differences in the patches.

The patches are different as they are usually whatever came out of diff
process that I used at the time. It's not done on purpose, but when you are
hand assembling patches over a number of directories the diffs can get
reordered.

> Like the adding of EXPORT_SYMBOL(find_task_by_vpid); is in the top of
> linux-2.6.38-ocf.patch but in the bottom of linux-2.6.33-ocf.patch.

Its only a one line change,  if it is wrong for your kernel,  just add/delete
it as needed and feel free to pass on the required changes to the list for
others to learn from,

Thanks,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

[Ocf-linux-users] EXPORT_SYMBOL(find_task_by_vpid) not needed for kernel <= 2.6.30

[Hauke M. <ha...@ha...>]

In the patch linux-2.6.30-ocf.patch the adding of
EXPORT_SYMBOL(find_task_by_vpid) is wrong, because kernel <= 2.6.30
already have this and adding it twice causes a compiler error.

kernel/pid.c:395:1: error: redefinition of '__kstrtab_find_task_by_vpid'
kernel/pid.c:386:1: note: previous definition of
'__kstrtab_find_task_by_vpid' was here
kernel/pid.c:395:1: error: redefinition of '__ksymtab_find_task_by_vpid'
kernel/pid.c:386:1: note: previous definition of
'__ksymtab_find_task_by_vpid' was here

Why don't you have patches for every major kernel version and why is the
ordering of the changes different from patch to patch. This makes it
hard to find the differences in the patches.
Like the adding of EXPORT_SYMBOL(find_task_by_vpid); is in the top of
linux-2.6.38-ocf.patch but in the bottom of linux-2.6.33-ocf.patch.

Hauke

Re: [Ocf-linux-users] A quick question about cryptodev openssl engine.

[Liu H. <onl...@gm...>]

Hi David,

Got it, thanks for your opinion.

Much appreciated!
Hui

2011/7/30 David McCullough <dav...@mc...>

>
> Jivin Liu Hui lays it down ...
> > Hi David and all.
> >
> > I take a loot at the source code of cryptodev openssl engine and have one
> question.
> >
> > OCF-Linux has a good framework for IPSEC combination request,
> > for example, if 3des+sha1 comes, ocf-driver can handle them in one
> operation.
> > So some hardware which support combination request, this is very
> convenient because they don't have to do the request for two times. And it
> also save a lot time for memory copy.
> >
> > But openssl engine mechanism seems to can't handle combination request,
> they only can pass
> > crypt and hash request separately to the cryptodev.  So,  driver and
> hardware have to operate twice instead of one.
> >
> > Is this a restrict of OPENSSL engine mechanism? If so, the cryptodev
> engine have to follow this restrict. Am I right?
>
> This is a restiction of how the openssl engine is implemented.
> I believe cryptodev will allow conbinations just like the kernel, you can
> try it by modifying cryptotest and see.
>
> > And I don't understand, why the famous OPENSSL doesn't consider the
> combination request in its engine mechanism? This is very important for
> performance.
>
> You will notice that by default openssl doesn't even do hashes,  you need
> to
> enable it specifically with a config option.
>
> You are right though,  if you wanted to do both cipher and hash,  then
> having cryptodev do both at the same time would be great.  I am not sure
> the
> openssl internals are geared up for that though.
>
> If you can figure it out then I am sure the openssl devs would be happy to
> take a patch.
>
> If, however,  you just want to do cipher+hash in another program,  then
> just
> go ahead and do it using cryptodev directly.  if you hit any issues I'll be
> glad to fix them or sort it out.
>
> Cheers,
> Davidm
>
> --
> David McCullough,      dav...@mc...,  Ph:+61 734352815
> McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org
>



-- 
Thanks & Best Regards
Liu Hui
--

Re: [Ocf-linux-users] A quick question about cryptodev openssl engine.

[David M. <dav...@mc...>]

Jivin Liu Hui lays it down ...
> Hi David and all.
> 
> I take a loot at the source code of cryptodev openssl engine and have one question.
> 
> OCF-Linux has a good framework for IPSEC combination request,
> for example, if 3des+sha1 comes, ocf-driver can handle them in one operation.
> So some hardware which support combination request, this is very convenient because they don't have to do the request for two times. And it also save a lot time for memory copy.
> 
> But openssl engine mechanism seems to can't handle combination request, they only can pass
> crypt and hash request separately to the cryptodev.  So,  driver and hardware have to operate twice instead of one.
> 
> Is this a restrict of OPENSSL engine mechanism? If so, the cryptodev engine have to follow this restrict. Am I right?

This is a restiction of how the openssl engine is implemented.
I believe cryptodev will allow conbinations just like the kernel, you can
try it by modifying cryptotest and see.

> And I don't understand, why the famous OPENSSL doesn't consider the combination request in its engine mechanism? This is very important for performance.

You will notice that by default openssl doesn't even do hashes,  you need to
enable it specifically with a config option.

You are right though,  if you wanted to do both cipher and hash,  then
having cryptodev do both at the same time would be great.  I am not sure the
openssl internals are geared up for that though.

If you can figure it out then I am sure the openssl devs would be happy to
take a patch.

If, however,  you just want to do cipher+hash in another program,  then just
go ahead and do it using cryptodev directly.  if you hit any issues I'll be
glad to fix them or sort it out.

Cheers,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

[Ocf-linux-users] A quick question about cryptodev openssl engine.

[Liu H. <onl...@gm...>]

Hi David and all.

I take a loot at the source code of cryptodev openssl engine and have one
question.

OCF-Linux has a good framework for IPSEC combination request,
for example, if 3des+sha1 comes, ocf-driver can handle them in one
operation.
So some hardware which support combination request, this is very convenient
because they don't have to do the request for two times. And it also save a
lot time for memory copy.

But openssl engine mechanism seems to can't handle combination request, they
only can pass
crypt and hash request separately to the cryptodev.  So,  driver and
hardware have to operate twice instead of one.

Is this a restrict of OPENSSL engine mechanism? If so, the cryptodev engine
have to follow this restrict. Am I right?

And I don't understand, why the famous OPENSSL doesn't consider the
combination request in its engine mechanism? This is very important for
performance.

Much appreciated!
Hui

-- 
Thanks & Best Regards
Liu Hui
--

Re: [Ocf-linux-users] The development problem of developing an OCF driver, could you please give me some hint?

[David M. <dav...@mc...>]

Jivin Paul Wouters lays it down ...
> On Tue, 26 Jul 2011, David McCullough wrote:
> 
> > If your "user" only asked for DES in its session that would be fine,  but
> > openswan asks for DES+SHA1,  which your driver cannot do,  and cryptosoft
> > can no longer do.
> 
> Why can't cryptosoft do that? Is it a policy because 1des is too weak?

cryptosoft can do it normally,  but after DES support was commented out of
cryptosoft by Hui it can't :-)

Of course the fact that DES+SHA1 requires a driver that can support the
combination is a deficiancy in OCF IMO,  but that needs to be addressed at a
higher layer than cryptosoft,  if it is.

Cheers,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

Re: [Ocf-linux-users] The development problem of developing an OCF driver, could you please give me some hint?

[Paul W. <pa...@xe...>]

On Tue, 26 Jul 2011, David McCullough wrote:

> If your "user" only asked for DES in its session that would be fine,  but
> openswan asks for DES+SHA1,  which your driver cannot do,  and cryptosoft
> can no longer do.

Why can't cryptosoft do that? Is it a policy because 1des is too weak?

Paul

Re: [Ocf-linux-users] The development problem of developing an OCF driver, could you please give me some hint?

[Liu H. <onl...@gm...>]

David,

It is very clear~~

Much appreciated!
Hui

2011/7/26 David McCullough <dav...@mc...>

>
> Jivin Liu Hui lays it down ...
> > Hi David,
> >
> > Thanks for the timely reply!
> >
> > I started with ocfnull, but I refer a lot of other drivers' code. So,
> maybe it is not a problem of ocfnull.
>
> ok
>
> > So, maybe another problem you mentioned is the root cause. Kernel wants
> my driver to do hash because I specified esp using des-sha1. So, des+sha1 is
> needed.
> >
> > But I don't understand the policy of OCF. If I just do DES in my driver,
> and will crytosoft handle sha1?  In my understanding, if my driver doesn't
> register sha1 and cryptosoft register sha1 then the sha1 work will be done
> in cryptosoft. i.e. the crypto-combination request will be done in two
> drivers.  Am I wrong?
>
> If your "user" only asked for DES in its session that would be fine,  but
> openswan asks for DES+SHA1,  which your driver cannot do,  and cryptosoft
> can no longer do.
>
> So OCF does not split your session over multiple drivers for you.  I know
> it
> seems illogical,  and to some extent I agree,  but that is the way it is.
>
> > And my hardware do support hash, I haven't implement it because I want to
> develop a simplest driver at first.
>
> Ok,  then just skip openswan and use cryptotest (from userspace) and
> ocfbench.ko in kernel space to check you driver and throughput.
>
> You can also use openssl and load/unload cryptosoft as needed to compare
> output etc.
>
> > And I have another question, in the same driver, the combination
> request(crypt+hash) are handled in one process or two?  I took a lot into
> other drivers, it seems that the combination request can be handled in one
> process or two.  For example, des-sha1, if you register des and sha1
> separately, then the des-sha1 will be handled in two process. But you also
> can check the combination in the first process and handle them together. Am
> I right?   These stuff confused me a lot.
>
> Well they are handled within one "session".  How the driver implements that
> session is up to the driver.  Most of the HW drivers do it in a sinle
> operation.  cryptosoft does it as 2 sepeerate actions.  Depending on your
> HW, you may do either. A single HW op is much better than 2 HW op's in
> sequence if you can do it.  Less copying and passes over the data,
>
> Cheers,
> Davidm
>
> > 2011/7/26 David McCullough <dav...@mc...>
> >
> >
> >
> >       Jivin Liu Hui lays it down ...
> >
> >       > Hi David and all,
> >       >
> >       > I am developing an OCF-LINUX-DRIVER for one chip. I got some
> problems, could you please take a look in it?
> >       > I started with ocfnull driver template and only added
> CRYPTO_DES_CBC algorithm to the driver:
> >
> >
> >       ocfnull is probably not a good example to follow if you are doing a
> real HW
> >       driver.  Be sure to look at some of the others as well once you get
> into it.
> >
> >
> >       > crypto_register(cp8_id, CRYPTO_DES_CBC, 0, 0);
> >       >
> >       > More alogrithm will be added after this simplest one works.
> >       >
> >       > In order to make cryptosoft driver not compete with my driver, I
> comment the CBC-DES in cryptosoft driver, like this:
> >       > // [CRYPTO_DES_CBC]         = { cbc(des),
>  SW_TYPE_BLKCIPHER, },
> >       >
> >       > And I also insmod my driver before cryptosoft.
> >       > In my opnion, if there are DES-CBC request, they will be sent to
> my driver.
> >       >
> >       > The ocf-linux dispatch work seem works. After I run 'service
> ipsec start', the newsessson routine in my driver was called, here is the
> dmesg print:
> >       > cp8_newsession()
> >       > cp8_newsession key:cri->cri_klen=64,(cri->cri_klen + 7)/8=8
> >       >     0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37
> >       > cp8_freesession()
> >       >
> >       > BUT, after I want to set up a connecton by 'ipsec auto --up
> net-to-net', error happended:
> >       > 003 ERROR: "net-to-net" #5: pfkey write() of K_SADB_ADD message
> 19 for Add SA esp.1e94ffe@172.22.14.5 failed. Errno 71: Protocol error
> >       >
> >       > The dmesg print show:
> >       > KLIPS klips_debug:ipsec_alg_enc_key_create: NULL ipsec_alg_enc
> object
> >       > KLIPS pfkey_add_parse: not successful for SA:  (error), deleting
> >       >
> >       > It seems that openswan can't find an ipsec_alg_enc object to
> create a key.
> >       >
> >       > But if I use DES-CBC algorithm of cryptosoft driver, this error
> will disappear.
> >       > I can't understand why the key generation is related with
> ocf-driver because ocf-driver is not in charge of generate key.
> >       > And I can't see the different between my driver and cryptosoft
> driver, i.e. why cryptosoft driver works and mine failed?
> >       >
> >       > Could you please give me some hint?
> >
> >
> >       It is possibly because openswan wants to do a combination
> hash+crypto.  I am
> >       not sure on this it seems likely given what you have tried.  The
> other
> >       option may be that ocfnull cut corners that a real driver cannot.
> >
> >       You have a couple of options,  test your driver using "cryptotest"
> >       initially.  That will get around the hash+cipher problems.
> >
> >       Second,  mod the ocfbench driver to test DES and do no hashing and
> try that
> >       for in kernel testing.
> >
> >       Once you have all that and you think you are ready to roll we can
> look at
> >       where it should go next.  Does your hardware support hashes ?  If
> so then
> >       get that implemented next and you should be done.  If not perhaps
> we can
> >       look at how ocf spreads requests across multiple drivers (ie.,
> hashes on one
> >       driver and ciphers on another).
> >
> >       Cheers,
> >       Davidm
> >
> >       --
> >       David McCullough,      dav...@mc...,  Ph:+61
> 734352815
> >       McAfee - SnapGear      http://www.mcafee.com
> http://www.uCdot.org
> >
> >
> >
> >
> >
> > --
> > Thanks & Best Regards
> > Liu Hui
> > --
> >
> >
>
> --
> David McCullough,      dav...@mc...,  Ph:+61 734352815
> McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org
>



-- 
Thanks & Best Regards
Liu Hui
--

Re: [Ocf-linux-users] The development problem of developing an OCF driver, could you please give me some hint?

[David M. <dav...@mc...>]

Jivin Liu Hui lays it down ...
> Hi David,
> 
> Thanks for the timely reply!
> 
> I started with ocfnull, but I refer a lot of other drivers' code. So, maybe it is not a problem of ocfnull.

ok

> So, maybe another problem you mentioned is the root cause. Kernel wants my driver to do hash because I specified esp using des-sha1. So, des+sha1 is needed. 
> 
> But I don't understand the policy of OCF. If I just do DES in my driver, and will crytosoft handle sha1?  In my understanding, if my driver doesn't register sha1 and cryptosoft register sha1 then the sha1 work will be done in cryptosoft. i.e. the crypto-combination request will be done in two drivers.  Am I wrong?

If your "user" only asked for DES in its session that would be fine,  but
openswan asks for DES+SHA1,  which your driver cannot do,  and cryptosoft
can no longer do.

So OCF does not split your session over multiple drivers for you.  I know it
seems illogical,  and to some extent I agree,  but that is the way it is.

> And my hardware do support hash, I haven't implement it because I want to develop a simplest driver at first.

Ok,  then just skip openswan and use cryptotest (from userspace) and
ocfbench.ko in kernel space to check you driver and throughput.

You can also use openssl and load/unload cryptosoft as needed to compare
output etc.

> And I have another question, in the same driver, the combination request(crypt+hash) are handled in one process or two?  I took a lot into other drivers, it seems that the combination request can be handled in one process or two.  For example, des-sha1, if you register des and sha1 separately, then the des-sha1 will be handled in two process. But you also can check the combination in the first process and handle them together. Am I right?   These stuff confused me a lot.

Well they are handled within one "session".  How the driver implements that
session is up to the driver.  Most of the HW drivers do it in a sinle
operation.  cryptosoft does it as 2 sepeerate actions.  Depending on your
HW, you may do either. A single HW op is much better than 2 HW op's in
sequence if you can do it.  Less copying and passes over the data,

Cheers,
Davidm

> 2011/7/26 David McCullough <dav...@mc...>
> 
> 
> 
> 	Jivin Liu Hui lays it down ...
> 	
> 	> Hi David and all,
> 	>
> 	> I am developing an OCF-LINUX-DRIVER for one chip. I got some problems, could you please take a look in it?
> 	> I started with ocfnull driver template and only added CRYPTO_DES_CBC algorithm to the driver:
> 	
> 	
> 	ocfnull is probably not a good example to follow if you are doing a real HW
> 	driver.  Be sure to look at some of the others as well once you get into it.
> 	
> 
> 	> crypto_register(cp8_id, CRYPTO_DES_CBC, 0, 0);
> 	>
> 	> More alogrithm will be added after this simplest one works.
> 	>
> 	> In order to make cryptosoft driver not compete with my driver, I comment the CBC-DES in cryptosoft driver, like this:
> 	> // [CRYPTO_DES_CBC]         = { cbc(des),          SW_TYPE_BLKCIPHER, },
> 	>
> 	> And I also insmod my driver before cryptosoft.
> 	> In my opnion, if there are DES-CBC request, they will be sent to my driver.
> 	>
> 	> The ocf-linux dispatch work seem works. After I run 'service ipsec start', the newsessson routine in my driver was called, here is the dmesg print:
> 	> cp8_newsession()
> 	> cp8_newsession key:cri->cri_klen=64,(cri->cri_klen + 7)/8=8
> 	>     0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37
> 	> cp8_freesession()
> 	>
> 	> BUT, after I want to set up a connecton by 'ipsec auto --up net-to-net', error happended:
> 	> 003 ERROR: "net-to-net" #5: pfkey write() of K_SADB_ADD message 19 for Add SA esp.1e94ffe@172.22.14.5 failed. Errno 71: Protocol error
> 	>
> 	> The dmesg print show:
> 	> KLIPS klips_debug:ipsec_alg_enc_key_create: NULL ipsec_alg_enc object
> 	> KLIPS pfkey_add_parse: not successful for SA:  (error), deleting
> 	>
> 	> It seems that openswan can't find an ipsec_alg_enc object to create a key.
> 	>
> 	> But if I use DES-CBC algorithm of cryptosoft driver, this error will disappear.
> 	> I can't understand why the key generation is related with ocf-driver because ocf-driver is not in charge of generate key.
> 	> And I can't see the different between my driver and cryptosoft driver, i.e. why cryptosoft driver works and mine failed?
> 	>
> 	> Could you please give me some hint?
> 	
> 	
> 	It is possibly because openswan wants to do a combination hash+crypto.  I am
> 	not sure on this it seems likely given what you have tried.  The other
> 	option may be that ocfnull cut corners that a real driver cannot.
> 	
> 	You have a couple of options,  test your driver using "cryptotest"
> 	initially.  That will get around the hash+cipher problems.
> 	
> 	Second,  mod the ocfbench driver to test DES and do no hashing and try that
> 	for in kernel testing.
> 	
> 	Once you have all that and you think you are ready to roll we can look at
> 	where it should go next.  Does your hardware support hashes ?  If so then
> 	get that implemented next and you should be done.  If not perhaps we can
> 	look at how ocf spreads requests across multiple drivers (ie., hashes on one
> 	driver and ciphers on another).
> 	
> 	Cheers,
> 	Davidm
> 	
> 	--
> 	David McCullough,      dav...@mc...,  Ph:+61 734352815
> 	McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org
> 	
> 
> 
> 
> 
> -- 
> Thanks & Best Regards
> Liu Hui
> --
> 
> 

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

Re: [Ocf-linux-users] The development problem of developing an OCF driver, could you please give me some hint?

[Liu H. <onl...@gm...>]

Hi David,

Thanks for the timely reply!

I started with ocfnull, but I refer a lot of other drivers' code. So, maybe
it is not a problem of ocfnull.

So, maybe another problem you mentioned is the root cause. Kernel wants my
driver to do hash because I specified esp using des-sha1. So, des+sha1 is
needed.

But I don't understand the policy of OCF. If I just do DES in my driver, and
will crytosoft handle sha1?  In my understanding, if my driver doesn't
register sha1 and cryptosoft register sha1 then the sha1 work will be done
in cryptosoft. i.e. the crypto-combination request will be done in two
drivers.  Am I wrong?

And my hardware do support hash, I haven't implement it because I want to
develop a simplest driver at first.

And I have another question, in the same driver, the combination
request(crypt+hash) are handled in one process or two?  I took a lot into
other drivers, it seems that the combination request can be handled in one
process or two.  For example, des-sha1, if you register des and sha1
separately, then the des-sha1 will be handled in two process. But you also
can check the combination in the first process and handle them together. Am
I right?   These stuff confused me a lot.

Thanks for your time.

Much appreciated!
Hui

2011/7/26 David McCullough <dav...@mc...>

>
> Jivin Liu Hui lays it down ...
> > Hi David and all,
> >
> > I am developing an OCF-LINUX-DRIVER for one chip. I got some problems,
> could you please take a look in it?
> > I started with ocfnull driver template and only added CRYPTO_DES_CBC
> algorithm to the driver:
>
> ocfnull is probably not a good example to follow if you are doing a real HW
> driver.  Be sure to look at some of the others as well once you get into
> it.
>
> > crypto_register(cp8_id, CRYPTO_DES_CBC, 0, 0);
> >
> > More alogrithm will be added after this simplest one works.
> >
> > In order to make cryptosoft driver not compete with my driver, I comment
> the CBC-DES in cryptosoft driver, like this:
> > // [CRYPTO_DES_CBC]         = { cbc(des),          SW_TYPE_BLKCIPHER, },
> >
> > And I also insmod my driver before cryptosoft.
> > In my opnion, if there are DES-CBC request, they will be sent to my
> driver.
> >
> > The ocf-linux dispatch work seem works. After I run 'service ipsec
> start', the newsessson routine in my driver was called, here is the dmesg
> print:
> > cp8_newsession()
> > cp8_newsession key:cri->cri_klen=64,(cri->cri_klen + 7)/8=8
> >     0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37
> > cp8_freesession()
> >
> > BUT, after I want to set up a connecton by 'ipsec auto --up net-to-net',
> error happended:
> > 003 ERROR: "net-to-net" #5: pfkey write() of K_SADB_ADD message 19 for
> Add SA esp.1e94ffe@172.22.14.5 failed. Errno 71: Protocol error
> >
> > The dmesg print show:
> > KLIPS klips_debug:ipsec_alg_enc_key_create: NULL ipsec_alg_enc object
> > KLIPS pfkey_add_parse: not successful for SA:  (error), deleting
> >
> > It seems that openswan can't find an ipsec_alg_enc object to create a
> key.
> >
> > But if I use DES-CBC algorithm of cryptosoft driver, this error will
> disappear.
> > I can't understand why the key generation is related with ocf-driver
> because ocf-driver is not in charge of generate key.
> > And I can't see the different between my driver and cryptosoft driver,
> i.e. why cryptosoft driver works and mine failed?
> >
> > Could you please give me some hint?
>
> It is possibly because openswan wants to do a combination hash+crypto.  I
> am
> not sure on this it seems likely given what you have tried.  The other
> option may be that ocfnull cut corners that a real driver cannot.
>
> You have a couple of options,  test your driver using "cryptotest"
> initially.  That will get around the hash+cipher problems.
>
> Second,  mod the ocfbench driver to test DES and do no hashing and try that
> for in kernel testing.
>
> Once you have all that and you think you are ready to roll we can look at
> where it should go next.  Does your hardware support hashes ?  If so then
> get that implemented next and you should be done.  If not perhaps we can
> look at how ocf spreads requests across multiple drivers (ie., hashes on
> one
> driver and ciphers on another).
>
> Cheers,
> Davidm
>
> --
> David McCullough,      dav...@mc...,  Ph:+61 734352815
> McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org
>



-- 
Thanks & Best Regards
Liu Hui
--

Re: [Ocf-linux-users] The development problem of developing an OCF driver, could you please give me some hint?

[David M. <dav...@mc...>]

Jivin Liu Hui lays it down ...
> Hi David and all,
> 
> I am developing an OCF-LINUX-DRIVER for one chip. I got some problems, could you please take a look in it?
> I started with ocfnull driver template and only added CRYPTO_DES_CBC algorithm to the driver:

ocfnull is probably not a good example to follow if you are doing a real HW
driver.  Be sure to look at some of the others as well once you get into it.

> crypto_register(cp8_id, CRYPTO_DES_CBC, 0, 0);
> 
> More alogrithm will be added after this simplest one works.
> 
> In order to make cryptosoft driver not compete with my driver, I comment the CBC-DES in cryptosoft driver, like this:
> // [CRYPTO_DES_CBC]         = { cbc(des),          SW_TYPE_BLKCIPHER, },
> 
> And I also insmod my driver before cryptosoft.
> In my opnion, if there are DES-CBC request, they will be sent to my driver.
> 
> The ocf-linux dispatch work seem works. After I run 'service ipsec start', the newsessson routine in my driver was called, here is the dmesg print:
> cp8_newsession()
> cp8_newsession key:cri->cri_klen=64,(cri->cri_klen + 7)/8=8
>     0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37
> cp8_freesession()
> 
> BUT, after I want to set up a connecton by 'ipsec auto --up net-to-net', error happended:
> 003 ERROR: "net-to-net" #5: pfkey write() of K_SADB_ADD message 19 for Add SA esp.1e94ffe@172.22.14.5 failed. Errno 71: Protocol error
> 
> The dmesg print show:
> KLIPS klips_debug:ipsec_alg_enc_key_create: NULL ipsec_alg_enc object
> KLIPS pfkey_add_parse: not successful for SA:  (error), deleting
> 
> It seems that openswan can't find an ipsec_alg_enc object to create a key.
> 
> But if I use DES-CBC algorithm of cryptosoft driver, this error will disappear.
> I can't understand why the key generation is related with ocf-driver because ocf-driver is not in charge of generate key.
> And I can't see the different between my driver and cryptosoft driver, i.e. why cryptosoft driver works and mine failed?
> 
> Could you please give me some hint? 

It is possibly because openswan wants to do a combination hash+crypto.  I am
not sure on this it seems likely given what you have tried.  The other
option may be that ocfnull cut corners that a real driver cannot.

You have a couple of options,  test your driver using "cryptotest"
initially.  That will get around the hash+cipher problems.

Second,  mod the ocfbench driver to test DES and do no hashing and try that
for in kernel testing.

Once you have all that and you think you are ready to roll we can look at
where it should go next.  Does your hardware support hashes ?  If so then
get that implemented next and you should be done.  If not perhaps we can
look at how ocf spreads requests across multiple drivers (ie., hashes on one
driver and ciphers on another).

Cheers,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

[Ocf-linux-users] The development problem of developing an OCF driver, could you please give me some hint?

[Liu H. <onl...@gm...>]

Hi David and all,

I am developing an OCF-LINUX-DRIVER for one chip. I got some problems, could
you please take a look in it?
I started with ocfnull driver template and only added CRYPTO_DES_CBC
algorithm to the driver:
crypto_register(cp8_id, CRYPTO_DES_CBC, 0, 0);

More alogrithm will be added after this simplest one works.

In order to make cryptosoft driver not compete with my driver, I comment the
CBC-DES in cryptosoft driver, like this:
// [CRYPTO_DES_CBC]         = { cbc(des),          SW_TYPE_BLKCIPHER, },

And I also insmod my driver before cryptosoft.
In my opnion, if there are DES-CBC request, they will be sent to my driver.

The ocf-linux dispatch work seem works. After I run 'service ipsec start',
the newsessson routine in my driver was called, here is the dmesg print:
cp8_newsession()
cp8_newsession key:cri->cri_klen=64,(cri->cri_klen + 7)/8=8
    0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37
cp8_freesession()

BUT, after I want to set up a connecton by 'ipsec auto --up net-to-net',
error happended:
003 ERROR: "net-to-net" #5: pfkey write() of K_SADB_ADD message 19 for Add
SA esp.1e94ffe@172.22.14.5 failed. Errno 71: Protocol error

The dmesg print show:
KLIPS klips_debug:ipsec_alg_enc_key_create: NULL ipsec_alg_enc object
KLIPS pfkey_add_parse: not successful for SA:  (error), deleting

It seems that openswan can't find an ipsec_alg_enc object to create a key.

But if I use DES-CBC algorithm of cryptosoft driver, this error will
disappear.
I can't understand why the key generation is related with ocf-driver because
ocf-driver is not in charge of generate key.
And I can't see the different between my driver and cryptosoft driver, i.e.
why cryptosoft driver works and mine failed?

Could you please give me some hint?

Much appreciated!
Hui

Re: [Ocf-linux-users] OCF_CRYPTOSOFT depends on CRYPTO_MANAGER

[David M. <dav...@mc...>]

Jivin Hauke Mehrtens lays it down ...
> Hi,
> 
> I am getting the following error while loading cryptosoft on an bcm47xx
> mips device. The attached patch fixes the problem.
> 
> cryptosoft: Unknown symbol crypto_alloc_ahash (err 0)
> cryptosoft: Unknown symbol crypto_ahash_setkey (err 0)
> cryptosoft: Unknown symbol crypto_alloc_ablkcipher (err 0)
> cryptosoft: Unknown symbol crypto_ahash_digest (err 0)

Ok,  I look at adding a fix into the tree.

CRYPTO_MANAGER is a little overkill though,  I think you just need to have
CRYPTO_HASH enabled.  Could you check with just that ?

Thanks,
Davidm

> --- a/crypto/ocf/Kconfig
> +++ b/crypto/ocf/Kconfig
> @@ -26,6 +26,7 @@ config OCF_CRYPTODEV
>  
>  config OCF_CRYPTOSOFT
>  	tristate "cryptosoft (software crypto engine)"
> +	select CRYPTO_MANAGER
>  	depends on OCF_OCF
>  	help
>  	  A software driver for the OCF framework that uses

> ------------------------------------------------------------------------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/

> _______________________________________________
> Ocf-linux-users mailing list
> Ocf...@li...
> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users


-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

[Ocf-linux-users] OCF_CRYPTOSOFT depends on CRYPTO_MANAGER

[Hauke M. <ha...@ha...>]

Hi,

I am getting the following error while loading cryptosoft on an bcm47xx
mips device. The attached patch fixes the problem.

cryptosoft: Unknown symbol crypto_alloc_ahash (err 0)
cryptosoft: Unknown symbol crypto_ahash_setkey (err 0)
cryptosoft: Unknown symbol crypto_alloc_ablkcipher (err 0)
cryptosoft: Unknown symbol crypto_ahash_digest (err 0)

Hauke

[Ocf-linux-users] ocf-linux-20110720 released

[David M. <dav...@mc...>]

Hi all,

A new release to fix a bug in cryptosoft causing a crash when algorithms
could not be found. This was caused by a change (at some point) in the
CryptoAPI tfm allocation returning PTR_ERR's instead of NULL.

    http://sourceforge.net/projects/ocf-linux/files/ocf-linux/20110720/

Cheers,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

Re: [Ocf-linux-users] insmod: error inserting './ocf.ko': -1 Invalid parameters

[Paul W. <pa...@xe...>]

On Tue, 21 Jun 2011, Marc wrote:

> FATAL: Error inserting ocf (/lib/modules/2.6.32/extra/ocf.ko): Invalid
> argument
>
> and also
>
> ~/ocf-linux-20110530/ocf# insmod ocf.ko
> insmod: error inserting 'ocf.ko': -1 Invalid parameters
>
> and
>
> insmod: error inserting 'cryptosoft.ko': -1 Invalid parameters

check with "dmesg" to see why those failed to load?

> Lastly there's no cryptodev.ko module being generated in the ocf folder
> or elsewhere so this module cannot be loaded.

I am not sure, but it might be that the cryptodev stuff is only available
after patching the kernel itself, eg you cannot just compile as an
external module.

Paul

[Ocf-linux-users] insmod: error inserting './ocf.ko': -1 Invalid parameters

[Marc <cc...@le...>]

Hello,

I'm having some trouble using the ocf modules on my ALIX board.

Kernel is 2.6.32
ocf version is "ocf-linux-20110530".

First of all, during "make ocf_modules" I'm getting tons of these:

WARNING: /root/ocf-linux-20110530/ocf/ocf: 'crypto_find_device_byhid'
exported twice. Previous export was in vmlinux

with various crypto_* functions. No idea if thats expected behaviour.

Secondly, after using make ocf_modules and ocf_install and
OCF_DIR=`pwd` (which does not survive reboots as any custom
environmental variable), it looks like this:

FATAL: Error inserting ocf (/lib/modules/2.6.32/extra/ocf.ko): Invalid
argument

and also

~/ocf-linux-20110530/ocf# insmod ocf.ko
insmod: error inserting 'ocf.ko': -1 Invalid parameters

and

insmod: error inserting 'cryptosoft.ko': -1 Invalid parameters

Lastly there's no cryptodev.ko module being generated in the ocf folder
or elsewhere so this module cannot be loaded.

I'm feeling like im doing something horribly wrong or missing something
really stupid but I just can figure out what that might be. Any pointers
would be greatly appreciated.

Greetings, Marc

[Ocf-linux-users] ocf-linux-20110530 released

[David M. <dav...@mc...>]

Hi all,

A new ocf-linux release.  Everything is updated to new versions; linux-2.6.39,
openssl-0.9.8r.

One new driver (uBsec BCM5365).  Lots of SMP work,  especially with cryptosoft.
Some patches from users. Better support for Openswan.  New release format which
is hopefully less confusing.  Better support for Desktop use.

Full changelog since the last release is available with the release:

	http://sourceforge.net/projects/ocf-linux/files/ocf-linux/20110530/

Cheers,
Davidm

--
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

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

[Paul W. <pa...@xe...>]

On Wed, 18 May 2011, Paul Wouters wrote:

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

Remind me to bring the Xelerance internal wiki pages on openswan / ocf benchmarking
to the public wiki. They're currently on a VM I don't have access to. But ping me
in a few days when I have access to these if I haven't posted them.

We found various tweaks to increase the traffic and got numbers that were comparable
in speed despite the SAref support overhead for L2TP/Transport Mode. This was using
cryptosoft with KLIPS on SMP machines without crypto offload hardware.

A few notes:

- Do not run iperf on the IPsec machines but on machines behind those.
- Run multiple TCP streams to reduce effects of a single stalled/lost packet
- Play a LOT with the MTU sizes
- Different brands of eth cards make a huge difference
- Disable various nic card offloading/checksumming
- Ensure the OCF buffers are high enough.Openswan's _startklips script tries
   to do this for you based on CPUs, but not based on hardware crypto offload.
   Specifically look at:
    /sys/module/ocf/parameters/crypto_q_max
    /sys/module/ipsec/parameters/ipsec_irs_cache_allocated_max
    /sys/module/ipsec/parameters/ipsec_ixs_cache_allocated_max

Paul

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

[Kim P. <kim...@fr...>]

On Mon, 23 May 2011 16:46:34 +0800
Vasanth Ragavendran <rag...@gm...> wrote:

> 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.

ok, so some version of the kernel.org kernel + klips + ocf patches.
What version?

> > 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

OCF_CRYPTODEV=y?  shouldn't be relevant.

> achieve only around 11Mbps. Thank u so much and sorry for the late reply.

so, given the following configuration settings:

CRYPTO_DEV_TALITOS=y
OCF_CRYPTOSOFT=y
#OCF_TALITOS is not set

and

grep talitos /proc/interrupts

indeed shows numbers incrementing with traffic - i.e., the
algorithms chosen for the tunnel are implemented in the driver -
then there's some performance bottleneck between the klips and/or
ocf code and the kernel's cryptoAPI.  How does a pure vanilla kernel
perform? i.e, without klips & ocf patches.

Kim

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

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

[Kim P. <kim...@fr...>]

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.

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?

Kim

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

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

Thank you all so much for responding.

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:
> >
> > >>> but when the Sec driver is configured as module into the kernel the
> module doesn;t get inserted
> > >>> gives segmentation fault and if the Sec driver is configured as
> non-module type the kernel doesn't
> > >>> bootsup at all!
> > >>
> > >> David might be able to help with this. The ubsec driver is mostly used
> on linksys/asus machines,
> > >> perhaps yours is slightly different?
> > >
> > > Based on the freescale URL posted to users@openswan, I assume you're
> > > referring to the "SEC23DRVRS" driver?  That is a standalone driver,
> > > and won't be of use unless you're prepared to write code to
> > > integrate it into your IPsec stack.
> > >
>
Yeah i was mentioning about SEC23DRVRS apologies for mentioning it in short
form.
and as Paul has asked to test with a lower MTU say 1400, the thruput worsens
i get only
4.71Mbps however with MTU being 1500 i get the thruput as 14.7Mbps.

> > 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?

> Ah, i thought he meant the ubsec one. Talitos I believe is also supported
> with OCF and KLIPS
> > IPsec, but I'm sure David can confirm that.
>
> I tried even with KLIPS and ocf,cryptodev and ocf-talitos and even here i
get no better throughput its only 11.7Mbps! Why am I getting such a lower
throughputs?
Thank you so much everybody for helping out. Awaiting your replies to
proceed further.

Yeah, Kim wrote the driver,  but the in kernel one is more up to date ;-)
>
> Cheers,
> Davidm
>
> --
> David McCullough,      dav...@mc...,  Ph:+61 734352815
> McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org
>



-- 
Thanks and Regards
R.Vasanth Ragavendran