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