On 17 January 2018 at 16:25, Rafał Miłecki <zaj...@gmail.com> wrote:
> 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.

If someone is interested in these existing implementations, there is a
list of these I'm aware of.

One of the earliest ones was Broadcom's CTF (Cut-Through Forwarding).
For BCM4706-based device it could bump NAT from 120 Mb/s to 850 Mb/s.
It was described by me in:
[1] Understanding/reimplementing forwarding acceleration used by Broadcom (ctf)
e-mail thread. It consisted of kernel modification (see ctf.diff in
above thread) and closed source ctf.ko.

Marvell announced their own "fastpath" implementation in 2014 in e-mail thread:
[2] Introducing "fastpath" - Kernel module for speeding up IP forwarding
They referenced a nice article on embedded.com [3].
AFAIU a year or two later they released it as the OpenFastPath project
[3] [4] under the BSD 3-clause license. Noone tried integrating it
with OpenWrt/LEDE AFAIK.

Finally there is Qualcomm's Shortcut Forwarding Engine. It's open
source and it's reported to increase NAT performance on AR9132-based
device from ~235 Mb/s to ~525 Mb/s. It's ported to LEDE as set of
patches to be applied on top of cloned repo [6] by a gwlim user.

[1] https://lists.openwrt.org/pipermail/openwrt-devel/2013-August/021112.html
[2] https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/030179.html
[3] 
https://www.embedded.com/design/operating-systems/4403058/Accelerating-network-packet-processing-in-Linux
[4] https://openfastpath.org/
[5] https://github.com/MarvellEmbeddedProcessors/ofp-marvell
[6] https://github.com/gwlim/Fast-Path-LEDE-OpenWRT

_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Reply via email to