Did this die? On 22 Dec 2014 9:06 am, "Tomer Eliyahu" <tomereliya...@gmail.com> wrote:
> Hi, > > We are software developers, part of Marvell's cellular platform > infrastructure team. > > Our team has been working on a project named "fastpath" for speeding > up IP forwarding in embedded systems. > The initial version (fastpath v1) has already been successfully > deployed in our latest pxa1801 (cellular modem) based products. > > We are in the final stages of fastpath v2 development, which is > completely hardware independent and requires minimal changes in the > generic networking code (the project consists of a kernel module and a > single kernel patch); despite being hardware independent, fastpath v2 > already achieved the same level of performance (as fastpath v1) and > even increased stability. > > Our development platform is running openwrt Barrier Breaker (r43694), > so naturally we chose to suggest this to the openwrt development > community first. > > You can find a brief description of our fastpath solution below. > > We are anxious to hear your thoughts/comments and will gladly share the > code. > > Best Regards, > > Ram Marzin r...@marvell.com > Tomer Eliyahu tom...@marvell.com > > > Fastpath in a nutshell > ---------------------- > > The basic concept of fastpath is to optimize the data-plane while > keeping the control-plane in the generic networking stack. > This is a known concept in the industry which is commonly used in > embedded systems [1], but so far we couldn't find any open source > implementation for it. > > Fast path implements an optimized data-plane, which replaces the > generic data-plane forwarding code for selected connections. The > data-plane implementation includes a straight forward optimized packet > processing engine which handles all the required packet manipulation > for IP forwarding, such as decrement ttl/hop count, checksum > adjustment, MAC header encapsulation and "dummy NAT" (TCP/UDP traffic > which does not carry any L3/L4 information in the packet payload). > > As noted above, the control-plane is handled by the generic networking > stack, with the only exception of learning new connections and marking > the valid ones as fastpath - some connections can't participate in > fastpath, such as any "non-dummy NAT" connections (e.g. FTP control > port), local traffic, and any protocol which is not supported (e.g. > IPv6 extensions, IPSec, IPv4 fragmanted packets, etc.). > Needless to say that ALL non-fastpath connections / protocols will > work as is, i.e. they simply won't go through fastpath. > > As a rule of thumb, it is safe to assume that in most of the cases, > 90% of the data will go through fastpath. In our experiments on > pxa1801, fastpath alone *almost doubled* the performance (both > Throughput and MIPS consumption) for TCP/UDP IPv4/IPv6 forwarding. > > References > [1] > http://www.embedded.com/design/operating-systems/4403058/Accelerating-network-packet-processing-in-Linux > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
