[Openswan Users] IXP425 Acceleration question
rogier at TaiwanGate.tw.reverze.net
rogier at TaiwanGate.tw.reverze.net
Mon Feb 21 18:22:46 CET 2005
Dan,
OpenSSL will be accelerated by it, but currently OpenSWAN doesn't hook
into OCF right (via KLIPS)? My main question was how to accelerate the
kernel part of OpenSWAN (KLIPS) in 2.4 for the IXP425, much like
freeswan-1.99 has...
Thanks though :)
Regards,
Rogier
On Mon, 21 Feb 2005, Dan Searle wrote:
> 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