Merge branch 'vita' into vita-timeline2

.travis.yml

@@ -10,6 +10,9 @@ before_script:
 script:
  - make -j
  - (cd src && sudo program/vita/selftest.snabb)
+ - (cd src && sudo program/vita/selftest6.snabb)
  - (cd src && sudo ./snabb snsh -t program.vita.exchange)
  - (cd src && sudo program/vita/conftest.snabb)
  - (cd src && sudo program/vita/test.snabb IMIX 1e6 3)
+ - (cd src && sudo program/vita/test6.snabb IMIX 1e6 3)
+ - (cd src && sudo program/vita/clitest.sh)

README.md

@@ -2,58 +2,34 @@
 
 🚧 🚧 🚧 🚧
 
-…is a *virtual private network* (VPN) gateway you can use to interconnect your
-LANs. Vita acts as a tunnel between your local, private network and any number
-of remote Vita gateways. With it, nodes spread across your outposts can
-communicate with each other as if they were on the same LAN, with
-confidentiality and authenticity ensured at the network layer. Vita is probably
-more efficient at encapsulating traffic than your application servers. You can
-free cycles for your application by offloading your packet encryption and
-authentication workload to Vita.
+…is a high-performance L3 VPN gateway you can use to interconnect your
+networks. Vita acts as a tunnel between your local, private network and any
+number of remote Vita gateways. With it, nodes spread across your outposts can
+communicate with each other with confidentiality and authenticity ensured at
+the network layer.
 
-![a mesh of Vita gateways forms a VPN](vita-sketch.png)
-
-A Vita network can be as small as two nodes with a single route, and as large
-as you like. For each pair of Vita gateways, a separate secure tunnel (*route*)
-can be established—“can be” because a Vita network does not need to be a full
-mesh, instead arbitrary hierarchies are supported on a route-by-route basis.
-Each route uses a pre-shared super key that is installed on both ends of the
-route. These keys need to be configured only once, and only need renewal when
-compromised, in which case the breach will affect only the route in question.
-The actual keys used to encrypt the traffic are ephemeral, and negotiated by
-Vita automatically, with no manual intervention required.
+Vita is probably more efficient at encapsulating traffic than your application
+servers. You can free cycles for your application by offloading your packet
+encryption and authentication workload to Vita.
 
-Deploying Vita is easy, and not invasive to your existing infrastructure. It
-can be as simple as adding an entry to the IP routing table of your default
-gateway, to ensure that packets to destinations within your private network are
-routed over an extra hop: the Vita gateway. Whether Vita forwards the
-encapsulated packets back to your default gateway, or directly to your modem
-depends on your setup, and is freely configurable.
-
-![private traffic is routed over a Vita gateway, and encapsulated before it is
-transmitted over the Internet](vita-detail.png)
-
-To configure a Vita route, you need to specify the address prefix of the
-destination subnetwork, and the public IP address of the target Vita gateway
-(in addition to the pre-shared key). At the other end, you specify the source
-prefix and gateway address in symmetry. You can even add and remove routes
-while Vita is running, without affecting unrelated routes.
+![a mesh of Vita gateways forms a VPN](vita-sketch.png)
 
 ## WARNING:
 
 > Vita is in its early “tech-demo” stage of development. Not for production!
 
 ## Features
 
+- ~2.5 Mpps (or ~5 Gbps of IMIX traffic) per core on a modern CPU
 - Runs on commodity hardware
-- Implements IPsec for IPv4, specifically
-  *IP Encapsulating Security Payload* (ESP) in tunnel mode (audit needed)
+- Implements IPsec for IPv4 and IPv6, specifically
+  *IP Encapsulating Security Payload* (ESP) in tunnel mode
 - Uses optimized AES-GCM 128-bit encryption based on a reference
   implementation by *Intel* for their AVX2 (generation-4) processors
-- Suitable for 1-Gigabit, 10-Gigabit (and beyond?) Ethernet
 - Automated key exchange and rotation, with perfect forward secrecy (PFS)
   (audit needed)
-- Dynamic reconfiguration (update routes while running)
+- Can act as a pure data-plane and consume SAs established by other means
+- Dynamic reconfiguration via YANG RPCs (update routes while running)
 - Strong observability: access relevant statistics of a running Vita node
 
 ## Documentation
@@ -97,6 +73,34 @@ machine:
 End-to-end benchmarking procedures are documented in
 [vita-loadtest.md](https://github.com/inters/vita/tree/master/src/program/vita/vita-loadtest.md).
 
+## Deployment
+
+A Vita network can be as small as two nodes with a single route, and as large
+as you like. For each pair of Vita gateways, a separate secure tunnel (*route*)
+can be established—“can be” because a Vita network does not need to be a full
+mesh, instead arbitrary hierarchies are supported on a route-by-route basis.
+Each route uses a pre-shared super key that is installed on both ends of the
+route. These keys need to be configured only once, and only need renewal when
+compromised, in which case the breach will affect only the route in question.
+The actual keys used to encrypt the traffic are ephemeral, and negotiated by
+Vita automatically, with no manual intervention required.
+
+Deploying Vita is easy, and not invasive to your existing infrastructure. It
+can be as simple as adding an entry to the IP routing table of your default
+gateway, to ensure that packets to destinations within your private network are
+routed over an extra hop: the Vita gateway. Whether Vita forwards the
+encapsulated packets back to your default gateway, or directly to your modem
+depends on your setup, and is freely configurable.
+
+![private traffic is routed over a Vita gateway, and encapsulated before it is
+transmitted over the Internet](vita-detail.png)
+
+To configure a Vita route, you need to specify the address prefix of the
+destination subnetwork, and the public IP address of the target Vita gateway
+(in addition to the pre-shared key). At the other end, you specify the source
+prefix and gateway address in symmetry. You can even add and remove routes
+while Vita is running, without affecting unrelated routes.
+
 ## Powered by
 
 ![Snabb](snabb.png)
@@ -109,5 +113,5 @@ networking toolkit with a wonderful community.
 
 ![NLnet](nlnet.png)
 
-[NLnet](https://nlnet.nl) funded Vita development in 2017/2018 with their
+[NLnet](https://nlnet.nl) funded Vita development in 2018/2019 with their
 generous donation. 🙇‍♂️

src/Makefile.vita

@@ -2,21 +2,23 @@ INCLUDE = *.* core arch jit syscall pf \
           lib/token_bucket.* lib/tsc.* \
           lib/lua lib/protocol lib/checksum.* lib/ipsec \
           lib/yang lib/stream.* lib/stream lib/buffer.* \
-          lib/xsd_regexp.* lib/maxpc.* lib/ctable.* lib/binary_search.* \
+          lib/xsd_regexp.* lib/maxpc.* lib/ctable.* lib/cltable.* \
+          lib/binary_search.* lib/multi_copy.* lib/hash \
           lib/ptree lib/rrd.* lib/fibers \
-          lib/multi_copy.* lib/hash lib/cltable.* lib/lpm lib/interlink.* \
+          lib/poptrie* lib/interlink.* \
           lib/hardware lib/macaddress.* lib/numa.* lib/cpuset.* \
           lib/scheduling.* lib/timers \
-          apps/interlink apps/intel_mp \
+          apps/basic apps/interlink apps/intel_mp \
+          apps/ipv6/nd_light.lua lib/pcap \
           program/vita program/config program/ps program/pci_bind \
           program/top program/shm
 
 INCLUDE_TEST = $(INCLUDE) \
-               lib/pmu* apps/basic apps/test apps/packet_filter apps/ipv4 \
-               lib/pcap apps/pcap \
+               lib/pmu* apps/test apps/packet_filter apps/ipv4 \
                program/snsh program/snabbmark \
-               lib/virtio apps/vhost apps/ipsec apps/ipv6 \
-               apps/lwaftr/{loadgen,lwutil,constants}.* program/loadtest
+               lib/virtio apps/vhost apps/ipsec apps/pcap \
+               apps/lwaftr/lwutil.* apps/lwaftr/constants.* \
+               apps/lwaftr/loadgen.* program/loadtest
 
 all:
 	INCLUDE='$(INCLUDE)' $(MAKE)

src/apps/intel_mp/README.md

@@ -72,18 +72,19 @@ For a given NIC, all driver instances should have this parameter either
 enabled or disabled uniformly. If this is enabled, *macaddr* must be
 specified.
 
-— Key **vmdq_queuing_mode**
+— Key **vmdq_queueing_mode**
 
-*Optional*. Sets the queuing mode to use in VMDq mode. Has no effect when
-VMDq is disabled. The available queuing modes are `"rss-64-2"`
+*Optional*. Sets the queueing mode to use in VMDq mode. Has no effect when
+VMDq is disabled. The available queueing modes for the 82599 are `"rss-64-2"`
 (the default with 64 pools, 2 queues each) and `"rss-32-4"`
-(32 pools, 4 queues each).
+(32 pools, 4 queues each). The i350 provides only a single mode (8 pools, 2
+queues each) and hence ignores this option.
 
 — Key **poolnum**
 
 *Optional*. The VMDq pool to associate with, numbered from 0. The default
 is to select a pool number automatically. The maximum pool number depends
-on the queuing mode.
+on the queueing mode.
 
 — Key **macaddr**
 
@@ -203,4 +204,5 @@ Each chipset supports a differing number of receive / transmit queues:
 
 The Intel82599 supports both VMDq and RSS with 32/64 pools and 4/2 RSS queues for
 each pool.
-While the i350 supports VMDq, this driver does not currently support it.
+Intel1g i350 supports both VMDq and RSS with 8 pools 2 queues for each pool.
+Intel1g i210 does not support VMDq.