I have just started using OpenWRT and I am fascinated by the possibility this system offers. Of course, you could get and old PC and go for pfsense, however running Openwrt on a SOC has its good points.
I wonder if is there any chance to compare SOCs performance between multiple vendors, also against traditional CPUs....
1 Like
(Moved to the Hardware Questions and Recommendations section.)
The thing is that with SoC it's not just about the CPU, particularity when we are talking about routers, where connectivity is an important part. You could have a SoC with good processing power but the connectivity side might not be as attractive, especially when closed-source drivers are involved. Latest Raspberry Pi is an example.
2 Likes
For instance, how does the Ubiquiti Edgemax ER-X (Dual-Core 880 MHz, MIPS1004Kc) compares with average OpenWRT router?
- What is an "average OpenWrt router"?
- What packages are you going to install and run on this "average" device?
- Are any of these specialized - perhaps suited for a device with built-in crypto CPU or hardware NAT, etc (e.g. NATing multiple WANs, encrypted VPN concentrator, HTTPS server, RADIUS, etc.)?
In theory, it should possess twice as much processing power as a 800 single-cored MIPS device.
1 Like
trying to answer your question:
the erx cpu is relatively underpowered compared to others as it uses a seperate chip to perform network translation functions.
these "accelerator chip" will not work with openwrt.
Did someone compare routers with a sort of performance scale?
1 Like
A first attempt: 
Such graphs can easily be created in the wiki, see the wiki source of https://openwrt.org/inbox/openvpn_performance.
If other useful performance indicators come to your mind, feel free to create a similar graphic in the wiki's inbox.
7 Likes
Is the difference in performance really this big between ipq806x and ipq40xx or is it because of poor multi-cpu utilization (ipq806x being dual core with about double the frequency of ipq40xx) ?
VPN is effectively a single-core process.
2 Likes
So is the (general) performance of ipq40xx comparable to ipq806x?
And how can mvebu achieve these results ?
That, and QCA KRAIT300 ~= Cortex A15 has very different performance levels than ARM Cortex A7.
Edit: Btw., I wouldn't trust the actual (example?) figures in that chart too much, yes mvebu is much faster than ipq806x at plain routing, but when it comes to crypto operations (and that is the limiting factor for VPN usage), both mvebu and ipq806x are pretty close to each other (actually with ipq8065 slightly in the lead).
1 Like
mvebu has CESA hardware acceleration crypto engine whose driver is in-tree. With OpenSSL and cryptodev, OpenVPN can offload AES-ECB/CBC en/decryption to it.
ipq806x also has a crypto engine in its NSS core but no driver is available (yet)
1 Like
And for MT7621 and MT7628, there is an out-of-tree and WIP driver available, authored by @drbrains
https://github.com/vschagen/mtk-eip93 (MT7621)
By the time I commented, the crypto driver for MT7628 is stable while MT7621 one needs more work.
1 Like
OpenVPN does not use ECB and even with hardware crypto, OpenVPN throughput is not even close to as high as that chart shows on mvebu (which kind of looks to be just OpenSSL performance) due to the massive overhead OpenVPN has.
To compare the performance of multiple vendor's SOCs, either you have to have hands own experience on them or read reviews by users. Reviews may reflect the the personal preferences of the users.
Nah, ipq40xx does not have a NSS (Network Subsystem - Dedicated CPU-cores + 3 Ethernet-Macs + Switch). Instead it's called ESS (Ethernet Subsystem) over there which just includes one Ethernet-Mac and the internal Switch + transceivers.
So the crypto on the ipq40xx is just a on a DMA channel and can used by standard ALG interface.
This is a list of the currently supported cryptos (from /proc/crypto)
name : hmac(sha256)
driver : hmac-sha256-qce
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : ahash
async : yes
blocksize : 64
digestsize : 32
name : hmac(sha1)
driver : hmac-sha1-qce
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : ahash
async : yes
blocksize : 64
digestsize : 20
name : sha256
driver : sha256-qce
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : ahash
async : yes
blocksize : 64
digestsize : 32
name : sha1
driver : sha1-qce
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : ahash
async : yes
blocksize : 64
digestsize : 20
name : cbc(des3_ede)
driver : cbc-3des-qce
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : ablkcipher
async : yes
blocksize : 8
min keysize : 24
max keysize : 24
ivsize : 8
geniv : <default>
name : ecb(des3_ede)
driver : ecb-3des-qce
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : ablkcipher
async : yes
blocksize : 8
min keysize : 24
max keysize : 24
ivsize : 0
geniv : <default>
name : cbc(des)
driver : cbc-des-qce
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : ablkcipher
async : yes
blocksize : 8
min keysize : 8
max keysize : 8
ivsize : 8
geniv : <default>
name : ecb(des)
driver : ecb-des-qce
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : ablkcipher
async : yes
blocksize : 8
min keysize : 8
max keysize : 8
ivsize : 0
geniv : <default>
name : xts(aes)
driver : xts-aes-qce
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : ablkcipher
async : yes
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 16
geniv : <default>
name : ctr(aes)
driver : ctr-aes-qce
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : ablkcipher
async : yes
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 16
geniv : <default>
name : cbc(aes)
driver : cbc-aes-qce
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : ablkcipher
async : yes
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 16
geniv : <default>
name : ecb(aes)
driver : ecb-aes-qce
module : kernel
priority : 300
refcnt : 1
selftest : passed
internal : no
type : ablkcipher
async : yes
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 16
geniv : <default>
So there are "direct" offloads available for hmac-sha256, sha256, xts-aes, ctr-aes, cbc-aes and ecb-aes.
(I skipped the (3)des and sha1 since they should not be used anymore).
1 Like
So that means it doesn't require additional (out-of-tree) crypto driver to run on master OpenWrt?
The qce driver is available in the upstream vanilla linux for some time now:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/crypto/qcom-qce.txt
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/crypto/qce
1 Like
openssl engine -pre DUMP_INFO devcrypto detects the qce driver as software crypto driver:
root@OpenWrt:~# openssl engine -pre DUMP_INFO devcrypto
(devcrypto) /dev/crypto engine
Information about ciphers supported by the /dev/crypto engine:
Cipher DES-CBC, NID=31, /dev/crypto info: id=1, driver=cbc-des-qce (software)
Cipher DES-EDE3-CBC, NID=44, /dev/crypto info: id=2, driver=cbc-3des-qce (software)
Cipher BF-CBC, NID=91, /dev/crypto info: id=3, CIOCGSESSION (session open call) failed
Cipher CAST5-CBC, NID=108, /dev/crypto info: id=4, CIOCGSESSION (session open call) failed
Cipher AES-128-CBC, NID=419, /dev/crypto info: id=11, driver=cbc-aes-qce (software)
Cipher AES-192-CBC, NID=423, /dev/crypto info: id=11, driver=cbc-aes-qce (software)
Cipher AES-256-CBC, NID=427, /dev/crypto info: id=11, driver=cbc-aes-qce (software)
Cipher RC4, NID=5, /dev/crypto info: id=12, CIOCGSESSION (session open call) failed
Cipher AES-128-CTR, NID=904, /dev/crypto info: id=21, driver=ctr-aes-qce (software)
Cipher AES-192-CTR, NID=905, /dev/crypto info: id=21, driver=ctr-aes-qce (software)
Cipher AES-256-CTR, NID=906, /dev/crypto info: id=21, driver=ctr-aes-qce (software)
Cipher AES-128-ECB, NID=418, /dev/crypto info: id=23, driver=ecb-aes-qce (software)
Cipher AES-192-ECB, NID=422, /dev/crypto info: id=23, driver=ecb-aes-qce (software)
Cipher AES-256-ECB, NID=426, /dev/crypto info: id=23, driver=ecb-aes-qce (software)
Information about digests supported by the /dev/crypto engine:
Digest MD5, NID=4, /dev/crypto info: id=13, driver=md5-generic (software), CIOCCPHASH capable
Digest SHA1, NID=64, /dev/crypto info: id=14, driver=sha1-qce (software), CIOCCPHASH capable
Digest RIPEMD160, NID=117, /dev/crypto info: id=102, driver=unknown. CIOCGSESSION (session open) failed
Digest SHA224, NID=675, /dev/crypto info: id=103, driver=sha224-generic (software), CIOCCPHASH capable
Digest SHA256, NID=672, /dev/crypto info: id=104, driver=sha256-qce (software), CIOCCPHASH capable
Digest SHA384, NID=673, /dev/crypto info: id=105, driver=unknown. CIOCGSESSION (session open) failed
Digest SHA512, NID=674, /dev/crypto info: id=106, driver=unknown. CIOCGSESSION (session open) failed
[Success]: DUMP_INFO
@cotequeiroz How to make it detect them as hw accelerated?