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

Re: [Ocf-linux-users] Current status

[David M. <uc...@gm...>]

J.W...@mi... wrote the following:
> Hi all,
> 
> I'm able to get hold of some hifn boards, and I wonder whether I still need to apply specific patches.
> On the suse mailing list, they claim that the patch is already included in main stream kernel, but only works on 32-bit machines.

That would be the linux-crypto driver,  not the OCF drivers.

OCF is not part of the kernel,  it is a seperately maintained HW crypto
project.

The OCF hifn drivers work fine on 64bit systems,  but for some uses you
will need to patch your kernel.

> Besides loading a kernelmodule, any other tweaks todo?
> 
> One board I would like to use on an openvpn box. Can that be done without altering distro-supplied openvpn/openssl ?

I don't believe so,  you would need to recompile openssl with cryptodev
enabled under linux.  Depending on the version of openssl you are using you
may need to patch that as well.

> Another board I intend to use for bulk generating keys/certificates with ejbca.
> When hinting this to their developpers, I was asked if there was an pkcs11 driver for the accelerator board.
> But shouldn't it be enough if openssl is capable in talking to the board?

To accelerate pkcs using HIFN under ocf-linux you will need to:

* patch your kernel
* possibly patch openssl (depending on the version)

I am not aware of any other solutions that provide this though.

The only thing I will point out is that pkcs acceleration is not a magic
solution.  From my experience it will not let you generate more keys per
second.  What I have seen is that the rate stays about the same (there is a
lot of surrounding algs that are not accelerated).

What it does gain you is CPU cycles.  While the HIFN is crunching numbers
you can be doing other things (providing your application can take
advantage of this).

Hope that helps :-)

Cheers,
Davidm

-- 
David McCullough,  uc...@gm...,   Ph: 0410 560 763

[Ocf-linux-users] Current status

[<J.W...@mi...>]

Hi all,

I'm able to get hold of some hifn boards, and I wonder whether I still need to apply specific patches.
On the suse mailing list, they claim that the patch is already included in main stream kernel, but only works on 32-bit machines.

Besides loading a kernelmodule, any other tweaks todo?

One board I would like to use on an openvpn box. Can that be done without altering distro-supplied openvpn/openssl ?

Another board I intend to use for bulk generating keys/certificates with ejbca.
When hinting this to their developpers, I was asked if there was an pkcs11 driver for the accelerator board.
But shouldn't it be enough if openssl is capable in talking to the board?


Kind regards, hans.

______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

Re: [Ocf-linux-users] patch for OCF

[hwang7 <hua...@wi...>]

> hwang7 wrote the following:
>> Hi david
>>
>> When using cryptosoft of OCF to do the crypto and run test scripts
>> which includes the following commands on SMP platform(we do the test
>> on fsl_p4080 which is a SMP processor with 8 cores):
>>
>> $ openssl speed -evp des -engine cryptodev -elapsed -multi 10
>> $ openssl speed -evp des3 -engine cryptodev -elapsed -multi 10
>> $ openssl speed -evp aes128 -engine cryptodev -elapsed -multi 10
>>
>> The system will give out call trace or hang.
>>
>> The root causes of this issue is:
>> The swcr_sessions is not protected properly, and the three
>> types of session operation "create session, use session, delete
>> session" are also not protected properly.
>>
>> So:
>> 1.add spin lock to protect swcr_sessions
>> 2.add state/ref fields to session, use session state to prevent from
>> deleting a session when it's in creating or using state, and use spin
>> lock to protect the session state.
>
> Thanks for sending in the patch. I did see it the first time you posted it,
> I just haven't had time to digest it fully, sorry for not responding
> earlier.
>
> Does the fsl_p4080 have any HW acceleration underneath cryptosoft or are
> you using purely software acceleration ?
>
I  use purely software acceleration to do the test.
> The patch looks pretty good,  but it would help me a lot if you could
> describe what kind of re-entry/call sequence was causing the main problem.
>
For CIOCFSESSION the execute path is :
     1) cse = csefind(fcr, ses);
     2) judge if cse is NULL
     3) csedelete(fcr, cse);
     4) error = csefree(cse);
For step4, if there are two delete requesets to the same cse called 
"delte_request1" and "delete_request2", then the swcr_freesession will 
also be called two times. Then in the below condition, there will be 
problem with cryptosoft:
     1) delte_request1 and delete_request2 is sent to kernel, both of 
these requests execute the csefind(fcr, ses) sucessfully
     2) delte_request1 is finished, so the slot for the session in 
swcr_sessions is free
     3) a create session is send to kernel, and it get the slot who is 
free at step 2)
     4) create session requeset is processed, and then wait for some 
resources
     5) delte_request2 get the cpu, and so it will delete the session 
created in step4
     6) create session requeset is wake up, and it will work on a 
session who is not exist...

Below is a log for this issue( this log is got from another SMP platform 
P2041):

Unable to handle kernel paging request for data at address 0x00000008
Faulting instruction address: 0xfa29abf4
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT SMP NR_CPUS=4 LTT NESTING LEVEL : 0
P2041 RDB
last sysfs file: /sys/devices/virtual/misc/crypto/uevent
Modules linked in: ipv6 sctp binfmt_misc bsdjail exportfs xfs jfs 
reiserfs jbd2
ext4 squashfs isofs cramfs jffs2 yaffs fat vfat msdos nls_cp437 ocf(P) 
cryptodev
(P) cryptosoft aes_generic sha1_generic sha256_generic ctr michael_mic 
xcbc blow
fish cast5 crypto_null sha512_generic camellia [last unloaded: 
xfrm6_mode_transp
ort]
NIP: fa29abf4 LR: fa29abec CTR: c0678348
REGS: eb1d9b80 TRAP: 0300   Tainted: P 
(2.6.34.10-WR4.3.0.0_standard)
MSR: 00029002 <EE,ME,CE>  CR: 24244448  XER: 20000000
DEAR: 00000008, ESR: 00000000
TASK = eaa25700[3776] 'openssl' THREAD: eb1d8000 CPU: 3
GPR00: fa29abec eb1d9c30 eaa25700 ea702cc0 c015012c e946d7ac 00000001 
eb1d9ab0
GPR08: 077af000 eb1dc540 00000000 eb1d9c30 24244448 10081f08 fa29b700 
eb1d8000
GPR16: fa29c45c fa29c460 00000000 fa29c0b0 c08cdac0 fa29b6a0 c08cdd7c 
fa29c464
GPR24: c08c2f60 fa2a0000 00000000 fa29c3f8 00000001 eb1d9d48 e64e2484 
eb1d9c30
NIP [fa29abf4] swcr_newsession+0x5fc/0xad4 [cryptosoft]
LR [fa29abec] swcr_newsession+0x5f4/0xad4 [cryptosoft]
Call Trace:
[eb1d9c30] [fa29abec] swcr_newsession+0x5f4/0xad4 [cryptosoft] (unreliable)
[eb1d9c90] [fa26fbf4] crypto_newsession+0x12c/0x36c [ocf]
[eb1d9cd0] [fa288164] cryptodev_ioctl+0xc68/0x20b8 [cryptodev]
[eb1d9e60] [fa2895ec] cryptodev_unlocked_ioctl+0x38/0x50 [cryptodev]
[eb1d9e70] [c0166370] vfs_ioctl+0x4c/0xf8
[eb1d9e90] [c016660c] do_vfs_ioctl+0x90/0x760
[eb1d9f00] [c0166d70] sys_ioctl+0x94/0x124
[eb1d9f40] [c0012970] ret_from_syscall+0x0/0x4

> Thanks,
> Davidm
>
>
>
>
Best Regards
========================
Wang Huanhuan
Work phone:  +86-10-8477-8568

>> diff -urbN ocf-linux-20120127/ocf/cryptosoft.c ocf-linux-20120127-1/ocf/cryptosoft.c
>> --- ocf-linux-20120127/ocf/cryptosoft.c	2012-01-27 09:04:28.000000000 +0800
>> +++ ocf-linux-20120127-1/ocf/cryptosoft.c	2013-01-30 12:41:25.554624164 +0800
>> @@ -77,6 +77,11 @@
>>
>>   #define SW_TYPE_INUSE		0x10000000
>>
>> +#define SW_SESSION_IDLE				0x0
>> +#define SW_SESSION_CREATION_IN_PROGRESS		0x1
>> +#define SW_SESSION_IN_USE			0x2
>> +#define SW_SESSION_DELETION_IN_PROGRESS		0x3
>> +
>>   /* We change some of the above if we have an async interface */
>>
>>   #define SW_TYPE_ALG_AMASK	(SW_TYPE_ALG_MASK | SW_TYPE_ASYNC)
>> @@ -91,6 +96,8 @@
>>   	struct work_struct  workq;
>>   	int					sw_type;
>>   	int					sw_alg;
>> +	int					sw_state;
>> +	int					sw_ref;
>>   	struct crypto_tfm	*sw_tfm;
>>   	spinlock_t			sw_tfm_lock;
>>   	union {
>> @@ -283,6 +290,25 @@
>>   MODULE_PARM_DESC(swcr_debug, "Enable debug");
>>
>>   static void swcr_process_req(struct swcr_req *req);
>> +static DEFINE_SPINLOCK(session_lock);
>> +
>> +static inline void _swcr_set_state(struct swcr_data *swd, int state, int lock)
>> +{
>> +	unsigned long flags;
>> +	if( lock )
>> +		spin_lock_irqsave(&session_lock, flags);
>> +
>> +	if (swd != NULL)
>> +		swd->sw_state = state;
>> +
>> +	if ( lock )
>> +		spin_unlock_irqrestore(&session_lock, flags);
>> +}
>> +
>> +static inline void swcr_set_state(struct swcr_data *swd, int state)
>> +{
>> +	_swcr_set_state(swd, state, 0);
>> +}
>>
>>   /*
>>    * somethings just need to be run with user context no matter whether
>> @@ -339,14 +365,17 @@
>>   swcr_newsession(device_t dev, u_int32_t *sid, struct cryptoini *cri)
>>   {
>>   	struct swcr_data **swd;
>> -	u_int32_t i;
>> +	u_int32_t index, i;
>>   	int error;
>>   	char *algo;
>>   	int mode;
>> +	unsigned long flags;
>>
>> +	spin_lock_irqsave(&session_lock, flags);
>>   	dprintk("%s()\n", __FUNCTION__);
>>   	if (sid == NULL || cri == NULL) {
>>   		dprintk("%s,%d - EINVAL\n", __FILE__, __LINE__);
>> +		spin_unlock_irqrestore(&session_lock, flags);
>>   		return EINVAL;
>>   	}
>>
>> @@ -372,6 +401,7 @@
>>   			else
>>   				swcr_sesnum /= 2;
>>   			dprintk("%s,%d: ENOBUFS\n", __FILE__, __LINE__);
>> +			spin_unlock_irqrestore(&session_lock, flags);
>>   			return ENOBUFS;
>>   		}
>>   		memset(swd, 0, swcr_sesnum * sizeof(struct swcr_data *));
>> @@ -386,30 +416,39 @@
>>   		swcr_sessions = swd;
>>   	}
>>
>> -	swd = &swcr_sessions[i];
>> -	*sid = i;
>> +	index = i;
>> +	swd = &swcr_sessions[index];
>> +	*sid = index;
>>
>>   	while (cri) {
>>   		*swd = (struct swcr_data *) kmalloc(sizeof(struct swcr_data),
>>   				SLAB_ATOMIC);
>>   		if (*swd == NULL) {
>> -			swcr_freesession(NULL, i);
>> +			swcr_set_state(swcr_sessions[index], SW_SESSION_DELETION_IN_PROGRESS);
>> +			spin_unlock_irqrestore(&session_lock, flags);
>> +			swcr_freesession(NULL, index);
>>   			dprintk("%s,%d: ENOBUFS\n", __FILE__, __LINE__);
>>   			return ENOBUFS;
>>   		}
>>   		memset(*swd, 0, sizeof(struct swcr_data));
>> +		swcr_set_state(*swd, SW_SESSION_CREATION_IN_PROGRESS);
>> +		spin_unlock_irqrestore(&session_lock, flags);
>>
>>   		if (cri->cri_alg < 0 ||
>>   				cri->cri_alg>=sizeof(crypto_details)/sizeof(crypto_details[0])){
>>   			printk("cryptosoft: Unknown algorithm 0x%x\n", cri->cri_alg);
>> -			swcr_freesession(NULL, i);
>> +			_swcr_set_state(swcr_sessions[index],
>> +				SW_SESSION_DELETION_IN_PROGRESS, 1);
>> +			swcr_freesession(NULL, index);
>>   			return EINVAL;
>>   		}
>>
>>   		algo = crypto_details[cri->cri_alg].alg_name;
>>   		if (!algo || !*algo) {
>>   			printk("cryptosoft: Unsupported algorithm 0x%x\n", cri->cri_alg);
>> -			swcr_freesession(NULL, i);
>> +			_swcr_set_state(swcr_sessions[index],
>> +				SW_SESSION_DELETION_IN_PROGRESS, 1);
>> +			swcr_freesession(NULL, index);
>>   			return EINVAL;
>>   		}
>>
>> @@ -450,7 +489,9 @@
>>   						algo,mode);
>>   				err = IS_ERR((*swd)->sw_tfm) ? -(PTR_ERR((*swd)->sw_tfm)) : EINVAL;
>>   				(*swd)->sw_tfm = NULL; /* ensure NULL */
>> -				swcr_freesession(NULL, i);
>> +				_swcr_set_state(swcr_sessions[index],
>> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
>> +				swcr_freesession(NULL, index);
>>   				return err;
>>   			}
>>
>> @@ -482,7 +523,9 @@
>>   			if (error) {
>>   				printk("cryptosoft: setkey failed %d (crt_flags=0x%x)\n", error,
>>   						(*swd)->sw_tfm->crt_flags);
>> -				swcr_freesession(NULL, i);
>> +				_swcr_set_state(swcr_sessions[index],
>> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
>> +				swcr_freesession(NULL, index);
>>   				return error;
>>   			}
>>   		} else if ((*swd)->sw_type & (SW_TYPE_HMAC | SW_TYPE_HASH)) {
>> @@ -504,7 +547,9 @@
>>   			if (!(*swd)->sw_tfm) {
>>   				dprintk("cryptosoft: crypto_alloc_hash failed(%s,0x%x)\n",
>>   						algo, mode);
>> -				swcr_freesession(NULL, i);
>> +				_swcr_set_state(swcr_sessions[index],
>> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
>> +				swcr_freesession(NULL, index);
>>   				return EINVAL;
>>   			}
>>
>> @@ -512,7 +557,9 @@
>>   			(*swd)->u.hmac.sw_key = (char *)kmalloc((*swd)->u.hmac.sw_klen,
>>   					SLAB_ATOMIC);
>>   			if ((*swd)->u.hmac.sw_key == NULL) {
>> -				swcr_freesession(NULL, i);
>> +				_swcr_set_state(swcr_sessions[index],
>> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
>> +				swcr_freesession(NULL, index);
>>   				dprintk("%s,%d: ENOBUFS\n", __FILE__, __LINE__);
>>   				return ENOBUFS;
>>   			}
>> @@ -532,24 +579,33 @@
>>   			if (!(*swd)->sw_tfm) {
>>   				dprintk("cryptosoft: crypto_alloc_comp failed(%s,0x%x)\n",
>>   						algo, mode);
>> -				swcr_freesession(NULL, i);
>> +				_swcr_set_state(swcr_sessions[index],
>> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
>> +				swcr_freesession(NULL, index);
>>   				return EINVAL;
>>   			}
>>   			(*swd)->u.sw_comp_buf = kmalloc(CRYPTO_MAX_DATA_LEN, SLAB_ATOMIC);
>>   			if ((*swd)->u.sw_comp_buf == NULL) {
>> -				swcr_freesession(NULL, i);
>> +				_swcr_set_state(swcr_sessions[index],
>> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
>> +				swcr_freesession(NULL, index);
>>   				dprintk("%s,%d: ENOBUFS\n", __FILE__, __LINE__);
>>   				return ENOBUFS;
>>   			}
>>   		} else {
>>   			printk("cryptosoft: Unhandled sw_type %d\n", (*swd)->sw_type);
>> -			swcr_freesession(NULL, i);
>> +			_swcr_set_state(swcr_sessions[index],
>> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
>> +				swcr_freesession(NULL, index);
>>   			return EINVAL;
>>   		}
>>
>>   		cri = cri->cri_next;
>>   		swd = &((*swd)->sw_next);
>> +		spin_lock_irqsave(&session_lock, flags);
>>   	}
>> +	swcr_set_state(swcr_sessions[index], SW_SESSION_IDLE);
>> +	spin_unlock_irqrestore(&session_lock, flags);
>>   	return 0;
>>   }
>>
>> @@ -559,22 +615,42 @@
>>   static int
>>   swcr_freesession(device_t dev, u_int64_t tid)
>>   {
>> +	unsigned long flags;
>>   	struct swcr_data *swd;
>>   	u_int32_t sid = CRYPTO_SESID2LID(tid);
>>
>> +	spin_lock_irqsave(&session_lock, flags);
>>   	dprintk("%s()\n", __FUNCTION__);
>>   	if (sid > swcr_sesnum || swcr_sessions == NULL ||
>>   			swcr_sessions[sid] == NULL) {
>>   		dprintk("%s,%d: EINVAL\n", __FILE__, __LINE__);
>> +		spin_unlock_irqrestore(&session_lock, flags);
>>   		return(EINVAL);
>>   	}
>>
>>   	/* Silently accept and return */
>> -	if (sid == 0)
>> +	if (sid == 0) {
>> +		spin_unlock_irqrestore(&session_lock, flags);
>>   		return(0);
>> +	}
>>
>>   	while ((swd = swcr_sessions[sid]) != NULL) {
>> +		if (swd->sw_state == SW_SESSION_IN_USE
>> +			|| swd->sw_state == SW_SESSION_CREATION_IN_PROGRESS) {
>> +			spin_unlock_irqrestore(&session_lock, flags);
>> +			return EAGAIN;
>> +		}
>> +		/*
>> +		 * If the session is to be deleted, it should all be deleted
>> +		 * so mark it as unuseable.
>> +		 * In fact, only the first swcr_data's state is used as the
>> +		 * session state now, so just change it to mark the session
>> +		 * as being delete
>> +		 */
>> +		swcr_set_state(swd, SW_SESSION_DELETION_IN_PROGRESS);
>>   		swcr_sessions[sid] = swd->sw_next;
>> +		swcr_set_state(swcr_sessions[sid], SW_SESSION_DELETION_IN_PROGRESS);
>> +		spin_unlock_irqrestore(&session_lock, flags);
>>   		if (swd->sw_tfm) {
>>   			switch (swd->sw_type & SW_TYPE_ALG_AMASK) {
>>   #ifdef HAVE_AHASH
>> @@ -615,16 +691,18 @@
>>   				kfree(swd->u.hmac.sw_key);
>>   		}
>>   		kfree(swd);
>> +		spin_lock_irqsave(&session_lock, flags);
>>   	}
>> +	spin_unlock_irqrestore(&session_lock, flags);
>>   	return 0;
>>   }
>>
>>   static void swcr_process_req_complete(struct swcr_req *req)
>>   {
>> +	unsigned long flags;
>>   	dprintk("%s()\n", __FUNCTION__);
>>
>>   	if (req->sw->sw_type & SW_TYPE_INUSE) {
>> -		unsigned long flags;
>>   		spin_lock_irqsave(&req->sw->sw_tfm_lock, flags);
>>   		req->sw->sw_type &= ~SW_TYPE_INUSE;
>>   		spin_unlock_irqrestore(&req->sw->sw_tfm_lock, flags);
>> @@ -665,6 +743,12 @@
>>   	}
>>
>>   done:
>> +	spin_lock_irqsave(&session_lock, flags);
>> +	req->sw_head->sw_ref--;
>> +	if (req->sw_head->sw_ref <= 0) {
>> +		swcr_set_state(req->sw_head, SW_SESSION_IDLE);
>> +	}
>> +	spin_unlock_irqrestore(&session_lock, flags);
>>   	dprintk("%s crypto_done %p\n", __FUNCTION__, req);
>>   	crypto_done(req->crp);
>>   	kmem_cache_free(swcr_req_cache, req);
>> @@ -1162,6 +1246,7 @@
>>   {
>>   	struct swcr_req *req = NULL;
>>   	u_int32_t lid;
>> +	unsigned long flags;
>>
>>   	dprintk("%s()\n", __FUNCTION__);
>>   	/* Sanity check */
>> @@ -1179,10 +1264,12 @@
>>   	}
>>
>>   	lid = crp->crp_sid & 0xffffffff;
>> +	spin_lock_irqsave(&session_lock, flags);
>>   	if (lid >= swcr_sesnum || lid == 0 || swcr_sessions == NULL ||
>>   			swcr_sessions[lid] == NULL) {
>>   		crp->crp_etype = ENOENT;
>>   		dprintk("%s,%d: ENOENT\n", __FILE__, __LINE__);
>> +		spin_unlock_irqrestore(&session_lock, flags);
>>   		goto done;
>>   	}
>>
>> @@ -1195,6 +1282,7 @@
>>   		if (skb_shinfo(skb)->nr_frags >= SCATTERLIST_MAX) {
>>   			printk("%s,%d: %d nr_frags > SCATTERLIST_MAX", __FILE__, __LINE__,
>>   					skb_shinfo(skb)->nr_frags);
>> +			spin_unlock_irqrestore(&session_lock, flags);
>>   			goto done;
>>   		}
>>   	} else if (crp->crp_flags & CRYPTO_F_IOV) {
>> @@ -1202,6 +1290,7 @@
>>   		if (uiop->uio_iovcnt > SCATTERLIST_MAX) {
>>   			printk("%s,%d: %d uio_iovcnt > SCATTERLIST_MAX", __FILE__, __LINE__,
>>   					uiop->uio_iovcnt);
>> +			spin_unlock_irqrestore(&session_lock, flags);
>>   			goto done;
>>   		}
>>   	}
>> @@ -1213,11 +1302,24 @@
>>   	if (req == NULL) {
>>   		dprintk("%s,%d: ENOMEM\n", __FILE__, __LINE__);
>>   		crp->crp_etype = ENOMEM;
>> +		spin_unlock_irqrestore(&session_lock, flags);
>>   		goto done;
>>   	}
>>   	memset(req, 0, sizeof(*req));
>>
>>   	req->sw_head = swcr_sessions[lid];
>> +	if (req->sw_head->sw_state == SW_SESSION_DELETION_IN_PROGRESS) {
>> +		crp->crp_etype = EINVAL;
>> +		spin_unlock_irqrestore(&session_lock, flags);
>> +		goto done;
>> +	} else if (req->sw_head->sw_state == SW_SESSION_CREATION_IN_PROGRESS) {
>> +		crp->crp_etype = EAGAIN;
>> +		spin_unlock_irqrestore(&session_lock, flags);
>> +		goto done;
>> +	}
>> +	swcr_set_state(req->sw_head, SW_SESSION_IN_USE);
>> +	req->sw_head->sw_ref++;
>> +	spin_unlock_irqrestore(&session_lock, flags);
>>   	req->crp = crp;
>>   	req->crd = crp->crp_desc;
>>
>>
>
>> ------------------------------------------------------------------------------
>> Try New Relic Now & We'll Send You this Cool Shirt
>> New Relic is the only SaaS-based application performance monitoring service
>> that delivers powerful full stack analytics. Optimize and monitor your
>> browser, app, & servers with just a few lines of code. Try New Relic
>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
>
>> _______________________________________________
>> Ocf-linux-users mailing list
>> Ocf...@li...
>> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
>
>

-- 

Re: [Ocf-linux-users] patch for OCF

[David M. <uc...@gm...>]

hwang7 wrote the following:
> Hi david
> 
> When using cryptosoft of OCF to do the crypto and run test scripts
> which includes the following commands on SMP platform(we do the test
> on fsl_p4080 which is a SMP processor with 8 cores):
> 
> $ openssl speed -evp des -engine cryptodev -elapsed -multi 10
> $ openssl speed -evp des3 -engine cryptodev -elapsed -multi 10
> $ openssl speed -evp aes128 -engine cryptodev -elapsed -multi 10
> 
> The system will give out call trace or hang.
> 
> The root causes of this issue is:
> The swcr_sessions is not protected properly, and the three
> types of session operation "create session, use session, delete
> session" are also not protected properly.
> 
> So:
> 1.add spin lock to protect swcr_sessions
> 2.add state/ref fields to session, use session state to prevent from
> deleting a session when it's in creating or using state, and use spin
> lock to protect the session state.

Thanks for sending in the patch. I did see it the first time you posted it,
I just haven't had time to digest it fully, sorry for not responding
earlier.

Does the fsl_p4080 have any HW acceleration underneath cryptosoft or are
you using purely software acceleration ?

The patch looks pretty good,  but it would help me a lot if you could
describe what kind of re-entry/call sequence was causing the main problem.

Thanks,
Davidm




> diff -urbN ocf-linux-20120127/ocf/cryptosoft.c ocf-linux-20120127-1/ocf/cryptosoft.c
> --- ocf-linux-20120127/ocf/cryptosoft.c	2012-01-27 09:04:28.000000000 +0800
> +++ ocf-linux-20120127-1/ocf/cryptosoft.c	2013-01-30 12:41:25.554624164 +0800
> @@ -77,6 +77,11 @@
>  
>  #define SW_TYPE_INUSE		0x10000000
>  
> +#define SW_SESSION_IDLE				0x0
> +#define SW_SESSION_CREATION_IN_PROGRESS		0x1
> +#define SW_SESSION_IN_USE			0x2
> +#define SW_SESSION_DELETION_IN_PROGRESS		0x3
> +
>  /* We change some of the above if we have an async interface */
>  
>  #define SW_TYPE_ALG_AMASK	(SW_TYPE_ALG_MASK | SW_TYPE_ASYNC)
> @@ -91,6 +96,8 @@
>  	struct work_struct  workq;
>  	int					sw_type;
>  	int					sw_alg;
> +	int					sw_state;
> +	int					sw_ref;
>  	struct crypto_tfm	*sw_tfm;
>  	spinlock_t			sw_tfm_lock;
>  	union {
> @@ -283,6 +290,25 @@
>  MODULE_PARM_DESC(swcr_debug, "Enable debug");
>  
>  static void swcr_process_req(struct swcr_req *req);
> +static DEFINE_SPINLOCK(session_lock);
> +
> +static inline void _swcr_set_state(struct swcr_data *swd, int state, int lock)
> +{
> +	unsigned long flags;
> +	if( lock )
> +		spin_lock_irqsave(&session_lock, flags);
> +
> +	if (swd != NULL)
> +		swd->sw_state = state;
> +
> +	if ( lock )
> +		spin_unlock_irqrestore(&session_lock, flags);
> +}
> +
> +static inline void swcr_set_state(struct swcr_data *swd, int state)
> +{
> +	_swcr_set_state(swd, state, 0);
> +}
>  
>  /*
>   * somethings just need to be run with user context no matter whether
> @@ -339,14 +365,17 @@
>  swcr_newsession(device_t dev, u_int32_t *sid, struct cryptoini *cri)
>  {
>  	struct swcr_data **swd;
> -	u_int32_t i;
> +	u_int32_t index, i;
>  	int error;
>  	char *algo;
>  	int mode;
> +	unsigned long flags;
>  
> +	spin_lock_irqsave(&session_lock, flags);
>  	dprintk("%s()\n", __FUNCTION__);
>  	if (sid == NULL || cri == NULL) {
>  		dprintk("%s,%d - EINVAL\n", __FILE__, __LINE__);
> +		spin_unlock_irqrestore(&session_lock, flags);
>  		return EINVAL;
>  	}
>  
> @@ -372,6 +401,7 @@
>  			else
>  				swcr_sesnum /= 2;
>  			dprintk("%s,%d: ENOBUFS\n", __FILE__, __LINE__);
> +			spin_unlock_irqrestore(&session_lock, flags);
>  			return ENOBUFS;
>  		}
>  		memset(swd, 0, swcr_sesnum * sizeof(struct swcr_data *));
> @@ -386,30 +416,39 @@
>  		swcr_sessions = swd;
>  	}
>  
> -	swd = &swcr_sessions[i];
> -	*sid = i;
> +	index = i;
> +	swd = &swcr_sessions[index];
> +	*sid = index;
>  
>  	while (cri) {
>  		*swd = (struct swcr_data *) kmalloc(sizeof(struct swcr_data),
>  				SLAB_ATOMIC);
>  		if (*swd == NULL) {
> -			swcr_freesession(NULL, i);
> +			swcr_set_state(swcr_sessions[index], SW_SESSION_DELETION_IN_PROGRESS);
> +			spin_unlock_irqrestore(&session_lock, flags);
> +			swcr_freesession(NULL, index);
>  			dprintk("%s,%d: ENOBUFS\n", __FILE__, __LINE__);
>  			return ENOBUFS;
>  		}
>  		memset(*swd, 0, sizeof(struct swcr_data));
> +		swcr_set_state(*swd, SW_SESSION_CREATION_IN_PROGRESS);
> +		spin_unlock_irqrestore(&session_lock, flags);
>  
>  		if (cri->cri_alg < 0 ||
>  				cri->cri_alg>=sizeof(crypto_details)/sizeof(crypto_details[0])){
>  			printk("cryptosoft: Unknown algorithm 0x%x\n", cri->cri_alg);
> -			swcr_freesession(NULL, i);
> +			_swcr_set_state(swcr_sessions[index],
> +				SW_SESSION_DELETION_IN_PROGRESS, 1);
> +			swcr_freesession(NULL, index);
>  			return EINVAL;
>  		}
>  
>  		algo = crypto_details[cri->cri_alg].alg_name;
>  		if (!algo || !*algo) {
>  			printk("cryptosoft: Unsupported algorithm 0x%x\n", cri->cri_alg);
> -			swcr_freesession(NULL, i);
> +			_swcr_set_state(swcr_sessions[index],
> +				SW_SESSION_DELETION_IN_PROGRESS, 1);
> +			swcr_freesession(NULL, index);
>  			return EINVAL;
>  		}
>  
> @@ -450,7 +489,9 @@
>  						algo,mode);
>  				err = IS_ERR((*swd)->sw_tfm) ? -(PTR_ERR((*swd)->sw_tfm)) : EINVAL;
>  				(*swd)->sw_tfm = NULL; /* ensure NULL */
> -				swcr_freesession(NULL, i);
> +				_swcr_set_state(swcr_sessions[index],
> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
> +				swcr_freesession(NULL, index);
>  				return err;
>  			}
>  
> @@ -482,7 +523,9 @@
>  			if (error) {
>  				printk("cryptosoft: setkey failed %d (crt_flags=0x%x)\n", error,
>  						(*swd)->sw_tfm->crt_flags);
> -				swcr_freesession(NULL, i);
> +				_swcr_set_state(swcr_sessions[index],
> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
> +				swcr_freesession(NULL, index);
>  				return error;
>  			}
>  		} else if ((*swd)->sw_type & (SW_TYPE_HMAC | SW_TYPE_HASH)) {
> @@ -504,7 +547,9 @@
>  			if (!(*swd)->sw_tfm) {
>  				dprintk("cryptosoft: crypto_alloc_hash failed(%s,0x%x)\n",
>  						algo, mode);
> -				swcr_freesession(NULL, i);
> +				_swcr_set_state(swcr_sessions[index],
> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
> +				swcr_freesession(NULL, index);
>  				return EINVAL;
>  			}
>  
> @@ -512,7 +557,9 @@
>  			(*swd)->u.hmac.sw_key = (char *)kmalloc((*swd)->u.hmac.sw_klen,
>  					SLAB_ATOMIC);
>  			if ((*swd)->u.hmac.sw_key == NULL) {
> -				swcr_freesession(NULL, i);
> +				_swcr_set_state(swcr_sessions[index],
> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
> +				swcr_freesession(NULL, index);
>  				dprintk("%s,%d: ENOBUFS\n", __FILE__, __LINE__);
>  				return ENOBUFS;
>  			}
> @@ -532,24 +579,33 @@
>  			if (!(*swd)->sw_tfm) {
>  				dprintk("cryptosoft: crypto_alloc_comp failed(%s,0x%x)\n",
>  						algo, mode);
> -				swcr_freesession(NULL, i);
> +				_swcr_set_state(swcr_sessions[index],
> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
> +				swcr_freesession(NULL, index);
>  				return EINVAL;
>  			}
>  			(*swd)->u.sw_comp_buf = kmalloc(CRYPTO_MAX_DATA_LEN, SLAB_ATOMIC);
>  			if ((*swd)->u.sw_comp_buf == NULL) {
> -				swcr_freesession(NULL, i);
> +				_swcr_set_state(swcr_sessions[index],
> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
> +				swcr_freesession(NULL, index);
>  				dprintk("%s,%d: ENOBUFS\n", __FILE__, __LINE__);
>  				return ENOBUFS;
>  			}
>  		} else {
>  			printk("cryptosoft: Unhandled sw_type %d\n", (*swd)->sw_type);
> -			swcr_freesession(NULL, i);
> +			_swcr_set_state(swcr_sessions[index],
> +					SW_SESSION_DELETION_IN_PROGRESS, 1);
> +				swcr_freesession(NULL, index);
>  			return EINVAL;
>  		}
>  
>  		cri = cri->cri_next;
>  		swd = &((*swd)->sw_next);
> +		spin_lock_irqsave(&session_lock, flags);
>  	}
> +	swcr_set_state(swcr_sessions[index], SW_SESSION_IDLE);
> +	spin_unlock_irqrestore(&session_lock, flags);
>  	return 0;
>  }
>  
> @@ -559,22 +615,42 @@
>  static int
>  swcr_freesession(device_t dev, u_int64_t tid)
>  {
> +	unsigned long flags;
>  	struct swcr_data *swd;
>  	u_int32_t sid = CRYPTO_SESID2LID(tid);
>  
> +	spin_lock_irqsave(&session_lock, flags);
>  	dprintk("%s()\n", __FUNCTION__);
>  	if (sid > swcr_sesnum || swcr_sessions == NULL ||
>  			swcr_sessions[sid] == NULL) {
>  		dprintk("%s,%d: EINVAL\n", __FILE__, __LINE__);
> +		spin_unlock_irqrestore(&session_lock, flags);
>  		return(EINVAL);
>  	}
>  
>  	/* Silently accept and return */
> -	if (sid == 0)
> +	if (sid == 0) {
> +		spin_unlock_irqrestore(&session_lock, flags);
>  		return(0);
> +	}
>  
>  	while ((swd = swcr_sessions[sid]) != NULL) {
> +		if (swd->sw_state == SW_SESSION_IN_USE
> +			|| swd->sw_state == SW_SESSION_CREATION_IN_PROGRESS) {
> +			spin_unlock_irqrestore(&session_lock, flags);
> +			return EAGAIN;
> +		}
> +		/*
> +		 * If the session is to be deleted, it should all be deleted
> +		 * so mark it as unuseable.
> +		 * In fact, only the first swcr_data's state is used as the
> +		 * session state now, so just change it to mark the session
> +		 * as being delete
> +		 */
> +		swcr_set_state(swd, SW_SESSION_DELETION_IN_PROGRESS);
>  		swcr_sessions[sid] = swd->sw_next;
> +		swcr_set_state(swcr_sessions[sid], SW_SESSION_DELETION_IN_PROGRESS);
> +		spin_unlock_irqrestore(&session_lock, flags);
>  		if (swd->sw_tfm) {
>  			switch (swd->sw_type & SW_TYPE_ALG_AMASK) {
>  #ifdef HAVE_AHASH
> @@ -615,16 +691,18 @@
>  				kfree(swd->u.hmac.sw_key);
>  		}
>  		kfree(swd);
> +		spin_lock_irqsave(&session_lock, flags);
>  	}
> +	spin_unlock_irqrestore(&session_lock, flags);
>  	return 0;
>  }
>  
>  static void swcr_process_req_complete(struct swcr_req *req)
>  {
> +	unsigned long flags;
>  	dprintk("%s()\n", __FUNCTION__);
>  
>  	if (req->sw->sw_type & SW_TYPE_INUSE) {
> -		unsigned long flags;
>  		spin_lock_irqsave(&req->sw->sw_tfm_lock, flags);
>  		req->sw->sw_type &= ~SW_TYPE_INUSE;
>  		spin_unlock_irqrestore(&req->sw->sw_tfm_lock, flags);
> @@ -665,6 +743,12 @@
>  	}
>  
>  done:
> +	spin_lock_irqsave(&session_lock, flags);
> +	req->sw_head->sw_ref--;
> +	if (req->sw_head->sw_ref <= 0) {
> +		swcr_set_state(req->sw_head, SW_SESSION_IDLE);
> +	}
> +	spin_unlock_irqrestore(&session_lock, flags);
>  	dprintk("%s crypto_done %p\n", __FUNCTION__, req);
>  	crypto_done(req->crp);
>  	kmem_cache_free(swcr_req_cache, req);
> @@ -1162,6 +1246,7 @@
>  {
>  	struct swcr_req *req = NULL;
>  	u_int32_t lid;
> +	unsigned long flags;
>  
>  	dprintk("%s()\n", __FUNCTION__);
>  	/* Sanity check */
> @@ -1179,10 +1264,12 @@
>  	}
>  
>  	lid = crp->crp_sid & 0xffffffff;
> +	spin_lock_irqsave(&session_lock, flags);
>  	if (lid >= swcr_sesnum || lid == 0 || swcr_sessions == NULL ||
>  			swcr_sessions[lid] == NULL) {
>  		crp->crp_etype = ENOENT;
>  		dprintk("%s,%d: ENOENT\n", __FILE__, __LINE__);
> +		spin_unlock_irqrestore(&session_lock, flags);
>  		goto done;
>  	}
>  
> @@ -1195,6 +1282,7 @@
>  		if (skb_shinfo(skb)->nr_frags >= SCATTERLIST_MAX) {
>  			printk("%s,%d: %d nr_frags > SCATTERLIST_MAX", __FILE__, __LINE__,
>  					skb_shinfo(skb)->nr_frags);
> +			spin_unlock_irqrestore(&session_lock, flags);
>  			goto done;
>  		}
>  	} else if (crp->crp_flags & CRYPTO_F_IOV) {
> @@ -1202,6 +1290,7 @@
>  		if (uiop->uio_iovcnt > SCATTERLIST_MAX) {
>  			printk("%s,%d: %d uio_iovcnt > SCATTERLIST_MAX", __FILE__, __LINE__,
>  					uiop->uio_iovcnt);
> +			spin_unlock_irqrestore(&session_lock, flags);
>  			goto done;
>  		}
>  	}
> @@ -1213,11 +1302,24 @@
>  	if (req == NULL) {
>  		dprintk("%s,%d: ENOMEM\n", __FILE__, __LINE__);
>  		crp->crp_etype = ENOMEM;
> +		spin_unlock_irqrestore(&session_lock, flags);
>  		goto done;
>  	}
>  	memset(req, 0, sizeof(*req));
>  
>  	req->sw_head = swcr_sessions[lid];
> +	if (req->sw_head->sw_state == SW_SESSION_DELETION_IN_PROGRESS) {
> +		crp->crp_etype = EINVAL;
> +		spin_unlock_irqrestore(&session_lock, flags);
> +		goto done;
> +	} else if (req->sw_head->sw_state == SW_SESSION_CREATION_IN_PROGRESS) {
> +		crp->crp_etype = EAGAIN;
> +		spin_unlock_irqrestore(&session_lock, flags);
> +		goto done;
> +	}
> +	swcr_set_state(req->sw_head, SW_SESSION_IN_USE);
> +	req->sw_head->sw_ref++;
> +	spin_unlock_irqrestore(&session_lock, flags);
>  	req->crp = crp;
>  	req->crd = crp->crp_desc;
>  
> 

> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service 
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

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


-- 
David McCullough,  da...@sp...,   Ph: 0410 560 763

[Ocf-linux-users] patch for OCF

[hwang7 <hua...@wi...>]

Hi david

When using cryptosoft of OCF to do the crypto and run test scripts which 
includes the following commands on SMP platform(we do the test on 
fsl_p4080 which is a SMP processor with 8 cores):

$ openssl speed -evp des -engine cryptodev -elapsed -multi 10
$ openssl speed -evp des3 -engine cryptodev -elapsed -multi 10
$ openssl speed -evp aes128 -engine cryptodev -elapsed -multi 10

The system will give out call trace or hang.

The root causes of this issue is:
The swcr_sessions is not protected properly, and the three
types of session operation "create session, use session, delete
session" are also not protected properly.

So:
1.add spin lock to protect swcr_sessions
2.add state/ref fields to session, use session state to prevent from
deleting a session when it's in creating or using state, and use spin
lock to protect the session state.


-- 
Best Regards
========================
Wang Huanhuan
Work phone:  +86-10-8477-8568

[Ocf-linux-users] Memory leak observed in cryptodev

[anand r. <one...@ya...>]

Hi,

I have implemented an OCF-driver for our crypto Hardware.

For initial testing I have just registered call backs for OCF like below.

        DEVMETHOD(cryptodev_newsession, xxx_newsession),
        DEVMETHOD(cryptodev_freesession,xxx_freesession),
        DEVMETHOD(cryptodev_process,    xxx_process),
        DEVMETHOD(cryptodev_kprocess,   xxx_kprocess),

But I am returning at the very beginning of callbacks xxx_newsession() and xxx_processs() without doing any operation by "return (EINVAL);"
So when I return like these the crypto operations supposed to be fallback to cryptosoft.


Now I am running this driver on two boards, on the first board I am running a TLS server (using openssl s_server -tls1)

and on the second board I am running TLS client (using openssl s_client -tls1) 


on both boards the crypto operations which are passed to OCF through OpenSSL will be offloaded to crypto Hardware but since I am returning immediately at xxx_newsession() with
error value, the crypto operation should get fallback to cryptosoft.

But when I do this I am observing a memory leak in the system. I have taken the memory usage details before starting the test and continuously observed memory usage till the duration of test,
using "cat /proc/meminfo" command.

Please give some suggestions on what could be going wrong.


Best Regards,
Anand

[Ocf-linux-users] OCF performance: any better way than using copy_from_user() and copy_to_user()?

[Zhou, B. <b-...@ti...>]

Hello,
We are using OCF on top of HW crypto drivers which are implemented as Linux struct crypto_alg and registered via crypto_register_alg().
OCF cryptosoft is used as a bridge between OCF and Linux crypto APIs. Using this infrastructure, we expect the crypto will not take too much CPU load since crypto is done by the HW, but it looks like CPU load is higher than what we expected. Our typical data size is ~1500 bytes.
Did anybody have similar CPU load concern using OCF? We are wondering if avoid using copy_from_user() and copy_to_user() in cryptodev.c will help improve the performance. If anybody can share experience or suggestions on this, it will be highly appreciated.

Thanks a lot,
Bin

Re: [Ocf-linux-users] ocf/random.c uses kernel_thread symbol no longer exported

[Russell S. <ru...@pe...>]

>>>>> "David" == David McCullough <uc...@gm...> writes:

David> Russell Senior wrote the following:
>>  This past autumn, the long-advertised removal of
>> EXPORT_SYMBOL(kernel_thread) finally occurred.  Linux 3.7.x no
>> longer exports the symbol, which causes ocf/random.c to not build.
>> Needs converting to kthread_$foo.

David> Thanksd for the update, will look into that as soon as I get
David> time, for now if you are stuck just turn off the OCF random
David> option,

I'm sure this is both horrid and ignorant, but I hacked at it enough
to compile.  This is what got commited in OpenWrt.  Possibly it will
kernel panic if the instruction pointer wanders too nearby:


Index: ocf/random.c
===================================================================
--- a/ocf/random.c
+++ b/ocf/random.c
@@ -50,4 +50,5 @@
 #include <linux/poll.h>
 #include <linux/random.h>
+#include <linux/kthread.h>
 #include <cryptodev.h>
 
@@ -80,7 +81,7 @@
 };
 
+static struct task_struct *random_thread;
 static int random_proc(void *arg);
 
-static pid_t		randomproc = (pid_t) -1;
 static spinlock_t	random_lock;
 
@@ -142,10 +143,8 @@
 	list_add_tail(&rops->random_list, &random_ops);
 	if (!started) {
-		randomproc = kernel_thread(random_proc, NULL, CLONE_FS|CLONE_FILES);
-		if (randomproc < 0) {
-			ret = randomproc;
-			printk("crypto: crypto_rregister cannot start random thread; "
-					"error %d", ret);
-		} else
+		random_thread = kthread_run(random_proc, NULL, "ocf-random");
+		if (IS_ERR(random_thread))
+			ret = PTR_ERR(random_thread);
+		else
 			started = 1;
 	}
@@ -173,5 +172,5 @@
 	spin_lock_irqsave(&random_lock, flags);
 	if (list_empty(&random_ops) && started)
-		kill_proc(randomproc, SIGKILL, 1);
+		kthread_stop(random_thread);
 	spin_unlock_irqrestore(&random_lock, flags);
 	return(0);
@@ -204,5 +203,4 @@
 #else
 	daemonize("ocf-random");
-	allow_signal(SIGKILL);
 #endif
 
@@ -307,10 +305,9 @@
 		}
 	}
-	
+
 	kfree(buf);
 
 bad_alloc:
 	spin_lock_irq(&random_lock);
-	randomproc = (pid_t) -1;
 	started = 0;
 	spin_unlock_irq(&random_lock);


-- 
Russell Senior, President
ru...@pe...

Re: [Ocf-linux-users] ocf/random.c uses kernel_thread symbol no longer exported

[David M. <uc...@gm...>]

Russell Senior wrote the following:
> 
> This past autumn, the long-advertised removal of
> EXPORT_SYMBOL(kernel_thread) finally occurred.  Linux 3.7.x no longer
> exports the symbol, which causes ocf/random.c to not build.  Needs
> converting to kthread_$foo.

Thanksd for the update,  will look into  that as soon as I get time,
for now if you are stuck just turn off the OCF random option,

Cheers,
Davidm

-- 
David McCullough,  da...@sp...,   Ph: 0410 560 763

[Ocf-linux-users] ocf/random.c uses kernel_thread symbol no longer exported

[Russell S. <ru...@pe...>]

This past autumn, the long-advertised removal of
EXPORT_SYMBOL(kernel_thread) finally occurred.  Linux 3.7.x no longer
exports the symbol, which causes ocf/random.c to not build.  Needs
converting to kthread_$foo.


-- 
Russell Senior, President
ru...@pe...

Re: [Ocf-linux-users] ocf seem not working

[David M. <uc...@gm...>]

Stefan Kuhne wrote the following:
> Am 26.12.2012 23:55, schrieb David McCullough:
> 
> Hallo,
> 
> > The -d option selects from OCF drivers.
> > 
> > If you have an OCF driver or a linux driver (that can be used via
> > cryptosoft),  then you can use if with OCF.
>
> ah, ok.
> I use cryptosoft with geode-aes.

That should still be fairly fast I think.

> > I haven't seen any mention of using the crypto in a WLAN card.
> > Depending on how the API looks for this device it just might not be
> > possible,
>
> It was a idea but it seems, that SMB has 2,5MByte/s in all configs.

Yeah,  the geode doesn't do anything but aes/sha IIRC,

Cheers,
Davidm

-- 
David McCullough,  da...@sp...,   Ph: 0410 560 763

Re: [Ocf-linux-users] ocf seem not working

[Stefan K. <ste...@gm...>]

Am 26.12.2012 23:55, schrieb David McCullough:

Hallo,

> The -d option selects from OCF drivers.
> 
> If you have an OCF driver or a linux driver (that can be used via
> cryptosoft),  then you can use if with OCF.
> 
ah, ok.
I use cryptosoft with geode-aes.

> I haven't seen any mention of using the crypto in a WLAN card.
> Depending on how the API looks for this device it just might not be
> possible,
> 
It was a idea but it seems, that SMB has 2,5MByte/s in all configs.

Thanks for your help and regards,
Stefan Kuhne

Re: [Ocf-linux-users] ocf seem not working

[David M. <uc...@gm...>]

Stefan Kuhne wrote the following:
> Am 15.12.2012 15:06, schrieb Stefan Kuhne:
> 
> Hello,
> 
> > I don't know if I told it. It's a board like Alix with AMD Geode CPU.
> > 
> when I turn off my Atheros WLAN (with unload modules) I get 2.5 MByte/s
> over SMB.
> 
> PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
> 5580     1 root     R     2848  1.1   0 86.0 openvpn --config
> /etc/openvpn/Bloebl.conf --daemon openvpn-Bloebl --management-hold
> 1470     2 root     SW       0  0.0   0  6.6 [ocf_0]
> 
> Could ocf use the AES engine of my Atheros WLAN card?
> cryptotest has an option "-d". Where can I get the possibly devices?
> Is there a defined module load order?

The -d option selects from OCF drivers.

If you have an OCF driver or a linux driver (that can be used via
cryptosoft),  then you can use if with OCF.

I haven't seen any mention of using the crypto in a WLAN card.
Depending on how the API looks for this device it just might not be
possible,

Cheers,
Davidm

-- 
David McCullough,  da...@sp...,   Ph: 0410 560 763

Re: [Ocf-linux-users] ocf seem not working

[Stefan K. <ste...@gm...>]

Am 15.12.2012 15:06, schrieb Stefan Kuhne:

Hello,

> I don't know if I told it. It's a board like Alix with AMD Geode CPU.
> 
when I turn off my Atheros WLAN (with unload modules) I get 2.5 MByte/s
over SMB.

PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
5580     1 root     R     2848  1.1   0 86.0 openvpn --config
/etc/openvpn/Bloebl.conf --daemon openvpn-Bloebl --management-hold
1470     2 root     SW       0  0.0   0  6.6 [ocf_0]

Could ocf use the AES engine of my Atheros WLAN card?
cryptotest has an option "-d". Where can I get the possibly devices?
Is there a defined module load order?

Regards,
Stefan Kuhne

Re: [Ocf-linux-users] ocf seem not working

[Stefan K. <ste...@gm...>]

Am 15.12.2012 14:54, schrieb David McCullough:

Hallo,

> Whats the difference in CPU usage ?  Not sure why you cannot get 100% CPU
> though,
> 
it is at 100% total.
When I use ocf I've round about 20% usage of ocf_0.

An example with another tunnel:
 5243     1 root     R     2760  1.1   0 59.7 openvpn --config
/etc/openvpn/WebSpace.conf --daemon openvpn-WebSpace --management-hold
  622     2 root     SW       0  0.0   0  3.9 [ocf_0]
There I get 1,5MByte/s, but I don't how how fast is the other site.

I don't know if I told it. It's a board like Alix with AMD Geode CPU.

Regards,
Stefan Kuhne

Re: [Ocf-linux-users] ocf seem not working

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

Jivin Stefan Kuhne lays it down ...
> Am 15.12.2012 03:06, schrieb Stefan Kuhne:
> 
> Hello,
> 
> > I've made some tests with iperf.
> > With openVPN over LAN I get 17Mbit/s with AES-128-CBC and SHA1, with
> > AES-128-CBC and without auth I get 22Mbit/s.
> 
> I've forgot something.
> Without ocf I get 15Mbit/s.

Whats the difference in CPU usage ?  Not sure why you cannot get 100% CPU
though,

Cheers,
Davidm

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

Re: [Ocf-linux-users] ocf seem not working

[Stefan K. <ste...@gm...>]

Am 15.12.2012 03:06, schrieb Stefan Kuhne:

Hello,

> I've made some tests with iperf.
> With openVPN over LAN I get 17Mbit/s with AES-128-CBC and SHA1, with
> AES-128-CBC and without auth I get 22Mbit/s.

I've forgot something.
Without ocf I get 15Mbit/s.

Regards,
Stefan Kuhne

Re: [Ocf-linux-users] ocf seem not working

[Stefan K. <ste...@gm...>]

Hello,

I've made some tests with iperf.
With openVPN over LAN I get 17Mbit/s with AES-128-CBC and SHA1, with
AES-128-CBC and without auth I get 22Mbit/s.
My CPU load ist at 100%.

What tells /proc/crypto?

I get:
Guardian 3.9.0-rev24506 # cat /proc/crypto
name         : cbc(aes)
driver       : cbc(geode-aes)
module       : cbc
priority     : 300
refcnt       : 9
selftest     : passed
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : cbc(aes)
driver       : cbc-aes-geode
module       : kernel
priority     : 400
refcnt       : 9
selftest     : passed
type         : givcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : chainiv

name         : ecb(arc4)
driver       : ecb(arc4-generic)
module       : ecb
priority     : 0
refcnt       : 1
selftest     : passed
type         : blkcipher
blocksize    : 1
min keysize  : 1
max keysize  : 256
ivsize       : 0
geniv        : <default>

name         : ecb(arc4)
driver       : ecb(arc4)-generic
module       : arc4
priority     : 100
refcnt       : 1
selftest     : passed
type         : blkcipher
blocksize    : 1
min keysize  : 1
max keysize  : 256
ivsize       : 0
geniv        : <default>

name         : arc4
driver       : arc4-generic
module       : arc4
priority     : 0
refcnt       : 3
selftest     : passed
type         : cipher
blocksize    : 1
min keysize  : 1
max keysize  : 256

name         : cbc(aes)
driver       : cbc-aes-geode
module       : geode_aes
priority     : 400
refcnt       : 9
selftest     : passed
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : ecb(aes)
driver       : ecb-aes-geode
module       : geode_aes
priority     : 400
refcnt       : 1
selftest     : passed
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 0
geniv        : <default>

name         : aes
driver       : geode-aes
module       : geode_aes
priority     : 300
refcnt       : 12
selftest     : passed
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : aes
driver       : aes-asm
module       : aes_i586
priority     : 200
refcnt       : 12
selftest     : passed
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : aes
driver       : aes-generic
module       : aes_generic
priority     : 100
refcnt       : 1
selftest     : passed
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : stdrng
driver       : krng
module       : kernel
priority     : 200
refcnt       : 2
selftest     : passed
type         : rng
seedsize     : 0

name         : md5
driver       : md5-generic
module       : kernel
priority     : 0
refcnt       : 1
selftest     : passed
type         : shash
blocksize    : 64
digestsize   : 16

Guardian 3.9.0-rev24506 #

dmesg tells my this with cryptosoft debug:
swcr_process()
swcr_process_req()
crypto OP success 0
swcr_process_req_complete()
swcr_process_req_complete crypto_done ccb23e00

Regards,
Stefan Kuhne

Re: [Ocf-linux-users] ocf seem not working

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

Jivin Stefan Kuhne lays it down ...
> Am 12.12.2012 01:24, schrieb David McCullough:
> 
> Hello,
> 
> > That looks right to me.  You can tell you are using HW crypto because the
> > speed throughput increases significantly with the  packet size.  Unfortunately
> > passing data to the kernel and back for crypto is not ideal :-(
> > 
> but I gt with and without "-engine cryptodev" the same result:

Ok,  I wasn't sure you were seeing that.  I was pretty sure that cryptodev
will be used by default these days (old versions didn't do this).

Specifying it makes sure yuo have the best chance ;-)

Cheers,
Davidm

> 
> Guardian 3.9.0-rev24485 # openssl speed -engine cryptodev -evp aes128
> -elapsed
> engine "cryptodev" set.
> You have chosen to measure elapsed time instead of user CPU time.
> Doing aes-128-cbc for 3s on 16 size blocks: 111539 aes-128-cbc's in 3.02s
> Doing aes-128-cbc for 3s on 64 size blocks: 103749 aes-128-cbc's in 3.01s
> Doing aes-128-cbc for 3s on 256 size blocks: 98841 aes-128-cbc's in 3.02s
> Doing aes-128-cbc for 3s on 1024 size blocks: 62480 aes-128-cbc's in 3.02s
> Doing aes-128-cbc for 3s on 8192 size blocks: 15896 aes-128-cbc's in 3.02s
> OpenSSL 1.0.0j 10 May 2012
> built on: date not available
> options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial)
> blowfish(ptr)
> compiler: i586-unknown-linux-uclibc-gcc -fPIC -DOPENSSL_PIC
> -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -DTERMIO  -pipe -Os -g2 -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fno-unwind-tables
> -fno-asynchronous-unwind-tables -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
> -fomit-frame-pointer -Wall
> The 'numbers' are in 1000s of bytes per second processed.
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> bytes
> aes-128-cbc        590.94k     2205.96k     8378.57k    21185.27k
> 43119.22k
> Guardian 3.9.0-rev24485 # openssl speed -evp aes128 -elapsed
> You have chosen to measure elapsed time instead of user CPU time.
> Doing aes-128-cbc for 3s on 16 size blocks: 113714 aes-128-cbc's in 3.01s
> Doing aes-128-cbc for 3s on 64 size blocks: 111686 aes-128-cbc's in 3.01s
> Doing aes-128-cbc for 3s on 256 size blocks: 93473 aes-128-cbc's in 3.01s
> Doing aes-128-cbc for 3s on 1024 size blocks: 65328 aes-128-cbc's in 3.01s
> Doing aes-128-cbc for 3s on 8192 size blocks: 15566 aes-128-cbc's in 3.01s
> OpenSSL 1.0.0j 10 May 2012
> built on: date not available
> options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial)
> blowfish(ptr)
> compiler: i586-unknown-linux-uclibc-gcc -fPIC -DOPENSSL_PIC
> -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -DTERMIO  -pipe -Os -g2 -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fno-unwind-tables
> -fno-asynchronous-unwind-tables -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
> -fomit-frame-pointer -Wall
> The 'numbers' are in 1000s of bytes per second processed.
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> bytes
> aes-128-cbc        604.46k     2374.72k     7949.86k    22224.54k
> 42364.34k
> Guardian 3.9.0-rev24485 #
> 
> Is this option obsolete?
> 
> Regards,
> Stefan Kuhne
> 
> 
> 

> Content-Type: multipart/signed; micalg=pgp-sha1;
> 	protocol="application/pgp-signature";
> 	boundary="------------enig5ABF492CECA018A510CB137F"
> 
> --------------enig5ABF492CECA018A510CB137F
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> Am 12.12.2012 01:24, schrieb David McCullough:
> 
> Hello,
> 
> > That looks right to me.  You can tell you are using HW crypto because t=
> he
> > speed throughput increases significantly with the  packet size.  Unfort=
> unately
> > passing data to the kernel and back for crypto is not ideal :-(
> >=20
> but I gt with and without "-engine cryptodev" the same result:
> 
> Guardian 3.9.0-rev24485 # openssl speed -engine cryptodev -evp aes128
> -elapsed
> engine "cryptodev" set.
> You have chosen to measure elapsed time instead of user CPU time.
> Doing aes-128-cbc for 3s on 16 size blocks: 111539 aes-128-cbc's in 3.02s=
> 
> Doing aes-128-cbc for 3s on 64 size blocks: 103749 aes-128-cbc's in 3.01s=
> 
> Doing aes-128-cbc for 3s on 256 size blocks: 98841 aes-128-cbc's in 3.02s=
> 
> Doing aes-128-cbc for 3s on 1024 size blocks: 62480 aes-128-cbc's in 3.02=
> s
> Doing aes-128-cbc for 3s on 8192 size blocks: 15896 aes-128-cbc's in 3.02=
> s
> OpenSSL 1.0.0j 10 May 2012
> built on: date not available
> options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial)
> blowfish(ptr)
> compiler: i586-unknown-linux-uclibc-gcc -fPIC -DOPENSSL_PIC
> -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -DTERMIO  -pipe -Os -g2 -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=3D64 -fno-unwind-tables
> -fno-asynchronous-unwind-tables -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
> -fomit-frame-pointer -Wall
> The 'numbers' are in 1000s of bytes per second processed.
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> bytes
> aes-128-cbc        590.94k     2205.96k     8378.57k    21185.27k
> 43119.22k
> Guardian 3.9.0-rev24485 # openssl speed -evp aes128 -elapsed
> You have chosen to measure elapsed time instead of user CPU time.
> Doing aes-128-cbc for 3s on 16 size blocks: 113714 aes-128-cbc's in 3.01s=
> 
> Doing aes-128-cbc for 3s on 64 size blocks: 111686 aes-128-cbc's in 3.01s=
> 
> Doing aes-128-cbc for 3s on 256 size blocks: 93473 aes-128-cbc's in 3.01s=
> 
> Doing aes-128-cbc for 3s on 1024 size blocks: 65328 aes-128-cbc's in 3.01=
> s
> Doing aes-128-cbc for 3s on 8192 size blocks: 15566 aes-128-cbc's in 3.01=
> s
> OpenSSL 1.0.0j 10 May 2012
> built on: date not available
> options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial)
> blowfish(ptr)
> compiler: i586-unknown-linux-uclibc-gcc -fPIC -DOPENSSL_PIC
> -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -DTERMIO  -pipe -Os -g2 -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=3D64 -fno-unwind-tables
> -fno-asynchronous-unwind-tables -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
> -fomit-frame-pointer -Wall
> The 'numbers' are in 1000s of bytes per second processed.
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> bytes
> aes-128-cbc        604.46k     2374.72k     7949.86k    22224.54k
> 42364.34k
> Guardian 3.9.0-rev24485 #
> 
> Is this option obsolete?
> 
> Regards,
> Stefan Kuhne
> 
> 
> 
> --------------enig5ABF492CECA018A510CB137F
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: OpenPGP digital signature
> Content-Disposition: attachment; filename="signature.asc"
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
> 
> iQEcBAEBAgAGBQJQyMZpAAoJEFLNPgL3IBVXCjAH/RmEOfoyV5LC+jrHRSeqYtXO
> KwWX16Z1eSp85IqK8HlL9xA/QhrHvrvFKZNbmu7IPIFSuLdNxLrqteq5vGNU9kcl
> BRgkJmhSZK5Mjd7yLWwNccFcyhP/buR0f+H5drfPesDybRTyDwASdWmw6oRAuU3c
> 6UrPoBomx7n0rt45OgYHV6+CUglv7Urb6Jzr08plWmreayFhvajQTMVLBXf6cOIN
> RIS7ewgLpmXo8ZXtruXo59KQOQ3GvU5HKa3hGXLWYZfKud84l+ZKP7U4WYKmzHgK
> hSHmO6AJ/2Bux83kWBvd9QYuTOYO+Wu6BXtvf9MPNMsLvnvspkATeD0TLVPv57c=
> =lt03
> -----END PGP SIGNATURE-----
> 
> --------------enig5ABF492CECA018A510CB137F--


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

Re: [Ocf-linux-users] ocf seem not working

[Stefan K. <ste...@gm...>]

Am 12.12.2012 01:24, schrieb David McCullough:

Hello,

> That looks right to me.  You can tell you are using HW crypto because the
> speed throughput increases significantly with the  packet size.  Unfortunately
> passing data to the kernel and back for crypto is not ideal :-(
> 
but I gt with and without "-engine cryptodev" the same result:

Guardian 3.9.0-rev24485 # openssl speed -engine cryptodev -evp aes128
-elapsed
engine "cryptodev" set.
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 111539 aes-128-cbc's in 3.02s
Doing aes-128-cbc for 3s on 64 size blocks: 103749 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 256 size blocks: 98841 aes-128-cbc's in 3.02s
Doing aes-128-cbc for 3s on 1024 size blocks: 62480 aes-128-cbc's in 3.02s
Doing aes-128-cbc for 3s on 8192 size blocks: 15896 aes-128-cbc's in 3.02s
OpenSSL 1.0.0j 10 May 2012
built on: date not available
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial)
blowfish(ptr)
compiler: i586-unknown-linux-uclibc-gcc -fPIC -DOPENSSL_PIC
-DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -DTERMIO  -pipe -Os -g2 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fno-unwind-tables
-fno-asynchronous-unwind-tables -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
-fomit-frame-pointer -Wall
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
bytes
aes-128-cbc        590.94k     2205.96k     8378.57k    21185.27k
43119.22k
Guardian 3.9.0-rev24485 # openssl speed -evp aes128 -elapsed
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 113714 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 64 size blocks: 111686 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 256 size blocks: 93473 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 1024 size blocks: 65328 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 8192 size blocks: 15566 aes-128-cbc's in 3.01s
OpenSSL 1.0.0j 10 May 2012
built on: date not available
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial)
blowfish(ptr)
compiler: i586-unknown-linux-uclibc-gcc -fPIC -DOPENSSL_PIC
-DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -DTERMIO  -pipe -Os -g2 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fno-unwind-tables
-fno-asynchronous-unwind-tables -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
-fomit-frame-pointer -Wall
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
bytes
aes-128-cbc        604.46k     2374.72k     7949.86k    22224.54k
42364.34k
Guardian 3.9.0-rev24485 #

Is this option obsolete?

Regards,
Stefan Kuhne

Re: [Ocf-linux-users] ocf seem not working

[Stefan K. <ste...@gm...>]

Am 11.12.2012 16:56, schrieb Stefan Kuhne:

Hello,

> Next step is to rebuild kernel with debug.
> 
anything else use ocf already.
So dmesg is full with debug output even I doesn't run anything.

Regards,
Stefan Kuhne

Re: [Ocf-linux-users] ocf seem not working

[Stefan K. <ste...@gm...>]

Am 06.12.2012 13:15, schrieb David McCullough:

Hello,

I've found some time for testing:

Guardian 3.9.0-rev24485 # ./cryptotest -z
   0.000 sec,       2    aes crypts,      16 bytes,   340426 byte/sec,
   2.6 Mb/sec
   0.000 sec,       2    aes crypts,      32 bytes,   800000 byte/sec,
   6.1 Mb/sec
   0.000 sec,       2    aes crypts,      64 bytes,  1641026 byte/sec,
  12.5 Mb/sec
   0.000 sec,       2    aes crypts,     128 bytes,  3084337 byte/sec,
  23.5 Mb/sec
   0.000 sec,       2    aes crypts,     256 bytes,  6023529 byte/sec,
  46.0 Mb/sec
   0.000 sec,       2    aes crypts,     512 bytes, 10343434 byte/sec,
  78.9 Mb/sec
   0.000 sec,       2    aes crypts,    1024 bytes, 17808696 byte/sec,
 135.9 Mb/sec
   0.000 sec,       2    aes crypts,    2048 bytes, 25283951 byte/sec,
 192.9 Mb/sec
   0.000 sec,       2    aes crypts,    4096 bytes, 34565401 byte/sec,
 263.7 Mb/sec
   0.000 sec,       2    aes crypts,    8192 bytes, 38370023 byte/sec,
 292.7 Mb/sec
   0.001 sec,       2    aes crypts,   16384 bytes, 39479518 byte/sec,
 301.2 Mb/sec
   0.002 sec,       2    aes crypts,   32768 bytes, 43343915 byte/sec,
 330.7 Mb/sec
   0.005 sec,       2    aes crypts,   65280 bytes, 26693928 byte/sec,
 203.7 Mb/sec
   0.000 sec,       2 aes192 crypts,      16 bytes,   280702 byte/sec,
   2.1 Mb/sec
   0.000 sec,       2 aes192 crypts,      32 bytes,   659794 byte/sec,
   5.0 Mb/sec
   0.000 sec,       2 aes192 crypts,      64 bytes,  1142857 byte/sec,
   8.7 Mb/sec
   0.001 sec,       2 aes192 crypts,     128 bytes,   257028 byte/sec,
   2.0 Mb/sec
   0.000 sec,       2 aes192 crypts,     256 bytes,  2694737 byte/sec,
  20.6 Mb/sec
   0.000 sec,       2 aes192 crypts,     512 bytes,  3835206 byte/sec,
  29.3 Mb/sec
   0.000 sec,       2 aes192 crypts,    1024 bytes,  5550136 byte/sec,
  42.3 Mb/sec
   0.001 sec,       2 aes192 crypts,    2048 bytes,  6470774 byte/sec,
  49.4 Mb/sec
   0.001 sec,       2 aes192 crypts,    4096 bytes,  6895623 byte/sec,
  52.6 Mb/sec
   0.002 sec,       2 aes192 crypts,    8192 bytes,  7098787 byte/sec,
  54.2 Mb/sec
   0.005 sec,       2 aes192 crypts,   16384 bytes,  7170241 byte/sec,
  54.7 Mb/sec
   0.009 sec,       2 aes192 crypts,   32768 bytes,  7323276 byte/sec,
  55.9 Mb/sec
   0.018 sec,       2 aes192 crypts,   65280 bytes,  7177176 byte/sec,
  54.8 Mb/sec
   0.000 sec,       2 aes256 crypts,      16 bytes,   296296 byte/sec,
   2.3 Mb/sec
   0.000 sec,       2 aes256 crypts,      32 bytes,   640000 byte/sec,
   4.9 Mb/sec
   0.000 sec,       2 aes256 crypts,      64 bytes,  1219048 byte/sec,
   9.3 Mb/sec
   0.000 sec,       2 aes256 crypts,     128 bytes,  1969231 byte/sec,
  15.0 Mb/sec
   0.000 sec,       2 aes256 crypts,     256 bytes,  3180124 byte/sec,
  24.3 Mb/sec
   0.000 sec,       2 aes256 crypts,     512 bytes,  4112450 byte/sec,
  31.4 Mb/sec
   0.000 sec,       2 aes256 crypts,    1024 bytes,  5211196 byte/sec,
  39.8 Mb/sec
   0.001 sec,       2 aes256 crypts,    2048 bytes,  5801700 byte/sec,
  44.3 Mb/sec
   0.001 sec,       2 aes256 crypts,    4096 bytes,  6229658 byte/sec,
  47.5 Mb/sec
   0.003 sec,       2 aes256 crypts,    8192 bytes,  6387524 byte/sec,
  48.7 Mb/sec
   0.005 sec,       2 aes256 crypts,   16384 bytes,  6405004 byte/sec,
  48.9 Mb/sec
   0.010 sec,       2 aes256 crypts,   32768 bytes,  6506751 byte/sec,
  49.6 Mb/sec
   0.020 sec,       2 aes256 crypts,   65280 bytes,  6477476 byte/sec,
  49.4 Mb/sec
   0.000 sec,       2   arc4 crypts,       8 bytes,   137931 byte/sec,
   1.1 Mb/sec
   0.000 sec,       2   arc4 crypts,      16 bytes,   329897 byte/sec,
   2.5 Mb/sec
   0.000 sec,       2   arc4 crypts,      32 bytes,   609524 byte/sec,
   4.7 Mb/sec
   0.000 sec,       2   arc4 crypts,      64 bytes,  1242718 byte/sec,
   9.5 Mb/sec
   0.000 sec,       2   arc4 crypts,     128 bytes,  2133333 byte/sec,
  16.3 Mb/sec
   0.000 sec,       2   arc4 crypts,     256 bytes,  3764706 byte/sec,
  28.7 Mb/sec
   0.000 sec,       2   arc4 crypts,     512 bytes,  5657459 byte/sec,
  43.2 Mb/sec
   0.000 sec,       2   arc4 crypts,    1024 bytes,  7937984 byte/sec,
  60.6 Mb/sec
   0.000 sec,       2   arc4 crypts,    2048 bytes,  9547786 byte/sec,
  72.8 Mb/sec
   0.001 sec,       2   arc4 crypts,    4096 bytes, 10908123 byte/sec,
  83.2 Mb/sec
   0.001 sec,       2   arc4 crypts,    8192 bytes, 11252747 byte/sec,
  85.9 Mb/sec
   0.003 sec,       2   arc4 crypts,   16384 bytes, 11770115 byte/sec,
  89.8 Mb/sec
   0.005 sec,       2   arc4 crypts,   32768 bytes, 12109387 byte/sec,
  92.4 Mb/sec
   0.011 sec,       2   arc4 crypts,   65280 bytes, 12146246 byte/sec,
  92.7 Mb/sec
   0.000 sec,       1    md5 crypts,       8 bytes,   135593 byte/sec,
   1.0 Mb/sec
   0.000 sec,       1    md5 crypts,      16 bytes,   340426 byte/sec,
   2.6 Mb/sec
   0.000 sec,       1    md5 crypts,      32 bytes,   603774 byte/sec,
   4.6 Mb/sec
   0.000 sec,       1    md5 crypts,      64 bytes,  1280000 byte/sec,
   9.8 Mb/sec
   0.000 sec,       1    md5 crypts,     128 bytes,  2245614 byte/sec,
  17.1 Mb/sec
   0.000 sec,       1    md5 crypts,     256 bytes,  4654545 byte/sec,
  35.5 Mb/sec
   0.000 sec,       1    md5 crypts,     512 bytes,  7420290 byte/sec,
  56.6 Mb/sec
   0.000 sec,       1    md5 crypts,    1024 bytes, 13298701 byte/sec,
 101.5 Mb/sec
   0.000 sec,       1    md5 crypts,    2048 bytes, 17808696 byte/sec,
 135.9 Mb/sec
   0.000 sec,       1    md5 crypts,    4096 bytes, 24236686 byte/sec,
 184.9 Mb/sec
   0.000 sec,       1    md5 crypts,    8192 bytes, 26425806 byte/sec,
 201.6 Mb/sec
   0.001 sec,       1    md5 crypts,   16384 bytes, 29414722 byte/sec,
 224.4 Mb/sec
   0.001 sec,       1    md5 crypts,   32768 bytes, 30854991 byte/sec,
 235.4 Mb/sec
   0.002 sec,       1    md5 crypts,   65280 bytes, 31984321 byte/sec,
 244.0 Mb/sec
Guardian 3.9.0-rev24485 #

This seams to be good.

> 	openssl speed -engine cryptodev -evp aes128 -elapsed
> 
Guardian 3.9.0-rev24485 # openssl speed -engine cryptodev -evp aes128
-elapsed
engine "cryptodev" set.
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 114524 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 64 size blocks: 103451 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 256 size blocks: 96658 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 1024 size blocks: 59689 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 8192 size blocks: 15119 aes-128-cbc's in 3.01s
OpenSSL 1.0.0j 10 May 2012
built on: date not available
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial)
blowfish(ptr)
compiler: i586-unknown-linux-uclibc-gcc -fPIC -DOPENSSL_PIC
-DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -DTERMIO  -pipe -Os -g2 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fno-unwind-tables
-fno-asynchronous-unwind-tables -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
-fomit-frame-pointer -Wall
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
bytes
aes-128-cbc        608.77k     2199.62k     8220.75k    20306.16k
41147.79k
Guardian 3.9.0-rev24485 #

This doesn't lock so good.

Next step is to rebuild kernel with debug.

Regards,
Stefan Kuhne

Re: [Ocf-linux-users] ocf seem not working

[Stefan K. <ste...@gm...>]

Am Do, 6.12.2012, 13:15 schrieb David McCullough:

Hello,

> Get the cryptotest program from the ocf tarball and compile and run that.
> It talk directly to /dev/crypto and will confirm that you have everything
> else working.  It can also do speed tests.
>
I'll test it.

> If that doesn't appear to be working,  try enabling debug in both the
> cryptodev/cryptosoft drivers to see what they can tell you.  Debug(kernel
> console output) will tell you if they are being accessed and may helkp
> track
> any failures,
>
I found that the cbc module was missing.
Now openssl shows more speed.
But my openVPN connection has only 50% lesser CPU load.

In the next days I'll test it with the cryptodev tool and an better
meaurment system.

Regards,
Stefan Kuhne

Re: [Ocf-linux-users] ocf seem not working

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

Jivin Stefan Kuhne lays it down ...
> Hello,
> 
> I've got ofc and openssl build.
> Now i get:
> 
> Guardian 3.9.0-rev24403 # ./openssl speed -evp aes-128-cbc -engine cryptodev
> engine "cryptodev" set.
> Doing aes-128-cbc for 3s on 16 size blocks: 862864 aes-128-cbc's in 2.97s
> Doing aes-128-cbc for 3s on 64 size blocks: 246323 aes-128-cbc's in 2.93s
> Doing aes-128-cbc for 3s on 256 size blocks: 61891 aes-128-cbc's in 2.85s
> Doing aes-128-cbc for 3s on 1024 size blocks: 16226 aes-128-cbc's in 2.96s
> Doing aes-128-cbc for 3s on 8192 size blocks: 2022 aes-128-cbc's in 2.91s
> OpenSSL 1.0.0j 10 May 2012
> built on: date not available
> options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial)
> blowfish(ptr)
> compiler: i586-unknown-linux-uclibc-gcc -fPIC -DOPENSSL_PIC
> -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -DTERMIO  -pipe -Os -g2 -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fno-unwind-tables
> -fno-asynchronous-unwind-tables -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
> -fomit-frame-pointer -Wall
> The 'numbers' are in 1000s of bytes per second processed.
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> bytes
> aes-128-cbc       4648.43k     5380.43k     5559.33k     5613.32k
> 5692.17k
> Guardian 3.9.0-rev24403 # lsmod
> ...
> cryptosoft             16461  0
> geode_aes              12337  2
> cryptodev              16433  4
> ocf                    21404  2 cryptosoft,cryptodev
> cs5535_mfd             12337  0
> aes_i586               16567  2
> aes_generic            36986  1 aes_i586
> ...
> Guardian 3.9.0-rev24403 # openssl engine
> (cryptodev) BSD cryptodev engine
> (dynamic) Dynamic engine loading support
> Guardian 3.9.0-rev24403 #
> 
> It seems, that ocf doesn't work.
> Any ideas were I can work on?


Get the cryptotest program from the ocf tarball and compile and run that.
It talk directly to /dev/crypto and will confirm that you have everything
else working.  It can also do speed tests.

Once you get that working,  then try:

	openssl speed -engine cryptodev -evp aes128 -elapsed

You really need to run "openssl speed" with -elapsed to get real useful
numbers out IMO.

If that doesn't appear to be working,  try enabling debug in both the
cryptodev/cryptosoft drivers to see what they can tell you.  Debug(kernel
console output) will tell you if they are being accessed and may helkp track
any failures,

Cheers,
Davidm

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

[Ocf-linux-users] ocf seem not working

[Stefan K. <ste...@gm...>]

Hello,

I've got ofc and openssl build.
Now i get:

Guardian 3.9.0-rev24403 # ./openssl speed -evp aes-128-cbc -engine cryptodev
engine "cryptodev" set.
Doing aes-128-cbc for 3s on 16 size blocks: 862864 aes-128-cbc's in 2.97s
Doing aes-128-cbc for 3s on 64 size blocks: 246323 aes-128-cbc's in 2.93s
Doing aes-128-cbc for 3s on 256 size blocks: 61891 aes-128-cbc's in 2.85s
Doing aes-128-cbc for 3s on 1024 size blocks: 16226 aes-128-cbc's in 2.96s
Doing aes-128-cbc for 3s on 8192 size blocks: 2022 aes-128-cbc's in 2.91s
OpenSSL 1.0.0j 10 May 2012
built on: date not available
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial)
blowfish(ptr)
compiler: i586-unknown-linux-uclibc-gcc -fPIC -DOPENSSL_PIC
-DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -DTERMIO  -pipe -Os -g2 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fno-unwind-tables
-fno-asynchronous-unwind-tables -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS
-fomit-frame-pointer -Wall
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
bytes
aes-128-cbc       4648.43k     5380.43k     5559.33k     5613.32k
5692.17k
Guardian 3.9.0-rev24403 # lsmod
...
cryptosoft             16461  0
geode_aes              12337  2
cryptodev              16433  4
ocf                    21404  2 cryptosoft,cryptodev
cs5535_mfd             12337  0
aes_i586               16567  2
aes_generic            36986  1 aes_i586
...
Guardian 3.9.0-rev24403 # openssl engine
(cryptodev) BSD cryptodev engine
(dynamic) Dynamic engine loading support
Guardian 3.9.0-rev24403 #

It seems, that ocf doesn't work.
Any ideas were I can work on?

Regards,
Stefan Kuhne