[Openswan Users] IXP425 Acceleration question

Dan Searle dan at adelix.com
Mon Feb 21 09:37:18 CET 2005


Hi,

Please see this posting I've quoted below from a posting I made on the
ARM Linux mailing list a while ago, it points to some patches required
to get the OCF working on Linux, and also how to compile OpenSSL to
make use of the /dev/crypto, and hence your hardware acceleration
(provided you have the ixp4xx.ko OCF crypto module loaded).

I have it working on my IXP425 development board, here's some stats
from "cryptotest" when using the hardware acceleration:

# cryptotest -z 1024
 0.067 sec,    2048    des crypts,       8 bytes,   246269 byte/sec,     1.9 Mb/sec
 0.067 sec,    2048    des crypts,      16 bytes,   488397 byte/sec,     3.7 Mb/sec
 0.069 sec,    2048    des crypts,      32 bytes,   947257 byte/sec,     7.2 Mb/sec
 0.073 sec,    2048    des crypts,      64 bytes,  1797304 byte/sec,    13.7 Mb/sec
 0.081 sec,    2048    des crypts,     128 bytes,  3242912 byte/sec,    24.7 Mb/sec
 0.097 sec,    2048    des crypts,     256 bytes,  5390249 byte/sec,    41.1 Mb/sec
 0.131 sec,    2048    des crypts,     512 bytes,  8003908 byte/sec,    61.1 Mb/sec
 0.198 sec,    2048    des crypts,    1024 bytes, 10611345 byte/sec,    81.0 Mb/sec
 0.336 sec,    2048    des crypts,    2048 bytes, 12486875 byte/sec,    95.3 Mb/sec
 0.632 sec,    2048    des crypts,    4096 bytes, 13265537 byte/sec,   101.2 Mb/sec
 1.333 sec,    2048    des crypts,    8192 bytes, 12586871 byte/sec,    96.0 Mb/sec
 0.067 sec,    2048   3des crypts,       8 bytes,   246317 byte/sec,     1.9 Mb/sec
 0.068 sec,    2048   3des crypts,      16 bytes,   483860 byte/sec,     3.7 Mb/sec
 0.071 sec,    2048   3des crypts,      32 bytes,   927681 byte/sec,     7.1 Mb/sec
 0.076 sec,    2048   3des crypts,      64 bytes,  1723271 byte/sec,    13.1 Mb/sec
 0.089 sec,    2048   3des crypts,     128 bytes,  2955833 byte/sec,    22.6 Mb/sec
 0.110 sec,    2048   3des crypts,     256 bytes,  4746750 byte/sec,    36.2 Mb/sec
 0.156 sec,    2048   3des crypts,     512 bytes,  6712519 byte/sec,    51.2 Mb/sec
 0.249 sec,    2048   3des crypts,    1024 bytes,  8415099 byte/sec,    64.2 Mb/sec
 0.437 sec,    2048   3des crypts,    2048 bytes,  9607733 byte/sec,    73.3 Mb/sec
 0.832 sec,    2048   3des crypts,    4096 bytes, 10085334 byte/sec,    76.9 Mb/sec
 1.728 sec,    2048   3des crypts,    8192 bytes,  9709161 byte/sec,    74.1 Mb/sec
 0.077 sec,    2048    aes crypts,      16 bytes,   425757 byte/sec,     3.2 Mb/sec
 0.079 sec,    2048    aes crypts,      32 bytes,   830232 byte/sec,     6.3 Mb/sec
 0.083 sec,    2048    aes crypts,      64 bytes,  1573796 byte/sec,    12.0 Mb/sec
 0.090 sec,    2048    aes crypts,     128 bytes,  2909608 byte/sec,    22.2 Mb/sec
 0.108 sec,    2048    aes crypts,     256 bytes,  4834777 byte/sec,    36.9 Mb/sec
 0.143 sec,    2048    aes crypts,     512 bytes,  7335110 byte/sec,    56.0 Mb/sec
 0.215 sec,    2048    aes crypts,    1024 bytes,  9768826 byte/sec,    74.5 Mb/sec
 0.363 sec,    2048    aes crypts,    2048 bytes, 11553824 byte/sec,    88.1 Mb/sec
 0.670 sec,    2048    aes crypts,    4096 bytes, 12525844 byte/sec,    95.6 Mb/sec
 1.414 sec,    2048    aes crypts,    8192 bytes, 11861971 byte/sec,    90.5 Mb/sec
 0.077 sec,    2048 aes192 crypts,      16 bytes,   425393 byte/sec,     3.2 Mb/sec
 0.079 sec,    2048 aes192 crypts,      32 bytes,   825089 byte/sec,     6.3 Mb/sec
 0.084 sec,    2048 aes192 crypts,      64 bytes,  1567997 byte/sec,    12.0 Mb/sec
 0.091 sec,    2048 aes192 crypts,     128 bytes,  2869478 byte/sec,    21.9 Mb/sec
 0.110 sec,    2048 aes192 crypts,     256 bytes,  4773284 byte/sec,    36.4 Mb/sec
 0.144 sec,    2048 aes192 crypts,     512 bytes,  7277230 byte/sec,    55.5 Mb/sec
 0.215 sec,    2048 aes192 crypts,    1024 bytes,  9756147 byte/sec,    74.4 Mb/sec
 0.361 sec,    2048 aes192 crypts,    2048 bytes, 11603303 byte/sec,    88.5 Mb/sec
 0.663 sec,    2048 aes192 crypts,    4096 bytes, 12657178 byte/sec,    96.6 Mb/sec
 1.393 sec,    2048 aes192 crypts,    8192 bytes, 12044110 byte/sec,    91.9 Mb/sec
 0.080 sec,    2048 aes256 crypts,      16 bytes,   409938 byte/sec,     3.1 Mb/sec
 0.081 sec,    2048 aes256 crypts,      32 bytes,   805051 byte/sec,     6.1 Mb/sec
 0.087 sec,    2048 aes256 crypts,      64 bytes,  1507771 byte/sec,    11.5 Mb/sec
 0.094 sec,    2048 aes256 crypts,     128 bytes,  2779658 byte/sec,    21.2 Mb/sec
 0.111 sec,    2048 aes256 crypts,     256 bytes,  4706440 byte/sec,    35.9 Mb/sec
 0.147 sec,    2048 aes256 crypts,     512 bytes,  7143326 byte/sec,    54.5 Mb/sec
 0.218 sec,    2048 aes256 crypts,    1024 bytes,  9621685 byte/sec,    73.4 Mb/sec
 0.365 sec,    2048 aes256 crypts,    2048 bytes, 11494204 byte/sec,    87.7 Mb/sec
 0.667 sec,    2048 aes256 crypts,    4096 bytes, 12584680 byte/sec,    96.0 Mb/sec
 1.400 sec,    2048 aes256 crypts,    8192 bytes, 11981124 byte/sec,    91.4 Mb/sec


> Dan
> 
> Take a look at the OCF work that was quietly posted to sourceforge late
> last year.
> The instructions/patches are for the SnapGear distro, but also include
> notes so
> That it is generally applicable to 2.4.x kernels (2.4.20-27)
> http://sourceforge.net/project/showfiles.php?group_id=74209&package_id=1
> 37358
> 
> I could have blasted this list earlier but chose to wait until more
> feedback
> Was obtained.  This work was already posted to the cryptoapi mailing
> list
> by David McCullough
> http://lists.logix.cz/pipermail/cryptoapi/2004/000218.html who
> Did the original work for the ixp4xx. See the mailing list for history.
> Questions 
> should be posted to http://lists.logix.cz/pipermail/cryptoapi/ 
> 
> David continues to update and posted an update dated 20041224
> http://lists.logix.cz/pipermail/cryptoapi/2004/000261.html which has not
> been rolled
> To sourceforge yet.
> 
> This design/implementation adapted the OCF (Open BSD Crypto Framework)
> to allow
> The NPE Crypto to be used by user space apps.  This includes an
> integration
> With OpenSSL. 
> 
> The integration is for IXP400 v1.4.  A new release of the Access library
> has been
> Released - V1.5. The Crypto API is the same so the integration should
> apply to this 
> Also.  But I have not verified it yet.
> 
> Notes on how to integrate this with MVL3.1 are to be posed to the intel
> web site.
> But then any experienced developer should be able to follow the readme
> with the package.
> 
> Hope this helps,
> 
> RR
> 
> 
>>-----Original Message-----
>>From: linux-arm-kernel-bounces at lists.arm.linux.org.uk 
>>[mailto:linux-arm-kernel-bounces at lists.arm.linux.org.uk] On 
>>Behalf Of Dan Searle
>>Sent: Wednesday, January 05, 2005 5:45 AM
>>To: Linux-arm-kernel at lists.arm.linux.org.uk
>>Subject: Using the intel IXP425 access library from user space
>>
>>Hi,
>>
>>I'm trying to modify vtund the user space tunneling daemon for 
>>vtun to off-load the encryption of data frames to the IXP425's 
>>crypto NPE to increase performance on encrypted tunnels.
>>
>>Problem is, the API for accessing the NPEs is in Intel's 
>>IXP400 Access Library which I have compiled as a kernel module 
>>and loaded at run time.
>>
>>Is it possible to access kernel symbols, or link a user space 
>>program with symbols in the kernel at run time?
>>
>>If not I suppose I will have to create another driver/module 
>>which would provide an interface to the IXP400 Crypto API via 
>>some kind of userspace<->kernel interface like the proc file 
>>system, system calls etc...
>>
>>Can someone recommend the lowest latency, most optimal way for 
>>me to pass buffers of data to a driver in kernel space from a 
>>daemon in user space? Obviously I would have to initialize a 
>>"handle" or connection to the kernel space API on which all 
>>subsequent operations like, passing plain text buffers could 
>>be tied to.
>>
>>I don't need the interface between kernel and user space to be 
>>non-blocking (asynchronous), as vtund uses blocking calls to 
>>encrypt and decrypt buffers already.
>>
>>Any ideas? Regards, Dan...
>>
>>--
>>
>>Dan Searle
>>Adelix Ltd
>>dan.searle at adelix.com web: www.adelix.com
>>tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
>>snail: The Old Post Office, Bristol Rd, Hambrook, Bristol BS16 1RY. UK.
>>
>>Any views expressed in this email communication are those of 
>>the individual sender, except where the sender specifically 
>>states them to be the views of a member of Adelix Ltd.  Adelix 
>>Ltd. does not represent, warrant or guarantee that the 
>>integrity of this communication has been maintained nor that 
>>the communication is free of errors or interference.
>>
>>
>>-------------------------------------------------------------------
>>Subscription options: 
>>http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
>>FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
>>Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php
>>




More information about the Users mailing list