[Soekris] Network/CPU performance on net5501-70

[Stuart Henderson]

On 2008-04-25, Wolfram Schlich <lists at wolfram.schlich.org> wrote:
> Tried these combinations:
>
> 	cipher BF-CBC
> 	tls-cipher DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA
>
> 	cipher AES-128-CBC
> 	tls-cipher DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA
>
> Changing 'cipher' didn't make much of a difference...

That's certainly software then. Here are results from a run of
"openssl speed -elapsed -evp aes128" and a run of "openssl speed
-elapsed -evp bf", this is OpenBSD -current on a Geode LX system
(not a Soekris but should be pretty much the same):

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc        933.12k     3518.13k    11131.13k    24439.77k    37186.08k
bf-cbc            6274.52k     7879.77k     8469.28k     8625.53k     8672.98k

and AES again, this time with hw crypto disabled (kern.usercrypto=0)

aes-128-cbc       5310.48k     6008.31k     6248.19k     6298.19k     6312.47k

AES *has* to be 128-bit to use the Geode's hw accel, other sizes
are not supported by the hardware.

> So, I'm more or less confused regarding Geode AES HW acceleration
> on Linux %-/

Try http://www.docunext.com/wiki/My_Notes_on_Patching_2.6.22_with_OCF

The /dev/crypto framework has been around for years though, Geode LX
driver for 18 months - on some other OS it "just works", I am amazed
this still hasn't been fully integrated into standard Linux kernels
and work out of the box yet.

If you compare my numbers with the ones from openssl on that page,
note the command line options, they don't use -elapsed on the Geode
tests so the results are invalid.

     -elapsed
           Measure time in real time instead of CPU user time.

The C7 speed test on that page *does* used -elapsed, so the figures
for that can be compared with mine (C7 overheads are lower, they use
CPU instructions rather than a discrete PCI device - it's a lot
faster. With Geode hw aes it's helpful to take your packet sizes
into account when deciding whether or not to enable it: if the
traffic is mostly VoIP it's probably better avoided due to the
overheads).

> To me it seems weird to patch a whole new crypto framework (OCF)
> into the kernel as there's already one (OpenSSL just seems not
> to be able to use it out of the box :-/).

*shrugs*  there are OS which don't make you work as hard :-)