Merge "master" into "ovn".

This brings in STT.

Conflicts:
	tutorial/ovs-sandbox

.gitignore

@@ -66,3 +66,4 @@ _debian
 odp-netlink.h
 OvsDpInterface.h
 /.vagrant/
+testsuite.tmp.orig

.travis/build.sh

@@ -38,9 +38,9 @@ function install_kernel()
 function install_dpdk()
 {
     if [ -n "$DPDK_GIT" ]; then
-	git clone $DPDK_GIT dpdk-$1
-	cd dpdk-$1
-	git checkout v$1
+        git clone $DPDK_GIT dpdk-$1
+        cd dpdk-$1
+        git checkout v$1
     else
         wget http://www.dpdk.org/browse/dpdk/snapshot/dpdk-$1.tar.gz
         tar xzvf dpdk-$1.tar.gz > /dev/null
@@ -49,6 +49,7 @@ function install_dpdk()
     find ./ -type f | xargs sed -i 's/max-inline-insns-single=100/max-inline-insns-single=400/'
     sed -ri 's,(CONFIG_RTE_BUILD_COMBINE_LIBS=).*,\1y,' config/common_linuxapp
     sed -ri 's,(CONFIG_RTE_LIBRTE_VHOST=).*,\1y,' config/common_linuxapp
+    sed -ri 's,(CONFIG_RTE_LIBRTE_VHOST_USER=).*,\1n,' config/common_linuxapp
     sed -ri '/CONFIG_RTE_LIBNAME/a CONFIG_RTE_BUILD_FPIC=y' config/common_linuxapp
     sed -ri '/EXECENV_CFLAGS  = -pthread -fPIC/{s/$/\nelse ifeq ($(CONFIG_RTE_BUILD_FPIC),y)/;s/$/\nEXECENV_CFLAGS  = -pthread -fPIC/}' mk/exec-env/linuxapp/rte.vars.mk
     make config CC=gcc T=x86_64-native-linuxapp-gcc
@@ -68,25 +69,27 @@ fi
 
 if [ "$DPDK" ]; then
     if [ -z "$DPDK_VER" ]; then
-	    DPDK_VER="1.8.0"
+        DPDK_VER="2.0.0"
     fi
     install_dpdk $DPDK_VER
-    # Disregard bad function casts until DPDK is fixed
-    CFLAGS="$CFLAGS -Wno-error=bad-function-cast -Wno-error=cast-align"
-    EXTRA_OPTS+="--with-dpdk=./dpdk-$DPDK_VER/build"
-elif [ $CC != "clang" ]; then
+    if [ "$CC" = "clang" ]; then
+        # Disregard cast alignment errors until DPDK is fixed
+        EXTRA_OPTS="$EXTRA_OPTS -Wno-cast-align"
+    fi
+    EXTRA_OPTS="$EXTRA_OPTS --with-dpdk=./dpdk-$DPDK_VER/build"
+elif [ "$CC" != "clang" ]; then
     # DPDK headers currently trigger sparse errors
     SPARSE_FLAGS="$SPARSE_FLAGS -Wsparse-error"
 fi
 
 configure_ovs $EXTRA_OPTS $*
 
 # Only build datapath if we are testing kernel w/o running testsuite
-if [ $KERNEL ] && [ ! "$TESTSUITE" ] && [ ! "$DPDK" ]; then
+if [ "$KERNEL" ] && [ ! "$TESTSUITE" ] && [ ! "$DPDK" ]; then
     cd datapath
 fi
 
-if [ $CC = "clang" ]; then
+if [ "$CC" = "clang" ]; then
     make CFLAGS="$CFLAGS -Wno-error=unused-command-line-argument"
 elif [[ $BUILD_ENV =~ "-m32" ]]; then
     # Disable sparse for 32bit builds on 64bit machine
@@ -95,7 +98,7 @@ else
     make CFLAGS="$CFLAGS $BUILD_ENV $SPARSE_FLAGS" C=1
 fi
 
-if [ $TESTSUITE ] && [ $CC != "clang" ]; then
+if [ "$TESTSUITE" ] && [ "$CC" != "clang" ]; then
     if ! make distcheck; then
         # testsuite.log is necessary for debugging.
         cat */_build/tests/testsuite.log

.travis/prepare.sh

@@ -1,11 +1,11 @@
 #!/bin/bash
 
-sudo apt-get update -qq
-sudo apt-get install -qq libssl-dev llvm-dev
-sudo apt-get install -qq gcc-multilib
+sudo -E apt-get update -qq
+sudo -E apt-get install -qq libssl-dev llvm-dev
+sudo -E apt-get install -qq gcc-multilib
 if [ "$DPDK" ]; then
-    sudo apt-get install -qq libfuse-dev
+    sudo -E apt-get install -qq libfuse-dev
 fi
 
 git clone git://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git
-cd sparse && make && sudo make install PREFIX=/usr && cd ..
+cd sparse && make && sudo -E make install PREFIX=/usr && cd ..

AUTHORS

@@ -24,6 +24,7 @@ Arun Sharma             [email protected]
 Aryan TaheriMonfared    [email protected]
 Ashwin Swaminathan      [email protected]
 Ben Pfaff               [email protected]
+Billy O'Mahony          [email protected]
 Brian Kruger            [email protected]
 Bruce Davie             [email protected]
 Bryan Phillippe         [email protected]
@@ -171,6 +172,7 @@ Thomas Lacroix          [email protected]
 Todd Deshane            [email protected]
 Tom Everman             [email protected]
 Tsvi Slonim             [email protected]
+Tuan Nguyen             [email protected]
 Tyler Coumbes           [email protected]
 Valient Gough           [email protected]
 Vivien Bernet-Rollande  [email protected]
@@ -229,6 +231,7 @@ Chunhe Li               [email protected]
 Ciara Loftus            [email protected]
 Daniel Badea            [email protected]
 Dave Walker             [email protected]
+David Evans             [email protected]
 David Palma             [email protected]
 Derek Cormier           [email protected]
 Dhaval Badiani          [email protected]
@@ -255,6 +258,7 @@ Henrik Amren            [email protected]
 Hiroshi Tanaka          [email protected]
 Hiroshi Miyata          [email protected]
 Hyojoon Kim             [email protected]
+Ian Stokes              [email protected]
 Igor Ganichev           [email protected]
 Igor Sever              [email protected]
 Jacob Cherkas           [email protected]
@@ -360,6 +364,7 @@ likunyun                [email protected]
 rahim entezari          [email protected]
 冯全树(Crab)            [email protected]
 胡靖飞                  [email protected]
+张伟                     [email protected]
 
 Thanks to all Open vSwitch contributors.  If you are not listed above
 but believe that you should be, please write to [email protected].

FAQ.md

@@ -173,14 +173,23 @@ A: The following table lists the Linux kernel versions against which the
 
    What should I do?
 
-A: If there is a newer version of Open vSwitch, consider building that
-   one, because it may support the kernel that you are building
-   against.  (To find out, consult the table in the previous answer.)
+A: You have the following options:
 
-   Otherwise, use the Linux kernel module supplied with the kernel
-   that you are using.  All versions of Open vSwitch userspace are
-   compatible with all versions of the Open vSwitch kernel module, so
-   this will also work.  See also the following question.
+   - Use the Linux kernel module supplied with the kernel that you are
+     using.  (See also the following FAQ.)
+
+   - If there is a newer released version of Open vSwitch, consider
+     building that one, because it may support the kernel that you are
+     building against.  (To find out, consult the table in the
+     previous FAQ.)
+
+   - The Open vSwitch "master" branch may support the kernel that you
+     are using, so consider building the kernel module from "master".
+
+  All versions of Open vSwitch userspace are compatible with all
+  versions of the Open vSwitch kernel module, so you do not have to
+  use the kernel module from one source along with the userspace
+  programs from the same source.
 
 ### Q: What features are not available in the Open vSwitch kernel datapath that ships as part of the upstream Linux kernel?
 
@@ -209,6 +218,7 @@ A: Support for tunnels was added to the upstream Linux kernel module
 | VXLAN    |    3.12
 | Geneve   |    3.18
 | LISP     | <not upstream>
+| STT      | <not upstream>
 
    If you are using a version of the kernel that is older than the one
    listed above, it is still possible to use that tunnel protocol. However,
@@ -350,6 +360,25 @@ A: Yes.  How you configure it depends on what you mean by "promiscuous
     SPAN, see "How do I configure a port as a SPAN port, that is,
     enable mirroring of all traffic to that port?"
 
+### Q: How do I configure a DPDK port as an access port?
+
+A: Firstly, you must have a DPDK-enabled version of Open vSwitch.
+
+   If your version is DPDK-enabled it will support the --dpdk
+   argument on the command line and will display lines with
+   "EAL:..." during startup when --dpdk is supplied.
+
+   Secondly, when adding a DPDK port, unlike a system port, the
+   type for the interface must be specified. For example;
+
+       ovs-vsctl add-br br0
+       ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk
+
+   Finally, it is required that DPDK port names begin with 'dpdk'.
+
+   See [INSTALL.DPDK.md] for more information on enabling and using DPDK with
+   Open vSwitch.
+
 ### Q: How do I configure a VLAN as an RSPAN VLAN, that is, enable mirroring of all traffic to that VLAN?
 
 A: The following commands configure br0 with eth0 as a trunk port and
@@ -639,6 +668,9 @@ A: More than likely, you've looped your network.  Probably, eth0 and
      documentation on the Port table in ovs-vswitchd.conf.db(5)
      for all the details.
 
+     Configuration for DPDK-enabled interfaces is slightly less
+     straightforward: see [INSTALL.DPDK.md].
+
    - Perhaps you don't actually need eth0 and eth1 to be on the
      same bridge.  For example, if you simply want to be able to
      connect each of them to virtual machines, then you can put
@@ -823,6 +855,92 @@ A: Open vSwitch wasn't able to create the port.  Check the
    ovs-vsctl will immediately report when there is an issue creating a
    port.
 
+### Q: I created a tap device tap0, configured an IP address on it, and
+    added it to a bridge, like this:
+
+        tunctl -t tap0
+	ifconfig tap0 192.168.0.123
+	ovs-vsctl add-br br0
+	ovs-vsctl add-port br0 tap0
+
+    I expected that I could then use this IP address to contact other
+    hosts on the network, but it doesn't work.  Why not?
+
+A: The short answer is that this is a misuse of a "tap" device.  Use
+   an "internal" device implemented by Open vSwitch, which works
+   differently and is designed for this use.  To solve this problem
+   with an internal device, instead run:
+
+       ovs-vsctl add-br br0
+       ovs-vsctl add-port br0 int0 -- set Interface int0 type=internal
+       ifconfig int0 192.168.0.123
+
+   Even more simply, you can take advantage of the internal port that
+   every bridge has under the name of the bridge:
+
+       ovs-vsctl add-br br0
+       ifconfig br0 192.168.0.123
+
+   In more detail, a "tap" device is an interface between the Linux
+   (or *BSD) network stack and a user program that opens it as a
+   socket.  When the "tap" device transmits a packet, it appears in
+   the socket opened by the userspace program.  Conversely, when the
+   userspace program writes to the "tap" socket, the kernel TCP/IP
+   stack processes the packet as if it had been received by the "tap"
+   device.
+
+   Consider the configuration above.  Given this configuration, if you
+   "ping" an IP address in the 192.168.0.x subnet, the Linux kernel
+   routing stack will transmit an ARP on the tap0 device.  Open
+   vSwitch userspace treats "tap" devices just like any other network
+   device; that is, it doesn't open them as "tap" sockets.  That means
+   that the ARP packet will simply get dropped.
+
+   You might wonder why the Open vSwitch kernel module doesn't
+   intercept the ARP packet and bridge it.  After all, Open vSwitch
+   intercepts packets on other devices.  The answer is that Open
+   vSwitch only intercepts *received* packets, but this is a packet
+   being transmitted.  The same thing happens for all other types of
+   network devices, except for Open vSwitch "internal" ports.  If you,
+   for example, add a physical Ethernet port to an OVS bridge,
+   configure an IP address on a physical Ethernet port, and then issue
+   a "ping" to an address in that subnet, the same thing happens: an
+   ARP gets transmitted on the physical Ethernet port and Open vSwitch
+   never sees it.  (You should not do that, as documented at the
+   beginning of this section.)
+
+   It can make sense to add a "tap" device to an Open vSwitch bridge,
+   if some userspace program (other than Open vSwitch) has opened the
+   tap socket.  This is the case, for example, if the "tap" device was
+   created by KVM (or QEMU) to simulate a virtual NIC.  In such a
+   case, when OVS bridges a packet to the "tap" device, the kernel
+   forwards that packet to KVM in userspace, which passes it along to
+   the VM, and in the other direction, when the VM sends a packet, KVM
+   writes it to the "tap" socket, which causes OVS to receive it and
+   bridge it to the other OVS ports.  Please note that in such a case
+   no IP address is configured on the "tap" device (there is normally
+   an IP address configured in the virtual NIC inside the VM, but this
+   is not visible to the host Linux kernel or to Open vSwitch).
+
+   There is one special case in which Open vSwitch does directly read
+   and write "tap" sockets.  This is an implementation detail of the
+   Open vSwitch userspace switch, which implements its "internal"
+   ports as Linux (or *BSD) "tap" sockets.  In such a userspace
+   switch, OVS receives packets sent on the "tap" device used to
+   implement an "internal" port by reading the associated "tap"
+   socket, and bridges them to the rest of the switch.  In the other
+   direction, OVS transmits packets bridged to the "internal" port by
+   writing them to the "tap" socket, causing them to be processed by
+   the kernel TCP/IP stack as if they had been received on the "tap"
+   device.  Users should not need to be concerned with this
+   implementation detail.
+
+   Open vSwitch has a network device type called "tap".  This is
+   intended only for implementing "internal" ports in the OVS
+   userspace switch and should not be used otherwise.  In particular,
+   users should not configure KVM "tap" devices as type "tap" (use
+   type "system", the default, instead).
+
 
 Quality of Service (QoS)
 ------------------------
@@ -1801,3 +1919,4 @@ http://openvswitch.org/
 [WHY-OVS.md]:WHY-OVS.md
 [INSTALL.md]:INSTALL.md
 [OPENFLOW-1.1+.md]:OPENFLOW-1.1+.md
+[INSTALL.DPDK.md]:INSTALL.DPDK.md