A long shot, but are there any news from Marvel legal department? Would sending them a case of good beer solve this? :)
On Sunday, 27 September 2015, Weedy <[email protected]> wrote: > Did this die? > On 22 Dec 2014 9:06 am, "Tomer Eliyahu" <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> Tomer Eliyahu [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> >> >> 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 >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> >
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
