Having just been the victim of the Intel I219 on linux, and a heavy user of OpenWRT, my initial response when I saw the logo was pure horror.
For those that don't know – as I didn't – the hardware behind Intel's more recent ethernet chipsets seem only to be tested and supported on the most basic of networking configurations. As soon as you add something like a macvlan, it is apparently normal to expect problems like dropped packets and module unloading every few GB. One of the solutions seems to be to disable offloading [0], but for me that just bought me an order of magnitude more time before the hang.
However, this does look like good work – and I have to celebrate the contribution from the devs on this one. There are huge gains to be had by network offloading – and perhaps in time Intel's hardware division will iron out the problems with their chipsets.
This topic of hardware offloading is interesting, and, for some people's requirements, is there an open source consideration to keep in mind: are you offloading to effectively "closed source"?
I'm a long-time OpenWrt user on various reflashed SOHO WiFi router SoC boxes, and I recently want to move my home router(s) to somewhat more open PC hardware (with Pfsense, OpenWrt, or DIY atop a GNU/Linux distro), and obtained some Intel gigabit NICs for this purpose.
Since I want to use fanless PC hardware (although even the first Intel card alone runs quite warm at idle), I'm wondering how the performance will be, running all packets through Linux+CPU+I/O, compared to whatever hardware optimizations OpenWrt is doing on the SoC boxes. If the performance on PC hardware falls short, offloading could make the difference, but that would be starting to look more like the closed SoC I was going to a lot of effort to move away from.
(Ultimately, I would want to do this on a fully-open RISC-V board, with open hardware NICs, open hardware AES, etc., but I don't know that will ever be viable. For now, PC hardware, as open and trustworthy as I can get it, might be closest.)
The MediaTek MT7621 SoC has support for hardware NAT in OpenWrt. The driver is being developed by Felix Fietkau of ath9k fame who has stated that it’s the most open (blob free) 5Ghz chip on the market. I’ve been using an mt7621 device since before the Lede split and the progress has been amazing. If you’re reading this Felix, thank you!!
I haven’t been following the development branch but the current stable branch says “Experimental feature. Not fully compatible with QoS/SQM”. For this reason I haven’t enabled it.
EDIT: My decision to go with the mt7621 came from watching the rant by Felix on wireless drivers.
https://youtu.be/hiUosbhR0Wo
If open is what you are interested in try OPNsense before pfSense.
I'd recommend starting off with keeping your LAN on a dumb pure L2 switch (no management interface or anything) with your box acting as the upstream swouterwall. It's a lot easier to start with that side of things and see how much load it generates there than it is to throw the whole thing at it and troubleshoot what parts are making it run slow.
I'll chime in, since I moved to PC-based fanless router hardware about 5 years ago, and for my needs it's been fantastic.
One of my WAN connections is 100Mbps down (25 up), and I don't have any problem saturating it. I'm only using whatever hardware offloading Linux supports out of the box, which from the parent article I guess is pretty minimal (e.g. stuff like checksum offloading, I suppose). I haven't noticed any bottlenecks when routing between two gigabit LANs (I just ran a quick dd|nc test that measures 940Mbps). However, my needs may be relatively simple and I'm sure there must be more complex scenarios that would benefit from the offloading described in the parent article.
I bought a 4-port Intel NIC because I wanted discrete network interfaces for 2 LANs and 2 WANs. I ended up having to saw off some of the PCI-e edge connector segments to make it fit in my motherboard, so I'm presumably not getting the benefit of all the lanes the NIC could otherwise take advantage of, but nonetheless it seems satisfactory for my needs.
The two advancements I'm following in the router field (which do not fit your requirements though) are 1) Router 7 [a router implementation fully written in Go] [1] 2) Turris MOX [a modular, extensible router] [2].
You could run Router 7 on PC Engines [3] who at least use Coreboot.
I just found out about Turris Omnia. Its not open source but its modular like a PC. But its a router. I know it does not make sense so please take a look yourself
My experience with OpenWrt and hardware acceleration is that it matters once speeds gets high enough.
I’ve had some TP-Link Archer c7’s I’ve used as a main router in the past.
When all it has to do is switch packets on my local network there’s literally no load (as inspected by using htop). Gigabits ahoy.
However when routing stuff out to the internet, it needs not only to switch but also to do software NAT, and then the SoCs performance starts saturating between 350 and 380 mbps. Doing 500mbps is not happening.
For that reason I changed my main router to a Linksys WRT 1900 ACS (with a Marvel-based SOC) which has hardware NAT.
It runs symmetric 500mbps without seeing the gauges in htop even move. It’s a night and day difference.
Once speeds get high enough, HW offloading isn’t just nice to have, it’s a requirement.
And when you do have that, almost all those other tasks the router has to do becomes trivial because you have wads and wads of CPU to spare.
Imo PC-based solutions are overkill, but yes, you may end up with a more open solution that way.
There's a push at the moment to get the Qualcomm QSDK hardware offloading ported to modern kernels for IPQ8064 (Dual Core Arm SoC with an additional 2 Packet Processing cores) - sadly, Qualcomm haven't kept pace with upstream Kernel dev so it's a mammoth task.
And that's the crux of the problem with these SoC's - they can have fantastic packet processing performance (and in the case of the IPQ8064 NSS cores accelerated PPPoE, qdisc and crypto) but it's all tied up in vendor only repos, doesn't track upstream and so you're stuck with buggy vendor firmware.
I was reading QSDK page [1] and it seems to me that they are doing something different from openwrt.
>The QCA Software Development Kit (QSDK) project allows users to build an OpenWrt based platform containing additional enhancements for Qualcomm Atheros chipsets that have not yet made it into the public OpenWrt repository.
I'm not aware of the project goals so I may be wrong.
Openwrt is such a gem,not just for home routers but also for IoT gateways etc. Its installation base is probably on par with Debian. I have long been hoping that Linux Foundation or somebody else to endorse this project and give it a huge boost on top of this already great project.
Just the other day I tried the build system[1] for openwrt
and I was amazed to find how easy it is to create a custom image for a platform of your choice. And not just the kernel you can also build specific packages ,if they are not already supported by the package repository or are outdated.
Everything can be done from a graphical interface. Just a few stokes of keyboard and you have your own custom build. Really impressive stuff.
Not of this particular presentation. But there are quite a few other videos talking about openwrt on the website (you'll find them under previous summits menu)
dpwm|6 years ago
For those that don't know – as I didn't – the hardware behind Intel's more recent ethernet chipsets seem only to be tested and supported on the most basic of networking configurations. As soon as you add something like a macvlan, it is apparently normal to expect problems like dropped packets and module unloading every few GB. One of the solutions seems to be to disable offloading [0], but for me that just bought me an order of magnitude more time before the hang.
However, this does look like good work – and I have to celebrate the contribution from the devs on this one. There are huge gains to be had by network offloading – and perhaps in time Intel's hardware division will iron out the problems with their chipsets.
[0] https://sourceforge.net/p/e1000/bugs/571/
voltagex_|6 years ago
neilv|6 years ago
I'm a long-time OpenWrt user on various reflashed SOHO WiFi router SoC boxes, and I recently want to move my home router(s) to somewhat more open PC hardware (with Pfsense, OpenWrt, or DIY atop a GNU/Linux distro), and obtained some Intel gigabit NICs for this purpose.
Since I want to use fanless PC hardware (although even the first Intel card alone runs quite warm at idle), I'm wondering how the performance will be, running all packets through Linux+CPU+I/O, compared to whatever hardware optimizations OpenWrt is doing on the SoC boxes. If the performance on PC hardware falls short, offloading could make the difference, but that would be starting to look more like the closed SoC I was going to a lot of effort to move away from.
(Ultimately, I would want to do this on a fully-open RISC-V board, with open hardware NICs, open hardware AES, etc., but I don't know that will ever be viable. For now, PC hardware, as open and trustworthy as I can get it, might be closest.)
nominated1|6 years ago
I haven’t been following the development branch but the current stable branch says “Experimental feature. Not fully compatible with QoS/SQM”. For this reason I haven’t enabled it.
EDIT: My decision to go with the mt7621 came from watching the rant by Felix on wireless drivers. https://youtu.be/hiUosbhR0Wo
zamadatix|6 years ago
I'd recommend starting off with keeping your LAN on a dumb pure L2 switch (no management interface or anything) with your box acting as the upstream swouterwall. It's a lot easier to start with that side of things and see how much load it generates there than it is to throw the whole thing at it and troubleshoot what parts are making it run slow.
simmons|6 years ago
One of my WAN connections is 100Mbps down (25 up), and I don't have any problem saturating it. I'm only using whatever hardware offloading Linux supports out of the box, which from the parent article I guess is pretty minimal (e.g. stuff like checksum offloading, I suppose). I haven't noticed any bottlenecks when routing between two gigabit LANs (I just ran a quick dd|nc test that measures 940Mbps). However, my needs may be relatively simple and I'm sure there must be more complex scenarios that would benefit from the offloading described in the parent article.
I bought a 4-port Intel NIC because I wanted discrete network interfaces for 2 LANs and 2 WANs. I ended up having to saw off some of the PCI-e edge connector segments to make it fit in my motherboard, so I'm presumably not getting the benefit of all the lanes the NIC could otherwise take advantage of, but nonetheless it seems satisfactory for my needs.
Fnoord|6 years ago
You could run Router 7 on PC Engines [3] who at least use Coreboot.
[1] https://github.com/rtr7/router7
[2] https://www.turris.cz/en/overview/
[3] https://www.pcengines.ch/
workrockin|6 years ago
https://www.turris.cz/en/overview/
They also launched an indiegogo campaign last year that you can check out here
https://www.indiegogo.com/projects/turris-mox-modular-open-s...
josteink|6 years ago
My experience with OpenWrt and hardware acceleration is that it matters once speeds gets high enough.
I’ve had some TP-Link Archer c7’s I’ve used as a main router in the past.
When all it has to do is switch packets on my local network there’s literally no load (as inspected by using htop). Gigabits ahoy.
However when routing stuff out to the internet, it needs not only to switch but also to do software NAT, and then the SoCs performance starts saturating between 350 and 380 mbps. Doing 500mbps is not happening.
For that reason I changed my main router to a Linksys WRT 1900 ACS (with a Marvel-based SOC) which has hardware NAT.
It runs symmetric 500mbps without seeing the gauges in htop even move. It’s a night and day difference.
Once speeds get high enough, HW offloading isn’t just nice to have, it’s a requirement.
And when you do have that, almost all those other tasks the router has to do becomes trivial because you have wads and wads of CPU to spare.
Imo PC-based solutions are overkill, but yes, you may end up with a more open solution that way.
philjohn|6 years ago
And that's the crux of the problem with these SoC's - they can have fantastic packet processing performance (and in the case of the IPQ8064 NSS cores accelerated PPPoE, qdisc and crypto) but it's all tied up in vendor only repos, doesn't track upstream and so you're stuck with buggy vendor firmware.
oneowl|6 years ago
>The QCA Software Development Kit (QSDK) project allows users to build an OpenWrt based platform containing additional enhancements for Qualcomm Atheros chipsets that have not yet made it into the public OpenWrt repository.
I'm not aware of the project goals so I may be wrong.
[1] https://wiki.codeaurora.org/xwiki/bin/QSDK/
ausjke|6 years ago
workrockin|6 years ago
Everything can be done from a graphical interface. Just a few stokes of keyboard and you have your own custom build. Really impressive stuff.
[1] https://openwrt.org/docs/guide-developer/build-system/use-bu...
cbluth|6 years ago
workrockin|6 years ago
http://openwrtsummit.org/