That would be a really intresting and important feature for many hardware.
Fernando
On 26/09/2015 23:57, Weedy wrote:
Did this die?
On 22 Dec 2014 9:06 am, "Tomer Eliyahu" <tomereliya...@gmail.com
<mailto: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 <mailto:r...@marvell.com>
Tomer Eliyahu tom...@marvell.com <mailto: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
<mailto: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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
