Wow I should do backup of SDCARD that my Turris 1.0 boot from and give it a try too.
Which parts of Omnia hardware is not supported in OpenWrt 20.xx with kernel 5.4?
That may differ from the board revisions and what extra hardware a user may have deployed, but since the .20 and .23 board revisions are (almost?) identically wired those should work with the hardware as shipped from the vendor. Not sure about the .13 board revision, whether it makes a big difference.
Mind I have not taken the node through the paces, just curious about how SFP works out, then NFtables and perhaps LXC v 4.0.2 (particularity if unprivileged containers work out of the box), Maybe taking a look at eBPF and whether XDP is already fully there or rather later in kernel 5.6, same for MPTCP that likely arrives only with kernel 5.7.
Unfortunately neither kernel development nor OpenWrt have gotten around about the secondary dead link from CPU (eth0) to switch and thus requires the patch from TOS to get it to work.
1 Like
5.5 claims to add XDP support into mvneta, so after that we might hope. I havenât really checked properly â itâs still a bit far off, user-space SW also takes time to start supporting XDP, and perhaps the overall benefit on these smaller devices wonât be high.
1 Like
Likely that a fully grown up NIC with advanced hardware and driver capabilities will make more of a difference, but then it may still squeeze a bit extra with an SoC that could be crucial when closing in on 1 GbE throughput. And anyway, what is the saying - curiosity got the cat, or something⌠?
Perhaps if people want to serve very large amount of DNS over UDP from Turris, it might help significantly. ATM itâs far-fetched to extrapolate from x86 with Intel server cards â I wanted to at least try it âfor funâ on Omnia as well when 5.5+ kernel comes there, but I guess that may take a year or two 
In normal Turris use cases I can imagine, almost all traffic gets routed/forwarded by kernel already, so there I donât expect XDP can really help (unless you want to write a custom filter that drops most of the traffic or something).
There you hit the nail. It will benefit fending off malicious traffic since packet filtering can be offloaded from the CPU to the NIC (driver). I havenât yet gotten really around to eBPF, which should be mature in 5.4 and which XDP will leverage, but with NFTables on my boxes some traffic gets filtered already by NETDEV at driver level at the WAN port and thus frees up CPU cycles.
SOHO might not be the common target for DDoS or such rubbish but the actorâs capabilities are increasing and thus I trust that potential targets should have the capabilities to deal with it without being inconvenienced.
Well, this a big player/target but suppose it makes the idea clear https://blog.cloudflare.com/how-to-drop-10-million-packets/
Anyway, dropping slightly off thread topic.