Skip to content

Commit

Permalink
Merge remote-tracking branch 'origin/master' into ddlog2
Browse files Browse the repository at this point in the history
  • Loading branch information
@justinpettit
justinpettit committed Mar 1, 2019
2 parents 1b3b281 + cac3eca commit a656467
Show file tree
Hide file tree
Showing 107 changed files with 5,588 additions and 1,181 deletions.
1 change: 0 additions & 1 deletion .travis.yml
View file
Expand Up @@ -33,7 +33,6 @@ env:
- TESTSUITE=1 KERNEL=3.16.54
- TESTSUITE=1 OPTS="--enable-shared"
- BUILD_ENV="-m32" OPTS="--disable-ssl"
- KERNEL=3.16.54 DPDK=1
- KERNEL=3.16.54 DPDK=1 OPTS="--enable-shared"
- KERNEL=3.16.54 TESTSUITE=1 DPDK=1
- KERNEL=3.16.54 DPDK_SHARED=1
Expand Down
39 changes: 24 additions & 15 deletions .travis/linux-build.sh
View file
@@ -1,6 +1,7 @@
#!/bin/bash

set -o errexit
set -x

KERNELSRC=""
CFLAGS="-Werror"
Expand Down Expand Up @@ -43,7 +44,7 @@ function install_kernel()
fi

KERNELSRC=$(pwd)
if [ ! "$DPDK" ]; then
if [ ! "$DPDK" ] && [ ! "$DPDK_SHARED" ]; then
EXTRA_OPTS="--with-linux=$(pwd)"
fi
echo "Installed kernel source in $(pwd)"
Expand Down Expand Up @@ -72,14 +73,14 @@ function install_dpdk()
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$(pwd)/$TARGET/lib
fi
make config CC=gcc T=$TARGET
make CC=gcc RTE_KERNELDIR=$KERNELSRC
make -j4 CC=gcc RTE_KERNELDIR=$KERNELSRC
echo "Installed DPDK source in $(pwd)"
cd ..
}

function configure_ovs()
{
./boot.sh && ./configure $*
./boot.sh && ./configure $* || { cat config.log; exit 1; }
}

if [ "$KERNEL" ] || [ "$DPDK" ] || [ "$DPDK_SHARED" ]; then
Expand All @@ -95,36 +96,44 @@ if [ "$DPDK" ] || [ "$DPDK_SHARED" ]; then
# Disregard cast alignment errors until DPDK is fixed
CFLAGS="$CFLAGS -Wno-cast-align"
fi
EXTRA_OPTS="$EXTRA_OPTS --with-dpdk=./dpdk-$DPDK_VER/build"
EXTRA_OPTS="$EXTRA_OPTS --with-dpdk=$(pwd)/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 $*

make selinux-policy

# Only build datapath if we are testing kernel w/o running testsuite
if [ "$KERNEL" ] && [ ! "$TESTSUITE" ] && [ ! "$DPDK" ]; then
cd datapath
fi
OPTS="$EXTRA_OPTS $*"

if [ "$CC" = "clang" ]; then
make -j2 CFLAGS="$CFLAGS -Wno-error=unused-command-line-argument"
export OVS_CFLAGS="$CFLAGS -Wno-error=unused-command-line-argument"
elif [[ $BUILD_ENV =~ "-m32" ]]; then
# Disable sparse for 32bit builds on 64bit machine
make -j2 CFLAGS="$CFLAGS $BUILD_ENV"
export OVS_CFLAGS="$CFLAGS $BUILD_ENV"
else
make -j2 CFLAGS="$CFLAGS $BUILD_ENV $SPARSE_FLAGS" C=1
OPTS="$OPTS --enable-sparse"
export OVS_CFLAGS="$CFLAGS $BUILD_ENV $SPARSE_FLAGS"
fi

if [ "$TESTSUITE" ]; then
# 'distcheck' will reconfigure with required options.
# Now we only need to prepare the Makefile wihtout sparse-wrapped CC.
configure_ovs

export DISTCHECK_CONFIGURE_FLAGS="$OPTS"
if ! make distcheck TESTSUITEFLAGS=-j4 RECHECK=yes; then
# testsuite.log is necessary for debugging.
cat */_build/tests/testsuite.log
exit 1
fi
else
configure_ovs $OPTS
make selinux-policy

# Only build datapath if we are testing kernel w/o running testsuite
if [ "$KERNEL" ] && [ ! "$DPDK" ] && [ ! "$DPDK_SHARED" ]; then
cd datapath
fi
make -j4
fi

exit 0
2 changes: 1 addition & 1 deletion .travis/linux-prepare.sh
View file
Expand Up @@ -8,7 +8,7 @@ set -ev
# environments claim to have LLVM (llvm-config exists and works) but
# linking against it fails.
git clone git://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git
cd sparse && make HAVE_LLVM= install && cd ..
cd sparse && make -j4 HAVE_LLVM= install && cd ..

pip install --disable-pip-version-check --user six flake8 hacking
pip install --user --upgrade docutils
4 changes: 4 additions & 0 deletions AUTHORS.rst
View file
Expand Up @@ -77,6 +77,7 @@ Bert Vermeulen bert@biot.com
Bhanuprakash Bodireddy bhanuprakash.bodireddy@intel.com
Billy O'Mahony billy.o.mahony@intel.com
Binbin Xu xu.binbin1@zte.com.cn
Brian Haley haleyb.dev@gmail.com
Brian Kruger bkruger+ovsdev@gmail.com
Bruce Davie bdavie@vmware.com
Bryan Phillippe bp@toroki.com
Expand Down Expand Up @@ -122,6 +123,7 @@ Ed Maste emaste@freebsd.org
Ed Swierk eswierk@skyportsystems.com
Edouard Bourguignon madko@linuxed.net
Eelco Chaudron echaudro@redhat.com
Eli Britstein elibr@mellanox.com
Eric Lapointe elapointe@corsa.com
Esteban Rodriguez Betancourt estebarb@hpe.com
Aymerich Edward edward.aymerich@hpe.com
Expand Down Expand Up @@ -245,6 +247,7 @@ Martino Fornasa mf@fornasa.it
Martin Xu martinxu9.ovs@gmail.com
Maryam Tahhan maryam.tahhan@intel.com
Matteo Croce mcroce@redhat.com
Matthias May matthias.may@neratec.com
Mauricio Vásquez mauricio.vasquezbernal@studenti.polito.it
Maxime Coquelin maxime.coquelin@redhat.com
Mehak Mahajan
Expand All @@ -255,6 +258,7 @@ Miguel Angel Ajo majopela@redhat.com
Mijo Safradin mijo@linux.vnet.ibm.com
Mika Vaisanen mika.vaisanen@gmail.com
Minoru TAKAHASHI takahashi.minoru7@gmail.com
Moshe Levi moshele@mellanox.com
Murphy McCauley murphy.mccauley@gmail.com
Natasha Gude
Neal Shrader neal@digitalocean.com
Expand Down
52 changes: 27 additions & 25 deletions Documentation/faq/releases.rst
View file
Expand Up @@ -105,31 +105,32 @@ Q: Are all features available with all datapaths?
The following table lists the datapath supported features from an Open
vSwitch user's perspective.

===================== ============== ============== ========= =======
Feature Linux upstream Linux OVS tree Userspace Hyper-V
===================== ============== ============== ========= =======
NAT 4.6 YES Yes NO
Connection tracking 4.3 YES PARTIAL PARTIAL
Tunnel - LISP NO YES NO NO
Tunnel - STT NO YES NO YES
Tunnel - GRE 3.11 YES YES YES
Tunnel - VXLAN 3.12 YES YES YES
Tunnel - Geneve 3.18 YES YES YES
Tunnel - GRE-IPv6 4.18 YES YES NO
Tunnel - VXLAN-IPv6 4.3 YES YES NO
Tunnel - Geneve-IPv6 4.4 YES YES NO
Tunnel - ERSPAN 4.18 YES YES NO
Tunnel - ERSPAN-IPv6 4.18 YES YES NO
QoS - Policing YES YES YES NO
QoS - Shaping YES YES NO NO
sFlow YES YES YES NO
IPFIX 3.10 YES YES NO
Set action YES YES YES PARTIAL
NIC Bonding YES YES YES YES
Multiple VTEPs YES YES YES YES
Meters 4.15 YES YES NO
Conntrack zone limit 4.18 YES NO NO
===================== ============== ============== ========= =======
========================== ============== ============== ========= =======
Feature Linux upstream Linux OVS tree Userspace Hyper-V
========================== ============== ============== ========= =======
Connection tracking 4.3 YES YES YES
Conntrack Fragment Reass. 4.3 YES YES YES
NAT 4.6 YES YES NO
Conntrack zone limit 4.18 YES NO NO
Tunnel - LISP NO YES NO NO
Tunnel - STT NO YES NO YES
Tunnel - GRE 3.11 YES YES YES
Tunnel - VXLAN 3.12 YES YES YES
Tunnel - Geneve 3.18 YES YES YES
Tunnel - GRE-IPv6 4.18 YES YES NO
Tunnel - VXLAN-IPv6 4.3 YES YES NO
Tunnel - Geneve-IPv6 4.4 YES YES NO
Tunnel - ERSPAN 4.18 YES YES NO
Tunnel - ERSPAN-IPv6 4.18 YES YES NO
QoS - Policing YES YES YES NO
QoS - Shaping YES YES NO NO
sFlow YES YES YES NO
IPFIX 3.10 YES YES NO
Set action YES YES YES PARTIAL
NIC Bonding YES YES YES YES
Multiple VTEPs YES YES YES YES
Meters 4.15 YES YES NO
========================== ============== ============== ========= =======

Do note, however:

Expand Down Expand Up @@ -176,6 +177,7 @@ Q: What DPDK version does each Open vSwitch release work with?
2.8.x 17.05.2
2.9.x 17.11.4
2.10.x 17.11.4
2.11.x 18.11
============ =======

Q: Are all the DPDK releases that OVS versions work with maintained?
Expand Down
78 changes: 75 additions & 3 deletions Documentation/ref/ovsdb-server.7.rst
View file
Expand Up @@ -364,7 +364,79 @@ Initial views of rows are not presented in update2 notifications, but in the
response object to the ``monitor_cond`` request. The formatting of the
<table-updates2> object, however, is the same in either case.

4.1.15 Get Server ID
4.1.15 Monitor_cond_since
-------------------------

A new monitor method added in Open vSwitch version 2.12. The
``monitor_cond_since`` request enables a client to request changes that
happened after a specific transaction id. A client can use this feature to
request only latest changes after a server connection reset instead of
re-transfer all data from the server again.

The ``monitor_cond`` method described in Section 4.1.12 also applies to
``monitor_cond_since``, with the following exceptions:

* RPC request method becomes ``monitor_cond_since``.

* Reply result includes extra parameters.

* Subsequent changes are sent to the client using the ``update3`` monitor
notification, described in Section 4.1.16

The request object has the following members::

"method": "monitor_cond_since"
"params": [<db-name>, <json-value>, <monitor-cond-requests>, <last-txn-id>]
"id": <nonnull-json-value>

The <last-txn-id> parameter is the transaction id that identifies the latest
data the client already has, and it requests server to send changes AFTER this
transaction (exclusive).

All other parameters are the same as ``monitor_cond`` method.

The response object has the following members::

"result": [<found>, <last-txn-id>, <table-updates2>]
"error": null
"id": same "id" as request

The <found> is a boolean value that tells if the <last-txn-id> requested by
client is found in server's history or not. If true, the changes after that
version up to current is sent. Otherwise, all data is sent.

The <last-txn-id> is the transaction id that identifies the latest transaction
included in the changes in <table-updates2> of this response, so that client
can keep tracking. If there is no change involved in this response, it is the
same as the <last-txn-id> in the request if <found> is true, or zero uuid if
<found> is false. If the server does not support transaction uuid, it will
be zero uuid as well.

All other parameters are the same as in response object of ``monitor_cond``
method.

Like in ``monitor_cond``, subsequent changes that match conditions in
<monitor-cond-request> are automatically sent to the client, but using
``update3`` monitor notification (see Section 4.1.16), instead of ``update2``.

4.1.16 Update3 notification
---------------------------

The ``update3`` notification is sent by the server to the client to report
changes in tables that are being monitored following a ``monitor_cond_since``
request as described above. The notification has the following members::

"method": "update3"
"params": [<json-value>, <last-txn-id>, <table-updates2>]
"id": null

The <last-txn-id> is the same as described in the response object of
``monitor_cond_since``.

All other parameters are the same as in ``update2`` monitor notification (see
Section 4.1.14).

4.1.17 Get Server ID
--------------------

A new RPC method added in Open vSwitch version 2.7. The request contains the
Expand All @@ -384,7 +456,7 @@ The response object contains the following members::
running OVSDB server process. A fresh UUID is generated when the process
restarts.

4.1.16 Database Change Awareness
4.1.18 Database Change Awareness
--------------------------------

RFC 7047 does not provide a way for a client to find out about some kinds of
Expand Down Expand Up @@ -414,7 +486,7 @@ The reply is always the same::
"error": null
"id": same "id" as request

4.1.17 Schema Conversion
4.1.19 Schema Conversion
------------------------

Open vSwitch 2.9 adds a new JSON-RPC request to convert an online database from
Expand Down

0 comments on commit a656467

Please sign in to comment.