ocf-linux-users Mailing List for Open Cryptographic Framework for Linux (Page 2)
Brought to you by:
david-m
You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(12) |
Sep
(39) |
Oct
(16) |
Nov
(7) |
Dec
(17) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(10) |
Feb
(1) |
Mar
(18) |
Apr
(8) |
May
(14) |
Jun
(12) |
Jul
(35) |
Aug
(11) |
Sep
(3) |
Oct
(3) |
Nov
(7) |
Dec
(2) |
2009 |
Jan
(20) |
Feb
(12) |
Mar
(31) |
Apr
(20) |
May
(31) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(11) |
Oct
|
Nov
(2) |
Dec
(6) |
2010 |
Jan
(20) |
Feb
(10) |
Mar
(16) |
Apr
|
May
(17) |
Jun
|
Jul
(2) |
Aug
(30) |
Sep
(6) |
Oct
|
Nov
|
Dec
(1) |
2011 |
Jan
|
Feb
(9) |
Mar
(7) |
Apr
(6) |
May
(20) |
Jun
(2) |
Jul
(13) |
Aug
(4) |
Sep
(7) |
Oct
(9) |
Nov
(5) |
Dec
(2) |
2012 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(19) |
2013 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(8) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
From: David M. <uc...@gm...> - 2014-01-09 13:40:32
|
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 |
From: <J.W...@mi...> - 2014-01-09 12:52:29
|
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. |
From: hwang7 <hua...@wi...> - 2013-04-24 01:33:09
|
> 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 > > -- |
From: David M. <uc...@gm...> - 2013-04-23 11:59:22
|
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 |
From: hwang7 <hua...@wi...> - 2013-04-23 08:29:48
|
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 |
From: anand r. <one...@ya...> - 2013-02-24 10:20:36
|
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 |
From: Zhou, B. <b-...@ti...> - 2013-02-12 19:42:28
|
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 |
From: Russell S. <ru...@pe...> - 2013-02-07 10:33:14
|
>>>>> "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... |
From: David M. <uc...@gm...> - 2013-01-27 02:33:19
|
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 |
From: Russell S. <ru...@pe...> - 2013-01-25 16:51:55
|
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... |
From: David M. <uc...@gm...> - 2012-12-27 00:38:17
|
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 |
From: Stefan K. <ste...@gm...> - 2012-12-27 00:17:27
|
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 |
From: David M. <uc...@gm...> - 2012-12-26 23:11:48
|
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 |
From: Stefan K. <ste...@gm...> - 2012-12-22 20:22:24
|
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 |
From: Stefan K. <ste...@gm...> - 2012-12-15 14:07:08
|
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 |
From: David M. <dav...@mc...> - 2012-12-15 13:55:14
|
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 |
From: Stefan K. <ste...@gm...> - 2012-12-15 11:36:48
|
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 |
From: Stefan K. <ste...@gm...> - 2012-12-15 02:07:42
|
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 |
From: David M. <dav...@mc...> - 2012-12-12 23:47:07
|
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 |
From: Stefan K. <ste...@gm...> - 2012-12-12 18:13:21
|
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 |
From: Stefan K. <ste...@gm...> - 2012-12-11 18:42:46
|
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 |
From: Stefan K. <ste...@gm...> - 2012-12-11 15:57:06
|
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 |
From: Stefan K. <ste...@gm...> - 2012-12-06 14:09:48
|
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 |
From: David M. <dav...@mc...> - 2012-12-06 12:31:35
|
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 |
From: Stefan K. <ste...@gm...> - 2012-12-04 22:10:38
|
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 |