Thank you for reply, what about Network controllers?
Network Controllers :
- Quad LAN with Intel® Ethernet Controller I350-AM4
- Quad LAN with Intel® C3000 SoC
- Dual LAN with Intel® I210-IS 1G SFP
If they're supported in main line kernel, they should be here too.
if you can find out which kernel module they use, you can check if the same module is available in openwrt.
2 Likes
Sorry, I don't know about this, how can I get this information? i don't have them yet and they did not release any datasheet.
Google knows, and you only need to know the chip, which you do.
I can tell you i350 is the igb module, and it's supported, the i210 is actually using the same module.
4 Likes
i see, thank you for your effort, i appreciated it. so i don't need to worry about the boards.
not the boards, but then there's the question of the actual SFP modules...
1 Like
SFP module uses i210, and there is C3000 SoC besides I350
pretty sure there's got to be support for the actual module too, not only the driving chip,
but I might be wrong, haven't really used SFP...
1 Like
Okay, thank you, i will try to get information from Supermicro, if i get anything worth to share, i will.
What i found is a block diagram of Chipset, as you can see Network controllers are Intel I350, MARVELL 88E1543 and I210IS but i could not find infomation about Kernel.
Yes, for sure it works. These are fabulous boards. I currently use OpenWRT on the following board, which is very similar: https://www.supermicro.com/en/products/motherboard/a2sdi-8c-hln4f
I also used OpenWRT on the previous generation of this motherboard. All in all, I've been using OpenWRT on one of these motherboards since 2012. They're fast and robust. You do need some tuning at the OS level to get maximum network performance. If you get around to building a router based on this board, ping me and I'll be happy to help out with some details.
I even have a port of all the Intel Quickassist drivers to OpenWRT
@dl12345 thank you for reply, sorry for late respond, i was not around, that's a great news, thanks for sharing.
What OS level tuning you mean, can you share with me?, and can you share Intel Quickassist drivers, i don't know about them.
Your help is appreciated, Thank you.
Just a quick question, currently the official build seems to have issue with AES-NI (OpenSSL unable to use the hardware acceleration), can your build show support of both AES-NI/QAT under OpenSSL?
Yes, of course. See image below: it shows my openwrt release (it's about a year and a half old version of Master), the QAT driver status as being loaded, the Intel QAT kernel modules loaded, the hugetables filesystem loaded (used by QAT's contiguous memory driver) and a run of an openssl speed test for RSA using the QAT engine.
My build is using glibc and has a custom kernel obviously, not only because of the QAT drivers, but also because it has some optimizations for a non-resource-constrained system. These used to be many, but in recent years the x86_64 build has improved considerably and the kernel config is much better now than it was, say 10 years ago.
I have, however, noted to you in a previous reply that it is pointless implementing QAT on OpenWRT as the workloads are a mismatch and AES-NI outperforms it by a large margin.
Intel QAT only outperforms AES-NI when there are multiple asynchronous processes doing crypto operations on large buffers simultaneously.
Performing AES operations on anything less than an 8K sized buffer is much quicker using AES-NI than Intel's QAT engine.
This is because a lot of data needs to be shunted across the bus to the QAT hardware, whereas AES-NI is a CPU instruction.
Furthermore, the speed of the openssl AES software implementation suffers considerably when not offloading due to engine related polling that happens when the QAT engine is compiled into openssl, resulting in up to a 40% performance hit for small buffer sized, software-based encryption/decryption (Intel is aware of this - the Intel folk responsible for QAT gave me some good assistance and support while I was porting it, extending to giving me access even to updated code at the time that they'd not yet published).
So, as a result of this polling-related inefficiency, even though I have QAT installed on my openwrt, I deliberately compile QAT's AES implementation out, since 1.) I never use it as it performs like a dog and 2.) it slows down the software implementation that I DO use by 40%.
Please read this long thread for more insight into hardware crypto engines on OpenWRT and more specifically QAT: https://forum.openwrt.org/t/which-wifi-routers-have-hardware-aes-encryption-support. There's lots of useful information, explanations and benchmarks.
Here's the port of Intel QAT to OpenWRT: https://github.com/dl12345/quickassist-openwrt-denverton
When it comes to network communications, Intel QAT is a blatant workload mismatch unless you're running a very busy public-facing nginx that is patched with Intel QAT routines. I recommend forgetting about it and not even trying to implement it, as you won't use it. These Supermicro Denverton platforms have a lot to recommend them other than the QAT technology.
Please see my reply to @fakemanhk just above, as it answers some of the questions you asked (what OS level tuning and where is the port of Intel QAT).
In brief, modifications include the QAT port in the kernel, optimizations in the kernel config for a non-resource-constrained x86_64 system, use of glibc, full nls support and full versions of many of the packages (instead of the cut-down busybox versions).
My OpenWRT looks more like a desktop distro in terms of it's libc and packages than an embedded distro, since I have a 500GB SSD in it, 16GB of RAM and 8 cores.
@dl12345 thank you for your reply, I don't know much about OpenWrt, I'm having trouble understanding what you're saying, i did not receive the board yet. So i will come back when i start to install it.
Unfortunately I don't know why the current build can't even use AES-NI (OpenSSL engine list doesn't show any acceleration), not sure if I have to compile a custom one.
AESNI isn't implemented as an engine, so it won't show up as an engine. If you have AESNI in your openssl then it will automatically use it with the right command line switch (-evp) and will show it when you do a speed test. The output below is from my QAT-capable openssl, but you can see the compiler definition in the output -DAESNI_ASM
compiler: ccache_cc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -Wformatro -O3 -DPIC -fpic -ffunction-sections -fdata-sections -fpic -specs=/opt/openwrt/x86/master/openwrt/include/hardened-ld-pie.specs -znow -zrelro -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENBN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -DPIC
Openssl will automatically use AESNI when you use the -evp option. If you wish to check for sure if it's using openssl then try these two commands
This one should run much faster than the second one:
openssl speed -elapsed -evp aes-128-cbc
This below explicitly disables AESNI and forces a vanilla software only run. OPENSSL_ia32cap is the x86_64 capabilities vector that can be tweaked to enable/disable instruction set extensions
OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-cbc
You can clearly see the difference in speed on my machine
root@openwrt:/etc# openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 54073058 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 21815757 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 6198768 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 1651775 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 210226 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 105253 aes-128-cbc's in 3.00s
OpenSSL 1.1.1k 25 Mar 2021
built on: Sat Mar 27 11:29:08 2021 UTC
options:bn(64,64) rc4(16x,int) des(int) aes(partial) blowfish(ptr)
compiler: ccache_cc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -Wformat -Werror=format-security -DPIC -fpic -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wl,-z,now -Wl,-z,relro -O3 -DPIC -fpic -ffunction-sections -fdata-sections -fpic -specs=/opt/openwrt/x86/master/openwrt/include/hardened-ld-pie.specs -znow -zrelro -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -DPIC
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 288389.64k 465402.82k 528961.54k 563805.87k 574057.13k 574821.72k
root@openwrt:/etc# OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 18736508 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 5621367 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 1491052 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 378232 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 47467 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 23738 aes-128-cbc's in 3.00s
OpenSSL 1.1.1k 25 Mar 2021
built on: Sat Mar 27 11:29:08 2021 UTC
options:bn(64,64) rc4(16x,int) des(int) aes(partial) blowfish(ptr)
compiler: ccache_cc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -Wformat -Werror=format-security -DPIC -fpic -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wl,-z,now -Wl,-z,relro -O3 -DPIC -fpic -ffunction-sections -fdata-sections -fpic -specs=/opt/openwrt/x86/master/openwrt/include/hardened-ld-pie.specs -znow -zrelro -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -DPIC
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 99928.04k 119922.50k 127236.44k 129103.19k 129616.55k 129641.13k
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.