123 lines
		
	
	
		
			4.6 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			123 lines
		
	
	
		
			4.6 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| Shortcut Forwarding Engine
 | |
| --------------------------
 | |
| 
 | |
| Welcome to "Shortcut" :-)
 | |
| 
 | |
| Here's a quick FAQ:
 | |
| 
 | |
| 
 | |
| Q) What is Shortcut?
 | |
| 
 | |
| A) Shortcut is an in-Linux-kernel IP packet forwarding engine.  It's designed
 | |
| to offer very high speed IP packet forwarding based on IP connection tracking.
 | |
| It's dramatically faster than the standard netfilter-based NAT forwarding path
 | |
| but is designed to synchronise state back to netfilter/conntrack so that it
 | |
| doesn't need to deal with all of the complexities of special cases.
 | |
| 
 | |
| 
 | |
| Q) What versions of IP does it support?
 | |
| 
 | |
| A) The current version only supports IPv4 but will be extended to support IPv6 in
 | |
| the future.
 | |
| 
 | |
| 
 | |
| Q) What transport protocols does it support?
 | |
| 
 | |
| A) TCP and UDP.  It also knows enough about ICMP to spot ICMP error messages
 | |
| related to TCP and UDP and handle things accordingly.
 | |
| 
 | |
| 
 | |
| Q) Is there a design spec for this software?
 | |
| 
 | |
| A) Not at the moment.  I'll write one when I get more time.  The code is
 | |
| intended to be a good tutorial though - it's very heavily commented.  If you
 | |
| find yourself reading something and not understanding it then I take that to
 | |
| mean I've probably not done a sufficently good job of explaining what it's
 | |
| doing in the comments.  Let me know - I will try to fix it :-)
 | |
| 
 | |
| 
 | |
| Q) Why was it written?
 | |
| 
 | |
| A) It was written as a demonstration of what can be done to provide high
 | |
| performance forwarding inside the kernel.  There were two initial motivations:
 | |
| 
 | |
| 1) To provide a platform to enable research into how QoS analysis systems can
 | |
| offload work and avoid huge Linux overheads.
 | |
| 
 | |
| 2) To provide a tool to investigate the behaviour of various processors, SoCs
 | |
| and software sets so that we can characterize and design new network processor
 | |
| SoCs.
 | |
| 
 | |
| 
 | |
| Q) How much faster is it than the Linux kernel forwarding path?
 | |
| 
 | |
| A) At the time of pushing this to github it's been tested on a QCA AP135.
 | |
| This has a Scorpion (QCA Scopion, not the QMC one :-)) SoC, QCA9550.  The
 | |
| SoC's processor is a MIPS74K running at 720 MHz and with a DDR2 memory
 | |
| subsystem that offers a peak of 600 MT/s (16-bit transfers).
 | |
| 
 | |
| Running IPv4 NAT forwarding of UDP between the board's 2 GMAC ports and
 | |
| using a SmartBits 200 as a traffic generator Linux is able to forward 70k PPS.
 | |
| Once the SFE code is invoked this will increase to 350k PPS!
 | |
| 
 | |
| There's also a slightly hacky mode which causes SFE to bypass the Linux
 | |
| bridge layer, but this isn't really ready for use because it doesn't have
 | |
| sufficient MAC address checks or integration of statistics back to the
 | |
| Ethernet bridge, but that runs at 436k PPS.
 | |
| 
 | |
| 
 | |
| Q) Are there any diagnostics?
 | |
| 
 | |
| A) Yes, this is a research tool after all!  There's a complex way to do this
 | |
| that's more general purpose and a simple one - here's the simple one:
 | |
| 
 | |
| 	mknod /dev/sfe c 253 0
 | |
| 
 | |
| The file /dev/sfe is an XML-ish output and provides details of all the
 | |
| network connections currently being offloaded.  It also reports the numbers
 | |
| of packets that took various "exception" paths within the code.  In addition
 | |
| it provides a summary of the number of connections, attempts to accelerate
 | |
| connections, cancel accelerations, etc.  It also reports the numbers of
 | |
| packets that were forwarded and not forwarded by the engine and has some
 | |
| stats on the effectiveness of the hashing algorithm it uses.
 | |
| 
 | |
| 
 | |
| Q) How does the code interact with Linux?
 | |
| 
 | |
| A) There are four minor patches required to make this software run with
 | |
| Linux.  These are currently against a 3.3.8 or 3.4.0 kernel:
 | |
| 
 | |
| * (net/core/dev.c) adds a hook to allow packets to be extracted out.
 | |
| 
 | |
| * (net/netfilter/nf_conntrack_proto_tcp.c) exposes a state variable inside
 | |
|   netfilter that's necessary to enable TCP sequence and ACK checking within
 | |
|   the offload path.  Note that this specific patch is against the QCA QSDK
 | |
|   patched version of 3.3.8 - there's a slightly braindead "performance"
 | |
|   patch in that kernel, courtesy of the OpenWrt community that makes the
 | |
|   Linux forwarding path slightly faster at the expense of losing
 | |
|   functionality :-(
 | |
| 
 | |
| * (net/Kconfig) adds the shortcut-fe option.
 | |
| 
 | |
| * (net/Makefile) adds the shortcut-fe build support.
 | |
| 
 | |
| Once these are applied and the module is loaded then everything else
 | |
| is automatic :-)  The patches are in this git repo.
 | |
| 
 | |
| 
 | |
| Q) Are any of the pieces reused from other projects?
 | |
| 
 | |
| A) Yes!  Some of the forwarding concepts are reused from the Ubicom Network
 | |
| Accelerator that morphed into part of the Akronite NSS.  This code has all
 | |
| been substantially changed though to accomodate Linux's needs.
 | |
| 
 | |
| There are also some pieces that I borrowed from the QCA "FastNAT" software
 | |
| written by Xiaoping Fan <xfan@qca.qualcomm.com>.  Xiaoping's code was the
 | |
| first actual demonstration within QCA that this in-kernel concept could yield
 | |
| signficant performance gains.
 | |
| 
 | |
| 
 | |
| Enjoy!
 | |
| Dave Hudson <dhudson@qti.qualcomm.com>
 | |
| 
 | 
