Hi Jan,
Thanks for your replay :)
>>ah OK; I've grabbed a copy, built and installed it on 2 servers and ran some
>>test: I get similar figures for 'openssl speed' but those numbers are
>>artificial, i.e. they do not reflect true performance of the system.
>>According to the site http://cryptodev-linux.org/index.html I should be
>>getting some improvement but not *that* much.
i think the cryptodev got much improved with enabled it, take a look for
following what i got test data-------------without cryptodev-------------The
'numbers' are in 1000s of bytes per second processed.type 16 bytes
64 bytes 256 bytes 1024 bytes 8192 bytesaes-128-cbc 158525.06k
214128.67k 242916.10k 250279.55k 253359.45k-------------with
cryptodev-------------The 'numbers' are in 1000s of bytes per second
processed.type 16 bytes 64 bytes 256 bytes 1024 bytes
8192 bytesaes-128-cbc 45084.53k 191286.30k 656871.75k 3228385.28k
18282905.60k--------------compare the 8192 bytes per second processed, with
cryptodev up to 18282905.60k, without is only 253359.45k, this is very good
improved. don't look at that times of openssl speed -evp aes-128-cbc
>>this is partly true - openvpn minimizes the user-to-kernel and kernel-to-user
>>copying of packets but it does happen and yes this is indeed the bottleneck.
>>There is little we can do about this, although other tools such as vtun get
>>slightly better performance.
do you mean if we want through "hardware encryption accelerator <-->
cryptodev(kernel) <--> openvpn(user space)" is not good as the bottleneck
existed? what is your suggestion? how about we do that in this way "hardware
encryption accelerator <--> openvpn(user space)" that mean we customize Openvpn
let it call to CPU manufacturer provides API by directly?
Thank you very much.
Yuqian
