Re: [ovs-dev] [CudaMailTagged] [patch_v1] ovn: Add additional comments regarding arp responders.

[Han Zhou]

On Tue, Sep 27, 2016 at 5:11 PM, Darrell Ball  wrote:

>>
>> These port types are skipped because ARP responder is not supposed to
handle ARP requests that come from physical network.
>
>
> There is a special case of the l2gateway where
> a request comes from the physical network destined to a VM
> somewhere; this is north->south traffic. This traffic hits a single
> l2gateway inport and is associated with a logical switch.
> There will be an arp responder on this source HV in gateway role.
> Hence, there would be a single arp reply back out to the physical network.
>

Agree. So my "because ..." part was not accurate.

>
>>
>> Otherwise, because all the chassises receiving the requests will reply,
there will be redundant responses.
>
>
> I got your point; let me roll in and elaborate a bit ?
>
> "These port types are skipped.  Otherwise the arp
> request is received by multiple hypervisors, which all have the
> same mac binding downloaded from northd, which will cause
> redundant arp replies, confusing the originator of the arp request. "
>

Sounds good to me.
Acked-by: Han Zhou 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3 2/4] ovn: OCF script for OVN OVSDB servers

[Babu Shanmugam]

Hi Andrew,

I have added "Signed-off-by" on your behalf. Hope you don't mind.


On Wednesday 28 September 2016 10:00 AM, bscha...@redhat.com wrote:

From: Babu Shanmugam 

Co-authored-by: Numan Siddique 
Signed-off-by: Numan Siddique 
Co-authored-by: Andrew Beekhof 
Signed-off-by: Andrew Beekhof 
Signed-off-by: Babu Shanmugam 
---
  ovn/utilities/automake.mk   |   6 +-
  ovn/utilities/ovndb-servers.ocf | 349 
  2 files changed, 353 insertions(+), 2 deletions(-)
  create mode 100755 ovn/utilities/ovndb-servers.ocf

diff --git a/ovn/utilities/automake.mk b/ovn/utilities/automake.mk
index b03d125..164cdda 100644
--- a/ovn/utilities/automake.mk
+++ b/ovn/utilities/automake.mk
@@ -1,5 +1,6 @@
  scripts_SCRIPTS += \
-ovn/utilities/ovn-ctl
+ovn/utilities/ovn-ctl \
+ovn/utilities/ovndb-servers.ocf
  
  man_MANS += \

  ovn/utilities/ovn-ctl.8 \
@@ -20,7 +21,8 @@ EXTRA_DIST += \
  ovn/utilities/ovn-docker-overlay-driver \
  ovn/utilities/ovn-docker-underlay-driver \
  ovn/utilities/ovn-nbctl.8.xml \
-ovn/utilities/ovn-trace.8.xml
+ovn/utilities/ovn-trace.8.xml \
+ovn/utilities/ovndb-servers.ocf
  
  DISTCLEANFILES += \

  ovn/utilities/ovn-ctl.8 \
diff --git a/ovn/utilities/ovndb-servers.ocf b/ovn/utilities/ovndb-servers.ocf
new file mode 100755
index 000..bb6c9dc
--- /dev/null
+++ b/ovn/utilities/ovndb-servers.ocf
@@ -0,0 +1,349 @@
+#!/bin/bash
+
+: ${OCF_FUNCTIONS_DIR=${OCF_ROOT}/lib/heartbeat}
+. ${OCF_FUNCTIONS_DIR}/ocf-shellfuncs
+: ${OVN_CTL_DEFAULT="/usr/share/openvswitch/scripts/ovn-ctl"}
+CRM_MASTER="${HA_SBIN_DIR}/crm_master -l reboot"
+CRM_ATTR_REPL_INFO="${HA_SBIN_DIR}/crm_attribute --type crm_config --name 
OVN_REPL_INFO -s ovn_ovsdb_master_server"
+OVN_CTL=${OCF_RESKEY_ovn_ctl:-${OVN_CTL_DEFAULT}}
+MASTER_IP=${OCF_RESKEY_master_ip}
+
+# Invalid IP address is an address that can never exist in the network, as
+# mentioned in rfc-5737. The ovsdb servers connects to this IP address till
+# a master is promoted and the IPAddr2 resource is started.
+INVALID_IP_ADDRESS=192.0.2.254
+
+host_name=$(ocf_local_nodename)
+: ${slave_score=5}
+: ${master_score=10}
+
+ovsdb_server_metadata() {
+cat <
+
+
+  1.0
+
+  
+This resource manages ovsdb-server.
+  
+
+  
+Manages ovsdb-server.
+  
+
+  
+
+  
+  
+  Location to the ovn-ctl script file
+  
+  ovn-ctl script
+  
+  
+
+  
+  
+  The IP address resource which will be available on the master ovsdb server
+  
+  master ip address
+  
+  
+
+  
+
+  
+
+
+
+
+
+
+
+
+  
+
+END
+exit $OCF_SUCCESS
+}
+
+ovsdb_server_notify() {
+# requires the notify=true meta resource attribute
+local 
type_op="${OCF_RESKEY_CRM_meta_notify_type}-${OCF_RESKEY_CRM_meta_notify_operation}"
+
+if [ "$type_op" != "post-promote" ]; then
+# We are only interested in specific events
+return $OCF_SUCCESS
+fi
+
+if [ "x${OCF_RESKEY_CRM_meta_notify_promote_uname}" = "x${host_name}" ]; 
then
+# Record ourselves so that the agent has a better chance of doing
+# the right thing at startup
+${CRM_ATTR_REPL_INFO} -v "$host_name"
+
+else
+# Synchronize with the new master
+${OVN_CTL} demote_ovnnb --db-nb-sync-from-addr=${MASTER_IP}
+${OVN_CTL} demote_ovnsb --db-sb-sync-from-addr=${MASTER_IP}
+fi
+}
+
+ovsdb_server_usage() {
+cat < Stop -> Start -> Promote
+# At the point this is run, the only active masters will be
+# previous masters minus any that were scheduled to be demoted
+
+for master in ${OCF_RESKEY_CRM_meta_notify_master_uname}; do
+found=0
+for old in ${OCF_RESKEY_CRM_meta_notify_demote_uname}; do
+if [ $master = $old ]; then
+found=1
+fi
+done
+if [ $found = 0 ]; then
+# Rely on master-max=1
+# Pacemaker will demote any additional ones it finds before 
starting new copies
+echo "$master"
+return
+fi
+done
+
+local expected_master=$($CRM_ATTR_REPL_INFO --query  -q 2>/dev/null)
+case "x${OCF_RESKEY_CRM_meta_notify_start_uname}x" in
+*${expected_master}*) echo "${expected_master}";; # The previous 
master is expected to start
+esac
+}
+
+ovsdb_server_find_active_peers() {
+# Do we have any peers that are not stopping
+for peer in ${OCF_RESKEY_CRM_meta_notify_slave_uname}; do
+found=0
+for old in ${OCF_RESKEY_CRM_meta_notify_stop_uname}; do
+if [ $peer = $old ]; then
+found=1
+fi
+done
+if [ $found = 0 ]; then
+# Rely on master-max=1
+# Pacemaker will demote any additional ones it finds before 
starting new copies
+echo "$peer"
+return
+fi
+ 

[ovs-dev] [PATCH v3 4/4] ovn: Add ovndb servers ocf script in debian packager

[bschanmu]

From: Babu Shanmugam 

The OCF script will be present in the ovn-common package and installed
in the openvswitch scripts folder and a symbolic link to this file will
be created in the OCF resources folder.

The OCF resource agent name for this resource is ocf:ovn:ovndb-servers

Signed-off-by: Babu Shanmugam 
---
 debian/automake.mk |  2 ++
 debian/ovn-common.install  |  1 +
 debian/ovn-common.postinst | 24 
 debian/ovn-common.postrm   | 23 +++
 4 files changed, 50 insertions(+)
 create mode 100644 debian/ovn-common.postinst
 create mode 100644 debian/ovn-common.postrm

diff --git a/debian/automake.mk b/debian/automake.mk
index 73b4d00..f793d4f 100644
--- a/debian/automake.mk
+++ b/debian/automake.mk
@@ -63,6 +63,8 @@ EXTRA_DIST += \
debian/ovn-controller-vtep.manpages \
debian/ovn-common.install \
debian/ovn-common.manpages \
+   debian/ovn-common.postinst \
+   debian/ovn-common.postrm \
debian/ovn-docker.install \
debian/ovn-host.dirs \
debian/ovn-host.init \
diff --git a/debian/ovn-common.install b/debian/ovn-common.install
index acb1dc9..8b833dc 100644
--- a/debian/ovn-common.install
+++ b/debian/ovn-common.install
@@ -1,3 +1,4 @@
 usr/bin/ovn-nbctl
 usr/bin/ovn-sbctl
 usr/share/openvswitch/scripts/ovn-ctl
+usr/share/openvswitch/scripts/ovndb-servers.ocf
diff --git a/debian/ovn-common.postinst b/debian/ovn-common.postinst
new file mode 100644
index 000..588044f
--- /dev/null
+++ b/debian/ovn-common.postinst
@@ -0,0 +1,24 @@
+#!/bin/sh
+# postinst script for ovn-common
+#
+# see: dh_installdeb(1)
+
+set -e
+
+case "$1" in
+configure)
+mkdir -p /usr/lib/ocf/resource.d/ovn
+ln -sf /usr/share/openvswitch/scripts/ovndb-servers.ocf 
/usr/lib/ocf/resource.d/ovn/ovndb-servers
+;;
+abort-upgrade|abort-remove|abort-deconfigure)
+;;
+
+*)
+echo "postinst called with unknown argument \`$1'" >&2
+exit 1
+;;
+esac
+
+#DEBHELPER#
+
+exit 0
diff --git a/debian/ovn-common.postrm b/debian/ovn-common.postrm
new file mode 100644
index 000..9face72
--- /dev/null
+++ b/debian/ovn-common.postrm
@@ -0,0 +1,23 @@
+#!/bin/sh
+# postrm script for openvswitch-testcontroller
+#
+# see: dh_installdeb(1)
+
+set -e
+
+case "$1" in
+purge|remove)
+rm -rf /usr/lib/ocf/resource.d/ovn
+;;
+upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
+;;
+
+*)
+echo "postrm called with unknown argument \`$1'" >&2
+exit 1
+;;
+esac
+
+#DEBHELPER#
+
+exit 0
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v3 2/4] ovn: OCF script for OVN OVSDB servers

[bschanmu]

From: Babu Shanmugam 

Co-authored-by: Numan Siddique 
Signed-off-by: Numan Siddique 
Co-authored-by: Andrew Beekhof 
Signed-off-by: Andrew Beekhof 
Signed-off-by: Babu Shanmugam 
---
 ovn/utilities/automake.mk   |   6 +-
 ovn/utilities/ovndb-servers.ocf | 349 
 2 files changed, 353 insertions(+), 2 deletions(-)
 create mode 100755 ovn/utilities/ovndb-servers.ocf

diff --git a/ovn/utilities/automake.mk b/ovn/utilities/automake.mk
index b03d125..164cdda 100644
--- a/ovn/utilities/automake.mk
+++ b/ovn/utilities/automake.mk
@@ -1,5 +1,6 @@
 scripts_SCRIPTS += \
-ovn/utilities/ovn-ctl
+ovn/utilities/ovn-ctl \
+ovn/utilities/ovndb-servers.ocf
 
 man_MANS += \
 ovn/utilities/ovn-ctl.8 \
@@ -20,7 +21,8 @@ EXTRA_DIST += \
 ovn/utilities/ovn-docker-overlay-driver \
 ovn/utilities/ovn-docker-underlay-driver \
 ovn/utilities/ovn-nbctl.8.xml \
-ovn/utilities/ovn-trace.8.xml
+ovn/utilities/ovn-trace.8.xml \
+ovn/utilities/ovndb-servers.ocf
 
 DISTCLEANFILES += \
 ovn/utilities/ovn-ctl.8 \
diff --git a/ovn/utilities/ovndb-servers.ocf b/ovn/utilities/ovndb-servers.ocf
new file mode 100755
index 000..bb6c9dc
--- /dev/null
+++ b/ovn/utilities/ovndb-servers.ocf
@@ -0,0 +1,349 @@
+#!/bin/bash
+
+: ${OCF_FUNCTIONS_DIR=${OCF_ROOT}/lib/heartbeat}
+. ${OCF_FUNCTIONS_DIR}/ocf-shellfuncs
+: ${OVN_CTL_DEFAULT="/usr/share/openvswitch/scripts/ovn-ctl"}
+CRM_MASTER="${HA_SBIN_DIR}/crm_master -l reboot"
+CRM_ATTR_REPL_INFO="${HA_SBIN_DIR}/crm_attribute --type crm_config --name 
OVN_REPL_INFO -s ovn_ovsdb_master_server"
+OVN_CTL=${OCF_RESKEY_ovn_ctl:-${OVN_CTL_DEFAULT}}
+MASTER_IP=${OCF_RESKEY_master_ip}
+
+# Invalid IP address is an address that can never exist in the network, as
+# mentioned in rfc-5737. The ovsdb servers connects to this IP address till
+# a master is promoted and the IPAddr2 resource is started.
+INVALID_IP_ADDRESS=192.0.2.254
+
+host_name=$(ocf_local_nodename)
+: ${slave_score=5}
+: ${master_score=10}
+
+ovsdb_server_metadata() {
+cat <
+
+
+  1.0
+
+  
+This resource manages ovsdb-server.
+  
+
+  
+Manages ovsdb-server.
+  
+
+  
+
+  
+  
+  Location to the ovn-ctl script file
+  
+  ovn-ctl script
+  
+  
+
+  
+  
+  The IP address resource which will be available on the master ovsdb server
+  
+  master ip address
+  
+  
+
+  
+
+  
+
+
+
+
+
+
+
+
+  
+
+END
+exit $OCF_SUCCESS
+}
+
+ovsdb_server_notify() {
+# requires the notify=true meta resource attribute
+local 
type_op="${OCF_RESKEY_CRM_meta_notify_type}-${OCF_RESKEY_CRM_meta_notify_operation}"
+
+if [ "$type_op" != "post-promote" ]; then
+# We are only interested in specific events
+return $OCF_SUCCESS
+fi
+
+if [ "x${OCF_RESKEY_CRM_meta_notify_promote_uname}" = "x${host_name}" ]; 
then
+# Record ourselves so that the agent has a better chance of doing
+# the right thing at startup
+${CRM_ATTR_REPL_INFO} -v "$host_name"
+
+else
+# Synchronize with the new master
+${OVN_CTL} demote_ovnnb --db-nb-sync-from-addr=${MASTER_IP}
+${OVN_CTL} demote_ovnsb --db-sb-sync-from-addr=${MASTER_IP}
+fi
+}
+
+ovsdb_server_usage() {
+cat < Stop -> Start -> Promote
+# At the point this is run, the only active masters will be
+# previous masters minus any that were scheduled to be demoted
+
+for master in ${OCF_RESKEY_CRM_meta_notify_master_uname}; do
+found=0
+for old in ${OCF_RESKEY_CRM_meta_notify_demote_uname}; do
+if [ $master = $old ]; then
+found=1
+fi
+done
+if [ $found = 0 ]; then
+# Rely on master-max=1
+# Pacemaker will demote any additional ones it finds before 
starting new copies
+echo "$master"
+return
+fi
+done
+
+local expected_master=$($CRM_ATTR_REPL_INFO --query  -q 2>/dev/null)
+case "x${OCF_RESKEY_CRM_meta_notify_start_uname}x" in
+*${expected_master}*) echo "${expected_master}";; # The previous 
master is expected to start
+esac
+}
+
+ovsdb_server_find_active_peers() {
+# Do we have any peers that are not stopping
+for peer in ${OCF_RESKEY_CRM_meta_notify_slave_uname}; do
+found=0
+for old in ${OCF_RESKEY_CRM_meta_notify_stop_uname}; do
+if [ $peer = $old ]; then
+found=1
+fi
+done
+if [ $found = 0 ]; then
+# Rely on master-max=1
+# Pacemaker will demote any additional ones it finds before 
starting new copies
+echo "$peer"
+return
+fi
+done
+}
+
+ovsdb_server_master_update() {
+
+case $1 in
+$OCF_SUCCESS)
+$CRM_MASTER -v ${slave_score};;
+$OCF_RUNNING_MASTER)
+

[ovs-dev] [PATCH v3 1/4] ovn: ovn-ctl support for HA ovn DB servers

[bschanmu]

From: Babu Shanmugam 

This patch adds support to start_ovsdb() function in ovn-ctl to start the
ovn db servers in backup mode. This can be done in the following ways
1. Use parameters --ovn-nb-sync-from-addr and --ovn-sb-sync-from-addr to
   set the addresses of the active server.
2. Create files $etcdir/ovnnb-active.conf and $etcdir/ovnsb-active.conf
   with the tcp url of the active servers.

Additional functions to promote a backup server to active and demote
active server to backup mode are also added in this patch

One can optionally set the DB parameters for northd in
$etcdir/ovn-northd-db-params.conf. For example,

--ovnnb-db=tcp:172.16.247.230:6641 --ovnsb-db=tcp:172.16.247.230:6642

The parameters will be used as is, by start_northd(). If this file exists,
start_northd() will not start the DB servers even if $OVN_MANAGE_OVSDB is
'yes'.

Signed-off-by: Babu Shanmugam 
---
 ovn/utilities/ovn-ctl | 173 ++
 1 file changed, 148 insertions(+), 25 deletions(-)

diff --git a/ovn/utilities/ovn-ctl b/ovn/utilities/ovn-ctl
index 07bff8a..1c1687f 100755
--- a/ovn/utilities/ovn-ctl
+++ b/ovn/utilities/ovn-ctl
@@ -26,6 +26,9 @@ for dir in "$sbindir" "$bindir" /sbin /bin /usr/sbin 
/usr/bin; do
 done
 
 
+ovnnb_active_conf_file="$etcdir/ovnnb-active.conf"
+ovnsb_active_conf_file="$etcdir/ovnsb-active.conf"
+ovn_northd_db_conf_file="$etcdir/ovn-northd-db-params.conf"
 ## - ##
 ## start ##
 ## - ##
@@ -45,6 +48,44 @@ stop_ovsdb () {
 fi
 }
 
+demote_ovnnb() {
+if test ! -z "$DB_NB_SYNC_FROM_ADDR"; then
+echo "tcp:$DB_NB_SYNC_FROM_ADDR:$DB_NB_SYNC_FROM_PORT" > 
$ovnnb_active_conf_file
+fi
+
+if test -e $ovnnb_active_conf_file; then
+ovs-appctl -t $rundir/ovnnb_db.ctl 
ovsdb-server/set-active-ovsdb-server `cat $ovnnb_active_conf_file`
+ovs-appctl -t $rundir/ovnnb_db.ctl 
ovsdb-server/connect-active-ovsdb-server
+else
+echo >&2 "$0: active server details not set"
+exit 1
+fi
+}
+
+demote_ovnsb() {
+if test ! -z "$DB_SB_SYNC_FROM_ADDR"; then
+echo "tcp:$DB_SB_SYNC_FROM_ADDR:$DB_SB_SYNC_FROM_PORT" > 
$ovnsb_active_conf_file
+fi
+
+if test -e $ovnsb_active_conf_file; then
+ovs-appctl -t $rundir/ovnsb_db.ctl 
ovsdb-server/set-active-ovsdb-server `cat $ovnsb_active_conf_file`
+ovs-appctl -t $rundir/ovnsb_db.ctl 
ovsdb-server/connect-active-ovsdb-server
+else
+echo >&2 "$0: active server details not set"
+exit 1
+fi
+}
+
+promote_ovnnb() {
+rm -f $ovnnb_active_conf_file
+ovs-appctl -t $rundir/ovnnb_db.ctl 
ovsdb-server/disconnect-active-ovsdb-server
+}
+
+promote_ovnsb() {
+rm -f $ovnsb_active_conf_file
+ovs-appctl -t $rundir/ovnsb_db.ctl 
ovsdb-server/disconnect-active-ovsdb-server
+}
+
 start_ovsdb () {
 # Check and eventually start ovsdb-server for Northbound DB
 if ! pidfile_is_running $DB_NB_PID; then
@@ -52,7 +93,20 @@ start_ovsdb () {
 
 set ovsdb-server
 
-set "$@" --detach --monitor $OVN_NB_LOG --log-file=$OVN_NB_LOGFILE 
--remote=punix:$DB_NB_SOCK --remote=ptcp:$DB_NB_PORT:$DB_NB_ADDR 
--pidfile=$DB_NB_PID --unixctl=ovnnb_db.ctl
+set "$@" --detach --monitor $OVN_NB_LOG \
+--log-file=$OVN_NB_LOGFILE \
+--remote=punix:$DB_NB_SOCK \
+--remote=ptcp:$DB_NB_PORT:$DB_NB_ADDR \
+--pidfile=$DB_NB_PID \
+--unixctl=ovnnb_db.ctl
+
+if test ! -z "$DB_NB_SYNC_FROM_ADDR"; then
+echo "tcp:$DB_NB_SYNC_FROM_ADDR:$DB_NB_SYNC_FROM_PORT" > 
$ovnnb_active_conf_file
+fi
+
+if test -e $ovnnb_active_conf_file; then
+set "$@" --sync-from=`cat $ovnnb_active_conf_file`
+fi
 
 $@ $DB_NB_FILE
 fi
@@ -63,11 +117,45 @@ start_ovsdb () {
 
 set ovsdb-server
 
-set "$@" --detach --monitor $OVN_SB_LOG --log-file=$OVN_SB_LOGFILE 
--remote=punix:$DB_SB_SOCK --remote=ptcp:$DB_SB_PORT:$DB_SB_ADDR 
--pidfile=$DB_SB_PID --unixctl=ovnsb_db.ctl
+set "$@" --detach --monitor $OVN_SB_LOG \
+--log-file=$OVN_SB_LOGFILE \
+--remote=punix:$DB_SB_SOCK \
+--remote=ptcp:$DB_SB_PORT:$DB_SB_ADDR \
+--pidfile=$DB_SB_PID \
+--unixctl=ovnsb_db.ctl
+
+if test ! -z "$DB_SB_SYNC_FROM_ADDR"; then
+echo "tcp:$DB_SB_SYNC_FROM_ADDR:$DB_SB_SYNC_FROM_PORT" > 
$ovnsb_active_conf_file
+fi
+
+if test -e $ovnsb_active_conf_file; then
+set "$@" --sync-from=`cat $ovnsb_active_conf_file`
+fi
+
 $@ $DB_SB_FILE
 fi
 }
 
+sync_status() {
+ovs-appctl -t $rundir/ovn${1}_db.ctl ovsdb-server/sync-status | awk 
'{if(NR==1) print $2}'
+}
+
+status_ovnnb() {
+if ! pidfile_is_running $DB_NB_PID; then
+echo "not-running"
+else
+echo "running/$(sync_status nb)"
+fi
+}
+
+status_ovnsb() {
+if ! pidfile_is_running 

[ovs-dev] [PATCH v3 3/4] ovn: Add ovn db servers ocf script in fedora packager

[bschanmu]

From: Babu Shanmugam 

The OCF script will be present in the ovn-common package and installed
in the openvswitch scripts folder. A symbolic link to this file will
be created in the OCF resources folder.

The OCF resource agent name for this resource is ocf:ovn:ovndb-servers

Signed-off-by: Babu Shanmugam 
---
 rhel/openvswitch-fedora.spec.in | 8 
 1 file changed, 8 insertions(+)

diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in
index eda8767..fb4aecd 100644
--- a/rhel/openvswitch-fedora.spec.in
+++ b/rhel/openvswitch-fedora.spec.in
@@ -310,6 +310,10 @@ rm -rf $RPM_BUILD_ROOT
 fi
 %endif
 
+%post ovn-common
+mkdir /usr/lib/ocf/resource.d/ovn
+ln -sf %{_datadir}/openvswitch/scripts/ovndb-servers.ocf 
/usr/lib/ocf/resource.d/ovn/ovndb-servers
+
 %post ovn-central
 %if 0%{?systemd_post:1}
 %systemd_post ovn-northd.service
@@ -354,6 +358,9 @@ rm -rf $RPM_BUILD_ROOT
 fi
 %endif
 
+%postun ovn-common
+rm -rf /usr/lib/ocf/resource.d/ovn
+
 %postun ovn-central
 %if 0%{?systemd_postun_with_restart:1}
 %systemd_postun_with_restart ovn-northd.service
@@ -493,6 +500,7 @@ fi
 %{_bindir}/ovn-sbctl
 %{_bindir}/ovn-trace
 %{_datadir}/openvswitch/scripts/ovn-ctl
+%{_datadir}/openvswitch/scripts/ovndb-servers.ocf
 %{_datadir}/openvswitch/scripts/ovn-bugtool-nbctl-show
 %{_datadir}/openvswitch/scripts/ovn-bugtool-sbctl-lflow-list
 %{_datadir}/openvswitch/scripts/ovn-bugtool-sbctl-show
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v3 0/4] High availability support for OVN DB servers using pacemaker

[bschanmu]

v2 -> v3:
- Handling few edged cases in the OCF script as suggested by
  Andrew Beekhof

This patch contains changes required to run a pacemaker resource agent
to manage OVN db servers in active/standby mode in a HA cluster.

Babu Shanmugam (4):
  ovn: ovn-ctl support for HA ovn DB servers
  ovn: OCF script for OVN OVSDB servers
  ovn: Add ovn db servers ocf script in fedora packager
  ovn: Add ovndb servers ocf script in debian packager

 debian/automake.mk  |   2 +
 debian/ovn-common.install   |   1 +
 debian/ovn-common.postinst  |  24 +++
 debian/ovn-common.postrm|  23 +++
 ovn/utilities/automake.mk   |   6 +-
 ovn/utilities/ovn-ctl   | 173 +---
 ovn/utilities/ovndb-servers.ocf | 349 
 rhel/openvswitch-fedora.spec.in |   8 +
 8 files changed, 559 insertions(+), 27 deletions(-)
 create mode 100644 debian/ovn-common.postinst
 create mode 100644 debian/ovn-common.postrm
 create mode 100755 ovn/utilities/ovndb-servers.ocf

-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVS+DPDK: Requested device 0000:01:00.0 cannot be used

[ychen]

It is my fault, though the image version is 3.10.45, but I didn't update 
package linux-libc-dev, it is still in version 3.2
After update package linux-libc-dev, the problem gone, and process 
ovs-vswitched is up!





At 2016-09-28 10:03:10, "ychen"  wrote:

some additional information:
1.$DPDK_DIR/tools/dpdk-devbind.py --status


Network devices using DPDK-compatible driver

:01:00.0 '82599EB 10-Gigabit SFI/SFP+ Network Connection' drv=vfio-pci 
unused=


Network devices using kernel driver
===
:01:00.1 '82599EB 10-Gigabit SFI/SFP+ Network Connection' if=eth1 drv=ixgbe 
unused=vfio-pci 
:06:00.0 'I350 Gigabit Network Connection' if=eth2 drv=igb unused=vfio-pci 
:06:00.1 'I350 Gigabit Network Connection' if=eth3 drv=igb unused=vfio-pci 


Other network devices
=



2.cat /etc/issue
Debian GNU/Linux 7 \n \l


3. I did some debug on ovs-switchd, and it seemed that when do dpdk_init(), 
the function rte_eal_pci_map_device() return -1, so the whole vswtiched 
process exited.
   some deep debug shows that VFIO_PRESENT is not defined, but now my kernel 
version is:
  Linux 10-180-0-39 3.10.45-openstack-amd64,  which is greater than 3.6.0









At 2016-09-27 21:36:27, "Aaron Conole"  wrote:
>ychen  writes:
>
>> hi, 
>> I follow the doc "INSTALLDPDK.md" to build ovs dpdk envrioment, but failed 
>> to start ovs-vswitchd
>> here is my configurations:
>> 1. kernel: 3.10.45-openstack-amd64 #1 SMP Tue Jul 1 01:52:20 UTC 2014 x86_64 
>> GNU/Linux
>> 2. NIC: 
>> 01:00.0 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit 
>> SFI/SFP+ Network Connection [8086:10fb] (rev 01)
>> 01:00.1 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit 
>> SFI/SFP+ Network Connection [8086:10fb] (rev 01)
>> 06:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network 
>> Connection [8086:1521] (rev 01)
>> 06:00.1 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network 
>> Connection [8086:1521] (rev 01)
>
>Can you also include the output of dpdk_nic_bind?  It is helpful to see
>which driver you are using.  What linux distribution is this on?
>
>> 3. IOMMU support
>>  /sys/kernel/iommu_groups/12/devices/:01:00.0
>> /sys/kernel/iommu_groups/12/devices/:01:00.1
>> /sys/kernel/iommu_groups/9/devices/:06:00.0
>> /sys/kernel/iommu_groups/9/devices/:06:00.1
>> BOOT_IMAGE=/boot/vmlinuz-3.10.45-openstack-amd64 
>> root=UUID=5cc1592c-91b4-485c-96cc-4528837dbeef ro default_hugepagesz=1G 
>> hugepagesz=1G hugepages=4 iommu=pt intel_iommu=on isolcpus=0-12 
>> intel_idle.max_cstate=0 idle=poll quiet cgroup_enable=memory crashkernel=512M
>> 4. hugepage support
>> AnonHugePages:229376 kB
>> HugePages_Total:   4
>> HugePages_Free:2
>> HugePages_Rsvd:0
>> HugePages_Surp:0
>> Hugepagesize:1048576 kB
>> 5.cpu information
>>   Architecture:  x86_64
>> CPU op-mode(s):32-bit, 64-bit
>> Byte Order:Little Endian
>> CPU(s):48
>> On-line CPU(s) list:   0-47
>> Thread(s) per core:2
>> Core(s) per socket:12
>> Socket(s): 2
>> NUMA node(s):  2
>> Vendor ID: GenuineIntel
>> CPU family:6
>> Model: 63
>> Stepping:  2
>> CPU MHz:   2599.988
>> BogoMIPS:  4601.07
>> Virtualization:VT-x
>> L1d cache: 32K
>> L1i cache: 32K
>> L2 cache:  256K
>> L3 cache:  30720K
>> NUMA node0 CPU(s): 
>> 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46
>> NUMA node1 CPU(s): 
>> 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47
>>
>>
>> 6.dpdk parameters in ovs
>>datapath_types  : [netdev, system]
>> db_version  : []
>> external_ids: {}
>> iface_types : [dpdk, dpdkr, dpdkvhostuser, dpdkvhostuserclient, 
>> geneve, gre, internal, ipsec_gre, lisp, patch, stt, system, tap, vxlan]
>> manager_options : []
>> next_cfg: 2
>> other_config: {dpdk-init="true", dpdk-lcore-mask="0xf", 
>> dpdk-socket-mem="1024,1024", pmd-cpu-mask="0x3"}
>> 7. error logs when start ovs-vswtichd
>> 2016-09-27T07:15:27Z|1|vlog|INFO|opened log file 
>> /var/log/openvswitch/ovs-vswitchd.log
>> 2016-09-27T07:15:27Z|2|ovs_numa|INFO|Discovered 24 CPU cores on NUMA 
>> node 0
>> 2016-09-27T07:15:27Z|3|ovs_numa|INFO|Discovered 24 CPU cores on NUMA 
>> node 1
>> 2016-09-27T07:15:27Z|4|ovs_numa|INFO|Discovered 2 NUMA nodes and 48 CPU 
>> cores
>> 2016-09-27T07:15:27Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock: 
>> connecting...
>> 2016-09-27T07:15:27Z|6|reconnect|INFO|unix:/var/run/openvswitch/db.sock: 
>> connected
>> 2016-09-27T07:15:27Z|7|dpdk|INFO|DPDK Enabled, initializing
>> 

[ovs-dev] [PATCH v2, 0/1] ovn: Extend Address_Set to Set to support define port name sets

[Zongkai LI]

This patch tries to extend table Address_Set to set, to support define port
name sets which could be used by ACL entries. By using port name set, CMS
can skinny down ACL entries to maintain.

v1 -> v2
rebase on upstream, add a new test for ACL using port name set and address set 
case

*** BLURB HERE ***

Zongkai LI (1):
  ovn: Extend Address_Set to Set to support define port name sets

 AUTHORS   |   1 +
 include/ovn/expr.h|   8 ++-
 ovn/controller/lflow.c|  35 -
 ovn/lib/expr.c|  67 ++---
 ovn/northd/ovn-northd.c   |  49 +++--
 ovn/ovn-nb.ovsschema  |  13 ++--
 ovn/ovn-nb.xml|  18 +++--
 ovn/ovn-sb.ovsschema  |  13 ++--
 ovn/ovn-sb.xml|  14 ++--
 ovn/utilities/ovn-nbctl.c |   4 +-
 ovn/utilities/ovn-sbctl.c |   4 +-
 ovn/utilities/ovn-trace.c |  20 +++---
 tests/ovn.at  | 179 --
 tests/test-ovn.c  |   6 +-
 14 files changed, 312 insertions(+), 119 deletions(-)

-- 
2.7.4

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v2, 1/1] ovn: Extend Address_Set to Set to support define port name sets

[Zongkai LI]

From: Zongkai LI 

This patch aims to extend table Address_Set to Set, make it more common to
accept variable set, not only address. And by that, we can skinny down ACLs,
if we use Set to defines port name sets for ACL to use, since lots of ACL
entries are similar but only "inport" and "outport" fields are different.

What changes:
  Adderss_Set   -> Set
  Adderss_Set.addresses -> Set.members
   (like addresses, or ports names)
 + Set.type
   (only "address", "string" are valid now)
  ACL match field, for example:
match : "outport == $ps1 && icmp4"

For scenario most ACL entries only have "inport" and "outport" fields are
different, by using Set to define port name set, CMS will have less ACL
entries to maintain, like:
 - less ACL entries to compare when synchronizing CMS DB with OVN NB DB.
 - less ACL entries to scan to locate one, when CMS disables a certain ACL
   rule for all ports.
 - when port deletion happen, instead of to locate ACL entries related to
   port by scanning ACL table, CMS may just need remove port name from
   relevant port name set.

Signed-off-by: Zongkai LI 
---
 AUTHORS   |   1 +
 include/ovn/expr.h|   8 ++-
 ovn/controller/lflow.c|  35 -
 ovn/lib/expr.c|  67 ++---
 ovn/northd/ovn-northd.c   |  49 +++--
 ovn/ovn-nb.ovsschema  |  13 ++--
 ovn/ovn-nb.xml|  18 +++--
 ovn/ovn-sb.ovsschema  |  13 ++--
 ovn/ovn-sb.xml|  14 ++--
 ovn/utilities/ovn-nbctl.c |   4 +-
 ovn/utilities/ovn-sbctl.c |   4 +-
 ovn/utilities/ovn-trace.c |  20 +++---
 tests/ovn.at  | 179 --
 tests/test-ovn.c  |   6 +-
 14 files changed, 312 insertions(+), 119 deletions(-)

diff --git a/AUTHORS b/AUTHORS
index 371c683..cdac86c 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -467,6 +467,7 @@ ZHANG Zhiming   zhangzhim...@yunshan.net.cn
 Zhangguanghui   zhang.guang...@h3c.com
 Ziyou Wang  ziy...@vmware.com
 Zoltán Balogh   zoltan.bal...@ericsson.com
+Zongkai LI zealo...@gmail.com
 ankur dwivedi   ankurengg2...@gmail.com
 chen zhang  3zhangchen9...@gmail.com
 james hopperjameshop...@email.com
diff --git a/include/ovn/expr.h b/include/ovn/expr.h
index 371ba20..a5fc5c6 100644
--- a/include/ovn/expr.h
+++ b/include/ovn/expr.h
@@ -466,17 +466,19 @@ void expr_constant_set_format(const struct 
expr_constant_set *, struct ds *);
 void expr_constant_set_destroy(struct expr_constant_set *cs);
 
 
-/* Address sets, aka "macros".
+/* Sets, like address sets and port name sets, aka "macros".
  *
  * Instead of referring to a set of value as:
  *{addr1, addr2, ..., addrN}
  * You can register a set of values and refer to them as:
  *$name
- * The macros should all have integer/masked-integer values.
+ * The values of macros should have the same type:
+ *all integer/masked-integer values for address sets,
+ *all string values for port name sets.
  * The values that don't qualify are ignored.
  */
 
-void expr_macros_add(struct shash *macros, const char *name,
+void expr_macros_add(struct shash *macros, const char *name, const char *type,
  const char * const *values, size_t n_values);
 void expr_macros_remove(struct shash *macros, const char *name);
 void expr_macros_destroy(struct shash *macros);
diff --git a/ovn/controller/lflow.c b/ovn/controller/lflow.c
index 4e67365..477caef 100644
--- a/ovn/controller/lflow.c
+++ b/ovn/controller/lflow.c
@@ -44,17 +44,18 @@ lflow_init(void)
 ovn_init_symtab();
 }
 
-/* Iterate address sets in the southbound database.  Create and update the
+/* Iterate sets in the southbound database.  Create and update the
  * corresponding symtab entries as necessary. */
 static void
-update_address_sets(struct controller_ctx *ctx,
-struct shash *expr_address_sets_p)
+update_sets(struct controller_ctx *ctx,
+struct shash *expr_sets_p)
 
 {
-const struct sbrec_address_set *as;
-SBREC_ADDRESS_SET_FOR_EACH (as, ctx->ovnsb_idl) {
-expr_macros_add(expr_address_sets_p, as->name,
-(const char *const *) as->addresses, as->n_addresses);
+const struct sbrec_set *set_rec;
+SBREC_SET_FOR_EACH (set_rec, ctx->ovnsb_idl) {
+expr_macros_add(expr_sets_p, set_rec->name, set_rec->type,
+(const char *const *) set_rec->members,
+set_rec->n_members);
 }
 }
 
@@ -75,7 +76,7 @@ static void consider_logical_flow(const struct lport_index 
*lports,
   struct hmap *dhcpv6_opts_p,
   uint32_t *conj_id_ofs_p,
   struct hmap *flow_table,
-  struct shash 

Re: [ovs-dev] OVS+DPDK: Requested device 0000:01:00.0 cannot be used

[ychen]

some additional information:
1.$DPDK_DIR/tools/dpdk-devbind.py --status


Network devices using DPDK-compatible driver

:01:00.0 '82599EB 10-Gigabit SFI/SFP+ Network Connection' drv=vfio-pci 
unused=


Network devices using kernel driver
===
:01:00.1 '82599EB 10-Gigabit SFI/SFP+ Network Connection' if=eth1 drv=ixgbe 
unused=vfio-pci 
:06:00.0 'I350 Gigabit Network Connection' if=eth2 drv=igb unused=vfio-pci 
:06:00.1 'I350 Gigabit Network Connection' if=eth3 drv=igb unused=vfio-pci 


Other network devices
=



2.cat /etc/issue
Debian GNU/Linux 7 \n \l


3. I did some debug on ovs-switchd, and it seemed that when do dpdk_init(), 
the function rte_eal_pci_map_device() return -1, so the whole vswtiched 
process exited.
   some deep debug shows that VFIO_PRESENT is not defined, but now my kernel 
version is:
  Linux 10-180-0-39 3.10.45-openstack-amd64,  which is greater than 3.6.0









At 2016-09-27 21:36:27, "Aaron Conole"  wrote:
>ychen  writes:
>
>> hi, 
>> I follow the doc "INSTALLDPDK.md" to build ovs dpdk envrioment, but failed 
>> to start ovs-vswitchd
>> here is my configurations:
>> 1. kernel: 3.10.45-openstack-amd64 #1 SMP Tue Jul 1 01:52:20 UTC 2014 x86_64 
>> GNU/Linux
>> 2. NIC: 
>> 01:00.0 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit 
>> SFI/SFP+ Network Connection [8086:10fb] (rev 01)
>> 01:00.1 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit 
>> SFI/SFP+ Network Connection [8086:10fb] (rev 01)
>> 06:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network 
>> Connection [8086:1521] (rev 01)
>> 06:00.1 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network 
>> Connection [8086:1521] (rev 01)
>
>Can you also include the output of dpdk_nic_bind?  It is helpful to see
>which driver you are using.  What linux distribution is this on?
>
>> 3. IOMMU support
>>  /sys/kernel/iommu_groups/12/devices/:01:00.0
>> /sys/kernel/iommu_groups/12/devices/:01:00.1
>> /sys/kernel/iommu_groups/9/devices/:06:00.0
>> /sys/kernel/iommu_groups/9/devices/:06:00.1
>> BOOT_IMAGE=/boot/vmlinuz-3.10.45-openstack-amd64 
>> root=UUID=5cc1592c-91b4-485c-96cc-4528837dbeef ro default_hugepagesz=1G 
>> hugepagesz=1G hugepages=4 iommu=pt intel_iommu=on isolcpus=0-12 
>> intel_idle.max_cstate=0 idle=poll quiet cgroup_enable=memory crashkernel=512M
>> 4. hugepage support
>> AnonHugePages:229376 kB
>> HugePages_Total:   4
>> HugePages_Free:2
>> HugePages_Rsvd:0
>> HugePages_Surp:0
>> Hugepagesize:1048576 kB
>> 5.cpu information
>>   Architecture:  x86_64
>> CPU op-mode(s):32-bit, 64-bit
>> Byte Order:Little Endian
>> CPU(s):48
>> On-line CPU(s) list:   0-47
>> Thread(s) per core:2
>> Core(s) per socket:12
>> Socket(s): 2
>> NUMA node(s):  2
>> Vendor ID: GenuineIntel
>> CPU family:6
>> Model: 63
>> Stepping:  2
>> CPU MHz:   2599.988
>> BogoMIPS:  4601.07
>> Virtualization:VT-x
>> L1d cache: 32K
>> L1i cache: 32K
>> L2 cache:  256K
>> L3 cache:  30720K
>> NUMA node0 CPU(s): 
>> 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46
>> NUMA node1 CPU(s): 
>> 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47
>>
>>
>> 6.dpdk parameters in ovs
>>datapath_types  : [netdev, system]
>> db_version  : []
>> external_ids: {}
>> iface_types : [dpdk, dpdkr, dpdkvhostuser, dpdkvhostuserclient, 
>> geneve, gre, internal, ipsec_gre, lisp, patch, stt, system, tap, vxlan]
>> manager_options : []
>> next_cfg: 2
>> other_config: {dpdk-init="true", dpdk-lcore-mask="0xf", 
>> dpdk-socket-mem="1024,1024", pmd-cpu-mask="0x3"}
>> 7. error logs when start ovs-vswtichd
>> 2016-09-27T07:15:27Z|1|vlog|INFO|opened log file 
>> /var/log/openvswitch/ovs-vswitchd.log
>> 2016-09-27T07:15:27Z|2|ovs_numa|INFO|Discovered 24 CPU cores on NUMA 
>> node 0
>> 2016-09-27T07:15:27Z|3|ovs_numa|INFO|Discovered 24 CPU cores on NUMA 
>> node 1
>> 2016-09-27T07:15:27Z|4|ovs_numa|INFO|Discovered 2 NUMA nodes and 48 CPU 
>> cores
>> 2016-09-27T07:15:27Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock: 
>> connecting...
>> 2016-09-27T07:15:27Z|6|reconnect|INFO|unix:/var/run/openvswitch/db.sock: 
>> connected
>> 2016-09-27T07:15:27Z|7|dpdk|INFO|DPDK Enabled, initializing
>> 2016-09-27T07:15:27Z|8|dpdk|INFO|No vhost-sock-dir provided - defaulting 
>> to /var/run/openvswitch
>> 2016-09-27T07:15:27Z|9|dpdk|INFO|EAL ARGS: ovs-vswitchd -c 0xf 
>> --socket-mem 1024,1024
>> EAL: Detected 48 lcore(s)
>> PMD: bnxt_rte_pmd_init() called for (null)
>> EAL: PCI device :01:00.0 on NUMA 

Re: [ovs-dev] [CudaMailTagged] [patch_v1] ovn: Add additional comments regarding arp responders.

[Darrell Ball]

On Tue, Sep 27, 2016 at 4:49 PM, Han Zhou  wrote:

>
>
> On Tue, Sep 27, 2016 at 2:36 PM, Darrell Ball  wrote:
> >
> > There has been enough confusion regarding arp responders in
> > ovn to warrant some additional comments;  hence add a
> > general description regarding why they exist and document
> > the special cases.
> >
> > The patch goes along with patch fix for vtep ports here:
> > https://patchwork.ozlabs.org/patch/675796/
> >
> > Signed-off-by: Darrell Ball 
> > ---
> >  ovn/northd/ovn-northd.8.xml | 21 ++---
> >  1 file changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> > index 307e8be..0755213 100644
> > --- a/ovn/northd/ovn-northd.8.xml
> > +++ b/ovn/northd/ovn-northd.8.xml
> > @@ -415,14 +415,29 @@
> >  Ingress Table 9: ARP/ND responder
> >
> >  
> > -  This table implements ARP/ND responder for known IPs.  It
> contains these
> > -  logical flows:
> > +  This table implements ARP/ND responder for known IPs.  The
> advantage
> > +  of the arp responder flow is to limit arp broadcasts by locally
> > +  responding to arp requests without the need to send to other
> > +  hypervisors.  One common case is when the inport is a logical
> > +  port associated with a VIF and the broadcast is responded to on
> the
> > +  local hypervisor rather than broadcast across the whole network
> and
> > +  responded to by the destination VM.  It contains these logical
> flows:
> >  
> >
> >  
> >
> >  Priority-100 flows to skip ARP responder if inport is of type
> > -localnet, and advances directly to the next table.
> > +localnet or vtep, and advances
> directly
> > +to the next table.  These port types are skipped because the arp
> > +requests are received by multiple hypervisors which all have the
> > +same mac binding locally.  There are some special cases:
>
> How about this:
>
> These port types are skipped because ARP responder is not supposed to
> handle ARP requests that come from physical network.
>

There is a special case of the l2gateway where
a request comes from the physical network destined to a VM
somewhere; this is north->south traffic. This traffic hits a single
l2gateway inport and is associated with a logical switch.
There will be an arp responder on this source HV in gateway role.
Hence, there would be a single arp reply back out to the physical network.



> Otherwise, because all the chassises receiving the requests will reply,
> there will be redundant responses.
>

I got your point; let me roll in and elaborate a bit ?

"These port types are skipped.  Otherwise the arp
request is received by multiple hypervisors, which all have the
same mac binding downloaded from northd, which will cause
redundant arp replies, confusing the originator of the arp request. "




>
> > +north->south traffic using the l2gateway port will use an arp
> > +responder on the l2 gateway chassis in the context of a logical
> > +switch datapath.  Another case is when traffic flows from
> > +south->north or east->west and goes through the gateway router.
> > +This arp request will flow through a transit logical switch at
> > +the destination hypervisor before going through the gateway
> router
> > +and its inport will be a logical switch router type port.
> >
> >
> >
> > --
> > 1.9.1
> >
> > ___
> > dev mailing list
> > dev@openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
>
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [CudaMailTagged] [patch_v1] ovn: Add additional comments regarding arp responders.

[Han Zhou]

On Tue, Sep 27, 2016 at 2:36 PM, Darrell Ball  wrote:
>
> There has been enough confusion regarding arp responders in
> ovn to warrant some additional comments;  hence add a
> general description regarding why they exist and document
> the special cases.
>
> The patch goes along with patch fix for vtep ports here:
> https://patchwork.ozlabs.org/patch/675796/
>
> Signed-off-by: Darrell Ball 
> ---
>  ovn/northd/ovn-northd.8.xml | 21 ++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index 307e8be..0755213 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -415,14 +415,29 @@
>  Ingress Table 9: ARP/ND responder
>
>  
> -  This table implements ARP/ND responder for known IPs.  It contains
these
> -  logical flows:
> +  This table implements ARP/ND responder for known IPs.  The
advantage
> +  of the arp responder flow is to limit arp broadcasts by locally
> +  responding to arp requests without the need to send to other
> +  hypervisors.  One common case is when the inport is a logical
> +  port associated with a VIF and the broadcast is responded to on the
> +  local hypervisor rather than broadcast across the whole network and
> +  responded to by the destination VM.  It contains these logical
flows:
>  
>
>  
>
>  Priority-100 flows to skip ARP responder if inport is of type
> -localnet, and advances directly to the next table.
> +localnet or vtep, and advances directly
> +to the next table.  These port types are skipped because the arp
> +requests are received by multiple hypervisors which all have the
> +same mac binding locally.  There are some special cases:

How about this:

These port types are skipped because ARP responder is not supposed to
handle ARP requests that come from physical network. Otherwise, because all
the chassises receiving the requests will reply, there will be redundant
responses.

> +north->south traffic using the l2gateway port will use an arp
> +responder on the l2 gateway chassis in the context of a logical
> +switch datapath.  Another case is when traffic flows from
> +south->north or east->west and goes through the gateway router.
> +This arp request will flow through a transit logical switch at
> +the destination hypervisor before going through the gateway
router
> +and its inport will be a logical switch router type port.
>
>
>
> --
> 1.9.1
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] sparse: Fix conflict between netinet/in.h and linux/in.h

[Daniele Di Proietto]

On 27/09/2016 15:19, "Joe Stringer"  wrote:

>On 8 June 2016 at 13:49, Daniele Di Proietto  wrote:
>>
>>
>>
>>
>>
>> On 08/06/2016 13:30, "Ben Pfaff"  wrote:
>>
>>>On Wed, Jun 08, 2016 at 01:07:32PM -0700, Ben Pfaff wrote:
 On Wed, Jun 01, 2016 at 07:23:29PM -0700, Daniele Di Proietto wrote:
 > linux/in.h (from linux uapi headers) carries many of the same
 > definitions as netinet/in.h (from glibc).
 >
 > If linux/in.h is included after netinet/in.h, conflicts are avoided in
 > two ways:
 >
 > 1) linux/libc-compat.h (included by linux/in.h) detects the include
 >guard of netinet/in.h and defines some macros (e.g.
 >__UAPI_DEF_IN_IPPROTO) to 0.  linux/in.h avoids exporting the same
 >enums if those macros are 0.
 >
 > 2) The two files are allowed to redefine the same macros as long as the
 >values are the same.
 >
 > Our include/sparse/netinet/in.h creates problems, because:
 >
 > 1) It uses a custom include guard
 > 2) It uses dummy values for some macros.
 >
 > This commit changes include/sparse/netinet/in.h to use the same include
 > guard as glibc netinet/in.h, and to use the same values for some macros.
 >
 > I think this problem is present with linux headers after
 > a263653ed798("netfilter: don't pull include/linux/netfilter.h from netns
 > headers") which cause our lib/netlink-conntrack.c to include linux/in.h
 > after netinet/in.h.

 The change to the macros seems fine.

 The change to the include guard concerns me though.  If other
 definitions of e.g. htons() are used, then how will those have the
 correct types for sparse checking?
>>>
>>>After talking to Daniele I understand better.  The reason to use glibc's
>>>header guard is that the Linux headers check for glibc's header guard
>>>and behave differently if it is present, and we want that same behavior
>>>when our "sparse"-compatible header is used.  Now that I understand, I
>>>support the change.
>>
>> Yeah, it's quite intricated
>>
>> I'm not sure our sparse headers cover all corner cases of glibc+linux 
>> headers,
>> but for now the build appears to work.
>>
>>>
>>>Acked-by: Ben Pfaff 
>>
>> Thanks for the review and testing, I pushed this to master
>
>I'd like to propose cherry-picking this to OVS-2.5 before the next
>v2.5 release, to fix the userspace build using sparse with newer
>kernels.

Good idea, I run make distcheck to make sure that this doesn't break anything 
and I backported it to branch-2.5

Thanks,

Daniele
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2 3/3] ofp-actions: Always consider inconsistent CT actions as an error.

[Jarno Rajahalme]

Thanks for the fast review, Joe!

Series pushed to master, branch-2.6, and branch-2.5.

  Jarno

> On Sep 27, 2016, at 2:38 PM, Joe Stringer  wrote:
> 
> On 27 September 2016 at 14:32, Jarno Rajahalme  > wrote:
>> We can't downgrade to OF1.0 and expect inconsistent CT actions
>> be silently disgarded.  Instead, datapath flow install fails, so
>> it is better to flag inconsistent CT actions as hard errors.
>> 
>> Signed-off-by: Jarno Rajahalme >
> 
> LGTM, minor spelling below. Thanks.
> 
> Acked-by: Joe Stringer >
> 
>> ---
>> lib/ofp-actions.c |  7 +--
>> tests/ofproto-dpif.at | 40 
>> tests/ovs-ofctl.at| 46 +++---
>> 3 files changed, 48 insertions(+), 45 deletions(-)
>> 
>> diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
>> index f896f98..19e47fb 100644
>> --- a/lib/ofp-actions.c
>> +++ b/lib/ofp-actions.c
>> @@ -7033,7 +7033,10 @@ ofpact_check__(enum ofputil_protocol 
>> *usable_protocols, struct ofpact *a,
>> if (!dl_type_is_ip_any(flow->dl_type)
>> || (flow->ct_state & CS_INVALID && oc->flags & NX_CT_F_COMMIT)
>> || (oc->alg == IPPORT_FTP && flow->nw_proto != IPPROTO_TCP)) {
>> -inconsistent_match(usable_protocols);
>> +/* We can't downgrade to OF1.0 and expect inconsistent CT 
>> actions
>> + * be silently disgarded.  Instead, datapath flow install 
>> fails, so
> 
> *discarded

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] sparse: Fix conflict between netinet/in.h and linux/in.h

[Joe Stringer]

On 8 June 2016 at 13:49, Daniele Di Proietto  wrote:
>
>
>
>
>
> On 08/06/2016 13:30, "Ben Pfaff"  wrote:
>
>>On Wed, Jun 08, 2016 at 01:07:32PM -0700, Ben Pfaff wrote:
>>> On Wed, Jun 01, 2016 at 07:23:29PM -0700, Daniele Di Proietto wrote:
>>> > linux/in.h (from linux uapi headers) carries many of the same
>>> > definitions as netinet/in.h (from glibc).
>>> >
>>> > If linux/in.h is included after netinet/in.h, conflicts are avoided in
>>> > two ways:
>>> >
>>> > 1) linux/libc-compat.h (included by linux/in.h) detects the include
>>> >guard of netinet/in.h and defines some macros (e.g.
>>> >__UAPI_DEF_IN_IPPROTO) to 0.  linux/in.h avoids exporting the same
>>> >enums if those macros are 0.
>>> >
>>> > 2) The two files are allowed to redefine the same macros as long as the
>>> >values are the same.
>>> >
>>> > Our include/sparse/netinet/in.h creates problems, because:
>>> >
>>> > 1) It uses a custom include guard
>>> > 2) It uses dummy values for some macros.
>>> >
>>> > This commit changes include/sparse/netinet/in.h to use the same include
>>> > guard as glibc netinet/in.h, and to use the same values for some macros.
>>> >
>>> > I think this problem is present with linux headers after
>>> > a263653ed798("netfilter: don't pull include/linux/netfilter.h from netns
>>> > headers") which cause our lib/netlink-conntrack.c to include linux/in.h
>>> > after netinet/in.h.
>>>
>>> The change to the macros seems fine.
>>>
>>> The change to the include guard concerns me though.  If other
>>> definitions of e.g. htons() are used, then how will those have the
>>> correct types for sparse checking?
>>
>>After talking to Daniele I understand better.  The reason to use glibc's
>>header guard is that the Linux headers check for glibc's header guard
>>and behave differently if it is present, and we want that same behavior
>>when our "sparse"-compatible header is used.  Now that I understand, I
>>support the change.
>
> Yeah, it's quite intricated
>
> I'm not sure our sparse headers cover all corner cases of glibc+linux headers,
> but for now the build appears to work.
>
>>
>>Acked-by: Ben Pfaff 
>
> Thanks for the review and testing, I pushed this to master

I'd like to propose cherry-picking this to OVS-2.5 before the next
v2.5 release, to fix the userspace build using sparse with newer
kernels.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] system-traffic: Collapse FTP NAT tests.

[Jarno Rajahalme]

Acked-by: Jarno Rajahalme 

> On Sep 7, 2016, at 4:34 PM, Joe Stringer  wrote:
> 
> Previously we had the following tests:
> * FTP with NAT
> * FTP with NAT (seq-adj)
> * FTP with NAT 2
> 
> Tests 1 and 2 share everything, except use different IP addresses. Test
> 3 has a different flow table, but shares the topology with 1 and 2.
> 
> This commit creates macros:
> * CHECK_FTP_NAT(title, ip, flow_table)
> * CHECK_FTP_NAT_PRE_RECIRC(title, ip, ip-as-hex)
> * CHECK_FTP_NAT_POST_RECIRC(title, ip, ip-as-hex)
> 
> The second macro represents tests 1 and 2, while the third macro
> represents two variations on test 3: with and without TCP sequence
> adjustment.
> 
> By using these macros to declare the tests, much of the code may be
> reused and shared rather than copying/pasting. As a result, the
> differences between tests are easier to identify.
> 
> Signed-off-by: Joe Stringer 
> ---
> tests/system-traffic.at | 218 ++--
> 1 file changed, 81 insertions(+), 137 deletions(-)
> 
> diff --git a/tests/system-traffic.at b/tests/system-traffic.at
> index 4dabd90356a1..31076f8b141a 100644
> --- a/tests/system-traffic.at
> +++ b/tests/system-traffic.at
> @@ -2405,103 +2405,55 @@ 
> udp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=,dport=),reply=(src=
> OVS_TRAFFIC_VSWITCHD_STOP
> AT_CLEANUP
> 
> -AT_SETUP([conntrack - FTP with NAT])
> -AT_SKIP_IF([test $HAVE_PYFTPDLIB = no])
> -CHECK_CONNTRACK()
> -CHECK_CONNTRACK_NAT()
> -
> -OVS_TRAFFIC_VSWITCHD_START()
> -
> -ADD_NAMESPACES(at_ns0, at_ns1)
> -
> -ADD_VETH(p0, at_ns0, br0, "10.1.1.1/24")
> -NS_CHECK_EXEC([at_ns0], [ip link set dev p0 address 80:88:88:88:88:88])
> -ADD_VETH(p1, at_ns1, br0, "10.1.1.2/24")
> -
> -dnl Allow any traffic from ns0->ns1. Only allow nd, return traffic from 
> ns1->ns0.
> -
> -AT_DATA([flows.txt], [dnl
> -dnl track all IP traffic, de-mangle non-NEW connections
> -table=0 in_port=1, ip, action=ct(table=1,nat)
> -table=0 in_port=2, ip, action=ct(table=2,nat)
> -dnl
> -dnl ARP
> -dnl
> -table=0 priority=100 arp arp_op=1 
> action=move:OXM_OF_ARP_TPA[[]]->NXM_NX_REG2[[]],resubmit(,8),goto_table:10
> -table=0 priority=10 arp action=normal
> -table=0 priority=0 action=drop
> -dnl
> -dnl Table 1: port 1 -> 2
> -dnl
> -dnl Allow new FTP connections. These need to be commited.
> -table=1 ct_state=+new, tcp, tp_dst=21, nw_src=10.1.1.1, 
> action=ct(alg=ftp,commit,nat(src=10.1.1.9)),2
> -dnl Allow established TCP connections, make sure they are NATted already.
> -table=1 ct_state=+est, tcp, nw_src=10.1.1.9, action=2
> -dnl
> -dnl Table 1: droppers
> +dnl CHECK_FTP_NAT(TITLE, IP_ADDR, FLOWS)
> dnl
> -table=1 priority=10, tcp, action=drop
> -table=1 priority=0,action=drop
> -dnl
> -dnl Table 2: port 2 -> 1
> -dnl
> -dnl Allow established TCP connections, make sure they are reverse NATted
> -table=2 ct_state=+est, tcp, nw_dst=10.1.1.1, action=1
> -dnl Allow (new) related (data) connections.  These need to be commited.
> -table=2 ct_state=+new+rel, tcp, nw_dst=10.1.1.9, action=ct(commit,nat),1
> -dnl Allow related ICMP packets, make sure they are reverse NATted
> -table=2 ct_state=+rel, icmp, nw_dst=10.1.1.1, action=1
> -dnl
> -dnl Table 2: droppers
> -dnl
> -table=2 priority=10, tcp, action=drop
> -table=2 priority=0, action=drop
> -dnl
> -dnl MAC resolution table for IP in reg2, stores mac in OXM_OF_PKT_REG0
> -dnl
> -table=8,reg2=0x0a010109/0x,action=load:0x8088->OXM_OF_PKT_REG0[[]]
> -table=8,priority=0,action=load:0->OXM_OF_PKT_REG0[[]]
> -dnl ARP responder mac filled in at OXM_OF_PKT_REG0, or 0 for normal action.
> -dnl TPA IP in reg2.
> -dnl Swaps the fields of the ARP message to turn a query to a response.
> -table=10 priority=100 arp xreg0=0 action=normal
> -table=10 
> priority=10,arp,arp_op=1,action=load:2->OXM_OF_ARP_OP[[]],move:OXM_OF_ARP_SHA[[]]->OXM_OF_ARP_THA[[]],move:OXM_OF_PKT_REG0[[0..47]]->OXM_OF_ARP_SHA[[]],move:OXM_OF_ARP_SPA[[]]->OXM_OF_ARP_TPA[[]],move:NXM_NX_REG2[[]]->OXM_OF_ARP_SPA[[]],move:NXM_OF_ETH_SRC[[]]->NXM_OF_ETH_DST[[]],move:OXM_OF_PKT_REG0[[0..47]]->NXM_OF_ETH_SRC[[]],move:NXM_OF_IN_PORT[[]]->NXM_NX_REG3[[0..15]],load:0->NXM_OF_IN_PORT[[]],output:NXM_NX_REG3[[0..15]]
> -table=10 priority=0 action=drop
> -])
> +dnl Checks the implementation of conntrack with FTP ALGs in combination with
> +dnl NAT, using the provided flow table.
> +m4_define([CHECK_FTP_NAT],
> +   [AT_SETUP([conntrack - FTP NAT $1])
> +AT_SKIP_IF([test $HAVE_PYFTPDLIB = no])
> +CHECK_CONNTRACK()
> +CHECK_CONNTRACK_NAT()
> 
> -AT_CHECK([ovs-ofctl --bundle add-flows br0 flows.txt])
> +OVS_TRAFFIC_VSWITCHD_START()
> 
> -dnl NETNS_DAEMONIZE([at_ns0], [[$PYTHON $srcdir/test-l7.py ftp]], [ftp1.pid])
> -NETNS_DAEMONIZE([at_ns1], [[$PYTHON $srcdir/test-l7.py ftp]], [ftp0.pid])
> -OVS_WAIT_UNTIL([ip netns exec at_ns1 netstat -l | grep ftp])
> +ADD_NAMESPACES(at_ns0, at_ns1)
> 
> -dnl FTP requests from p0->p1 should work fine.
> 

Re: [ovs-dev] [PATCH v2 3/3] ofp-actions: Always consider inconsistent CT actions as an error.

[Joe Stringer]

On 27 September 2016 at 14:32, Jarno Rajahalme  wrote:
> We can't downgrade to OF1.0 and expect inconsistent CT actions
> be silently disgarded.  Instead, datapath flow install fails, so
> it is better to flag inconsistent CT actions as hard errors.
>
> Signed-off-by: Jarno Rajahalme 

LGTM, minor spelling below. Thanks.

Acked-by: Joe Stringer 

> ---
>  lib/ofp-actions.c |  7 +--
>  tests/ofproto-dpif.at | 40 
>  tests/ovs-ofctl.at| 46 +++---
>  3 files changed, 48 insertions(+), 45 deletions(-)
>
> diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
> index f896f98..19e47fb 100644
> --- a/lib/ofp-actions.c
> +++ b/lib/ofp-actions.c
> @@ -7033,7 +7033,10 @@ ofpact_check__(enum ofputil_protocol 
> *usable_protocols, struct ofpact *a,
>  if (!dl_type_is_ip_any(flow->dl_type)
>  || (flow->ct_state & CS_INVALID && oc->flags & NX_CT_F_COMMIT)
>  || (oc->alg == IPPORT_FTP && flow->nw_proto != IPPROTO_TCP)) {
> -inconsistent_match(usable_protocols);
> +/* We can't downgrade to OF1.0 and expect inconsistent CT actions
> + * be silently disgarded.  Instead, datapath flow install fails, 
> so

*discarded
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2 2/3] ofp-actions: Check that 'alg=ftp' matches on TCP.

[Joe Stringer]

On 27 September 2016 at 14:32, Jarno Rajahalme  wrote:
> Datapath flow setup fails when setting the FTP helper on an
> unsupported IP protocol.  It is better to fail at the OpenFlow rule
> set-up time instead.
>
> Signed-off-by: Jarno Rajahalme 

Acked-by: Joe Stringer 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2 1/3] ofp-actions: Style fixes.

[Joe Stringer]

On 27 September 2016 at 14:32, Jarno Rajahalme  wrote:
> Replace a tab by a space and remove an unnecessary variable.
>
> Signed-off-by: Jarno Rajahalme 

Acked-by: Joe Stringer 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [CudaMailTagged] [patch_v1] ovn: Add additional comments regarding arp responders.

[Darrell Ball]

There has been enough confusion regarding arp responders in
ovn to warrant some additional comments;  hence add a
general description regarding why they exist and document
the special cases.

The patch goes along with patch fix for vtep ports here:
https://patchwork.ozlabs.org/patch/675796/

Signed-off-by: Darrell Ball 
---
 ovn/northd/ovn-northd.8.xml | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index 307e8be..0755213 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -415,14 +415,29 @@
 Ingress Table 9: ARP/ND responder
 
 
-  This table implements ARP/ND responder for known IPs.  It contains these
-  logical flows:
+  This table implements ARP/ND responder for known IPs.  The advantage
+  of the arp responder flow is to limit arp broadcasts by locally
+  responding to arp requests without the need to send to other
+  hypervisors.  One common case is when the inport is a logical
+  port associated with a VIF and the broadcast is responded to on the
+  local hypervisor rather than broadcast across the whole network and
+  responded to by the destination VM.  It contains these logical flows:
 
 
 
   
 Priority-100 flows to skip ARP responder if inport is of type
-localnet, and advances directly to the next table.
+localnet or vtep, and advances directly
+to the next table.  These port types are skipped because the arp
+requests are received by multiple hypervisors which all have the
+same mac binding locally.  There are some special cases:
+north->south traffic using the l2gateway port will use an arp
+responder on the l2 gateway chassis in the context of a logical
+switch datapath.  Another case is when traffic flows from
+south->north or east->west and goes through the gateway router.
+This arp request will flow through a transit logical switch at
+the destination hypervisor before going through the gateway router
+and its inport will be a logical switch router type port.
   
 
   
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v2 1/3] ofp-actions: Style fixes.

[Jarno Rajahalme]

Replace a tab by a space and remove an unnecessary variable.

Signed-off-by: Jarno Rajahalme 
---
 include/openvswitch/ofp-actions.h | 2 +-
 lib/ofp-actions.c | 8 +++-
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/include/openvswitch/ofp-actions.h 
b/include/openvswitch/ofp-actions.h
index 67e84fa..74e9dcc 100644
--- a/include/openvswitch/ofp-actions.h
+++ b/include/openvswitch/ofp-actions.h
@@ -556,7 +556,7 @@ enum nx_conntrack_flags {
 #define NX_CT_RECIRC_NONE OFPTT_ALL
 
 #if !defined(IPPORT_FTP)
-#defineIPPORT_FTP  21
+#define IPPORT_FTP  21
 #endif
 
 /* OFPACT_CT.
diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
index 22c7b16..6fea508 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -7029,7 +7029,6 @@ ofpact_check__(enum ofputil_protocol *usable_protocols, 
struct ofpact *a,
 
 case OFPACT_CT: {
 struct ofpact_conntrack *oc = ofpact_get_CT(a);
-enum ofperr err;
 
 if (!dl_type_is_ip_any(flow->dl_type)
 || (flow->ct_state & CS_INVALID && oc->flags & NX_CT_F_COMMIT)) {
@@ -7040,10 +7039,9 @@ ofpact_check__(enum ofputil_protocol *usable_protocols, 
struct ofpact *a,
 return mf_check_src(>zone_src, flow);
 }
 
-err = ofpacts_check(oc->actions, ofpact_ct_get_action_len(oc),
-flow, max_ports, table_id, n_tables,
-usable_protocols);
-return err;
+return ofpacts_check(oc->actions, ofpact_ct_get_action_len(oc),
+ flow, max_ports, table_id, n_tables,
+ usable_protocols);
 }
 
 case OFPACT_NAT: {
-- 
2.1.4

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v2 2/3] ofp-actions: Check that 'alg=ftp' matches on TCP.

[Jarno Rajahalme]

Datapath flow setup fails when setting the FTP helper on an
unsupported IP protocol.  It is better to fail at the OpenFlow rule
set-up time instead.

Signed-off-by: Jarno Rajahalme 
---
 lib/ofp-actions.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
index 6fea508..f896f98 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -7031,7 +7031,8 @@ ofpact_check__(enum ofputil_protocol *usable_protocols, 
struct ofpact *a,
 struct ofpact_conntrack *oc = ofpact_get_CT(a);
 
 if (!dl_type_is_ip_any(flow->dl_type)
-|| (flow->ct_state & CS_INVALID && oc->flags & NX_CT_F_COMMIT)) {
+|| (flow->ct_state & CS_INVALID && oc->flags & NX_CT_F_COMMIT)
+|| (oc->alg == IPPORT_FTP && flow->nw_proto != IPPROTO_TCP)) {
 inconsistent_match(usable_protocols);
 }
 
-- 
2.1.4

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v2 3/3] ofp-actions: Always consider inconsistent CT actions as an error.

[Jarno Rajahalme]

We can't downgrade to OF1.0 and expect inconsistent CT actions
be silently disgarded.  Instead, datapath flow install fails, so
it is better to flag inconsistent CT actions as hard errors.

Signed-off-by: Jarno Rajahalme 
---
 lib/ofp-actions.c |  7 +--
 tests/ofproto-dpif.at | 40 
 tests/ovs-ofctl.at| 46 +++---
 3 files changed, 48 insertions(+), 45 deletions(-)

diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
index f896f98..19e47fb 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -7033,7 +7033,10 @@ ofpact_check__(enum ofputil_protocol *usable_protocols, 
struct ofpact *a,
 if (!dl_type_is_ip_any(flow->dl_type)
 || (flow->ct_state & CS_INVALID && oc->flags & NX_CT_F_COMMIT)
 || (oc->alg == IPPORT_FTP && flow->nw_proto != IPPROTO_TCP)) {
-inconsistent_match(usable_protocols);
+/* We can't downgrade to OF1.0 and expect inconsistent CT actions
+ * be silently disgarded.  Instead, datapath flow install fails, so
+ * it is better to flag inconsistent CT actions as hard errors. */
+return OFPERR_OFPBAC_MATCH_INCONSISTENT;
 }
 
 if (oc->zone_src.field) {
@@ -7052,7 +7055,7 @@ ofpact_check__(enum ofputil_protocol *usable_protocols, 
struct ofpact *a,
 (on->range_af == AF_INET && flow->dl_type != htons(ETH_TYPE_IP)) ||
 (on->range_af == AF_INET6
  && flow->dl_type != htons(ETH_TYPE_IPV6))) {
-inconsistent_match(usable_protocols);
+return OFPERR_OFPBAC_MATCH_INCONSISTENT;
 }
 return 0;
 }
diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index e2b983f..7b5972d 100644
--- a/tests/ofproto-dpif.at
+++ b/tests/ofproto-dpif.at
@@ -8396,7 +8396,7 @@ add_of_ports br0 1 2
 AT_CHECK([ovs-appctl vlog/set dpif_netdev:dbg vconn:info ofproto_dpif:info])
 
 AT_DATA([flows.txt], [dnl
-ct_state=-trk,action=ct(table=0,zone=0)
+ipv6,ct_state=-trk,action=ct(table=0,zone=0)
 ct_state=+trk,action=controller
 ])
 
@@ -8407,14 +8407,14 @@ AT_CHECK([ovs-ofctl monitor br0 65534 invalid_ttl -P 
nxt_packet_in --detach --no
 
 AT_CHECK([ovs-appctl time/stop])
 
-AT_CHECK([ovs-appctl netdev-dummy/receive p2 
'eth(src=80:88:88:88:88:88,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=192.168.0.1,tip=192.168.0.2,op=1,sha=50:54:00:00:00:05,tha=00:00:00:00:00:00)'])
+AT_CHECK([ovs-appctl netdev-dummy/receive p2 
'0060970769ea860580da86dd60203afffe80020086fffe0580dafe80026097fffe0769ea870068bdfe80026097fffe0769ea0101860580da'])
 
 OVS_WAIT_UNTIL([test `wc -l < ofctl_monitor.log` -ge 1])
 OVS_WAIT_UNTIL([ovs-appctl -t ovs-ofctl exit])
 
 AT_CHECK([cat ofctl_monitor.log], [0], [dnl
-NXT_PACKET_IN (xid=0x0): cookie=0x0 total_len=42 ct_state=inv|trk,in_port=2 
(via action) data_len=42 (unbuffered)
-arp,vlan_tci=0x,dl_src=80:88:88:88:88:88,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=192.168.0.1,arp_tpa=192.168.0.2,arp_op=1,arp_sha=50:54:00:00:00:05,arp_tha=00:00:00:00:00:00
+NXT_PACKET_IN (xid=0x0): cookie=0x0 total_len=86 ct_state=inv|trk,in_port=2 
(via action) data_len=86 (unbuffered)
+icmp6,vlan_tci=0x,dl_src=00:00:86:05:80:da,dl_dst=00:60:97:07:69:ea,ipv6_src=fe80::200:86ff:fe05:80da,ipv6_dst=fe80::260:97ff:fe07:69ea,ipv6_label=0x0,nw_tos=0,nw_ecn=0,nw_ttl=255,icmp_type=135,icmp_code=0,nd_target=fe80::260:97ff:fe07:69ea,nd_sll=00:00:86:05:80:da,nd_tll=00:00:00:00:00:00
 icmp6_csum:68bd
 ])
 
 OVS_VSWITCHD_STOP
@@ -8545,8 +8545,8 @@ AT_DATA([flows.txt], [dnl
 dnl Table 0
 dnl
 table=0,priority=100,arp,action=normal
-table=0,priority=10,in_port=1,udp,action=ct(commit,table=1)
-table=0,priority=10,in_port=2,action=ct(table=1)
+table=0,priority=10,ip,in_port=1,udp,action=ct(commit,table=1)
+table=0,priority=10,ip,in_port=2,action=ct(table=1)
 table=0,priority=1,action=drop
 dnl
 dnl Table 1
@@ -8596,12 +8596,12 @@ dnl Allow new connections on p1->p2. Allow only 
established connections p2->p1
 AT_DATA([flows.txt], [dnl
 dnl Table 0
 dnl
-table=0,priority=100,arp,action=normal
-table=0,priority=10,in_port=1,udp,tp_src=1,action=ct(commit,exec(set_field:1->ct_mark)),controller
-table=0,priority=10,in_port=1,udp,tp_src=3,action=ct(commit,exec(set_field:3->ct_mark)),controller
-table=0,priority=10,in_port=1,udp,tp_src=5,action=ct(commit,exec(set_field:5->ct_mark)),controller
-table=0,priority=10,in_port=2,actions=ct(table=1)
-table=0,priority=1,action=drop
+table=0,arp,action=normal
+table=0,ip,in_port=1,udp,tp_src=1,action=ct(commit,exec(set_field:1->ct_mark)),controller
+table=0,ip,in_port=1,udp,tp_src=3,action=ct(commit,exec(set_field:3->ct_mark)),controller
+table=0,ip,in_port=1,udp,tp_src=5,action=ct(commit,exec(set_field:5->ct_mark)),controller
+table=0,ip,in_port=2,actions=ct(table=1)
+table=0,priority=0,action=drop
 dnl
 dnl Table 1
 dnl
@@ -8657,10 +8657,10 @@ dnl Allow new 

Re: [ovs-dev] [PATCH] ofp-actions: Error on conntrack action inconsistency.

[Jarno Rajahalme]

> On Sep 27, 2016, at 11:06 AM, Joe Stringer  wrote:
> 
> On 26 September 2016 at 18:46, Jarno Rajahalme  > wrote:
>> Setting up a datapath flow that has a conntrack action with 'alg=ftp',
>> but does not match on 'nw_proto=tcp' fails with 'WARN' in
>> ovs-vswitchd.log.  It is better to flag such inconsistencies during
>> OpenFlow rule set-up time.  Also, conntrack action inconsistencies
>> should be flagged as such, rather than assuming that falling back to
>> OpenFlow 1.0 (which allows inconsistent actions) would remedy the
>> situation.
>> 
>> Remove the IP check from the action inconsistency check so that it is
>> possible to write rules that operate on both IPv4 and IPv6 packets,
>> when the action itself is not IP version dependent.  Correspondingly,
>> when translating a conntrack action, do not issue any datapath actions
>> if the packet being translated is not an IP packet, as conntrack can
>> operate only on IP packets and a datapath flow set-up otherwise fails
>> anyway.
>> 
>> Signed-off-by: Jarno Rajahalme 
> 
> I see about three separate changes here, it would be easier to
> understand what you're trying to solve if they were proposed
> separately. I also see a few cosmetic changes which are usually
> handled separate from functional changes.
> 
> * Ensuring match on TCP for alg=ftp looks good
> 
> * Enforcing the action inconsistency check
> 
> Falling back to OF1.0 could allow one flow to execute CT() on any
> {ip,ipv6} packets, so while it may fail it's also not a terrible
> assumption that it may remedy the situation. That said, it sounds like
> a reasonable change to me - I doubt that people are relying on this,
> and it makes the errors more explicit by erroring back at the OF layer
> rather than printing a message in a kernel log somewhere.
> 
> There may be an argument for the two above being bugfixes: people
> running v2.5 LTS are more likely to run into unexpected translation
> errors in the datapath without these checks being properly presented
> at the OpenFlow layer.
> 

OK.

> * Removing IP check from action inconsistency check
> 
> I wouldn't mind some input from eg. OVN pipeline writers whether it is
> useful to match on any proto (ie, ipv4+ipv6) to do CT(). This is a
> basic tradeoff between pipeline flexibility and explicit erroring at
> the OpenFlow layer. I could see someone wanting to build conjunctive
> flows that do CT(), but it's disallowed today and no-one's complained,
> so is it really that useful?
> 
> Regardless I'm not sure that silently skipping the CT() action is
> quite right - shouldn't it complain that the flows are wrong?
> 

I’ll remove this change in v2 and separate out the changes to separate patches.

Thanks for the review,

  Jarno

>> ---
>> include/openvswitch/ofp-actions.h |  2 +-
>> lib/ofp-actions.c | 22 +++---
>> ofproto/ofproto-dpif-xlate.c  | 10 +++---
>> tests/ofproto-dpif.at |  6 +++---
>> tests/ovs-ofctl.at| 34 +-
>> 5 files changed, 39 insertions(+), 35 deletions(-)
>> 
>> diff --git a/include/openvswitch/ofp-actions.h 
>> b/include/openvswitch/ofp-actions.h
>> index 67e84fa..74e9dcc 100644
>> --- a/include/openvswitch/ofp-actions.h
>> +++ b/include/openvswitch/ofp-actions.h
>> @@ -556,7 +556,7 @@ enum nx_conntrack_flags {
>> #define NX_CT_RECIRC_NONE OFPTT_ALL
>> 
>> #if !defined(IPPORT_FTP)
>> -#defineIPPORT_FTP  21
>> +#define IPPORT_FTP  21
>> #endif
>> 
>> /* OFPACT_CT.
>> diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
>> index 22c7b16..4a8e79d 100644
>> --- a/lib/ofp-actions.c
>> +++ b/lib/ofp-actions.c
>> @@ -7029,31 +7029,31 @@ ofpact_check__(enum ofputil_protocol 
>> *usable_protocols, struct ofpact *a,
>> 
>> case OFPACT_CT: {
>> struct ofpact_conntrack *oc = ofpact_get_CT(a);
>> -enum ofperr err;
>> 
>> -if (!dl_type_is_ip_any(flow->dl_type)
>> -|| (flow->ct_state & CS_INVALID && oc->flags & NX_CT_F_COMMIT)) 
>> {
>> -inconsistent_match(usable_protocols);
>> +if ((flow->ct_state & CS_INVALID && oc->flags & NX_CT_F_COMMIT)
>> +|| (oc->alg == IPPORT_FTP && flow->nw_proto != IPPROTO_TCP)) {
>> +/* We can't downgrade to OF1.0 and expect inconsistent CT 
>> actions
>> + * be silently disgarded.  Instead, datapath flow install 
>> fails, so
>> + * it is better to flag inconsistent CT actions as hard errors. 
>> */
>> +return OFPERR_OFPBAC_MATCH_INCONSISTENT;
>> }
>> 
>> if (oc->zone_src.field) {
>> return mf_check_src(>zone_src, flow);
>> }
>> 
>> -err = ofpacts_check(oc->actions, ofpact_ct_get_action_len(oc),
>> -flow, max_ports, table_id, n_tables,
>> -usable_protocols);
>> -return err;
>> +return ofpacts_check(oc->actions, 

Re: [ovs-dev] 2.6 release update

[Ben Pfaff]

On Tue, Sep 27, 2016 at 01:41:06PM -0700, Jarno Rajahalme wrote:
> 
> > On Sep 27, 2016, at 8:36 AM, Ben Pfaff  wrote:
> > 
> > The previous plan was to release last Thursday.  When I surveyed the
> > team at VMware, they said there were a few more bug fixes they wanted to
> > get into 2.6.  I think that the last of these is this fix from Jarno:
> >https://patchwork.ozlabs.org/patch/672410/
> > 
> > Once that's in, which I expect to happen today, we'll do the release.
> > Justin, do you want to send the release patches now so that we can have
> > that ready to go?
> > 
> 
> I’m working today on a small OpenFlow API tightening around validating CT 
> actions. Currently we allow inconsistent CT actions on OpenFlow 1.0, which in 
> some cases leads to surprising results, like packet executes working but 
> corresponding datapath flow setups failing.
> 
> IMO we could address this on a .1 release as well, but it might be nice to 
> have these kind of changes done ASAP…

My general feeling is that we can address this in .1.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] 2.6 release update

[Jarno Rajahalme]

> On Sep 27, 2016, at 8:36 AM, Ben Pfaff  wrote:
> 
> The previous plan was to release last Thursday.  When I surveyed the
> team at VMware, they said there were a few more bug fixes they wanted to
> get into 2.6.  I think that the last of these is this fix from Jarno:
>https://patchwork.ozlabs.org/patch/672410/
> 
> Once that's in, which I expect to happen today, we'll do the release.
> Justin, do you want to send the release patches now so that we can have
> that ready to go?
> 

I’m working today on a small OpenFlow API tightening around validating CT 
actions. Currently we allow inconsistent CT actions on OpenFlow 1.0, which in 
some cases leads to surprising results, like packet executes working but 
corresponding datapath flow setups failing.

IMO we could address this on a .1 release as well, but it might be nice to have 
these kind of changes done ASAP…

  Jarno



___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] The LTE, LTE-Advanced & 5G Ecosystem: 2016 – 2030

[James Bennett]

The LTE, LTE-Advanced & 5G Ecosystem: 2016 – 2030 – Infrastructure,
Devices, Operator Services, Verticals, Strategies & Forecasts

Report Information

Release Year: 2016

Number of Pages: 399

Number of Figures: 283

Report Overview

As a natural upgrade path for mobile operators from the previously detached
GSM, CDMA and TD-SCDMA ecosystems, LTE has emerged as the first truly
global mobile communications standard. Commonly marketed as the “4G”
standard, LTE promises to provide higher data rates and lower latency at a
much lower TCO (Total Cost of Ownership) than 3G technologies.

The TCO and performance is further enhanced by deployment of small cells
and the LTE-Advanced standard, which improves performance and data rates
using features such as the aggregation of carriers, interference management
and advanced antenna techniques.

With over 500 fully commercial network launches, LTE has become a
mainstream technology, and a number of mobile operators have already
deployed LTE-Advanced technology. SNS Research estimates that LTE service
revenues will account for over $600 Billion in 2016. The figure is further
expected to grow at a CAGR of more than 5% over the next four years.

While LTE and LTE-Advanced deployments are still underway, mobile operators
and vendors have already embarked on R initiatives to develop so-called
“5G” networks, with a vision of commercialization by 2020. 5G is
essentially a revolutionary paradigm shift in wireless networking to
support the throughput, latency, and scalability requirements of future use
cases such as extreme bandwidth augmented reality applications and
connectivity management for Billions of M2M (Machine to Machine) devices.

By 2020, LTE and 5G infrastructure investments are expected to account for
a market worth $32 Billion. This includes spending on distributed
macrocells, small cells, C-RAN architecture equipment and mobile core
solutions.

The “LTE, LTE-Advanced & 5G Ecosystem: 2016 – 2030 – Infrastructure,
Devices, Operator Services, Verticals, Strategies & Forecasts” report
presents an in-depth assessment of the LTE, LTE-Advanced and 5G ecosystem
including key market drivers, challenges, technologies, service revenue
potential, deployment strategies, vertical market opportunities, mobile
operator case studies, R initiatives, future roadmap, value chain, vendor
assessment and market share. The report also tracks revenue and shipments
for both infrastructure and devices, along with subscription and service
revenue from 2016 through to 2030.

The report comes with an associated Excel datasheet suite covering
quantitative data from all numeric forecasts presented in the report.

More Information
at: [1]http://www.snstelecom.com/lte-lte-advanced-5g-ecosystem

Other Related Reports

The Private LTE Network Ecosystem: 2016 – 2030

[2]http://www.snstelecom.com/private-lte

The Public Safety LTE & Mobile Broadband Market: 2016 – 2030

[3]http://www.snstelecom.com/public-safety-lte

The 5G Wireless Ecosystem: 2016 – 2030

[4]http://www.snstelecom.com/5g

The HetNet Ecosystem (Small Cells, Carrier Wi-Fi, C-RAN & DAS): 2016 – 2030

[5]http://www.snstelecom.com/hetnet

The Wireless Network Infrastructure Ecosystem: 2016 – 2030

[6]http://www.snstelecom.com/wireless-network-infrastructure

The C-RAN (Centralized Radio Access Network) Ecosystem: 2016 – 2030

[7]http://www.snstelecom.com/c-ran

Topics Covered

The report covers the following topics:
* LTE/LTE-Advanced technology and market status
* 5G technology and R commitments
* Market drivers and barriers
* TCO comparison with legacy technologies
* LTE/5G infrastructure, devices, subscriptions and service revenue
* Infrastructure and device vendor share
* Antenna systems, RAN, mobile core, backhaul and fronthaul deployment
strategies
* Mobile operator reviews, service models, pricing strategies and LTE/5G
deployment case studies
* Unlicensed LTE, VoLTE, RCS, eMBMS and M2M services
* Vertical markets for LTE/5G networks
* Industry roadmap and value chain
* Company profiles and strategies of over 90 ecosystem players including
infrastructure  vendors, device OEMs and mobile operators
* Market analysis and forecasts from 2016 till 2030

Market Analysis & Forecast Segmentation
Market forecasts are provided for each of the following submarkets and
their subcategories:

LTE/5G Infrastructure Shipments & Revenue
* Distributed Macrocell Base Stations
* Small Cells
* RRHs (Remote Radio Heads)
* C-RAN BBUs (Centralized RAN Baseband Units)
* Mobile Core

LTE/5G Device Shipments & Revenue
* Handsets
* Tablets
* Embedded M2M Modules
* USB Dongles
* Routers

LTE/5G Subscriptions and Service Revenue
* FDD LTE
* TD-LTE
* 5G

Private LTE/5G Infrastructure Revenue
* Public Safety
* Military
* Energy & Utilities
* Transportation
* Mining & Others

Regional Markets
* Asia Pacific
* Eastern Europe
* Latin & Central America
* Middle East & Africa
* North America
* Western Europe

Key Questions Answered

The report provides answers to the 

Re: [ovs-dev] GRE over IPsec on CentOS using openvswitch 2.5.0

[Mrityunjay Kumar]

yes .. just seen...

but his answer is not up to mark ...  in IST day time will revert my
finding. again my question ...  it tested welll by some one or we need to
test after having discussion. waiting for ovs dev team to reply on this ...

*Regards*,
Mrityunjay Kumar.
Mobile: +91 - 9731528504


On Wed, Sep 28, 2016 at 1:28 AM, Guru Shetty  wrote:

>
>
> On 27 September 2016 at 12:55, Mrityunjay Kumar 
> wrote:
>
>> Hi Team
>> Request you to please answer. GRE over IPsec on CentOS using openvswitch
>> 2.5.0 is working or not. we need to think accordingly. Please updat only
>> yes or not ?
>>
>
> Did you read Ansis's reply in disc...@openvswitch.org ?
>
>
>>
>> If yes..  let me know how?
>>
>>
>>
>> *Regards*,
>> MJ
>> ___
>> dev mailing list
>> dev@openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
>>
>
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] Any updates on the "userspace meter" patches ?

[Jarno Rajahalme]

> On Sep 27, 2016, at 4:57 AM, Enas Ahmad  wrote:
> 
> Hi,
> I know that meters are still not implemented in the OVS master branch. 
> However, I would like to enquiry about the "userspace meter" patches 
> submitted a while ago by Jarno Rajahalme, is there any updates on these 
> patches? has the implementation been extended to support "DSCP remark" action 
> ? 
> 

They have not been applied, as they still need more work.

Regards,

  Jarno

> Thanks,
> Enas
> 
> This message and its contents, including attachments are intended solely for 
> the original recipient. If you are not the intended recipient or have 
> received this message in error, please notify me immediately and delete this 
> message from your computer system. Any unauthorized use or distribution is 
> prohibited. Please consider the environment before printing this email.

This legalese makes little sense on a public mailing list.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] upcall: Don't start new revalidation round too soon after the last one.

[Jarno Rajahalme]

> On Sep 26, 2016, at 5:39 PM, Ben Pfaff  wrote:
> 
> On Tue, Sep 20, 2016 at 11:42:45AM -0700, Jarno Rajahalme wrote:
>> The execution time of 'ovs-ofctl add-flows' with a large number of
>> flows can be more than halved if revalidators are not running after
>> each flow mod separately.  This was first suspected when it was found
>> that 'ovs-ofctl --bundle add-flows' is about 10 times faster than the
>> same command without the '--bundle' option in a scenario where there
>> is a large set of flows being added and no datapath flows at all.  One
>> of the differences caused by the '--bundle' option is that the
>> revalidators are woken up only once, at the end of the whole set of
>> flow table changes, rather than after each flow table change
>> individually.
>> 
>> This patch limits the revalidation to run at most 200 times a second
>> by enforcing a minimum of 5ms time gap between the start times of
>> revalidation rounds.  If nothing happens in, say 6 milliseconds, and
>> then a new flow table change is signaled, the revalidator threads wake
>> up immediately without any further delay.  Values smaller than 5 were
>> found to increase the 'ovs-ofctl add-flows' execution time noticeably.
>> 
>> Since the revalidators are not running after each flow mod, the
>> overall OVS CPU utilization during the 'ovs-ofctl add-flows' run time
>> is reduced roughly by one core on a four core machine.
>> 
>> In testing the 'ovs-ofctl add-flows' execution time is not
>> significantly improved from this even if the revalidators are not
>> notified about the flow table changes at all.
>> 
>> Signed-off-by: Jarno Rajahalme 
> 
> Is this the patch you said you wanted to squeak into branch-2.6?
> 
> Acked-by: Ben Pfaff 

Yes, thank you. Running the testsuite once more I noticed that I needed to add 
this incremental to wait for the added delay in a test case that changes the 
flow tables in a loop and expected the changes to be instantly visible in the 
datapath:

diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index e2b983f..025c923 100644
--- a/tests/ofproto-dpif.at
+++ b/tests/ofproto-dpif.at
@@ -4609,6 +4609,9 @@ m4_define([CHECK_CONTINUATION], [dnl
 m4_if([$3], [0], [],
 [AT_CHECK([echo "$actions1" | sed 's/pause/controller(pause)/g' | 
ovs-ofctl -O OpenFlow13 add-flows br1 -])])
 
+# Make sure the datapath is up-to-date before sending the packet.
+ovs-appctl revalidator/wait
+
 # Run a packet through the switch.
 AT_CHECK([ovs-appctl netdev-dummy/receive p1 "$flow"], [0], [stdout])

Pushed to master and branch-2.6.

  Jarno

 


___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] GRE over IPsec on CentOS using openvswitch 2.5.0

[Guru Shetty]

On 27 September 2016 at 12:55, Mrityunjay Kumar  wrote:

> Hi Team
> Request you to please answer. GRE over IPsec on CentOS using openvswitch
> 2.5.0 is working or not. we need to think accordingly. Please updat only
> yes or not ?
>

Did you read Ansis's reply in disc...@openvswitch.org ?


>
> If yes..  let me know how?
>
>
>
> *Regards*,
> MJ
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] INSTALL.md: Add details about kernel module preference.

[Darrell Ball]

On Tue, Sep 27, 2016 at 8:21 AM, Guru Shetty  wrote:

>
>
> On 26 September 2016 at 20:52, Darrell Ball  wrote:
>
>>
>>
>> On Mon, Sep 26, 2016 at 7:34 AM, Gurucharan Shetty  wrote:
>>
>>> Signed-off-by: Gurucharan Shetty 
>>> ---
>>>  INSTALL.md | 23 ++-
>>>  1 file changed, 22 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/INSTALL.md b/INSTALL.md
>>> index bb40e4a..6ecefdf 100644
>>> --- a/INSTALL.md
>>> +++ b/INSTALL.md
>>> @@ -322,9 +322,30 @@ Building the Sources
>>>  4. Run "make install" to install the executables and manpages into the
>>> running system, by default under /usr/local.
>>>
>>> -5. If you built kernel modules, you may install and load them, e.g.:
>>> +5. If you built kernel modules, you may install them, e.g.:
>>>
>>>`% make modules_install`
>>> +
>>> +It is possible that you already had a Open vSwitch kernel module
>>> +installed on your machine that came from upstream Linux (in a
>>> +different directory).  To make sure that you insert the Open vSwitch
>>> +kernel module you built from this repository, you should create a
>>> +depmod.d file that prefers your newly installed kernel modules over
>>> +the kernel modules from upstream Linux.  The following snippet of
>>> +code achieves the same.
>>> +
>>> +```
>>> +% config_file="/etc/depmod.d/openvswitch.conf"
>>> +% for module in datapath/linux/*.ko; do
>>> +  modname="$(basename ${module})"
>>> +  echo "override $modname * extra" >> "$config_file"
>>> +  echo "override $modname * weak-updates" >> "$config_file"
>>> +  done
>>> +% depmod -a
>>> +```
>>> +
>>>
>>
>> I tried the script
>>
>> #!/bin/bash
>> config_file="/etc/depmod.d/openvswitch.conf"
>> for module in datapath/linux/*.ko; do
>> modname="$(basename ${module})"
>> echo "override $modname * extra" >> "$config_file"
>> echo "override $modname * weak-updates" >> "$config_file"
>> done
>> depmod -a
>>
>> on Ubuntu 14.04 and the script generated the expected
>> file contents
>>
>> dball@ubuntu:~/openvswitch/ovs/_gcc$ cat /etc/depmod.d/openvswitch.conf
>> override openvswitch.ko * extra
>> override openvswitch.ko * weak-updates
>> override vport-geneve.ko * extra
>> override vport-geneve.ko * weak-updates
>> override vport-gre.ko * extra
>> override vport-gre.ko * weak-updates
>> override vport-lisp.ko * extra
>> override vport-lisp.ko * weak-updates
>> override vport-stt.ko * extra
>> override vport-stt.ko * weak-updates
>> override vport-vxlan.ko * extra
>> override vport-vxlan.ko * weak-updates
>>
>
> Can you try the v3 that I sent. It is very similar to what we do for RHEL
> here:
> https://github.com/openvswitch/ovs/blob/master/rhel/
> openvswitch-kmod-rhel6.spec.in#L65
>


Looks better without the ".ko" suffix in config file

Acked-by: Darrell Ball 




>
>> However the "extra" directory where locally built ovs kos are installed
>> is not
>> taking precedence
>>
>> dball@ubuntu:~/openvswitch/ovs/_gcc$ sudo modinfo openvswitch
>> filename:   /lib/modules/3.19.0-25-generic
>> /kernel/net/openvswitch/openvswitch.ko
>> license:GPL
>> description:Open vSwitch switching datapath
>> srcversion: EB1236CA2503B5F233DE125
>> depends:libcrc32c
>> intree: Y
>> vermagic:   3.19.0-25-generic SMP mod_unload modversions
>> signer: Magrathea: Glacier signing key
>> sig_key:6A:AA:11:D1:8C:2D:3A:40:B1:B4
>> :DB:E5:BF:8A:D6:56:DD:F5:18:38
>> sig_hashalgo:   sha512
>>
>> So I edited the script to do something minimal, although it may not
>> work for all distributions ?
>>
>> #!/bin/bash
>> config_file="/etc/depmod.d/openvswitch.conf"
>> echo "search extra" >> "$config_file"
>> depmod -a
>>
>> dball@ubuntu:~/openvswitch/ovs/_gcc$ cat /etc/depmod.d/openvswitch.conf
>> search extra
>>
>> and it seems to work (i.e. overrides my default config file) on Ubuntu
>>
>> dball@ubuntu:~/openvswitch/ovs/_gcc$ sudo modinfo openvswitch
>> filename:   /lib/modules/3.19.0-25-generic/extra/openvswitch.ko
>> alias:  net-pf-16-proto-16-family-ovs_packet
>> alias:  net-pf-16-proto-16-family-ovs_flow
>> alias:  net-pf-16-proto-16-family-ovs_vport
>> alias:  net-pf-16-proto-16-family-ovs_datapath
>> version:2.6.90
>> license:GPL
>> description:Open vSwitch switching datapath
>> srcversion: E30F336D9883ACAE1CB02EA
>> depends:nf_conntrack,nf_nat,nf_defrag
>> _ipv6,libcrc32c,nf_nat_ipv6,nf_nat_ipv4,gre,nf_defrag_ipv4
>> vermagic:   3.19.0-25-generic SMP mod_unload modversions
>> parm:   udp_port:Destination UDP port (ushort)
>>
>>
>>
>>
>>
>>> +Finally, load the kernel modules that you need.  e.g.:
>>> +
>>>`% /sbin/modprobe openvswitch`
>>>
>>> To verify that the modules have been loaded, run "/sbin/lsmod" and
>>> --
>>> 1.9.1
>>>
>>> ___
>>> dev 

[ovs-dev] GRE over IPsec on CentOS using openvswitch 2.5.0

[Mrityunjay Kumar]

Hi Team
Request you to please answer. GRE over IPsec on CentOS using openvswitch
2.5.0 is working or not. we need to think accordingly. Please updat only
yes or not ?

If yes..  let me know how?



*Regards*,
MJ
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] travis: Work around glibtoolize error.

[Joe Stringer]

On 21 September 2016 at 14:01, Joe Stringer  wrote:
> On 21 September 2016 at 11:44, Lance Richardson  wrote:
>>> From: "Joe Stringer" 
>>> To: dev@openvswitch.org
>>> Sent: Wednesday, September 21, 2016 2:36:42 PM
>>> Subject: [ovs-dev] [PATCH] travis: Work around glibtoolize error.
>>>
>>> Signed-off-by: Joe Stringer 
>>> ---
>>>  .travis/osx-prepare.sh | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/.travis/osx-prepare.sh b/.travis/osx-prepare.sh
>>> index cf46d872edfa..611c0709d760 100755
>>> --- a/.travis/osx-prepare.sh
>>> +++ b/.travis/osx-prepare.sh
>>> @@ -1,3 +1,5 @@
>>>  #!/bin/bash
>>>  set -ev
>>>  pip install --user six
>>> +
>>> +brew uninstall libtool && brew install libtool || true
>>> --
>>> 2.9.3
>>>
>>
>> LGTM, although I wonder what changed in the base image and hope
>> we don't see similar drift in the future...
>
> Looks like it's a migration from macos 10.9->10.11 and upgrade of
> xcode 6.1->7.3 and maybe some other userland changes.
> https://blog.travis-ci.com/2016-09-15-new-default-osx-image-coming/
>
> I'll follow up with Travis-CI, but in the mean time this fixes the
> build so it seems like a good idea.

I received an update from Travis support, and they recommended this
approach until they have a chance to fix their osx images.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/1] Using ethtool on failure using miimon

[Joe Stringer]

Hi David,

Thanks for the submission. Since this is a bugfix for a long-running
behaviour, I reduced the patch to just the functional changes and
applied it to master, branch-2.6 and branch-2.5.

Here's the final change, please let me know if it is still missing something:
https://github.com/openvswitch/ovs/commit/9120cfc05cd49d4ba1a47eb97e6407e72a5d33f7

I had trouble applying your patch but I was able to work around it. In
future please use "git format-patch" to format a patch, and if you
can, "git send-email" to send it. These take care of ensuring that the
patch arrives correctly to the mailinglist. For bugfixes, the change
should also be as small as possible to make it easier to review the
core change and less likely to have unintended consequences.
Refactoring and cosmetic changes should be separate.

Did you ever get confirmation from upstream that the fix was applied to Linux?

On 25 September 2016 at 09:18, David Hill  wrote:
> I'm not a C/C++ developer.  Well this is very far away from my memory.  I
> changed the following line:
>
> +  error = netdev_linux_get_ethtool(name, miimon);
> to
> +  error = netdev_linux_get_ethtool(, );
>
> as it looks like we're sending adresses to functions instead of the values.
> This should work and it
> passed the "make check".
>
> Correct me if I'm wrong please!
>
> Dave
>
>
> On 09/25/2016 12:06 PM, David Hill wrote:
>>
>> From 2748f6325facb7d5d880d620041e2f11767abe0c Mon Sep 17 00:00:00 2001
>> From: David Hill 
>> Date: Tue, 30 Aug 2016 15:13:31 -0400
>> Subject: [PATCH 1/1] netdev-linux.c - Trying to use miimon and on failure
>> failback to ethtool
>>
>> Some network drivers might return true to SIOCGMIIPHY and an error on
>> SIOCGMIIREG, this patch will
>> simply fallback to ethtool if this happens and failover should still
>> happen on an OVS using such nics.
>>
>> Signed-off-by: David Hill 
>>
>> ---
>>  lib/netdev-linux.c | 50
>> ++
>>  1 file changed, 30 insertions(+), 20 deletions(-)
>>
>> diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c
>> index efc9527..05aa91f 100644
>> --- a/lib/netdev-linux.c
>> +++ b/lib/netdev-linux.c
>> @@ -1426,6 +1426,33 @@ netdev_linux_do_miimon(const char *name, int cmd,
>> const char *cmd_name,
>>  }
>>
>>  static int
>> +netdev_linux_get_ethtool(const char *name, bool *miimon)
>> +{
>> +struct mii_ioctl_data data;
>> +int error;
>> +
>> +*miimon = false;
>> +
>> +struct ethtool_cmd ecmd;
>> +VLOG_DBG_RL(, "%s: failed to query MII, falling back to ethtool",
>> +name);
>> +
>> +COVERAGE_INC(netdev_get_ethtool);
>> +memset(, 0, sizeof ecmd);
>> +error = netdev_linux_do_ethtool(name, , ETHTOOL_GLINK,
>> +"ETHTOOL_GLINK");
>> +if (!error) {
>> +struct ethtool_value eval;
>> +memcpy(, , sizeof eval);
>> +*miimon = !!eval.data;
>> +} else {
>> +VLOG_WARN_RL(, "%s: ethtool link status failed", name);
>> +}
>> +
>> +return error;
>> +}
>> +
>> +static int
>>  netdev_linux_get_miimon(const char *name, bool *miimon)
>>  {
>>  struct mii_ioctl_data data;
>> @@ -1443,28 +1470,11 @@ netdev_linux_get_miimon(const char *name, bool
>> *miimon)
>>  if (!error) {
>>  *miimon = !!(data.val_out & BMSR_LSTATUS);
>> -} else {
>> -VLOG_WARN_RL(, "%s: failed to query MII", name);
>> -}
>> -} else {
>> -struct ethtool_cmd ecmd;
>> -
>> -VLOG_DBG_RL(, "%s: failed to query MII, falling back to
>> ethtool",
>> -name);
>> -
>> -COVERAGE_INC(netdev_get_ethtool);
>> -memset(, 0, sizeof ecmd);
>> -error = netdev_linux_do_ethtool(name, , ETHTOOL_GLINK,
>> -"ETHTOOL_GLINK");
>> -if (!error) {
>> -struct ethtool_value eval;
>> -
>> -memcpy(, , sizeof eval);
>> -*miimon = !!eval.data;
>> -} else {
>> -VLOG_WARN_RL(, "%s: ethtool link status failed", name);
>>  }
>>  }
>> +if (error) {
>> +  error = netdev_linux_get_ethtool(, );
>> +}
>>
>>  return error;
>>  }
>> --
>> 2.7.4
>>
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v3] ovn-vtep: fix arping from vtep-gw physical port

[Ramu Ramamurthy]

Currently, arping from a vtep-gw physical-switch port to
a VIF IP address does not work.

When a physical-switch-port arps for an IP address
of a VIF, that arp packet comes into the VIF hypervisor via a
vxlan tunnel. That arp packet must not be responded-to by the
arp responder table because, potentially, multiple hypervisors
could independently respond.

Signed-off-by: Ramu Ramamurthy 
---
 ovn/northd/ovn-northd.8.xml | 5 +++--
 ovn/northd/ovn-northd.c | 5 -
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index 1da633a..f27b776 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -421,8 +421,9 @@
 
 
   
-Priority-100 flows to skip ARP responder if inport is of type
-localnet, and advances directly to the next table.
+Priority-100 flows to skip the ARP responder if inport type is
+localnet or vtep, and advances directly
+to the next table.
   
 
   
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index cdc5525..9606c95 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -2683,7 +2683,10 @@ build_lswitch_flows(struct hmap *datapaths, struct hmap 
*ports,
 continue;
 }
 
-if (!strcmp(op->nbsp->type, "localnet")) {
+/* Skip arp responder if the logical switch inport
+ * is of type localnet or vtep. */
+if (!strcmp(op->nbsp->type, "localnet")
+|| !strcmp(op->nbsp->type, "vtep")) {
 ds_clear();
 ds_put_format(, "inport == %s", op->json_key);
 ovn_lflow_add(lflows, op->od, S_SWITCH_IN_ARP_ND_RSP, 100,
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] vagrant: add CentOS 7.2 support

[Thadeu Lima de Souza Cascardo]

Signed-off-by: Thadeu Lima de Souza Cascardo 
---
 Vagrantfile | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/Vagrantfile b/Vagrantfile
index 91f943d..f83d3fc 100644
--- a/Vagrantfile
+++ b/Vagrantfile
@@ -30,6 +30,15 @@ aptitude -y install -R \
linux-headers-`uname -r`
 SCRIPT
 
+$bootstrap_centos = 

Re: [ovs-dev] How to setup IVSHM in OVS-DPDK

[Amit Pathania]

Hi, this is amit.Did you get solution to your problem?
I also want to carryout process to process communication between different
VMs

-- 
*Amit Pathania*
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] openvswitch: Allow external IPsec tunnel management.

[pravin shelar]

On Mon, Sep 26, 2016 at 1:15 PM, pravin shelar  wrote:
> On Mon, Sep 26, 2016 at 11:49 AM, Ansis Atteka  wrote:
>>
>>
>> On 26 September 2016 at 03:48, Pravin B Shelar  wrote:
>>>
>>> OVS GRE IPsec tunnel support has multiple issues, Therefore
>>
>> s/issues,/issues.
>>>
>>> it was deprecated in OVS 2.6.
>>>
>>> Following patch removes support GRE IPsec and allow external
>>
>> s/support/support for
>> s/allow/allows
>>>
>>> IPsec tunnel management for any type of tunnel not just GRE.
>>>
>>> e.g. user can encrpt Geneve or VxLan traffic.
>>
>> s/encrpt/encrypt
>>>
>>>
>>> It can be done by using openflow pipeline to set skb-mark
>>> and using xfrm to implement IPsec tunnels. xfrm can match
>>> on the skb-mark to encrypt selective tunnel traffic.
>>
>>
>> Some folks may misinterpret the paragraph above that we are recommending
>> them to use XFRM *directly* as an alternative. XFRM is just NetLink
>> interface to linux kernel to install IPsec keys after these keys have been
>> negotiated by IPsec keying daemon, such as strongSwan, openSwan/libreswan or
>> racoon.
>>
>> Instead I would recommend users to use one of the IPsec keying daemons
>> rather than XFRM directly.
>>
> ok, sounds good, I will update commit msg.
>
>>> VMware-BZ: 1710701
>>> Signed-off-by: Pravin B Shelar 
>>> ---
>>> This is targeted for OVS master branch only.
>>> ---
>>>  NEWS |   1 +
>>>  README.md|   2 +-
>>>
>>>  debian/automake.mk   |   7 -
>>>  debian/control   |  24 --
>>>  debian/openvswitch-ipsec.dirs|   1 -
>>>  debian/openvswitch-ipsec.init| 203 
>>>  debian/openvswitch-ipsec.install |   1 -
>>>  debian/ovs-monitor-ipsec | 507
>>> ---
>>>  lib/netdev-vport.c   |  67 +-
>>>  lib/netdev.h |   1 -
>>>  ofproto/ofproto-dpif-ipfix.c |  15 --
>>>  ofproto/ofproto-dpif-sflow.c |   7 -
>>>  ofproto/tunnel.c |  13 -
>>>  tests/automake.mk|   1 -
>>>  tests/ofproto-macros.at  |  49 
>>>  tests/ovn-controller.at  |   2 +-
>>>  tests/ovs-monitor-ipsec.at   | 271 -
>>>  tests/testsuite.at   |   1 -
>>>  tests/tunnel-push-pop-ipv6.at|   2 +-
>>>  tests/tunnel-push-pop.at |   2 +-
>>>  tests/tunnel.at  |  87 +--
>>>  utilities/bugtool/ovs-bugtool.in |   2 +-
>>>  utilities/ovs-appctl.8.in|   4 +-
>>>  vswitchd/vswitch.xml |  57 +
>>>  24 files changed, 23 insertions(+), 1304 deletions(-)
>>>  delete mode 100644 debian/openvswitch-ipsec.dirs
>>>  delete mode 100755 debian/openvswitch-ipsec.init
>>>  delete mode 100644 debian/openvswitch-ipsec.install
>>>  delete mode 100755 debian/ovs-monitor-ipsec
>>>  delete mode 100644 tests/ovs-monitor-ipsec.at
>>
>>
>> Assuming you were able to build all other debian packages with "fakeroot
>> debian/rules binary" after removing and editing those files, then
>> Acked-by: Ansis Atteka 
>>
> Thanks for review.
>
>> Let me know, if you want me to independently verify that as well?
>
> I will test this but it will be nice if you verify it independently.

I tested it on Debian, It was pretty straight forward to build Debian
packages. I did not see any issue with the patch. so I pushed the
patch to master.

Thanks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ofp-actions: Error on conntrack action inconsistency.

[Joe Stringer]

On 26 September 2016 at 18:46, Jarno Rajahalme  wrote:
> Setting up a datapath flow that has a conntrack action with 'alg=ftp',
> but does not match on 'nw_proto=tcp' fails with 'WARN' in
> ovs-vswitchd.log.  It is better to flag such inconsistencies during
> OpenFlow rule set-up time.  Also, conntrack action inconsistencies
> should be flagged as such, rather than assuming that falling back to
> OpenFlow 1.0 (which allows inconsistent actions) would remedy the
> situation.
>
> Remove the IP check from the action inconsistency check so that it is
> possible to write rules that operate on both IPv4 and IPv6 packets,
> when the action itself is not IP version dependent.  Correspondingly,
> when translating a conntrack action, do not issue any datapath actions
> if the packet being translated is not an IP packet, as conntrack can
> operate only on IP packets and a datapath flow set-up otherwise fails
> anyway.
>
> Signed-off-by: Jarno Rajahalme 

I see about three separate changes here, it would be easier to
understand what you're trying to solve if they were proposed
separately. I also see a few cosmetic changes which are usually
handled separate from functional changes.

* Ensuring match on TCP for alg=ftp looks good

* Enforcing the action inconsistency check

Falling back to OF1.0 could allow one flow to execute CT() on any
{ip,ipv6} packets, so while it may fail it's also not a terrible
assumption that it may remedy the situation. That said, it sounds like
a reasonable change to me - I doubt that people are relying on this,
and it makes the errors more explicit by erroring back at the OF layer
rather than printing a message in a kernel log somewhere.

There may be an argument for the two above being bugfixes: people
running v2.5 LTS are more likely to run into unexpected translation
errors in the datapath without these checks being properly presented
at the OpenFlow layer.

* Removing IP check from action inconsistency check

I wouldn't mind some input from eg. OVN pipeline writers whether it is
useful to match on any proto (ie, ipv4+ipv6) to do CT(). This is a
basic tradeoff between pipeline flexibility and explicit erroring at
the OpenFlow layer. I could see someone wanting to build conjunctive
flows that do CT(), but it's disallowed today and no-one's complained,
so is it really that useful?

Regardless I'm not sure that silently skipping the CT() action is
quite right - shouldn't it complain that the flows are wrong?

> ---
>  include/openvswitch/ofp-actions.h |  2 +-
>  lib/ofp-actions.c | 22 +++---
>  ofproto/ofproto-dpif-xlate.c  | 10 +++---
>  tests/ofproto-dpif.at |  6 +++---
>  tests/ovs-ofctl.at| 34 +-
>  5 files changed, 39 insertions(+), 35 deletions(-)
>
> diff --git a/include/openvswitch/ofp-actions.h 
> b/include/openvswitch/ofp-actions.h
> index 67e84fa..74e9dcc 100644
> --- a/include/openvswitch/ofp-actions.h
> +++ b/include/openvswitch/ofp-actions.h
> @@ -556,7 +556,7 @@ enum nx_conntrack_flags {
>  #define NX_CT_RECIRC_NONE OFPTT_ALL
>
>  #if !defined(IPPORT_FTP)
> -#defineIPPORT_FTP  21
> +#define IPPORT_FTP  21
>  #endif
>
>  /* OFPACT_CT.
> diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
> index 22c7b16..4a8e79d 100644
> --- a/lib/ofp-actions.c
> +++ b/lib/ofp-actions.c
> @@ -7029,31 +7029,31 @@ ofpact_check__(enum ofputil_protocol 
> *usable_protocols, struct ofpact *a,
>
>  case OFPACT_CT: {
>  struct ofpact_conntrack *oc = ofpact_get_CT(a);
> -enum ofperr err;
>
> -if (!dl_type_is_ip_any(flow->dl_type)
> -|| (flow->ct_state & CS_INVALID && oc->flags & NX_CT_F_COMMIT)) {
> -inconsistent_match(usable_protocols);
> +if ((flow->ct_state & CS_INVALID && oc->flags & NX_CT_F_COMMIT)
> +|| (oc->alg == IPPORT_FTP && flow->nw_proto != IPPROTO_TCP)) {
> +/* We can't downgrade to OF1.0 and expect inconsistent CT actions
> + * be silently disgarded.  Instead, datapath flow install fails, 
> so
> + * it is better to flag inconsistent CT actions as hard errors. 
> */
> +return OFPERR_OFPBAC_MATCH_INCONSISTENT;
>  }
>
>  if (oc->zone_src.field) {
>  return mf_check_src(>zone_src, flow);
>  }
>
> -err = ofpacts_check(oc->actions, ofpact_ct_get_action_len(oc),
> -flow, max_ports, table_id, n_tables,
> -usable_protocols);
> -return err;
> +return ofpacts_check(oc->actions, ofpact_ct_get_action_len(oc),
> + flow, max_ports, table_id, n_tables,
> + usable_protocols);
>  }
>
>  case OFPACT_NAT: {
>  struct ofpact_nat *on = ofpact_get_NAT(a);
>
> -if (!dl_type_is_ip_any(flow->dl_type) ||
> -(on->range_af == AF_INET && flow->dl_type != 

Re: [ovs-dev] [PATCH] OVSDB: Fix segfalut during replication.

[Andy Zhou]

On Mon, Sep 26, 2016 at 8:30 PM, Ben Pfaff  wrote:

> On Tue, Sep 20, 2016 at 01:27:08PM -0700, Andy Zhou wrote:
> > The newly added replication logic makes it possible for a monitor to
> > receive delete and insertion of the same row back to back, which
> > was not possible before. Add logic (and comment) to handle this
> > case to avoid follow crash reported by Valgrind:
>
> On Tue, Sep 20, 2016 at 01:27:08PM -0700, Andy Zhou wrote:
> > The newly added replication logic makes it possible for a monitor to
> > receive delete and insertion of the same row back to back, which
> > was not possible before. Add logic (and comment) to handle this
> > case to avoid follow crash reported by Valgrind:
>
> Thanks a lot.
>
> Acked-by: Ben Pfaff 
>
Thanks for the review. Pushed to master and branch-2.6.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ovsdb: Fix memory leak when disposing 'replication_dbs'

[Andy Zhou]

On Mon, Sep 26, 2016 at 8:32 PM, Ben Pfaff  wrote:

> On Tue, Sep 20, 2016 at 05:49:47PM -0700, Andy Zhou wrote:
> > Found by inspection.
> >
> > The 'replication_dbs' structure was not freed after use.
> > Fix by adding a new function replication_dbs_destroy().
> >
> > Also remove unnecessary global pointer variables initializer.
> >
> > Signed-off-by: Andy Zhou 
>
> Acked-by: Ben Pfaff 
>

Thanks. Pushed to master and branch-2.6
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] Prepare for 2.6.1.

[Ben Pfaff]

On Tue, Sep 27, 2016 at 10:16:26AM -0700, Justin Pettit wrote:
> Signed-off-by: Justin Pettit 

Thanks!

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/2] Set release date for 2.6.0.

[Ben Pfaff]

On Tue, Sep 27, 2016 at 10:16:25AM -0700, Justin Pettit wrote:
> Signed-off-by: Justin Pettit 

Let's give Jarno a bit of time to get his last fix in, but here's my ack
in advance.

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [branch-2.5 1/2] Set release date for 2.5.1.

[Ben Pfaff]

On Tue, Sep 27, 2016 at 10:23:03AM -0700, Justin Pettit wrote:
> Signed-off-by: Justin Pettit 

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [branch-2.5 2/2] Prepare for 2.5.2.

[Ben Pfaff]

On Tue, Sep 27, 2016 at 10:23:04AM -0700, Justin Pettit wrote:
> Signed-off-by: Justin Pettit 

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [branch-2.5 2/2] Prepare for 2.5.2.

[Justin Pettit]

Signed-off-by: Justin Pettit 
---
 NEWS | 4 
 configure.ac | 2 +-
 debian/changelog | 7 +++
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 570b995..62afe6e 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,7 @@
+v2.5.2 - xx xxx 
+-
+
+
 v2.5.1 - 27 Sep 2016
 -
- DPDK:
diff --git a/configure.ac b/configure.ac
index 171b8b1..2e641ea 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@
 # limitations under the License.
 
 AC_PREREQ(2.63)
-AC_INIT(openvswitch, 2.5.1, b...@openvswitch.org)
+AC_INIT(openvswitch, 2.5.2, b...@openvswitch.org)
 AC_CONFIG_SRCDIR([datapath/datapath.c])
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_AUX_DIR([build-aux])
diff --git a/debian/changelog b/debian/changelog
index e7e9024..7d08587 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+openvswitch (2.5.2-1) unstable; urgency=low
+   [ Open vSwitch team ]
+   * New upstream version
+   - Nothing yet!
+
+ -- Open vSwitch team   Tue, 27 Sep 2016 10:21:47 -0700
+
 openvswitch (2.5.1-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [branch-2.5 1/2] Set release date for 2.5.1.

[Justin Pettit]

Signed-off-by: Justin Pettit 
---
 NEWS |  4 ++--
 debian/changelog | 13 ++---
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/NEWS b/NEWS
index c31c7ad..570b995 100644
--- a/NEWS
+++ b/NEWS
@@ -1,4 +1,4 @@
-v2.5.1 - xx xxx 
+v2.5.1 - 27 Sep 2016
 -
- DPDK:
  * New appctl command 'dpif-netdev/pmd-rxq-show' to check the port/rxq
@@ -7,7 +7,7 @@ v2.5.1 - xx xxx 
- ovs-pki: Changed message digest algorithm from SHA-1 to SHA-512 because
  SHA-1 is no longer secure and some operating systems have started to
  disable it in OpenSSL.
-
+   - Bug fixes
 
 v2.5.0 - 26 Feb 2016
 -
diff --git a/debian/changelog b/debian/changelog
index aeb86a5..e7e9024 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,16 @@
 openvswitch (2.5.1-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
-   - Nothing yet!
-
- -- Open vSwitch team   Fri, 26 Feb 2016 17:23:21 -0700
+   - DPDK:
+ * New appctl command 'dpif-netdev/pmd-rxq-show' to check the port/rxq
+   assignment.
+ * Type of log messages from PMD threads changed from INFO to DBG.
+   - ovs-pki: Changed message digest algorithm from SHA-1 to SHA-512 because
+ SHA-1 is no longer secure and some operating systems have started to
+ disable it in OpenSSL.
+   - Bug fixes
+
+ -- Open vSwitch team   Tue, 27 Sep 2016 10:18:23 -0700
 
 openvswitch (2.5.0-1) unstable; urgency=low
[ Open vSwitch team ]
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 1/2] Set release date for 2.6.0.

[Justin Pettit]

Signed-off-by: Justin Pettit 
---
 NEWS | 5 +
 debian/changelog | 2 +-
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/NEWS b/NEWS
index fc5065c..d921ccf 100644
--- a/NEWS
+++ b/NEWS
@@ -1,7 +1,4 @@
-
--
-
-v2.6.0 - xx xxx 
+v2.6.0 - 27 Sep 2016
 -
- First supported release of OVN.  See ovn-architecture(7) for more
  details.
diff --git a/debian/changelog b/debian/changelog
index 93a1708..46e7473 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -122,7 +122,7 @@ openvswitch (2.6.0-1) unstable; urgency=low
- Add 'mtu_request' column to the Interface table. It can be used to
  configure the MTU of non-internal ports.
 
- -- Open vSwitch team   Mon, 15 Aug 2016 19:53:13 -0700
+ -- Open vSwitch team   Tue, 27 Sep 2016 10:13:47 -0700
 
 openvswitch (2.5.0-1) unstable; urgency=low
[ Open vSwitch team ]
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 2/2] Prepare for 2.6.1.

[Justin Pettit]

Signed-off-by: Justin Pettit 
---
 NEWS | 4 
 configure.ac | 2 +-
 debian/changelog | 7 +++
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index d921ccf..e15ad09 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,7 @@
+v2.6.1 - xx xxx 
+-
+
+
 v2.6.0 - 27 Sep 2016
 -
- First supported release of OVN.  See ovn-architecture(7) for more
diff --git a/configure.ac b/configure.ac
index 3493711..da3bbae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@
 # limitations under the License.
 
 AC_PREREQ(2.63)
-AC_INIT(openvswitch, 2.6.0, b...@openvswitch.org)
+AC_INIT(openvswitch, 2.6.1, b...@openvswitch.org)
 AC_CONFIG_SRCDIR([datapath/datapath.c])
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_AUX_DIR([build-aux])
diff --git a/debian/changelog b/debian/changelog
index 46e7473..d9b6bf3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+openvswitch (2.6.1-1) unstable; urgency=low
+   [ Open vSwitch team ]
+   * New upstream version
+   - Nothing yet!
+
+ -- Open vSwitch team   Tue, 27 Sep 2016 10:15:43 -0700
+
 openvswitch (2.6.0-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] GRE over IPsec on CentOS

[Ansis Atteka]

On Sep 26, 2016 7:02 PM,  wrote:
>
> Hi all ,
>
> I have been trying to test IPSEC over GRE on Centos7.3 . I am able to
test on ubuntu14.04 .

The ovs-monitor-ipsec daemon never was packaged (ie had *.rpm package) for
CentOS. Just for debain/ubuntu.

However, now we just removed debian package as well. See latest Pravin's
patch for more details that he sent a day ago.

The history behind this is that skb mark was taken away from IPsec. I will
try to think about it if it it still somehow possible to salvage the
situation and have IPsec work properly without havin least significant skb
mark bit assigned to IPsec.

>
> I wanted to know whether this feature is supported on Centos .
>
>
> If not supported, please let me know how to achieve IPSEC over GRE on
Centos .
>
>
> thanks
> MJ
> -
>
> We did integration on Debian, but it shouldn't be hard to port to
CentOS.  It uses racoon and ipsec-tools, and is managed by the
"debian/ovs-monitor-ipsec".  I'm not 100% happy with our solution, but it
works.  I'd start by looking there.
>
> --Justin
>
>
> On Dec 14, 2012, at 1:49 AM, Diego Rivero http://openvswitch.org/mailman/listinfo/dev>> wrote:
>
> > How can I achieve GRE over IPsec on CentOS 6.3 instead of debian?
> >
> > So far what I've understood is the following..
> >
> > # ovs-vsctl add-port br0 gre0
> > # ovs-vsctl set interface gre0 type=ipsec_gre \
> > options:remote_ip=192.168.2.xxx \
> > options:psk=testtest \
> > options:certificate=cert.pem \
> > options:peer_cert='"-BEGIN CERTIFICATE-(not a real peer
certificate)-END CERTIFICATE- \
> >
> >
> > But I don't know how to move it forward. Do I need to install openswan
for encryption? How can I configure to tell open vswitch the existance of
openswan? Does open vswitch have an encription module on its own?
> >
> > Thanks in advance.
> >
> > Diego
> > ___
> > dev mailing list
> > dev at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
>
>
>
> The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s) and
may contain proprietary, confidential or privileged information. If you are
not the intended recipient, you should not disseminate, distribute or copy
this e-mail. Please notify the sender immediately and destroy all copies of
this message and any attachments. WARNING: Computer viruses can be
transmitted via email. The recipient should check this email and any
attachments for the presence of viruses. The company accepts no liability
for any damage caused by any virus transmitted by this email. www.wipro.com
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] 2.6 release update

[Ben Pfaff]

The previous plan was to release last Thursday.  When I surveyed the
team at VMware, they said there were a few more bug fixes they wanted to
get into 2.6.  I think that the last of these is this fix from Jarno:
https://patchwork.ozlabs.org/patch/672410/

Once that's in, which I expect to happen today, we'll do the release.
Justin, do you want to send the release patches now so that we can have
that ready to go?

Thanks,

Ben.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [ovs-discuss] Configuring MTU for dpdk and vhost ports

[Kapil Adhikesavalu]

Thanks Mark, just figured that myself, i wasn't using the latest OVS, so
mtu_request wasn't working.. Appreciate your help.

Regards
Kapil.

On Tue, Sep 27, 2016 at 8:47 PM, Kavanagh, Mark B  wrote:

> >
> >Hi,
> >
> >Is there a way to configure MTU for dpdk and vhost ports from its default
> 1500 ?
> >I read, "with OVS, Normally the MTU should be changed using operating
> system specific
> >interfaces (e.g. ifconfig).", but as they are dpdk ports, how can i
> configure them ?
> >
>
> Hi Kapil,
>
> Depending on the version of OvS that you're using, you may use the
> Interface's 'mtu_request' field to modify the MTU of DPDK-type ports.
>
> From INSTALL.DPDK-ADVANCED.md:
>
> "By default, DPDK ports are configured with standard Ethernet MTU
> (1500B). To
> enable Jumbo Frames support for a DPDK port, change the
> Interface's `mtu_request`
> attribute to a sufficiently large value.
>
> e.g. Add a DPDK Phy port with MTU of 9000:
>
> `ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk --
> set Interface dpdk0 mtu_request=9000`
>
> e.g. Change the MTU of an existing port to 6200:
>
> `ovs-vsctl set Interface dpdk0 mtu_request=6200`"
>
> This functionality is currently supported on OvS Master and 2.6 branches.
>
> Hope this helps,
> Mark
>
> >Regards
> >Kapil
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v3] INSTALL.md: Add details about kernel module preference.

[Gurucharan Shetty]

Signed-off-by: Gurucharan Shetty 
---
 INSTALL.md | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/INSTALL.md b/INSTALL.md
index bb40e4a..a073465 100644
--- a/INSTALL.md
+++ b/INSTALL.md
@@ -322,9 +322,30 @@ Building the Sources
 4. Run "make install" to install the executables and manpages into the
running system, by default under /usr/local.
 
-5. If you built kernel modules, you may install and load them, e.g.:
+5. If you built kernel modules, you may install them, e.g.:
 
   `% make modules_install`
+
+It is possible that you already had a Open vSwitch kernel module
+installed on your machine that came from upstream Linux (in a
+different directory).  To make sure that you insert the Open vSwitch
+kernel module you built from this repository, you should create a
+depmod.d file that prefers your newly installed kernel modules over
+the kernel modules from upstream Linux.  The following snippet of
+code achieves the same.
+
+```
+% config_file="/etc/depmod.d/openvswitch.conf"
+% for module in datapath/linux/*.ko; do
+  modname="$(basename ${module})"
+  echo "override ${modname%.ko} * extra" >> "$config_file"
+  echo "override ${modname%.ko} * weak-updates" >> "$config_file"
+  done
+% depmod -a
+```
+
+Finally, load the kernel modules that you need.  e.g.:
+
   `% /sbin/modprobe openvswitch`
 
To verify that the modules have been loaded, run "/sbin/lsmod" and
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] INSTALL.md: Add details about kernel module preference.

[Guru Shetty]

On 26 September 2016 at 20:52, Darrell Ball  wrote:

>
>
> On Mon, Sep 26, 2016 at 7:34 AM, Gurucharan Shetty  wrote:
>
>> Signed-off-by: Gurucharan Shetty 
>> ---
>>  INSTALL.md | 23 ++-
>>  1 file changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/INSTALL.md b/INSTALL.md
>> index bb40e4a..6ecefdf 100644
>> --- a/INSTALL.md
>> +++ b/INSTALL.md
>> @@ -322,9 +322,30 @@ Building the Sources
>>  4. Run "make install" to install the executables and manpages into the
>> running system, by default under /usr/local.
>>
>> -5. If you built kernel modules, you may install and load them, e.g.:
>> +5. If you built kernel modules, you may install them, e.g.:
>>
>>`% make modules_install`
>> +
>> +It is possible that you already had a Open vSwitch kernel module
>> +installed on your machine that came from upstream Linux (in a
>> +different directory).  To make sure that you insert the Open vSwitch
>> +kernel module you built from this repository, you should create a
>> +depmod.d file that prefers your newly installed kernel modules over
>> +the kernel modules from upstream Linux.  The following snippet of
>> +code achieves the same.
>> +
>> +```
>> +% config_file="/etc/depmod.d/openvswitch.conf"
>> +% for module in datapath/linux/*.ko; do
>> +  modname="$(basename ${module})"
>> +  echo "override $modname * extra" >> "$config_file"
>> +  echo "override $modname * weak-updates" >> "$config_file"
>> +  done
>> +% depmod -a
>> +```
>> +
>>
>
> I tried the script
>
> #!/bin/bash
> config_file="/etc/depmod.d/openvswitch.conf"
> for module in datapath/linux/*.ko; do
> modname="$(basename ${module})"
> echo "override $modname * extra" >> "$config_file"
> echo "override $modname * weak-updates" >> "$config_file"
> done
> depmod -a
>
> on Ubuntu 14.04 and the script generated the expected
> file contents
>
> dball@ubuntu:~/openvswitch/ovs/_gcc$ cat /etc/depmod.d/openvswitch.conf
> override openvswitch.ko * extra
> override openvswitch.ko * weak-updates
> override vport-geneve.ko * extra
> override vport-geneve.ko * weak-updates
> override vport-gre.ko * extra
> override vport-gre.ko * weak-updates
> override vport-lisp.ko * extra
> override vport-lisp.ko * weak-updates
> override vport-stt.ko * extra
> override vport-stt.ko * weak-updates
> override vport-vxlan.ko * extra
> override vport-vxlan.ko * weak-updates
>

Can you try the v3 that I sent. It is very similar to what we do for RHEL
here:
https://github.com/openvswitch/ovs/blob/master/rhel/openvswitch-kmod-rhel6.spec.in#L65


>
> However the "extra" directory where locally built ovs kos are installed is
> not
> taking precedence
>
> dball@ubuntu:~/openvswitch/ovs/_gcc$ sudo modinfo openvswitch
> filename:   /lib/modules/3.19.0-25-generic/kernel/net/openvswitch/
> openvswitch.ko
> license:GPL
> description:Open vSwitch switching datapath
> srcversion: EB1236CA2503B5F233DE125
> depends:libcrc32c
> intree: Y
> vermagic:   3.19.0-25-generic SMP mod_unload modversions
> signer: Magrathea: Glacier signing key
> sig_key:6A:AA:11:D1:8C:2D:3A:40:B1:B4
> :DB:E5:BF:8A:D6:56:DD:F5:18:38
> sig_hashalgo:   sha512
>
> So I edited the script to do something minimal, although it may not
> work for all distributions ?
>
> #!/bin/bash
> config_file="/etc/depmod.d/openvswitch.conf"
> echo "search extra" >> "$config_file"
> depmod -a
>
> dball@ubuntu:~/openvswitch/ovs/_gcc$ cat /etc/depmod.d/openvswitch.conf
> search extra
>
> and it seems to work (i.e. overrides my default config file) on Ubuntu
>
> dball@ubuntu:~/openvswitch/ovs/_gcc$ sudo modinfo openvswitch
> filename:   /lib/modules/3.19.0-25-generic/extra/openvswitch.ko
> alias:  net-pf-16-proto-16-family-ovs_packet
> alias:  net-pf-16-proto-16-family-ovs_flow
> alias:  net-pf-16-proto-16-family-ovs_vport
> alias:  net-pf-16-proto-16-family-ovs_datapath
> version:2.6.90
> license:GPL
> description:Open vSwitch switching datapath
> srcversion: E30F336D9883ACAE1CB02EA
> depends:nf_conntrack,nf_nat,nf_defrag_ipv6,libcrc32c,nf_nat_ipv6,
> nf_nat_ipv4,gre,nf_defrag_ipv4
> vermagic:   3.19.0-25-generic SMP mod_unload modversions
> parm:   udp_port:Destination UDP port (ushort)
>
>
>
>
>
>> +Finally, load the kernel modules that you need.  e.g.:
>> +
>>`% /sbin/modprobe openvswitch`
>>
>> To verify that the modules have been loaded, run "/sbin/lsmod" and
>> --
>> 1.9.1
>>
>> ___
>> dev mailing list
>> dev@openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
>>
>
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [ovs-discuss] Configuring MTU for dpdk and vhost ports

[Kavanagh, Mark B]

>
>Hi,
>
>Is there a way to configure MTU for dpdk and vhost ports from its default 1500 
>?
>I read, "with OVS, Normally the MTU should be changed using operating system 
>specific
>interfaces (e.g. ifconfig).", but as they are dpdk ports, how can i configure 
>them ?
>

Hi Kapil,

Depending on the version of OvS that you're using, you may use the Interface's 
'mtu_request' field to modify the MTU of DPDK-type ports.

From INSTALL.DPDK-ADVANCED.md:

"By default, DPDK ports are configured with standard Ethernet MTU 
(1500B). To
enable Jumbo Frames support for a DPDK port, change the Interface's 
`mtu_request`
attribute to a sufficiently large value.

e.g. Add a DPDK Phy port with MTU of 9000:

`ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk -- set 
Interface dpdk0 mtu_request=9000`

e.g. Change the MTU of an existing port to 6200:

`ovs-vsctl set Interface dpdk0 mtu_request=6200`"

This functionality is currently supported on OvS Master and 2.6 branches.

Hope this helps,
Mark

>Regards
>Kapil
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Configuring MTU for dpdk and vhost ports

[Kapil Adhikesavalu]

Hi,

Is there a way to configure MTU for dpdk and vhost ports from its default
1500 ?
I read, "with OVS, Normally the MTU should be changed using operating
system specific interfaces (e.g. ifconfig).", but as they are dpdk ports,
how can i configure them ?

Regards
Kapil
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVS+DPDK: Requested device 0000:01:00.0 cannot be used

[Aaron Conole]

ychen  writes:

> hi, 
> I follow the doc "INSTALLDPDK.md" to build ovs dpdk envrioment, but failed to 
> start ovs-vswitchd
> here is my configurations:
> 1. kernel: 3.10.45-openstack-amd64 #1 SMP Tue Jul 1 01:52:20 UTC 2014 x86_64 
> GNU/Linux
> 2. NIC: 
> 01:00.0 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit 
> SFI/SFP+ Network Connection [8086:10fb] (rev 01)
> 01:00.1 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit 
> SFI/SFP+ Network Connection [8086:10fb] (rev 01)
> 06:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network 
> Connection [8086:1521] (rev 01)
> 06:00.1 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network 
> Connection [8086:1521] (rev 01)

Can you also include the output of dpdk_nic_bind?  It is helpful to see
which driver you are using.  What linux distribution is this on?

> 3. IOMMU support
>  /sys/kernel/iommu_groups/12/devices/:01:00.0
> /sys/kernel/iommu_groups/12/devices/:01:00.1
> /sys/kernel/iommu_groups/9/devices/:06:00.0
> /sys/kernel/iommu_groups/9/devices/:06:00.1
> BOOT_IMAGE=/boot/vmlinuz-3.10.45-openstack-amd64 
> root=UUID=5cc1592c-91b4-485c-96cc-4528837dbeef ro default_hugepagesz=1G 
> hugepagesz=1G hugepages=4 iommu=pt intel_iommu=on isolcpus=0-12 
> intel_idle.max_cstate=0 idle=poll quiet cgroup_enable=memory crashkernel=512M
> 4. hugepage support
> AnonHugePages:229376 kB
> HugePages_Total:   4
> HugePages_Free:2
> HugePages_Rsvd:0
> HugePages_Surp:0
> Hugepagesize:1048576 kB
> 5.cpu information
>   Architecture:  x86_64
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:Little Endian
> CPU(s):48
> On-line CPU(s) list:   0-47
> Thread(s) per core:2
> Core(s) per socket:12
> Socket(s): 2
> NUMA node(s):  2
> Vendor ID: GenuineIntel
> CPU family:6
> Model: 63
> Stepping:  2
> CPU MHz:   2599.988
> BogoMIPS:  4601.07
> Virtualization:VT-x
> L1d cache: 32K
> L1i cache: 32K
> L2 cache:  256K
> L3 cache:  30720K
> NUMA node0 CPU(s): 
> 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46
> NUMA node1 CPU(s): 
> 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47
>
>
> 6.dpdk parameters in ovs
>datapath_types  : [netdev, system]
> db_version  : []
> external_ids: {}
> iface_types : [dpdk, dpdkr, dpdkvhostuser, dpdkvhostuserclient, 
> geneve, gre, internal, ipsec_gre, lisp, patch, stt, system, tap, vxlan]
> manager_options : []
> next_cfg: 2
> other_config: {dpdk-init="true", dpdk-lcore-mask="0xf", 
> dpdk-socket-mem="1024,1024", pmd-cpu-mask="0x3"}
> 7. error logs when start ovs-vswtichd
> 2016-09-27T07:15:27Z|1|vlog|INFO|opened log file 
> /var/log/openvswitch/ovs-vswitchd.log
> 2016-09-27T07:15:27Z|2|ovs_numa|INFO|Discovered 24 CPU cores on NUMA node > 0
> 2016-09-27T07:15:27Z|3|ovs_numa|INFO|Discovered 24 CPU cores on NUMA node 
> 1
> 2016-09-27T07:15:27Z|4|ovs_numa|INFO|Discovered 2 NUMA nodes and 48 CPU 
> cores
> 2016-09-27T07:15:27Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock: 
> connecting...
> 2016-09-27T07:15:27Z|6|reconnect|INFO|unix:/var/run/openvswitch/db.sock: 
> connected
> 2016-09-27T07:15:27Z|7|dpdk|INFO|DPDK Enabled, initializing
> 2016-09-27T07:15:27Z|8|dpdk|INFO|No vhost-sock-dir provided - defaulting 
> to /var/run/openvswitch
> 2016-09-27T07:15:27Z|9|dpdk|INFO|EAL ARGS: ovs-vswitchd -c 0xf 
> --socket-mem 1024,1024
> EAL: Detected 48 lcore(s)
> PMD: bnxt_rte_pmd_init() called for (null)
> EAL: PCI device :01:00.0 on NUMA socket 0
> EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
> EAL: Error - exiting with code: 1
>   Cause: Requested device :01:00.0 cannot be used

This can mean that the device is not properly bound, bound to an
unsupported driver, or even a possible SELinux issue.

> 8. version information
>Open vSwitch 2.6.0
>   dpdk: 16.07
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVS+DPDK: Requested device 0000:01:00.0 cannot be used

[Ilya Maximets]

Yet another workaround: Disable all ports but one on each NIC.

On 27.09.2016 15:18, Ilya Maximets wrote:
>> 3. IOMMU support
>>  /sys/kernel/iommu_groups/12/devices/:01:00.0
>> /sys/kernel/iommu_groups/12/devices/:01:00.1
>> /sys/kernel/iommu_groups/9/devices/:06:00.0
>> /sys/kernel/iommu_groups/9/devices/:06:00.1
> 
> It's all because ports of your NICs are in the same iommu groups.
> You need to patch your kernel to fix this behaviour or get another kernel.
> Also, you may try to use UIO driver instead.
> 
> Best regards, Ilya Maximets.
> 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH ovs RFC 8/9] dpif-hw-netlink: support for flow dump from tc

[Paul Blakey]

added support dump flows from tc.

Signed-off-by: Paul Blakey 
Signed-off-by: Shahar Klein 
---
 lib/dpif-hw-netlink.c | 215 ++
 1 file changed, 199 insertions(+), 16 deletions(-)

diff --git a/lib/dpif-hw-netlink.c b/lib/dpif-hw-netlink.c
index 9473832..663b15b 100644
--- a/lib/dpif-hw-netlink.c
+++ b/lib/dpif-hw-netlink.c
@@ -852,63 +852,246 @@ static int
 dpif_hw_netlink_flow_flush(struct dpif *dpif_)
 {
 struct dpif_hw_netlink *dpif = dpif_hw_netlink_cast(dpif_);
+struct port_netdev_hash_data *data;
 
+VLOG_DBG("%s %d %s, (%p) flush start\n", __FILE__, __LINE__, __func__,
+ dpif);
+HMAP_FOR_EACH(data, node, >port_to_netdev) {
+if (data->netdev) {
+VLOG_DBG("%s %d %s, (%p) flusing port: %d, netdev: %p\n", __FILE__,
+ __LINE__, __func__, dpif, data->port, data->netdev);
+tc_flush_flower(netdev_get_ifindex(data->netdev));
+}
+}
+
+VLOG_DBG("%s %d %s, (%p) flush end\n", __FILE__, __LINE__, __func__, dpif);
 return dpif->lp_dpif_netlink->dpif_class->
 flow_flush(dpif->lp_dpif_netlink);
 }
 
+struct dpif_hw_netlink_flow_dump {
+struct dpif_flow_dump up;
+struct dpif_flow_dump *netlink_dump;
+struct nl_dump *flow_dumps;
+int num_dumps;
+int given;
+struct ovs_mutex lock;
+odp_port_t ports[10];
+struct netdev *netdevs[10];
+};
+
+static struct dpif_hw_netlink_flow_dump *
+dpif_hw_netlink_flow_dump_cast(struct dpif_flow_dump *dump)
+{
+return CONTAINER_OF(dump, struct dpif_hw_netlink_flow_dump, up);
+}
+
 static struct dpif_flow_dump *
 dpif_hw_netlink_flow_dump_create(const struct dpif *dpif_, bool terse)
 {
-struct dpif_flow_dump *dump;
+struct dpif_hw_netlink_flow_dump *dump;
 struct dpif_hw_netlink *dpif = dpif_hw_netlink_cast(dpif_);
+struct nl_dump *flow_dumps = 0;
+int count = 0;
 
-dump =
-dpif->lp_dpif_netlink->dpif_class->
-flow_dump_create(dpif->lp_dpif_netlink, terse);
-dump->dpif = CONST_CAST(struct dpif *, dpif_);
+int num_ports = hmap_count(>port_to_netdev);
+
+dump = xmalloc(sizeof *dump);
+dpif_flow_dump_init(>up, dpif_);
+dump->up.terse = terse;
 
-return dump;
+if (num_ports) {
+flow_dumps = xmalloc(sizeof (struct nl_dump) * num_ports);
 
+struct port_netdev_hash_data *data;
+
+HMAP_FOR_EACH(data, node, >port_to_netdev) {
+if (data->netdev) {
+dump->ports[count] = data->port;
+dump->netdevs[count] = data->netdev;
+
+tc_dump_flower_start(netdev_get_ifindex(data->netdev),
+ _dumps[count]);
+count++;
+}
+}
+}
+
+dump->netlink_dump =
+dpif->lp_dpif_netlink->dpif_class->
+flow_dump_create(dpif->lp_dpif_netlink, terse);
+dump->flow_dumps = flow_dumps;
+dump->num_dumps = count;
+dump->given = 0;
+ovs_mutex_init(>lock);
+return >up;
 }
 
 static int
 dpif_hw_netlink_flow_dump_destroy(struct dpif_flow_dump *dump_)
 {
+int error;
+struct dpif_hw_netlink_flow_dump *dump =
+dpif_hw_netlink_flow_dump_cast(dump_);
 struct dpif_hw_netlink *dpif = dpif_hw_netlink_cast(dump_->dpif);
 
-dump_->dpif = dpif->lp_dpif_netlink;
-return dpif->lp_dpif_netlink->dpif_class->flow_dump_destroy(dump_);
+int cur = 0;
+
+for (cur = 0; cur < dump->num_dumps; cur++) {
+struct nl_dump *nl_dump = >flow_dumps[cur];
+
+int ret = nl_dump_done(nl_dump);
+
+if (ret != 0)
+VLOG_ERR("nl_dump_done error  ret[%d]: %d\n", cur, ret);
+}
+
+error =
+dpif->lp_dpif_netlink->dpif_class->
+flow_dump_destroy(dump->netlink_dump);
+
+if (dump->flow_dumps)
+free(dump->flow_dumps);
+free(dump);
+
+return error;
+}
+
+struct dpif_hw_netlink_flow_dump_thread {
+struct dpif_flow_dump_thread up;
+struct dpif_flow_dump_thread *netlink_thread;
+struct dpif_hw_netlink_flow_dump *dump;
+struct ofpbuf nl_flows;
+struct ofpbuf temp_buf;
+int current_dump;
+int flower_done;
+};
+
+static void
+dpif_hw_netlink_get_next_dump(struct dpif_hw_netlink_flow_dump_thread *thread)
+{
+/* TODO:Consider changing to a atomc dump->given... */
+
+struct dpif_hw_netlink_flow_dump *dump = thread->dump;
+
+ovs_mutex_lock(>lock);
+/* if we haven't finished (dumped everything) */
+if (dump->given < dump->num_dumps) {
+/* if we are the first to find that given dump is finished (for race
+ * condition, e.g 3 finish dump 0 at the same time) */
+if (thread->current_dump == dump->given) {
+thread->current_dump = ++dump->given;
+/* did we just finish the last dump? done. */
+if (dump->given == dump->num_dumps) {
+thread->flower_done = 1;
+}
+   

[ovs-dev] [PATCH ovs RFC 7/9] dpif-hw-netlink: operate implementation

[Paul Blakey]

added flow offload with tc, supporting
flow get, flow put, and flow del.

Signed-off-by: Paul Blakey 
Signed-off-by: Shahar Klein 
---
 lib/dpif-hw-netlink.c | 687 +-
 1 file changed, 682 insertions(+), 5 deletions(-)

diff --git a/lib/dpif-hw-netlink.c b/lib/dpif-hw-netlink.c
index 885827a..9473832 100644
--- a/lib/dpif-hw-netlink.c
+++ b/lib/dpif-hw-netlink.c
@@ -47,6 +47,74 @@
 
 VLOG_DEFINE_THIS_MODULE(dpif_hw_netlink);
 
+extern bool SKIP_HW;
+
+static inline void *
+nla_data(const struct nlattr *nla)
+{
+return (char *) nla + NLA_HDRLEN;
+}
+
+static char *
+attrname(int type)
+{
+static char unkowntype[64];
+
+switch (type) {
+case OVS_KEY_ATTR_PRIORITY:
+return "OVS_KEY_ATTR_PRIORITY";
+case OVS_KEY_ATTR_CT_LABELS:
+return "OVS_KEY_ATTR_CT_LABELS";
+case OVS_KEY_ATTR_IN_PORT:
+return "OVS_KEY_ATTR_IN_PORT";
+case OVS_KEY_ATTR_ETHERNET:
+return "OVS_KEY_ATTR_ETHERNET";
+case OVS_KEY_ATTR_VLAN:
+return "OVS_KEY_ATTR_VLAN";
+case OVS_KEY_ATTR_ETHERTYPE:
+return "OVS_KEY_ATTR_ETHERTYPE";
+case OVS_KEY_ATTR_IPV4:
+return "OVS_KEY_ATTR_IPV4";
+case OVS_KEY_ATTR_IPV6:
+return "OVS_KEY_ATTR_IPV6";
+case OVS_KEY_ATTR_TCP:
+return "OVS_KEY_ATTR_TCP";
+case OVS_KEY_ATTR_UDP:
+return "OVS_KEY_ATTR_UDP";
+case OVS_KEY_ATTR_ICMP:
+return "OVS_KEY_ATTR_ICMP";
+case OVS_KEY_ATTR_ICMPV6:
+return "OVS_KEY_ATTR_ICMPV6";
+case OVS_KEY_ATTR_ARP:
+return "OVS_KEY_ATTR_ARP";
+case OVS_KEY_ATTR_ND:
+return "OVS_KEY_ATTR_ND";
+case OVS_KEY_ATTR_SKB_MARK:
+return "OVS_KEY_ATTR_SKB_MARK";
+case OVS_KEY_ATTR_TUNNEL:
+return "OVS_KEY_ATTR_TUNNEL";
+case OVS_KEY_ATTR_SCTP:
+return "OVS_KEY_ATTR_SCTP";
+case OVS_KEY_ATTR_TCP_FLAGS:
+return "OVS_KEY_ATTR_TCP_FLAGS";
+case OVS_KEY_ATTR_DP_HASH:
+return "OVS_KEY_ATTR_DP_HASH";
+case OVS_KEY_ATTR_RECIRC_ID:
+return "OVS_KEY_ATTR_RECIRC_ID";
+case OVS_KEY_ATTR_MPLS:
+return "OVS_KEY_ATTR_MPLS";
+case OVS_KEY_ATTR_CT_STATE:
+return "OVS_KEY_ATTR_CT_STATE";
+case OVS_KEY_ATTR_CT_ZONE:
+return "OVS_KEY_ATTR_CT_ZONE";
+case OVS_KEY_ATTR_CT_MARK:
+return "OVS_KEY_ATTR_CT_MARK";
+default:
+sprintf(unkowntype, "unkown_type(%d)\n", type);
+return unkowntype;
+}
+}
+
 static char *
 printufid(const ovs_u128 * ovs_ufid)
 {
@@ -426,7 +494,7 @@ dpif_hw_tc_flow_to_dpif_flow(struct dpif_hw_netlink *dpif,
sizeof (*ipv4_mask));
 
 memset(_mask->ipv4_proto, 0xFF, sizeof (ipv4_mask->ipv4_proto));
-ipv4->ipv4_proto = tc_flow->ip_proto;   
+ipv4->ipv4_proto = tc_flow->ip_proto;
 ipv4_mask->ipv4_frag = UINT8_MAX;
 
 if (tc_flow->ip_type == 4) {
@@ -441,7 +509,7 @@ dpif_hw_tc_flow_to_dpif_flow(struct dpif_hw_netlink *dpif,
 }
 
 if (tc_flow->ip_proto == IPPROTO_ICMP) {
-/* putting a masked out icmp  */
+/* putting a masked out icmp */
 struct ovs_key_icmp *icmp =
 nl_msg_put_unspec_uninit(outflow, OVS_KEY_ATTR_ICMP,
  sizeof (*icmp));
@@ -490,7 +558,7 @@ dpif_hw_tc_flow_to_dpif_flow(struct dpif_hw_netlink *dpif,
 size_t actions_offset =
 nl_msg_start_nested(outflow, OVS_FLOW_ATTR_ACTIONS);
 if (tc_flow->ifindex_out) {
-/* TODO:  make this faster */
+/* TODO: make this faster */
 int ovsport = get_ovs_port(dpif, tc_flow->ifindex_out);
 
 nl_msg_put_u32(outflow, OVS_ACTION_ATTR_OUTPUT, ovsport);
@@ -843,13 +911,622 @@ dpif_hw_netlink_flow_dump_next(struct 
dpif_flow_dump_thread *thread_,
  max_flows);
 }
 
+static bool
+odp_mask_attr_is_wildcard(const struct nlattr *ma)
+{
+return is_all_zeros(nl_attr_get(ma), nl_attr_get_size(ma));
+}
+
+static bool
+odp_mask_is_exact(enum ovs_key_attr attr, const void *mask, size_t size)
+{
+if (attr == OVS_KEY_ATTR_TCP_FLAGS) {
+return TCP_FLAGS(*(ovs_be16 *) mask) == TCP_FLAGS(OVS_BE16_MAX);
+}
+if (attr == OVS_KEY_ATTR_IPV6) {
+const struct ovs_key_ipv6 *ipv6_mask = mask;
+
+return ((ipv6_mask->ipv6_label & htonl(IPV6_LABEL_MASK))
+== htonl(IPV6_LABEL_MASK))
+&& ipv6_mask->ipv6_proto == UINT8_MAX
+&& ipv6_mask->ipv6_tclass == UINT8_MAX
+&& ipv6_mask->ipv6_hlimit == UINT8_MAX
+&& ipv6_mask->ipv6_frag == UINT8_MAX
+&& ipv6_mask_is_exact((const struct in6_addr *)
+  ipv6_mask->ipv6_src)
+&& ipv6_mask_is_exact((const struct in6_addr *)
+  ipv6_mask->ipv6_dst);
+}
+if (attr == 

[ovs-dev] [PATCH ovs RFC 2/9] dpif-hw-netlink: Add tc interface

[Paul Blakey]

Add tc interface in order to send/recv data from/to the HW.
The kerenl side of tc will pass the tc messages to the driver and back.

Signed-off-by: Shahar Klein 
Signed-off-by: Paul Blakey 
---
 lib/automake.mk |   2 +
 lib/tc.c| 796 
 lib/tc.h| 102 
 3 files changed, 900 insertions(+)
 create mode 100644 lib/tc.c
 create mode 100644 lib/tc.h

diff --git a/lib/automake.mk b/lib/automake.mk
index 5c517b7..c7c828d 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -341,6 +341,8 @@ if LINUX
 lib_libopenvswitch_la_SOURCES += \
lib/dpif-netlink.c \
lib/dpif-netlink.h \
+   lib/tc.h \
+   lib/tc.c \
lib/dpif-hw-netlink.c \
lib/dpif-hw-netlink.h \
lib/if-notifier.c \
diff --git a/lib/tc.c b/lib/tc.c
new file mode 100644
index 000..2c6534a
--- /dev/null
+++ b/lib/tc.c
@@ -0,0 +1,796 @@
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "timeval.h"
+#include "netlink-socket.h"
+#include "netlink.h"
+#include "ofpbuf.h"
+#include "rtnetlink.h"
+#include "openvswitch/vlog.h"
+#include "tc.h"
+
+bool SKIP_HW = false;
+
+VLOG_DEFINE_THIS_MODULE(tc);
+
+/* Returns tc handle 'major':'minor'. */
+static unsigned int
+tc_make_handle(unsigned int major, unsigned int minor)
+{
+return TC_H_MAKE(major << 16, minor);
+}
+
+static struct tcmsg *
+hw_tc_make_request(int ifindex, int type, unsigned int flags,
+   struct ofpbuf *request)
+{
+struct tcmsg *tcmsg;
+
+ofpbuf_init(request, 512);
+
+struct nlmsghdr *nlmsghdr;
+
+ovs_assert(request->size == 0);
+
+nl_msg_reserve(request, NLMSG_HDRLEN + sizeof *tcmsg);
+nlmsghdr = nl_msg_put_uninit(request, NLMSG_HDRLEN);
+nlmsghdr->nlmsg_len = 0;
+nlmsghdr->nlmsg_type = type;
+nlmsghdr->nlmsg_flags = NLM_F_REQUEST | flags;
+nlmsghdr->nlmsg_seq = 0;
+nlmsghdr->nlmsg_pid = 0;
+
+tcmsg = ofpbuf_put_zeros(request, sizeof *tcmsg);
+tcmsg->tcm_family = AF_UNSPEC;
+tcmsg->tcm_ifindex = ifindex;
+/* Caller should fill in tcmsg->tcm_handle. */
+/* Caller should fill in tcmsg->tcm_parent. */
+
+return tcmsg;
+}
+
+static int
+tc_transact(struct ofpbuf *request, struct ofpbuf **replyp)
+{
+int error = nl_transact(NETLINK_ROUTE, request, replyp);
+
+ofpbuf_uninit(request);
+return error;
+}
+
+int
+parse_tc_flow(struct ofpbuf *reply, struct tc_flow *tc_flow)
+{
+struct tcmsg *tc;
+struct ofpbuf mask_d, *mask = _d;
+
+memset(tc_flow, 0, sizeof (*tc_flow));
+ofpbuf_init(mask, 512);
+if (NLMSG_HDRLEN + (sizeof *tc) > reply->size) {
+VLOG_ERR
+("parse error, offfset + size <= b->size @%d + %lu <= 
%d\n",
+ NLMSG_HDRLEN, sizeof *tc, reply->size);
+return -1;
+}
+
+tc = ofpbuf_at_assert(reply, NLMSG_HDRLEN, sizeof *tc);
+tc_flow->handle = tc->tcm_handle;
+tc_flow->eth_type = TC_H_MIN(tc->tcm_info);
+VLOG_DBG("SUCCESS, handle: 0x%x, %d, eth_type: 0x%x\n", tc->tcm_handle,
+ tc->tcm_handle, ntohs(tc_flow->eth_type));
+if (!tc_flow->handle)
+return EAGAIN;
+
+static const struct nl_policy tca_policy[] = {
+[TCA_KIND] = {.type = NL_A_STRING,.optional = false},
+[TCA_OPTIONS] = {.type = NL_A_NESTED,.optional = true},
+[TCA_STATS] = {.type = NL_A_UNSPEC,.min_len =
+   sizeof (struct tc_stats),.optional = true},
+[TCA_STATS2] = {.type = NL_A_NESTED,.optional = true},
+};
+struct nlattr *ta[ARRAY_SIZE(tca_policy)];
+
+if (!nl_policy_parse(reply, NLMSG_HDRLEN + sizeof (struct tcmsg),
+ tca_policy, ta, ARRAY_SIZE(ta))) {
+VLOG_ERR("failed to parse tca policy");
+return EPROTO;
+}
+if (!ta[TCA_OPTIONS]) {
+VLOG_ERR("TCA_OPTIONS IS MISSING!\n");
+return EPROTO;
+}
+
+const char *kind = nl_attr_get_string(ta[TCA_KIND]);
+
+if (strcmp(kind, "flower")) {
+VLOG_ERR("error, TCA_KIND not flower!\n");
+return EPROTO;
+}
+
+struct nlattr *nl_options = ta[TCA_OPTIONS];
+
+static const struct nl_policy tca_flower_policy[TCA_FLOWER_MAX + 1] = {
+[TCA_FLOWER_CLASSID] = {.type = NL_A_U32,.optional = true},
+[TCA_FLOWER_INDEV] = {.type = NL_A_STRING,.max_len =
+  IFNAMSIZ,.optional = true},
+
+[TCA_FLOWER_KEY_ETH_DST] = {.type = NL_A_UNSPEC,.min_len =
+ETH_ALEN,.optional = true},
+[TCA_FLOWER_KEY_ETH_DST_MASK] = {.type = NL_A_UNSPEC,.min_len =
+ ETH_ALEN,.optional = true},
+[TCA_FLOWER_KEY_ETH_SRC] = {.type = NL_A_UNSPEC,.min_len =
+ETH_ALEN,.optional = true},
+[TCA_FLOWER_KEY_ETH_SRC_MASK] = {.type = NL_A_UNSPEC,.min_len =
+

[ovs-dev] [PATCH ovs RFC 0/9] Introducing HW offload support for openvswitch

[Paul Blakey]

Openvswitch currently configures the kerenel datapath via netlink over an 
internal ovs protocol.

This patch series offers a new provider: dpif-netlink-tc that uses the tc 
flower protocol 
to offload ovs rules into HW data-path through netdevices that e.g represent 
NIC e-switch ports.

The user can create a bridge with type: datapath_type=dpif-hw-netlink in order 
to use this provider. 
This provider can be used to pass the tc flower rules to the HW for HW offloads.

Also introducing in this patch series a policy module in which the user can 
program a HW-offload 
policy. The policy module accept a ovs flow and returns a policy decision for 
each 
flow:NO_OFFLOAD or HW_ONLY -- currently the policy is to HW offload all rules. 

If the HW_OFFLOAD rule assignment fails the provider will fallback to the 
system datapath.

Flower was chosen b/c its sort of natural to state OVS DP rules for this 
classifier. However,
the code can be extended to support other classifiers such as U32, eBPF, etc 
which have
HW offloads as well.

The use-case we are currently addressing is the newly introduced SRIOV 
switchdev mode in the
Linux kernel which is introduced in version 4.8 [1][2]. This series was tested 
against SRIOV VFs
vports representors of the Mellanox 100G ConnectX-4 series exposed by the mlx5 
kernel driver.

Paul and Shahar.

[1] 
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=513334e18a74f70c0be58c2eb73af1715325b870
[2] 
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=53d94892e27409bb2b48140207c0273b2ba65f61

Paul Blakey (9):
  dpif-hw-netlink: New dpif provider
  dpif-hw-netlink: Add tc interface
  dpif-hw-netlink: Added new maps
  dpif-hw-netlink: added new user offload policy
  dpif-hw-netlink: converting a tc flow back to ovs flow
  dpif-hw-netlink: using port maps on init and changes
  dpif-hw-netlink: operate implementation
  dpif-hw-netlink: support for flow dump from tc
  netdev-linux: add tc ingress qdisc support

 lib/automake.mk |6 +
 lib/dpif-hw-netlink.c   | 1894 +++
 lib/dpif-hw-netlink.h   |   41 +
 lib/dpif-provider.h |1 +
 lib/dpif.c  |1 +
 lib/hw-offload-policy.c |   23 +
 lib/hw-offload-policy.h |   20 +
 lib/netdev-linux.c  |   72 ++
 lib/tc.c|  796 
 lib/tc.h|  102 +++
 10 files changed, 2956 insertions(+)
 create mode 100644 lib/dpif-hw-netlink.c
 create mode 100644 lib/dpif-hw-netlink.h
 create mode 100644 lib/hw-offload-policy.c
 create mode 100644 lib/hw-offload-policy.h
 create mode 100644 lib/tc.c
 create mode 100644 lib/tc.h

-- 
1.8.3.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH ovs RFC 3/9] dpif-hw-netlink: Added new maps

[Paul Blakey]

A flow in ovs can be accesses by ufid, and in tc by flow handle +
priority.
We use the protocol number as the priority so we save a map that
maps from ovs flow id to/from tc flow handle + protocol.
Also added a map to map ovs in_port to/from netdevice.

Signed-off-by: Paul Blakey 
Signed-off-by: Shahar Klein 
---
 lib/dpif-hw-netlink.c | 291 ++
 lib/dpif-hw-netlink.h |   4 +
 2 files changed, 295 insertions(+)

diff --git a/lib/dpif-hw-netlink.c b/lib/dpif-hw-netlink.c
index 5281de7..7394580 100644
--- a/lib/dpif-hw-netlink.c
+++ b/lib/dpif-hw-netlink.c
@@ -40,10 +40,289 @@
 #include "unaligned.h"
 #include "util.h"
 #include "openvswitch/vlog.h"
+#include "netdev-provider.h"
 #include "dpif-hw-netlink.h"
 
 VLOG_DEFINE_THIS_MODULE(dpif_hw_netlink);
 
+static char *
+printufid(const ovs_u128 * ovs_ufid)
+{
+static char ufid[64];
+
+if (ovs_ufid)
+sprintf(ufid, "%x%x%x%x", ovs_ufid->u32[0], ovs_ufid->u32[1],
+ovs_ufid->u32[2], ovs_ufid->u32[3]);
+else
+sprintf(ufid, "(missing_ufid)");
+return ufid;
+}
+
+static inline size_t
+hash_ufid(const ovs_u128 * ovs_ufid)
+{
+return hash_words64((const uint64_t *) ovs_ufid,
+sizeof *ovs_ufid / sizeof (uint64_t), 0);
+}
+
+static inline size_t
+hash_port(odp_port_t port)
+{
+return hash_int((int) port, 0);
+}
+
+static inline size_t
+hash_handle_proto_port(int handle, int protocol, odp_port_t port)
+{
+return hash_int(protocol, hash_int(handle, hash_port(port)));
+}
+
+static struct netdev *
+port_find(struct dpif_hw_netlink *dpif, odp_port_t port)
+{
+struct port_netdev_hash_data *data;
+size_t hash = hash_port(port);
+struct netdev *res = 0;
+
+ovs_mutex_lock(>hash_mutex);
+HMAP_FOR_EACH_WITH_HASH(data, node, hash, >port_to_netdev) {
+if (data->port == port)
+break;
+}
+if (data) {
+res = data->netdev;
+VLOG_DBG
+("found port mapping: port number %d -> port name %s (pointer: 
%p)\n",
+ port, res->name, res);
+}
+ovs_mutex_unlock(>hash_mutex);
+
+return res;
+}
+
+static int
+port_del_name(struct dpif_hw_netlink *dpif, char *name)
+{
+struct port_netdev_hash_data *data;
+
+ovs_mutex_lock(>hash_mutex);
+HMAP_FOR_EACH(data, node, >port_to_netdev) {
+if (!strcmp(data->netdev->name, name))
+break;
+}
+if (data)
+hmap_remove(>port_to_netdev, >node);
+ovs_mutex_unlock(>hash_mutex);
+
+free(data);
+return data ? 1 : 0;
+}
+
+static int
+port_del(struct dpif_hw_netlink *dpif, odp_port_t port)
+{
+struct port_netdev_hash_data *data;
+size_t hash = hash_port(port);
+
+ovs_mutex_lock(>hash_mutex);
+HMAP_FOR_EACH_WITH_HASH(data, node, hash, >port_to_netdev) {
+if (data->port == port)
+break;
+}
+if (data)
+hmap_remove(>port_to_netdev, >node);
+ovs_mutex_unlock(>hash_mutex);
+
+free(data);
+return data ? 1 : 0;
+}
+
+static int
+port_add(struct dpif_hw_netlink *dpif, odp_port_t port, struct netdev *netdev)
+{
+struct port_netdev_hash_data *data;
+size_t hash = hash_port(port);
+int ret = 0;
+
+if (!netdev || !netdev->name || !port)
+return -1;
+
+if (netdev->netdev_class == _internal_class) {
+if (!strcmp(netdev->name, "skip_hw")) {
+tc_set_skip_hw(true);
+}
+return -1;
+}
+if (port_del(dpif, port) || port_del_name(dpif, netdev->name)) {
+VLOG_DBG
+("%s %d %s (%p)  port number %d name: %s, deleted to be 
replaced\n",
+ __FILE__, __LINE__, __func__, dpif, port, netdev->name);
+ret = 1;
+}
+
+data = malloc(sizeof (struct port_netdev_hash_data));
+data->netdev = netdev;
+data->port = port;
+
+VLOG_DBG
+("%s %d %s (%p): adding new port mapping: %d -> netdev %p name: %s, 
type: %s, ifindex: %d, hash: %lu\n",
+ __FILE__, __LINE__, __func__, dpif, port, netdev, netdev->name,
+ netdev->netdev_class->type, netdev_get_ifindex(netdev), hash);
+ovs_mutex_lock(>hash_mutex);
+hmap_insert(>port_to_netdev, >node, hash);
+ovs_mutex_unlock(>hash_mutex);
+return ret;
+}
+
+static int
+delhandle(struct dpif_hw_netlink *dpif, const ovs_u128 * ovs_ufid)
+{
+struct ufid_handle_hash_data *data;
+size_t hash;
+
+if (!ovs_ufid) {
+VLOG_ERR("%s %d %s (%p) can't delete missing ufid\n", __FILE__,
+ __LINE__, __func__, dpif);
+return 0;
+}
+hash = hash_ufid(ovs_ufid);
+
+VLOG_DBG("%s %d %s (%p): removing %s\n", __FILE__, __LINE__, __func__,
+ dpif, printufid(ovs_ufid));
+
+ovs_mutex_lock(>hash_mutex);
+HMAP_FOR_EACH_WITH_HASH(data, node_ufid, hash, >ufid_to_handle) {
+if (!memcmp(>ovs_ufid, ovs_ufid, sizeof (*ovs_ufid)))
+break;
+}
+if (data) {
+  

[ovs-dev] [PATCH ovs RFC 5/9] dpif-hw-netlink: converting a tc flow back to ovs flow

[Paul Blakey]

new function that converts a tc flow back to dpif-flow.

Signed-off-by: Paul Blakey 
Signed-off-by: Shahar Klein 
---
 lib/dpif-hw-netlink.c | 169 ++
 1 file changed, 169 insertions(+)

diff --git a/lib/dpif-hw-netlink.c b/lib/dpif-hw-netlink.c
index e14c64c..92ac6cb 100644
--- a/lib/dpif-hw-netlink.c
+++ b/lib/dpif-hw-netlink.c
@@ -381,6 +381,175 @@ get_policy(struct dpif_hw_netlink *dpif, const ovs_u128 * 
ovs_ufid)
 return data->offloading_policy;
 }
 
+static int
+dpif_hw_tc_flow_to_dpif_flow(struct dpif_hw_netlink *dpif,
+ struct tc_flow *tc_flow,
+ struct dpif_flow *dpif_flow, odp_port_t inport,
+ struct ofpbuf *outflow, struct netdev *indev)
+{
+struct ofpbuf mask_d, *mask = _d;
+
+ofpbuf_init(mask, 512);
+
+dpif_flow->pmd_id = PMD_ID_NULL;
+
+size_t key_offset = nl_msg_start_nested(outflow, OVS_FLOW_ATTR_KEY);
+size_t mask_offset = nl_msg_start_nested(mask, OVS_FLOW_ATTR_MASK);
+
+nl_msg_put_u32(outflow, OVS_KEY_ATTR_IN_PORT, inport);
+nl_msg_put_u32(mask, OVS_KEY_ATTR_IN_PORT, 0x);
+
+/* OVS_KEY_ATTR_ETHERNET */
+struct ovs_key_ethernet *eth_key =
+nl_msg_put_unspec_uninit(outflow, OVS_KEY_ATTR_ETHERNET,
+ sizeof (*eth_key));
+struct ovs_key_ethernet *eth_key_mask =
+nl_msg_put_unspec_uninit(mask, OVS_KEY_ATTR_ETHERNET,
+ sizeof (*eth_key_mask));
+
+memset(eth_key_mask, 0xFF, sizeof (*eth_key_mask));
+eth_key->eth_src = tc_flow->src_mac;
+eth_key->eth_dst = tc_flow->dst_mac;
+eth_key_mask->eth_src = tc_flow->src_mac_mask;
+eth_key_mask->eth_dst = tc_flow->dst_mac_mask;
+
+nl_msg_put_be16(outflow, OVS_KEY_ATTR_ETHERTYPE, tc_flow->eth_type);
+nl_msg_put_be16(mask, OVS_KEY_ATTR_ETHERTYPE, 0x);
+
+/* OVS_KEY_ATTR_IPV4 */
+if (tc_flow->ip_proto) {
+struct ovs_key_ipv4 *ipv4 =
+nl_msg_put_unspec_uninit(outflow, OVS_KEY_ATTR_IPV4,
+ sizeof (*ipv4));
+struct ovs_key_ipv4 *ipv4_mask =
+nl_msg_put_unspec_zero(mask, OVS_KEY_ATTR_IPV4,
+   sizeof (*ipv4_mask));
+
+memset(_mask->ipv4_proto, 0xFF, sizeof (ipv4_mask->ipv4_proto));
+ipv4->ipv4_proto = tc_flow->ip_proto;   
+ipv4_mask->ipv4_frag = UINT8_MAX;
+
+if (tc_flow->ip_type == 4) {
+if (tc_flow->ipv4.ipv4_src)
+ipv4->ipv4_src = tc_flow->ipv4.ipv4_src;
+if (tc_flow->ipv4.ipv4_src_mask)
+ipv4_mask->ipv4_src = tc_flow->ipv4.ipv4_src_mask;
+if (tc_flow->ipv4.ipv4_dst)
+ipv4->ipv4_dst = tc_flow->ipv4.ipv4_dst;
+if (tc_flow->ipv4.ipv4_dst_mask)
+ipv4_mask->ipv4_dst = tc_flow->ipv4.ipv4_dst_mask;
+}
+
+if (tc_flow->ip_proto == IPPROTO_ICMP) {
+/* putting a masked out icmp  */
+struct ovs_key_icmp *icmp =
+nl_msg_put_unspec_uninit(outflow, OVS_KEY_ATTR_ICMP,
+ sizeof (*icmp));
+struct ovs_key_icmp *icmp_mask =
+nl_msg_put_unspec_uninit(mask, OVS_KEY_ATTR_ICMP,
+ sizeof (*icmp_mask));
+
+icmp->icmp_type = 0;
+icmp->icmp_code = 0;
+memset(icmp_mask, 0, sizeof (*icmp_mask));
+}
+if (tc_flow->ip_proto == IPPROTO_TCP) {
+struct ovs_key_tcp *tcp =
+nl_msg_put_unspec_uninit(outflow, OVS_KEY_ATTR_TCP,
+ sizeof (*tcp));
+struct ovs_key_tcp *tcp_mask =
+nl_msg_put_unspec_uninit(mask, OVS_KEY_ATTR_TCP,
+ sizeof (*tcp_mask));
+
+memset(tcp_mask, 0x00, sizeof (*tcp_mask));
+
+tcp->tcp_src = tc_flow->src_port;
+tcp_mask->tcp_src = tc_flow->src_port_mask;
+tcp->tcp_dst = tc_flow->dst_port;
+tcp_mask->tcp_dst = tc_flow->dst_port_mask;
+}
+if (tc_flow->ip_proto == IPPROTO_UDP) {
+struct ovs_key_udp *udp =
+nl_msg_put_unspec_uninit(outflow, OVS_KEY_ATTR_UDP,
+ sizeof (*udp));
+struct ovs_key_udp *udp_mask =
+nl_msg_put_unspec_uninit(mask, OVS_KEY_ATTR_UDP,
+ sizeof (*udp_mask));
+
+memset(udp_mask, 0xFF, sizeof (*udp_mask));
+
+udp->udp_src = tc_flow->src_port;
+udp_mask->udp_src = tc_flow->src_port_mask;
+udp->udp_dst = tc_flow->dst_port;
+udp_mask->udp_dst = tc_flow->dst_port_mask;
+}
+}
+nl_msg_end_nested(outflow, key_offset);
+nl_msg_end_nested(mask, 

[ovs-dev] [PATCH ovs RFC 1/9] dpif-hw-netlink: New dpif provider

[Paul Blakey]

Add infrastructure for a new provider that will be able
to send some flows to the HW for offloading.

Signed-off-by: Shahar Klein 
Signed-off-by: Paul Blakey 
---
 lib/automake.mk   |   2 +
 lib/dpif-hw-netlink.c | 463 ++
 lib/dpif-hw-netlink.h |  31 
 lib/dpif-provider.h   |   1 +
 lib/dpif.c|   1 +
 5 files changed, 498 insertions(+)
 create mode 100644 lib/dpif-hw-netlink.c
 create mode 100644 lib/dpif-hw-netlink.h

diff --git a/lib/automake.mk b/lib/automake.mk
index 5387d51..5c517b7 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -341,6 +341,8 @@ if LINUX
 lib_libopenvswitch_la_SOURCES += \
lib/dpif-netlink.c \
lib/dpif-netlink.h \
+   lib/dpif-hw-netlink.c \
+   lib/dpif-hw-netlink.h \
lib/if-notifier.c \
lib/if-notifier.h \
lib/netdev-linux.c \
diff --git a/lib/dpif-hw-netlink.c b/lib/dpif-hw-netlink.c
new file mode 100644
index 000..5281de7
--- /dev/null
+++ b/lib/dpif-hw-netlink.c
@@ -0,0 +1,463 @@
+
+#include 
+
+#include "dpif-netlink.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "bitmap.h"
+#include "dpif-provider.h"
+#include "dynamic-string.h"
+#include "flow.h"
+#include "fat-rwlock.h"
+#include "netdev.h"
+#include "netdev-linux.h"
+#include "netdev-vport.h"
+#include "netlink-conntrack.h"
+#include "netlink-notifier.h"
+#include "netlink-socket.h"
+#include "netlink.h"
+#include "odp-util.h"
+#include "ofpbuf.h"
+#include "packets.h"
+#include "poll-loop.h"
+#include "random.h"
+#include "shash.h"
+#include "sset.h"
+#include "timeval.h"
+#include "unaligned.h"
+#include "util.h"
+#include "openvswitch/vlog.h"
+#include "dpif-hw-netlink.h"
+
+VLOG_DEFINE_THIS_MODULE(dpif_hw_netlink);
+
+static struct dpif_hw_netlink *
+dpif_hw_netlink_cast(const struct dpif *dpif)
+{
+dpif_assert_class(dpif, _hw_netlink_class);
+return CONTAINER_OF(dpif, struct dpif_hw_netlink, dpif);
+}
+
+static int
+dpif_hw_netlink_open(const struct dpif_class *class OVS_UNUSED,
+ const char *name, bool create, struct dpif **dpifp)
+{
+struct dpif_hw_netlink *dpif;
+struct dpif *lp_dpif_netlink;
+
+if (dpif_create_and_open(name, "system", _dpif_netlink)) {
+VLOG_WARN("ERROR! %d\n", __LINE__);
+}
+
+dpif = xzalloc(sizeof *dpif);
+
+*CONST_CAST(const char **, >name) = xstrdup(name);
+uint16_t netflow_id = hash_string(dpif->name, 0);
+
+dpif->lp_dpif_netlink = lp_dpif_netlink;
+
+dpif_init(>dpif, _hw_netlink_class, dpif->name, netflow_id >> 8,
+  netflow_id);
+
+*dpifp = >dpif;
+
+return 0;
+}
+
+static void
+dpif_hw_netlink_close(struct dpif *dpif_)
+{
+struct dpif_hw_netlink *dpif = dpif_hw_netlink_cast(dpif_);
+
+return dpif->lp_dpif_netlink->dpif_class->close(dpif->lp_dpif_netlink);
+}
+
+static int
+dpif_hw_netlink_destroy(struct dpif *dpif_)
+{
+struct dpif_hw_netlink *dpif = dpif_hw_netlink_cast(dpif_);
+
+return dpif->lp_dpif_netlink->dpif_class->destroy(dpif->lp_dpif_netlink);
+}
+
+static bool
+dpif_hw_netlink_run(struct dpif *dpif_)
+{
+struct dpif_hw_netlink *dpif = dpif_hw_netlink_cast(dpif_);
+
+return dpif->lp_dpif_netlink->dpif_class->run(dpif->lp_dpif_netlink);
+}
+
+static int
+dpif_hw_netlink_get_stats(const struct dpif *dpif_,
+  struct dpif_dp_stats *stats)
+{
+struct dpif_hw_netlink *dpif = dpif_hw_netlink_cast(dpif_);
+
+return dpif->lp_dpif_netlink->dpif_class->get_stats(dpif->lp_dpif_netlink,
+stats);
+}
+
+static int
+dpif_hw_netlink_port_add(struct dpif *dpif_, struct netdev *netdev,
+ odp_port_t * port_nop)
+{
+struct dpif_hw_netlink *dpif = dpif_hw_netlink_cast(dpif_);
+
+return dpif->lp_dpif_netlink->dpif_class->port_add(dpif->lp_dpif_netlink,
+   netdev, port_nop);
+}
+
+static int
+dpif_hw_netlink_port_del(struct dpif *dpif_, odp_port_t port_no)
+{
+struct dpif_hw_netlink *dpif = dpif_hw_netlink_cast(dpif_);
+
+return dpif->lp_dpif_netlink->dpif_class->port_del(dpif->lp_dpif_netlink,
+   port_no);
+}
+
+static int
+dpif_hw_netlink_port_query_by_number(const struct dpif *dpif_,
+ odp_port_t port_no,
+ struct dpif_port *dpif_port)
+{
+struct dpif_hw_netlink *dpif = dpif_hw_netlink_cast(dpif_);
+
+return dpif->lp_dpif_netlink->dpif_class->
+port_query_by_number(dpif->lp_dpif_netlink, port_no, dpif_port);
+}
+
+static int
+dpif_hw_netlink_port_query_by_name(const struct dpif *dpif_,
+   const char *devname,
+   struct dpif_port 

[ovs-dev] [PATCH ovs RFC 9/9] netdev-linux: add tc ingress qdisc support

[Paul Blakey]

Add tc ingress qdisc support so we can add qdisc
as a qos on port or through config.
usage:
ovs-vsctl -- set port  qos=@newq -- --id=@newq create \
qos type=linux-ingress
where  is a already added port using vsctl add-port.

Signed-off-by: Paul Blakey 
Signed-off-by: Shahar Klein 
---
 lib/netdev-linux.c | 72 ++
 1 file changed, 72 insertions(+)

diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c
index 8e5fa90..5109b8c 100644
--- a/lib/netdev-linux.c
+++ b/lib/netdev-linux.c
@@ -419,6 +419,7 @@ static const struct tc_ops tc_ops_codel;
 static const struct tc_ops tc_ops_fqcodel;
 static const struct tc_ops tc_ops_sfq;
 static const struct tc_ops tc_ops_default;
+static const struct tc_ops tc_ops_ingress;
 static const struct tc_ops tc_ops_other;
 
 static const struct tc_ops *const tcs[] = {
@@ -428,6 +429,7 @@ static const struct tc_ops *const tcs[] = {
 _ops_fqcodel,/* Fair queue controlled delay */
 _ops_sfq,/* Stochastic fair queueing */
 _ops_default,/* Default qdisc (see tc-pfifo_fast(8)). */
+_ops_ingress,/* Ingress. */
 _ops_other,  /* Some other qdisc. */
 NULL
 };
@@ -4570,6 +4572,76 @@ static const struct tc_ops tc_ops_hfsc = {
 hfsc_class_dump_stats   /* class_dump_stats */
 };
 
+/* ingress traffic control class. */
+
+struct ingress {
+struct tc tc;
+};
+
+static void
+ingress_install__(struct netdev *netdev_)
+{
+struct netdev_linux *netdev = netdev_linux_cast(netdev_);
+struct ingress *ingress;
+
+ingress = xmalloc(sizeof *ingress);
+tc_init(>tc, _ops_ingress);
+
+netdev->tc = >tc;
+}
+
+static void
+ingress_parse_qdisc_details__(struct netdev *netdev OVS_UNUSED,
+  const struct smap *details OVS_UNUSED, 
+  struct ingress *ingress OVS_UNUSED)
+{
+   /* parse details  */
+}
+
+static int
+ingress_tc_install(struct netdev *netdev, const struct smap *details 
OVS_UNUSED)
+{
+int error;
+struct ingress ingress;
+
+ingress_parse_qdisc_details__(netdev, details, );
+error = tc_add_del_ingress_qdisc(netdev, true);
+if (!error) {
+ingress_install__(netdev);
+}
+return error;
+}
+
+static int
+ingress_tc_load(struct netdev *netdev, struct ofpbuf *nlmsg OVS_UNUSED)
+{
+ingress_install__(netdev);
+return 0;
+}
+
+static void
+ingress_tc_destroy(struct tc *tc)
+{
+struct ingress *ingress = CONTAINER_OF(tc, struct ingress, tc);
+free(ingress);
+}
+
+static const struct tc_ops tc_ops_ingress = {
+"ingress",   /* linux_name */
+"linux-ingress", /* ovs_name */
+0,   /* n_queues */
+ingress_tc_install,
+ingress_tc_load,
+ingress_tc_destroy,
+NULL,
+NULL,
+NULL,
+NULL,
+NULL,
+NULL,
+NULL
+};
+
 /* "linux-default" traffic control class.
  *
  * This class represents the default, unnamed Linux qdisc.  It corresponds to
-- 
1.8.3.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH ovs RFC 6/9] dpif-hw-netlink: using port maps on init and changes

[Paul Blakey]

updating the port maps on dpif open (without create)
and in port_add/port_del.

Signed-off-by: Paul Blakey 
Signed-off-by: Shahar Klein 
---
 lib/dpif-hw-netlink.c | 68 +--
 1 file changed, 60 insertions(+), 8 deletions(-)

diff --git a/lib/dpif-hw-netlink.c b/lib/dpif-hw-netlink.c
index 92ac6cb..885827a 100644
--- a/lib/dpif-hw-netlink.c
+++ b/lib/dpif-hw-netlink.c
@@ -574,11 +574,22 @@ dpif_hw_netlink_open(const struct dpif_class *class 
OVS_UNUSED,
 {
 struct dpif_hw_netlink *dpif;
 struct dpif *lp_dpif_netlink;
-
-if (dpif_create_and_open(name, "system", _dpif_netlink)) {
-VLOG_WARN("ERROR! %d\n", __LINE__);
+struct netdev *netdev;
+struct dpif_port dpif_port;
+struct dpif_port_dump dump;
+int error = 0;
+
+VLOG_DBG("%s %d %s: parameters name %s, create: %s\n", __FILE__, __LINE__,
+ __func__, name, (create ? "yes" : "no"));
+if (create) {
+if ((error = dpif_create(name, "system", _dpif_netlink))) {
+return error;
+}
+} else {
+if ((error = dpif_open(name, "system", _dpif_netlink))) {
+return error;
+}
 }
-
 dpif = xzalloc(sizeof *dpif);
 
 initmaps(dpif);
@@ -593,6 +604,31 @@ dpif_hw_netlink_open(const struct dpif_class *class 
OVS_UNUSED,
 
 *dpifp = >dpif;
 
+if (!create) {
+VLOG_DBG
+("%s %d %s(%p) requesting existing port dump, from dpif-netlink 
only.\n",
+ __FILE__, __LINE__, __func__, dpif);
+DPIF_PORT_FOR_EACH(_port, , dpif->lp_dpif_netlink) {
+VLOG_DBG("%s %d %s(%p) port: %s, type: %s\n", __FILE__, __LINE__,
+ __func__, dpif, dpif_port.name, dpif_port.type);
+if (dpif_port.type && !strcmp(dpif_port.type, "internal")) {
+if (!strcmp(dpif_port.name, "skip_hw")) {
+tc_set_skip_hw(true);
+}
+continue;
+}
+if (!netdev_open(dpif_port.name, dpif_port.type, )) {
+VLOG_DBG
+("%s %d %s(%p) opened a new netdev: %s, type: %s, ifindex: 
%d\n",
+ __FILE__, __LINE__, __func__, dpif, netdev->name,
+ netdev->netdev_class->type, netdev_get_ifindex(netdev));
+port_add(dpif, dpif_port.port_no, netdev);
+}
+}
+}
+VLOG_DBG("%s %d %s(%p) port dump end.\n", __FILE__, __LINE__, __func__,
+ dpif);
+
 return 0;
 }
 
@@ -634,19 +670,35 @@ static int
 dpif_hw_netlink_port_add(struct dpif *dpif_, struct netdev *netdev,
  odp_port_t * port_nop)
 {
+int error;
 struct dpif_hw_netlink *dpif = dpif_hw_netlink_cast(dpif_);
 
-return dpif->lp_dpif_netlink->dpif_class->port_add(dpif->lp_dpif_netlink,
-   netdev, port_nop);
+VLOG_DBG("%s %d %s (%p): request to add  netdev: %s\n", __FILE__, __LINE__,
+ __func__, dpif, netdev->name);
+error =
+dpif->lp_dpif_netlink->dpif_class->port_add(dpif->lp_dpif_netlink,
+netdev, port_nop);
+if (!error)
+port_add(dpif, *port_nop, netdev);
+else
+VLOG_ERR("%s %d %s (%p): failed to add port\n", __FILE__, __LINE__,
+ __func__, dpif);
+
+return error;
 }
 
 static int
 dpif_hw_netlink_port_del(struct dpif *dpif_, odp_port_t port_no)
 {
+int error;
 struct dpif_hw_netlink *dpif = dpif_hw_netlink_cast(dpif_);
 
-return dpif->lp_dpif_netlink->dpif_class->port_del(dpif->lp_dpif_netlink,
-   port_no);
+error =
+dpif->lp_dpif_netlink->dpif_class->port_del(dpif->lp_dpif_netlink,
+port_no);
+if (!error)
+port_del(dpif, port_no);
+return error;
 }
 
 static int
-- 
1.8.3.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH ovs RFC 4/9] dpif-hw-netlink: added new user offload policy

[Paul Blakey]

Added a new framework so use can specify which flows
to try and offload.
A new map was added to save each flow's policy.

Signed-off-by: Paul Blakey 
Signed-off-by: Shahar Klein 
---
 lib/automake.mk |  2 ++
 lib/dpif-hw-netlink.c   | 59 +
 lib/dpif-hw-netlink.h   |  6 +
 lib/hw-offload-policy.c | 23 +++
 lib/hw-offload-policy.h | 20 +
 5 files changed, 110 insertions(+)
 create mode 100644 lib/hw-offload-policy.c
 create mode 100644 lib/hw-offload-policy.h

diff --git a/lib/automake.mk b/lib/automake.mk
index c7c828d..f87cc8c 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -343,6 +343,8 @@ lib_libopenvswitch_la_SOURCES += \
lib/dpif-netlink.h \
lib/tc.h \
lib/tc.c \
+   lib/hw-offload-policy.c \
+   lib/hw-offload-policy.h \
lib/dpif-hw-netlink.c \
lib/dpif-hw-netlink.h \
lib/if-notifier.c \
diff --git a/lib/dpif-hw-netlink.c b/lib/dpif-hw-netlink.c
index 7394580..e14c64c 100644
--- a/lib/dpif-hw-netlink.c
+++ b/lib/dpif-hw-netlink.c
@@ -42,6 +42,8 @@
 #include "openvswitch/vlog.h"
 #include "netdev-provider.h"
 #include "dpif-hw-netlink.h"
+#include "tc.h"
+#include "hw-offload-policy.h"
 
 VLOG_DEFINE_THIS_MODULE(dpif_hw_netlink);
 
@@ -323,6 +325,62 @@ get_ovs_port(struct dpif_hw_netlink *dpif, int ifindex)
 return -1;
 }
 
+static void
+del_policy(struct dpif_hw_netlink *dpif, const ovs_u128 * ovs_ufid)
+{
+struct ufid_policy_hash_data *data;
+
+if (!ovs_ufid) {
+return;
+}
+size_t hash = hash_ufid(ovs_ufid);
+
+/* WRITE LOCK */
+HMAP_FOR_EACH_WITH_HASH(data, node_ufid, hash, >ufid_to_policy) {
+if (memcmp(>ovs_ufid, ovs_ufid, sizeof (*ovs_ufid)) == 0)
+break;
+}
+if (data) {
+hmap_remove(>ufid_to_policy, >node_ufid);
+free(data);
+}
+/* WRITE UNLOACK */
+}
+
+static void
+put_policy(struct dpif_hw_netlink *dpif, const ovs_u128 * ovs_ufid,
+   enum dpif_hw_offload_policy policy)
+{
+struct ufid_policy_hash_data *data =
+malloc(sizeof (struct ufid_policy_hash_data));
+
+data->ovs_ufid = *ovs_ufid;
+data->offloading_policy = policy;
+
+del_policy(dpif, ovs_ufid);
+/* WRITE LOCK */
+hmap_insert(>ufid_to_policy, >node_ufid, hash_ufid(ovs_ufid));
+/* WRITE UNLOCK */
+return;
+
+}
+
+static enum dpif_hw_offload_policy
+get_policy(struct dpif_hw_netlink *dpif, const ovs_u128 * ovs_ufid)
+{
+struct ufid_policy_hash_data *data = NULL;
+size_t hash = hash_ufid(ovs_ufid);
+
+/* READ LOCK */
+HMAP_FOR_EACH_WITH_HASH(data, node_ufid, hash, >ufid_to_policy) {
+if (memcmp(>ovs_ufid, ovs_ufid, sizeof (*ovs_ufid)) == 0)
+break;
+}
+/* READ UNLOCK */
+
+return data->offloading_policy;
+}
+
 static struct dpif_hw_netlink *
 dpif_hw_netlink_cast(const struct dpif *dpif)
 {
@@ -336,6 +394,7 @@ initmaps(struct dpif_hw_netlink *dpif)
 hmap_init(>port_to_netdev);
 hmap_init(>ufid_to_handle);
 hmap_init(>handle_to_ufid);
+hmap_init(>ufid_to_policy);
 ovs_mutex_init(>hash_mutex);
 return 0;
 }
diff --git a/lib/dpif-hw-netlink.h b/lib/dpif-hw-netlink.h
index f44abca..e2cee90 100644
--- a/lib/dpif-hw-netlink.h
+++ b/lib/dpif-hw-netlink.h
@@ -14,6 +14,7 @@ struct dpif_hw_netlink {
 struct hmap port_to_netdev;
 struct hmap ufid_to_handle;
 struct hmap handle_to_ufid;
+struct hmap ufid_to_policy;
 };
 
 struct port_netdev_hash_data {
@@ -32,4 +33,9 @@ struct ufid_handle_hash_data {
 odp_port_t port;
 };
 
+struct ufid_policy_hash_data {
+struct hmap_node node_ufid;
+ovs_u128 ovs_ufid;
+int offloading_policy;
+};
 #endif
diff --git a/lib/hw-offload-policy.c b/lib/hw-offload-policy.c
new file mode 100644
index 000..366c237
--- /dev/null
+++ b/lib/hw-offload-policy.c
@@ -0,0 +1,23 @@
+#include 
+#include "dpif.h"
+#include "openvswitch/types.h"
+#include "hw-offload-policy.h"
+#include "dpif-hw-netlink.h"
+
+enum dpif_hw_offload_policy
+HW_offload_test_put(struct dpif_hw_netlink *dpif, struct dpif_flow_put *put)
+{
+return DPIF_HW_OFFLOAD_ONLY;
+}
+
+enum dpif_hw_offload_policy
+HW_offload_test_del(struct dpif *dpif, struct dpif_flow_del *del)
+{
+return DPIF_HW_OFFLOAD_ONLY;
+}
+
+enum dpif_hw_offload_policy
+HW_offload_test_get(struct dpif *dpif, struct dpif_flow_get *get)
+{
+return DPIF_HW_OFFLOAD_ONLY;
+}
diff --git a/lib/hw-offload-policy.h b/lib/hw-offload-policy.h
new file mode 100644
index 000..8371fc0
--- /dev/null
+++ b/lib/hw-offload-policy.h
@@ -0,0 +1,20 @@
+
+#ifndef HW_OFFLOAD_POLICY_H
+#define HW_OFFLOAD_POLICY_H 1
+
+#include "dpif-hw-netlink.h"
+
+enum dpif_hw_offload_policy {
+DPIF_HW_NO_OFFLAOAD = 1,/* no offload - SW only */
+DPIF_HW_OFFLOAD_ONLY,   /* if fails fall back to SW */
+DPIF_HW_OFFLOAD_SPLIT,
+};
+
+enum dpif_hw_offload_policy 

Re: [ovs-dev] OVS+DPDK: Requested device 0000:01:00.0 cannot be used

[Ilya Maximets]

> 3. IOMMU support
>  /sys/kernel/iommu_groups/12/devices/:01:00.0
> /sys/kernel/iommu_groups/12/devices/:01:00.1
> /sys/kernel/iommu_groups/9/devices/:06:00.0
> /sys/kernel/iommu_groups/9/devices/:06:00.1

It's all because ports of your NICs are in the same iommu groups.
You need to patch your kernel to fix this behaviour or get another kernel.
Also, you may try to use UIO driver instead.

Best regards, Ilya Maximets.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Any updates on the "userspace meter" patches ?

[Enas Ahmad]

Hi,
I know that meters are still not implemented in the OVS master branch.
However, I would like to enquiry about the "userspace meter" patches
submitted a while ago by Jarno Rajahalme, is there any updates on these
patches? has the implementation been extended to support "DSCP remark"
action ?

Thanks,
Enas

-- 

--
This message and its contents, including attachments are intended solely 
for the original recipient. If you are not the intended recipient or have 
received this message in error, please notify me immediately and delete 
this message from your computer system. Any unauthorized use or 
distribution is prohibited. Please consider the environment before printing 
this email.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] OVS+DPDK: Requested device 0000:01:00.0 cannot be used

[ychen]

hi, 
I follow the doc "INSTALLDPDK.md" to build ovs dpdk envrioment, but failed to 
start ovs-vswitchd
here is my configurations:
1. kernel: 3.10.45-openstack-amd64 #1 SMP Tue Jul 1 01:52:20 UTC 2014 x86_64 
GNU/Linux
2. NIC: 
01:00.0 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit 
SFI/SFP+ Network Connection [8086:10fb] (rev 01)
01:00.1 Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit 
SFI/SFP+ Network Connection [8086:10fb] (rev 01)
06:00.0 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network 
Connection [8086:1521] (rev 01)
06:00.1 Ethernet controller [0200]: Intel Corporation I350 Gigabit Network 
Connection [8086:1521] (rev 01)
3. IOMMU support
 /sys/kernel/iommu_groups/12/devices/:01:00.0
/sys/kernel/iommu_groups/12/devices/:01:00.1
/sys/kernel/iommu_groups/9/devices/:06:00.0
/sys/kernel/iommu_groups/9/devices/:06:00.1
BOOT_IMAGE=/boot/vmlinuz-3.10.45-openstack-amd64 
root=UUID=5cc1592c-91b4-485c-96cc-4528837dbeef ro default_hugepagesz=1G 
hugepagesz=1G hugepages=4 iommu=pt intel_iommu=on isolcpus=0-12 
intel_idle.max_cstate=0 idle=poll quiet cgroup_enable=memory crashkernel=512M
4. hugepage support
AnonHugePages:229376 kB
HugePages_Total:   4
HugePages_Free:2
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:1048576 kB
5.cpu information
  Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):48
On-line CPU(s) list:   0-47
Thread(s) per core:2
Core(s) per socket:12
Socket(s): 2
NUMA node(s):  2
Vendor ID: GenuineIntel
CPU family:6
Model: 63
Stepping:  2
CPU MHz:   2599.988
BogoMIPS:  4601.07
Virtualization:VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache:  256K
L3 cache:  30720K
NUMA node0 CPU(s): 
0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46
NUMA node1 CPU(s): 
1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47


6.dpdk parameters in ovs
   datapath_types  : [netdev, system]
db_version  : []
external_ids: {}
iface_types : [dpdk, dpdkr, dpdkvhostuser, dpdkvhostuserclient, geneve, 
gre, internal, ipsec_gre, lisp, patch, stt, system, tap, vxlan]
manager_options : []
next_cfg: 2
other_config: {dpdk-init="true", dpdk-lcore-mask="0xf", 
dpdk-socket-mem="1024,1024", pmd-cpu-mask="0x3"}
7. error logs when start ovs-vswtichd
2016-09-27T07:15:27Z|1|vlog|INFO|opened log file 
/var/log/openvswitch/ovs-vswitchd.log
2016-09-27T07:15:27Z|2|ovs_numa|INFO|Discovered 24 CPU cores on NUMA node 0
2016-09-27T07:15:27Z|3|ovs_numa|INFO|Discovered 24 CPU cores on NUMA node 1
2016-09-27T07:15:27Z|4|ovs_numa|INFO|Discovered 2 NUMA nodes and 48 CPU 
cores
2016-09-27T07:15:27Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock: 
connecting...
2016-09-27T07:15:27Z|6|reconnect|INFO|unix:/var/run/openvswitch/db.sock: 
connected
2016-09-27T07:15:27Z|7|dpdk|INFO|DPDK Enabled, initializing
2016-09-27T07:15:27Z|8|dpdk|INFO|No vhost-sock-dir provided - defaulting to 
/var/run/openvswitch
2016-09-27T07:15:27Z|9|dpdk|INFO|EAL ARGS: ovs-vswitchd -c 0xf --socket-mem 
1024,1024
EAL: Detected 48 lcore(s)
PMD: bnxt_rte_pmd_init() called for (null)
EAL: PCI device :01:00.0 on NUMA socket 0
EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
EAL: Error - exiting with code: 1
  Cause: Requested device :01:00.0 cannot be used
8. version information
   Open vSwitch 2.6.0
  dpdk: 16.07
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Mail System Error - Returned Mail

[Post Office]

The original message was received at Tue, 27 Sep 2016 11:39:38 +0530 from 
160.24.197.253

- The following addresses had permanent fatal errors -




___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] INSTALL.md: Add details about kernel module preference.

[Darrell Ball]

On Mon, Sep 26, 2016 at 8:52 PM, Darrell Ball  wrote:

>
>
> On Mon, Sep 26, 2016 at 7:34 AM, Gurucharan Shetty  wrote:
>
>> Signed-off-by: Gurucharan Shetty 
>> ---
>>  INSTALL.md | 23 ++-
>>  1 file changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/INSTALL.md b/INSTALL.md
>> index bb40e4a..6ecefdf 100644
>> --- a/INSTALL.md
>> +++ b/INSTALL.md
>> @@ -322,9 +322,30 @@ Building the Sources
>>  4. Run "make install" to install the executables and manpages into the
>> running system, by default under /usr/local.
>>
>> -5. If you built kernel modules, you may install and load them, e.g.:
>> +5. If you built kernel modules, you may install them, e.g.:
>>
>>`% make modules_install`
>> +
>> +It is possible that you already had a Open vSwitch kernel module
>> +installed on your machine that came from upstream Linux (in a
>> +different directory).  To make sure that you insert the Open vSwitch
>> +kernel module you built from this repository, you should create a
>> +depmod.d file that prefers your newly installed kernel modules over
>> +the kernel modules from upstream Linux.  The following snippet of
>> +code achieves the same.
>> +
>> +```
>> +% config_file="/etc/depmod.d/openvswitch.conf"
>> +% for module in datapath/linux/*.ko; do
>> +  modname="$(basename ${module})"
>> +  echo "override $modname * extra" >> "$config_file"
>> +  echo "override $modname * weak-updates" >> "$config_file"
>> +  done
>> +% depmod -a
>> +```
>> +
>>
>
> I tried the script
>
> #!/bin/bash
> config_file="/etc/depmod.d/openvswitch.conf"
> for module in datapath/linux/*.ko; do
> modname="$(basename ${module})"
> echo "override $modname * extra" >> "$config_file"
> echo "override $modname * weak-updates" >> "$config_file"
> done
> depmod -a
>
> on Ubuntu 14.04 and the script generated the expected
> file contents
>
> dball@ubuntu:~/openvswitch/ovs/_gcc$ cat /etc/depmod.d/openvswitch.conf
> override openvswitch.ko * extra
> override openvswitch.ko * weak-updates
> override vport-geneve.ko * extra
> override vport-geneve.ko * weak-updates
> override vport-gre.ko * extra
> override vport-gre.ko * weak-updates
> override vport-lisp.ko * extra
> override vport-lisp.ko * weak-updates
> override vport-stt.ko * extra
> override vport-stt.ko * weak-updates
> override vport-vxlan.ko * extra
> override vport-vxlan.ko * weak-updates
>
> However the "extra" directory where locally built ovs kos are installed is
> not
> taking precedence
>
> dball@ubuntu:~/openvswitch/ovs/_gcc$ sudo modinfo openvswitch
> filename:   /lib/modules/3.19.0-25-generic/kernel/net/openvswitch/
> openvswitch.ko
> license:GPL
> description:Open vSwitch switching datapath
> srcversion: EB1236CA2503B5F233DE125
> depends:libcrc32c
> intree: Y
> vermagic:   3.19.0-25-generic SMP mod_unload modversions
> signer: Magrathea: Glacier signing key
> sig_key:6A:AA:11:D1:8C:2D:3A:40:B1:B4
> :DB:E5:BF:8A:D6:56:DD:F5:18:38
> sig_hashalgo:   sha512
>
> So I edited the script to do something minimal, although it may not
> work for all distributions ?
>
> #!/bin/bash
> config_file="/etc/depmod.d/openvswitch.conf"
> echo "search extra" >> "$config_file"
> depmod -a
>
> dball@ubuntu:~/openvswitch/ovs/_gcc$ cat /etc/depmod.d/openvswitch.conf
> search extra
>
> and it seems to work (i.e. overrides my default config file) on Ubuntu
>

I checked into this further and depmod just seems to be using an
alphabetical order for depmod
config files !
It does not seem to differentiate non-default vs default config files.
Hence, this approach will not work.



>
> dball@ubuntu:~/openvswitch/ovs/_gcc$ sudo modinfo openvswitch
> filename:   /lib/modules/3.19.0-25-generic/extra/openvswitch.ko
> alias:  net-pf-16-proto-16-family-ovs_packet
> alias:  net-pf-16-proto-16-family-ovs_flow
> alias:  net-pf-16-proto-16-family-ovs_vport
> alias:  net-pf-16-proto-16-family-ovs_datapath
> version:2.6.90
> license:GPL
> description:Open vSwitch switching datapath
> srcversion: E30F336D9883ACAE1CB02EA
> depends:nf_conntrack,nf_nat,nf_defrag_ipv6,libcrc32c,nf_nat_ipv6,
> nf_nat_ipv4,gre,nf_defrag_ipv4
> vermagic:   3.19.0-25-generic SMP mod_unload modversions
> parm:   udp_port:Destination UDP port (ushort)
>







>
>
>
>
>
>> +Finally, load the kernel modules that you need.  e.g.:
>> +
>>`% /sbin/modprobe openvswitch`
>>
>> To verify that the modules have been loaded, run "/sbin/lsmod" and
>> --
>> 1.9.1
>>
>> ___
>> dev mailing list
>> dev@openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
>>
>
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev