Hi Jan,
Welcome to join the discussion.
>the second set of numbers doesn't make sense, and a much better test is to
do an actual encryption test
I don't compile cryptodev kernel module for my PC and can not reproduce
this issue for now. You don't understand the reason why the performance
is much worse with cryptodev module for *big* blocks, right?
If yes, I guess the reason maybe kernel assign the work to multi cores
while OpenSSL uses one core. Would you share the output of command "mpstat
-P ALL 2"?
>My advice is to rerun your tests *without* the cryptodev module and then
decide wheter you really need CBC+CCM hmacs.
Yes, I confirm that without the cryptodev the performance is very bad for
my device. I don't have that device in my hand right now. But I saved one
aes-256-cbc result in my web notebook as below:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 19626.95k 24289.71k 25054.46k 25347.75k 25337.86k
Please note, there are two modes to accelerate encryption/decryption.
1. HW instructions like intel x86 CPU.
2. Using a crypto engine.
When your device is 2 and its CPU is not powerful, normally with cryptodev
speed is much faster at least for big blocks. Maybe for small blocks it's
slower because
it needs the time to push the work to kernel and then HW engine and the
time spent is may longer than the time costed by OpenSSL directly does the
encryption/decryption.
Tony
Jan Just Keijser <janj...@nikhef.nl> 于2020年12月2日周三 下午7:24写道：
> 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> 于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
> listOpenvpn-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
>
>
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
