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