Hello,
i am planning to buy supermicro boards which are https://www.supermicro.com/en/products/motherboard/a2sdv-4c-ln10pf
and/or
https://www.supermicro.com/en/products/motherboard/a2sdv-8c-ln10pf
i could not find any information about whether they support or not ?
can you help me please ?
it's x86, x86 is supported.
Thank you for reply, what about Network controllers?
Network Controllers :
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.
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.
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...
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...
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.
