hi Tony,
On 01/12/20 02:50, Tony He wrote:
Hi Arne,
openssl speed -evp aes-128-cbc
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc
20035.60k 123261.54k 267081.60k 1094764.09k 9181370.18k
openssl speed -evp aes-128-gcm
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-gcm
18738.76k 19284.91k 19524.44k 19606.87k 19685.46k
openssl speed -evp aes-128-ccm
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-ccm
53859.07k 215581.12k 862070.02k 3460786.43k 27566347.61k
openssl speed -evp sha1
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha1 3108.57k
12177.79k 57325.18k 181610.34k 1207364.27k
openssl speed -evp chacha20-poly1305
chacha20-poly1305 is an unknown cipher or digest
Using old openssl, so chacha20-poly1305 is not supported.
these numbers look suspiciously like you're using the linux cryptodev
module. Openssl speed results for the linux cryptodev module are totally
unreliable and I'd even go so far as to say that the *only* numbers I
trust in the output above are for aes-128-gcm
For example, if I do the same on an i5-6800 I get *without* the
cryptodev module:
$ openssl speed -evp aes-128-cbc
aes-128-cbc 1,104,599.38k 1,208,651.07k 1,231,766.70k
1,237,545.64k 1,248,793.94k
and with the module I get
aes-128-cbc 45,087.41k 127,822.72k 581,517.17k 2,256,593.19k
27,583,804.51k
the second set of numbers doesn't make sense, and a much better test is
to do an actual encryption test, e.g.
*without* the module
cat BIGFILE | openssl aes-256-cbc -e -pass pass:thisisabadpassword |
pv > /dev/null
2.93GB 0:00:05 [ 549MB/s] [ <=> ]
('pv' aka 'pipeview' is a handy tool to measure the throughput of a UNIX
pipe)
and with the module:
cat BIGFILE | ./openssl aes-256-cbc -e -pass pass:thisisabadpassword
-engine cryptodev| pv > /dev/null
engine "cryptodev" set.
2.93GB 0:00:07 [ 426MB/s] [ <=>
so you see that using the cryptodev module actually slows things down -
which is to be expected, as the application needs to do more work using
the cryptodev module.
My advice is to rerun your tests *without* the cryptodev module and then
decide wheter you really need CBC+CCM hmacs.
HTH,
JJK
Arne Schwabe <a...@rfc2549.org <mailto:a...@rfc2549.org>>
于2020年11月26日周四 下午6:40写道：
Am 26.11.20 um 10:41 schrieb Tony He:
> Hi Arne,
>
>>Since the original thread was not on the mailing list I am
missing your
>>goal but if your crypto acelator already works with OpenSSL, then it
>>will also work with the "normal" OpenVPN
>
> Yes, it wokrs with "normal" OpenVPN(OpenVPN2), but according to
the test
> result, it's still not fast(about 60Mbps).
> The bottleneck is not encryption operation any more. It comes
from the
> switch of user space and kernel space in the OpenVPN2,
> which makes the poor CPU of embedded device very busy. That's
why we
> need OpenVPN3 running in the kernel space.
What numbers are we are talking in crypto speed? Could you provide
from
your "poor" device:
openssl speed -evp aes-128-cbc
openssl speed -evp aes-128-gcm
openssl speed -evp aes-128-ccm
openssl speed -evp sha1
openssl speed -evp chacha20-poly1305
I want to what difference/gain in terms of raw crypto speed we are
talking here.
Arne
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
