[LEDE-DEV] A state of network acceleration
Rafał Miłecki
zajec5 at gmail.com
Wed Jan 17 07:25:10 PST 2018
Getting better network performance (mostly for NAT) using some kind of
acceleration was always a hot topic and people are still
looking/asking for it. I'd like to write a short summary and share my
understanding of current state so that:
1) People can undesrtand it better
2) We can have some rough plan
First of all there are two possible ways of accelerating network
traffic: in software and in hardware. Software solution is independent
of architecture/device and is mostly just bypassing in-kernel packets
flow. It still uses device's CPU which can be a bottleneck. Various
software implementations are reported to be faster from 2x to 5x.
Hardware acceleration requires hw-specific implementation and can
offload device's CPU.
Of course handling network traffic out of the networking subsystem
means some features like QoS / throughput limits / advanced firewall
rules may not/won't work.
The hardest task (for both methods) was always a Linux kernel
integration. Drivers had to somehow:
1) Get/build a table with rules for packets flow
2) Update in-kernel state to e.g. avoid connection timeout & its removal
The problem with all existing implementations was they used various
non-upstream patches for kernel integration. Some were less invasive,
some a bit more. They weren't properly reviewed by kernel developers
and usually were using hacks/solutions that couldn't be accepted.
The rescue to this was Pablo's work on offloading infrastructure. He
worked on this hard by developing & sending his patchset for upstream
kernel:
[1] [PATCH RFC,WIP 0/5] Flow offload infrastructure
[2] [PATCH nf-next RFC,v2 0/6] Flow offload infrastructure
[3] [PATCH nf-next,v3 0/7] Flow offload infrastructure
The best news is that his final patchset version was accepted and sits
now in the net-next [4] (and should become part of kernel 4.16).
Now, what does it mean for LEDE project:
1) There is upstream infrastructure that should be ready to use
2) It's based on & requires nftables
3) LEDE's firewall3 uses iptables (& friends) C API
4) There aren't any drivers for offloading hardware (switches?) yet
One thing I'm not sure about is if software accelerator is ready or not.
Pablo is his e-mail wrote:
> So far, this is a generic software flow table representation, that
> matches basic flow table hardware semantics but that also provides a
> software faster path. So you can use it to purely forward packets
> between two nics even if they come with no hardware offload support.
which could suggest software path is already there.
So there is my idea of what is needed by LEDE to get it working:
1) Rewrite firewall3 to use nftables
2) Switch to kernel 4.16 or backport offloading to 4.14
3) Work on implementing/enabling software acceleration path
Let me know if above description makes sense to you or correct me if
you think I misunderstood something :)
[1] https://www.spinics.net/lists/netfilter-devel/msg50141.html
[2] https://www.spinics.net/lists/netfilter-devel/msg50555.html
[3] https://www.spinics.net/lists/netfilter-devel/msg50759.html
[4] https://www.spinics.net/lists/netfilter-devel/msg50973.html
More information about the Lede-dev
mailing list