Re: [ovs-dev] [PATCH] rhel: fix ovn-common rpm installation failure

[Babu Shanmugam]

On Tuesday 22 November 2016 04:17 AM, Lance Richardson wrote:

The directory/usr/lib/ocf/  does not exist if the pacemaker
package has not been installed, which causes installation of the
ovn-common rpm to fail on "mkdir /usr/lib/ocf/resource.d/ovn".
Allow for the possibility that /usr/lib/ocf does not exist by
using "mkdir -p".

Fixes: a4245b7869c8 ("ovn: Add ovn db servers ocf script in fedora packager")
Signed-off-by: Lance Richardson
---
  rhel/openvswitch-fedora.spec.in | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Acked-by: Babu Shanmugam 
Tested-by: Babu Shanmugam 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] QUOTATION REQUEST

[telsfnu]

Dear Sir,

Can you please offer us for the attached?

Pls send your quotation.

Thanks & Regards, 

ELENA VILAS | Business Development Department | NIRMAL PVT. LTD. 

Survey No.136/1 (P) | Asangaon | Tal: Shahapur | Dist: Thane-421601 

DID: +91-2527-661093 [1] | Fax : +91-2527-661020 [2] | 

Website: www.nirmal.com [3] 

_  __EXPERTISE THAT DELIVERS___

Nirmal Private Limited (reg. no.: U24299KA1998PTC024038 ). Registered
address: Survey No. 136/1 (P) | Asangaon | Tal: Shahapur | Dist:
Thane-421601, India
This e-mail (including any attachments) is for the intended addressee(s)
only and may contain confidential and/or proprietary information
protected by law. You are hereby notified that any unauthorized reading,
disclosure, copying or distribution of this e-mail or use of information
herein is strictly prohibited. If you are not an intended recipient you
should delete this e-mail immediately.

  

Links:
--
[1] callto:+91-2527-661093
[2] callto:+91-2527-661020
[3] http://www.nirmal.com
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Proposal to move the Python lib to its own repo

[Ben Pfaff]

On Tue, Nov 15, 2016 at 11:29:51AM -0600, Terry Wilson wrote:
> The Python library isn't dependent on the code in the OVS tree. It
> being in-tree has a few shortcomings. My rationale for recommending
> the split:
>
> * Simple features and bugfixes for the Python lib can't be used by
> other projects (like Neutron) until the very latest OVS release is
> widely supported

I am not sure that I understand why.  Why would Neutron and other
projects be more willing to use a pre-release version of an OVS Python
library, than a pre-release version of OVS itself?  Or do you mean that
the OVS Python library would release more frequently than OVS itself?

The following two bullets are related:

> * Python 3 support is only available in version 2.6.0+ even though the
> code would work for previous releases
> 
> * Implying that the Python lib and OVS versions are related when they
> aren't is confusing

The Python library and OVS version numbers are indeed related, in that a
given version of OVS is meant to work with the same version of the
Python library, and vice versa.  Maybe there is some flexibility in
working with different versions, but if so then this is more by accident
than design.

Scanning the recent commits to the repository, it appears that the main
dependency is just that the main OVS code requires a new-enough version
of the Python code.  Probably, this is not a big deal, but the split-off
repos should explain the situation somewhere.

As you suggest, maybe the Python code from 2.6.x would work with earlier
versions of OVS.  But this was not a foreseen use, so I would not want
to recommend that users do this.  If we split the repos and start
thinking about this kind of possibility, then I agree that similar
combinations could make sense for OVS 2.7.x+.

> * A separate repo would allow adding committers that are familiar with
> the Python code, but less familiar with the C code.

I'd rather have only "committers", not "OVS committers" and "OVS Python
library committers".  We don't have "OVS committers" and "OVS Linux
datapath committers" and "OVS Windows datapath committers" and "OVS-DPDK
committers", for example.  We trust our committers not to commit code
without obtaining assurance that the code makes sense, through careful
coding and at least one quality review.  Part of that trust is trusting
committers to recognize when their own understanding of a piece code is
limited and therefore that they should obtain more or better reviews.
In other words, I want to trust programmers who do not know C to commit
to the C parts of OVS anyway, because they will take the trouble to get
good advice.

> * As a Python-only project, it could be more easily tested, built, and
> packaged according to Python project best practices.

I think that most of the Python tests run some part of OVS.  I'm not
sure how effective the Python library tests can be if OVS isn't
available.

> The current build process requires the Python code, but this is easily
> remedied by using git submodules. People tend to reflexively dislike
> them, but they are perfect for this application. The OVS tree can lock
> to any particular commit for the new python-ovs repo and be guaranteed
> that changes don't break the ovs build. I made a fork to show how
> simple the change would be:
> 
> https://github.com/otherwiseguy/ovs/commit/6766131b42807829ea78dbc43d164db8926030e7
> 
> commit 6766131b42807829ea78dbc43d164db8926030e7
> Author: Terry Wilson 
> Date:   Mon Nov 14 16:03:43 2016 -0600
> 
> Move python dir to a submodule

It's a straightforward change, yes, if it's valuable.

Documentation and webpage updates would be needed to explain the new
build process.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] Expose sFLOW "Processor information" counters.

[Neil McKee]

Hello Michal,

Most systems that run Open vSwitch can also run hsflowd to export a wide
range of standard host performance statistics:
http://sflow.org/sflow_host.txt
http://sflow.org/sflow_host_ip.txt

That's a large superset of the "struct processor" export you are filling in
here.

This "struct processor" was originally aimed at providing some visibility
into the CPU/memory status of closed-platform physical switches,  but it
has really been superseded in places where sflow_host is available.   Newer
physical switches tend to run Linux,  and usually run hsflowd (Cumulus
Linux,  Dell OS10, ...).

The hsflowd daemon integrates with OVS  (just add "ovs{}" to
/etc/hsflowd.conf and it will configure OVS sFlow):
http://sflow.net/host-sflow-linux-config.php

So I'm wondering if this patch is worthwhile?
But perhaps I missed something.  Is there a use-case where it's unlikely
that hsflowd can be layered on top?

Neil



--
Neil McKee
InMon Corp.
http://www.inmon.com

On Mon, Nov 21, 2016 at 5:34 AM, mweglicx 
wrote:

> Exports PROCESSOR structure with sFLOW counters.
> Refactors vswitchd/system-stats.* functionality to support
> complex system counters which are enabled on request, and basic stats
> enabled by default.
> Adjust unit tests with very basic sanity check for PROCESSOR counters.
>
> Signed-off-by: Michal Weglicki 
> ---
>  lib/sflow.h  |  12 ++
>  lib/sflow_receiver.c |   8 ++
>  ofproto/ofproto-dpif-sflow.c |  17 ++-
>  tests/ofproto-dpif.at|  28 +++-
>  tests/test-sflow.c   |  15 +++
>  vswitchd/bridge.c|   1 +
>  vswitchd/system-stats.c  | 308 ++
> ++---
>  vswitchd/system-stats.h  |  16 +++
>  8 files changed, 352 insertions(+), 53 deletions(-)
>
> diff --git a/lib/sflow.h b/lib/sflow.h
> index 95bedd9..53ba4e0 100644
> --- a/lib/sflow.h
> +++ b/lib/sflow.h
> @@ -502,6 +502,16 @@ typedef struct _SFLVlan_counters {
>  u_int32_t discards;
>  } SFLVlan_counters;
>
> +#define SFL_CTR_PROCESSOR_XDR_SIZE 28
> +
> +typedef struct _SFLProcessor_counters {
> +int32_t cpu_util_5s;  /* 5 second average CPU utilization */
> +int32_t cpu_util_1m;  /* 1 minute average CPU utilization */
> +int32_t cpu_util_5m;  /* 5 minute average CPU utilization */
> +u_int64_t total_memory; /* total memory (in bytes) */
> +u_int64_t free_memory;  /* free memory (in bytes) */
> +} SFLProcessor_counters;
> +
>  /* OpenFlow port */
>  typedef struct {
>  u_int64_t datapath_id;
> @@ -587,6 +597,7 @@ enum SFLCounters_type_tag {
>  SFLCOUNTERS_VG   = 4,
>  SFLCOUNTERS_VLAN = 5,
>  SFLCOUNTERS_LACP = 7,
> +SFLCOUNTERS_PROCESSOR= 1001,
>  SFLCOUNTERS_OPENFLOWPORT = 1004,
>  SFLCOUNTERS_PORTNAME = 1005,
>  SFLCOUNTERS_APP_RESOURCES = 2203,
> @@ -604,6 +615,7 @@ typedef union _SFLCounters_type {
>  SFLPortName portName;
>  SFLAPPResources_counters appResources;
>  SFLOVSDP_counters ovsdp;
> +SFLProcessor_counters processor;
>  } SFLCounters_type;
>
>  typedef struct _SFLCounters_sample_element {
> diff --git a/lib/sflow_receiver.c b/lib/sflow_receiver.c
> index cde1359..23468f1 100644
> --- a/lib/sflow_receiver.c
> +++ b/lib/sflow_receiver.c
> @@ -655,6 +655,7 @@ static int computeCountersSampleSize(SFLReceiver
> *receiver, SFL_COUNTERS_SAMPLE_
> case SFLCOUNTERS_PORTNAME: elemSiz = stringEncodingLength(>
> counterBlock.portName.portName); break;
> case SFLCOUNTERS_APP_RESOURCES: elemSiz =
> SFL_CTR_APP_RESOURCES_XDR_SIZE; break;
> case SFLCOUNTERS_OVSDP: elemSiz = SFL_CTR_OVSDP_XDR_SIZE; break;
> +case SFLCOUNTERS_PROCESSOR: elemSiz = SFL_CTR_PROCESSOR_XDR_SIZE;
> break;
> default:
> sflError(receiver, "unexpected counters_tag");
> return -1;
> @@ -795,6 +796,13 @@ int sfl_receiver_writeCountersSample(SFLReceiver
> *receiver, SFL_COUNTERS_SAMPLE_
> putNet32(receiver, elem->counterBlock.ovsdp.n_flows);
> putNet32(receiver, elem->counterBlock.ovsdp.n_masks);
> break;
> +   case SFLCOUNTERS_PROCESSOR:
> +   putNet32(receiver, elem->counterBlock.processor.
> cpu_util_5s);
> +   putNet32(receiver, elem->counterBlock.processor.
> cpu_util_1m);
> +   putNet32(receiver, elem->counterBlock.processor.
> cpu_util_5m);
> +   putNet64(receiver, elem->counterBlock.processor.
> total_memory);
> +   putNet64(receiver, elem->counterBlock.processor.
> free_memory);
> +   break;
> default:
> sflError(receiver, "unexpected counters_tag");
> return -1;
> diff --git a/ofproto/ofproto-dpif-sflow.c b/ofproto/ofproto-dpif-sflow.c
> index 37992b4..84bbe18 100644
> --- a/ofproto/ofproto-dpif-sflow.c
> +++ b/ofproto/ofproto-dpif-sflow.c
> @@ -43,6 +43,7 @@

[ovs-dev] [PATCH 1/3] ovs-ofctl: Fix memory leak in ofctl_packet_out().

[Yi-Hung Wei]

In testcase "bfd - bfd decay", valgrind reports a memory leak with the
following call stack.
xmalloc (util.c:112)
vconn_stream_new (vconn-stream.c:60)
vconn_stream_open (vconn-stream.c:85)
vconn_open (vconn.c:248)
open_vconn_socket (ovs-ofctl.c:517)
open_vconn__ (ovs-ofctl.c:553)
open_vconn (ovs-ofctl.c:587)
open_vconn_for_flow_mod (ovs-ofctl.c:1416)
ofctl_packet_out (ovs-ofctl.c:2148)
ovs_cmdl_run_command__ (command-line.c:115)
main (ovs-ofctl.c:151)

Signed-off-by: Yi-Hung Wei 
---
 utilities/ovs-ofctl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/utilities/ovs-ofctl.c b/utilities/ovs-ofctl.c
index 4b8a43c..29b324b 100644
--- a/utilities/ovs-ofctl.c
+++ b/utilities/ovs-ofctl.c
@@ -2149,6 +2149,7 @@ ofctl_packet_out(struct ovs_cmdl_context *ctx)
usable_protocols);
 opo = ofputil_encode_packet_out(, protocol);
 transact_noreply(vconn, opo);
+vconn_close(vconn);
 free(CONST_CAST(void *, po.packet));
 free(po.ofpacts);
 } else {
-- 
2.7.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 2/2] rhel: Add EnvironmentFile for ovn services.

[Russell Bryant]

A previous commit documented how you do this using systemd
native interfaces for customizing services.  However, it seems
that some people still would rather see environment variables
specified through an old-style sysconfig file.  It seems harmless
enough to provide, so this patch adds it.

The "-" prefix to the filename means that systemd will ignore this
setting if the file does not exist and will not report any error.

Signed-off-by: Russell Bryant 
---
 rhel/usr_lib_systemd_system_ovn-controller-vtep.service | 10 --
 rhel/usr_lib_systemd_system_ovn-controller.service  |  9 +++--
 rhel/usr_lib_systemd_system_ovn-northd.service  |  9 +++--
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/rhel/usr_lib_systemd_system_ovn-controller-vtep.service 
b/rhel/usr_lib_systemd_system_ovn-controller-vtep.service
index 88e18b6..70128a9 100644
--- a/rhel/usr_lib_systemd_system_ovn-controller-vtep.service
+++ b/rhel/usr_lib_systemd_system_ovn-controller-vtep.service
@@ -18,8 +18,13 @@
 # you could place the following contents in
 # /etc/systemd/system/ovn-controller-vtep.d/local.conf:
 #
-# [System]
-# Environment="OVN_DB=unix:/usr/local/var/run/openvswitch/db.sock" 
"VTEP_DB=unix:/usr/local/var/run/openvswitch/vtep.sock"
+#   [System]
+#   Environment="OVN_DB=unix:/usr/local/var/run/openvswitch/db.sock" 
"VTEP_DB=unix:/usr/local/var/run/openvswitch/vtep.sock"
+#
+# Alternatively, you may specify environment variables in the file 
/etc/sysconfig/ovn-controller-vtep:
+#
+#   OVN_DB="unix:/usr/local/var/run/openvswitch/db.sock"
+#   VTEP_DB="unix:/usr/local/var/run/openvswitch/vtep.sock"
 
 [Unit]
 Description=OVN VTEP gateway controller daemon
@@ -30,6 +35,7 @@ After=openvswitch.service
 [Service]
 Type=simple
 Environment=OVS_RUNDIR=%t/openvswitch OVN_DB=unix:%t/openvswitch/db.sock 
VTEP_DB=unix:%t/openvswitch/db.sock
+EnvironmentFile=-/etc/sysconfig/ovn-controller-vtep
 ExecStart=/usr/bin/ovn-controller-vtep -vconsole:emer -vsyslog:err -vfile:info 
\
   --log-file=/var/log/openvswitch/ovn-controller-vtep.log \
   --no-chdir --pidfile=${OVS_RUNDIR}/ovn-controller-vtep.pid \
diff --git a/rhel/usr_lib_systemd_system_ovn-controller.service 
b/rhel/usr_lib_systemd_system_ovn-controller.service
index ad1b146..d08e9e2 100644
--- a/rhel/usr_lib_systemd_system_ovn-controller.service
+++ b/rhel/usr_lib_systemd_system_ovn-controller.service
@@ -6,8 +6,12 @@
 # could place the following contents in
 # /etc/systemd/system/ovn-controller.d/local.conf:
 #
-# [System]
-# Environment="OVN_CONTROLLER_OPTS=--ovn-controller-log=-vconsole:emer 
-vsyslog:err -vfile:info"
+#   [System]
+#   Environment="OVN_CONTROLLER_OPTS=--ovn-controller-log=-vconsole:emer 
-vsyslog:err -vfile:info"
+#
+# Alternatively, you may specify environment variables in the file 
/etc/sysconfig/ovn-controller:
+#
+#   OVN_CONTROLLER_OPTS="--ovn-controller-log=-vconsole:emer -vsyslog:err 
-vfile:info"
 
 [Unit]
 Description=OVN controller daemon
@@ -18,5 +22,6 @@ After=openvswitch.service
 [Service]
 Type=oneshot
 RemainAfterExit=yes
+EnvironmentFile=-/etc/sysconfig/ovn-controller
 ExecStart=/usr/share/openvswitch/scripts/ovn-ctl start_controller 
$OVN_CONTROLLER_OPTS
 ExecStop=/usr/share/openvswitch/scripts/ovn-ctl stop_controller
diff --git a/rhel/usr_lib_systemd_system_ovn-northd.service 
b/rhel/usr_lib_systemd_system_ovn-northd.service
index 6e23eaa..0eedd1a 100644
--- a/rhel/usr_lib_systemd_system_ovn-northd.service
+++ b/rhel/usr_lib_systemd_system_ovn-northd.service
@@ -6,8 +6,12 @@
 # could place the following contents in
 # /etc/systemd/system/ovn-northd.d/local.conf:
 #
-# [System]
-# 
Environment="OVN_NORTHD_OPTS=--db-nb-sock=/usr/local/var/run/openvswitch/ovnnb_db.sock
 --db-sb-sock=/usr/local/var/run/openvswitch/ovnsb_db.sock"
+#   [System]
+#   
Environment="OVN_NORTHD_OPTS=--db-nb-sock=/usr/local/var/run/openvswitch/ovnnb_db.sock
 --db-sb-sock=/usr/local/var/run/openvswitch/ovnsb_db.sock"
+#
+# Alternatively, you may specify environment variables in the file 
/etc/sysconfig/ovn-controller:
+#
+#   OVN_NORTHD_OPTS="--db-nb-sock=/usr/local/var/run/openvswitch/ovnnb_db.sock 
--db-sb-sock=/usr/local/var/run/openvswitch/ovnsb_db.sock"
 
 [Unit]
 Description=OVN northd management daemon
@@ -19,5 +23,6 @@ After=openvswitch.service
 Type=oneshot
 RemainAfterExit=yes
 Environment=OVS_RUNDIR=%t/openvswitch OVS_DBDIR=/var/lib/openvswitch
+EnvironmentFile=-/etc/sysconfig/ovn-northd
 ExecStart=/usr/share/openvswitch/scripts/ovn-ctl start_northd $OVN_NORTHD_OPTS
 ExecStop=/usr/share/openvswitch/scripts/ovn-ctl stop_northd
-- 
2.9.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 1/2] rhel: Fix Environment for ovn-controller-vtep.

[Russell Bryant]

The systemd unit for ovn-controller-vtep incorrectly specified
Environment multiple times.  Multiple environment variables must
be specified separated by a space to a single Environment option.

Signed-off-by: Russell Bryant 
---
 rhel/usr_lib_systemd_system_ovn-controller-vtep.service | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/rhel/usr_lib_systemd_system_ovn-controller-vtep.service 
b/rhel/usr_lib_systemd_system_ovn-controller-vtep.service
index 3bd4331..88e18b6 100644
--- a/rhel/usr_lib_systemd_system_ovn-controller-vtep.service
+++ b/rhel/usr_lib_systemd_system_ovn-controller-vtep.service
@@ -29,9 +29,7 @@ After=openvswitch.service
 
 [Service]
 Type=simple
-Environment=OVS_RUNDIR=%t/openvswitch
-Environment=OVN_DB=unix:%t/openvswitch/db.sock
-Environment=VTEP_DB=unix:%t/openvswitch/db.sock
+Environment=OVS_RUNDIR=%t/openvswitch OVN_DB=unix:%t/openvswitch/db.sock 
VTEP_DB=unix:%t/openvswitch/db.sock
 ExecStart=/usr/bin/ovn-controller-vtep -vconsole:emer -vsyslog:err -vfile:info 
\
   --log-file=/var/log/openvswitch/ovn-controller-vtep.log \
   --no-chdir --pidfile=${OVS_RUNDIR}/ovn-controller-vtep.pid \
-- 
2.9.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] AUTHORS: Add Andrew Beekhof

[Ben Pfaff]

On Sun, Nov 20, 2016 at 11:41:11PM +0530, Numan Siddique wrote:
> Signed-off-by: Numan Siddique 

Applied, thanks!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Windows: Implement Hyper-V VIF discovery agent

[Yin Lin]

Create a VIF discovery daemon to tag Hyper-V adapters connected to OVS
switch
and add/delete OVS port correspondingly.

Signed-off-by: Yin Lin 
---
 windows/OvsDiscoveryAgent/App.config   |  18 ++
 windows/OvsDiscoveryAgent/OvsDiscoveryAgent.csproj |  83 
 windows/OvsDiscoveryAgent/OvsDiscoveryAgent.sln|  34 +++
 windows/OvsDiscoveryAgent/OvsDiscoveryService.cs   |  67 ++
 windows/OvsDiscoveryAgent/OvsSwitchMonitor.cs  |  73 +++
 windows/OvsDiscoveryAgent/OvsVsctl.cs  |  82 
 windows/OvsDiscoveryAgent/Program.cs   |  26 +++
 .../OvsDiscoveryAgent/Properties/AssemblyInfo.cs   |  36 
 .../Properties/Settings.Designer.cs|  38 
 .../OvsDiscoveryAgent/Properties/Settings.settings |   9 +
 windows/OvsDiscoveryAgent/VirtualAdapter.cs|  36 
 windows/OvsDiscoveryAgent/VirtualAdapterManager.cs | 228
+
 windows/OvsDiscoveryAgent/VirtualAdapterMonitor.cs | 109 ++
 windows/OvsDiscoveryAgent/WmiMonitor.cs| 193 +
 windows/OvsDiscoveryAgent/WqlCondition.cs  | 168 +++
 windows/OvsDiscoveryAgent/WqlHelper.cs | 130 
 windows/OvsDiscoveryAgent/WqlObject.cs | 133 
 17 files changed, 1463 insertions(+)
 create mode 100644 windows/OvsDiscoveryAgent/App.config
 create mode 100644 windows/OvsDiscoveryAgent/OvsDiscoveryAgent.csproj
 create mode 100644 windows/OvsDiscoveryAgent/OvsDiscoveryAgent.sln
 create mode 100644 windows/OvsDiscoveryAgent/OvsDiscoveryService.cs
 create mode 100644 windows/OvsDiscoveryAgent/OvsSwitchMonitor.cs
 create mode 100644 windows/OvsDiscoveryAgent/OvsVsctl.cs
 create mode 100644 windows/OvsDiscoveryAgent/Program.cs
 create mode 100644 windows/OvsDiscoveryAgent/Properties/AssemblyInfo.cs
 create mode 100644
windows/OvsDiscoveryAgent/Properties/Settings.Designer.cs
 create mode 100644 windows/OvsDiscoveryAgent/Properties/Settings.settings
 create mode 100644 windows/OvsDiscoveryAgent/VirtualAdapter.cs
 create mode 100644 windows/OvsDiscoveryAgent/VirtualAdapterManager.cs
 create mode 100644 windows/OvsDiscoveryAgent/VirtualAdapterMonitor.cs
 create mode 100644 windows/OvsDiscoveryAgent/WmiMonitor.cs
 create mode 100644 windows/OvsDiscoveryAgent/WqlCondition.cs
 create mode 100644 windows/OvsDiscoveryAgent/WqlHelper.cs
 create mode 100644 windows/OvsDiscoveryAgent/WqlObject.cs

diff --git a/windows/OvsDiscoveryAgent/App.config
b/windows/OvsDiscoveryAgent/App.config
new file mode 100644
index 000..caf9613
--- /dev/null
+++ b/windows/OvsDiscoveryAgent/App.config
@@ -0,0 +1,18 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+ovs-int
+
+
+
+
\ No newline at end of file
diff --git a/windows/OvsDiscoveryAgent/OvsDiscoveryAgent.csproj
b/windows/OvsDiscoveryAgent/OvsDiscoveryAgent.csproj
new file mode 100644
index 000..24c69bb
--- /dev/null
+++ b/windows/OvsDiscoveryAgent/OvsDiscoveryAgent.csproj
@@ -0,0 +1,83 @@
+
+http://schemas.microsoft.com/developer/msbuild/2003;>
+  
+  
+Debug
+AnyCPU
+{2563C1BE-B240-4F63-84C5-01D98D015A3F}
+Exe
+Properties
+OvsDiscoveryAgent
+OvsDiscoveryAgent
+v4.5.2
+512
+true
+  
+  
+AnyCPU
+true
+full
+false
+bin\Debug\
+DEBUG;TRACE
+prompt
+4
+  
+  
+AnyCPU
+pdbonly
+true
+bin\Release\
+TRACE
+prompt
+4
+  
+  
+
+
+
+
+
+
+
+
+
+
+  
+  
+
+
+  True
+  True
+  Settings.settings
+
+
+
+  Component
+
+
+
+
+
+
+
+
+
+
+  
+  
+
+
+  SettingsSingleFileGenerator
+  Settings.Designer.cs
+
+  
+  
+  
+
\ No newline at end of file
diff --git a/windows/OvsDiscoveryAgent/OvsDiscoveryAgent.sln
b/windows/OvsDiscoveryAgent/OvsDiscoveryAgent.sln
new file mode 100644
index 000..b3d6371
--- /dev/null
+++ b/windows/OvsDiscoveryAgent/OvsDiscoveryAgent.sln
@@ -0,0 +1,34 @@
+
+Microsoft Visual Studio Solution File, Format Version 12.00
+# Visual Studio 14
+VisualStudioVersion = 14.0.25123.0
+MinimumVisualStudioVersion = 10.0.40219.1
+Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "OvsDiscoveryAgent",
"OvsDiscoveryAgent.csproj", "{2563C1BE-B240-4F63-84C5-01D98D015A3F}"
+EndProject
+Global
+ GlobalSection(SolutionConfigurationPlatforms) = preSolution
+ Debug|Any CPU = Debug|Any CPU
+ Debug|x64 = Debug|x64
+ Debug|x86 = Debug|x86
+ Release|Any CPU = Release|Any CPU
+ Release|x64 = Release|x64
+ Release|x86 = Release|x86
+ EndGlobalSection
+ GlobalSection(ProjectConfigurationPlatforms) = postSolution
+ {2563C1BE-B240-4F63-84C5-01D98D015A3F}.Debug|Any CPU.ActiveCfg =
Debug|Any CPU
+ {2563C1BE-B240-4F63-84C5-01D98D015A3F}.Debug|Any CPU.Build.0 = Debug|Any
CPU
+ 

[ovs-dev] OVS-Hyper-V-Discovery-Agent Design Document

[Yin Lin]

Hi,

Below is a document that describes the design and implementation of VIF
discovery agent for Hyper-V that I have been working on. The coding has
already been completed and will be sent out for review in a follow up
patch. The document describes the effort and the choices made. Thanks
Sairam Venugopal for the initial review and edit of the document



Please have a look, and get in touch for any questions or comments.



Thanks!

-- Yin



===


   OVS-Hyper-V-Discovery-Agent Design Document

   ==

On Hyper-V, virtual switches and virtual adapters are created and managed
by Windows infrastructure. This is currently not integrated with OVS. When
a new virtual adapter is connected to a virtual switch with OVS extension
enabled, users need to manually tag it with an OVS port name and manually
use OVS userspace utilities such as ovs-vsctl to add a corresponding OVS
port.



This document describes design of a VIF discovery agent for OVS on Hyper-V
that functions as a counterpart to libvirt on KVM. The agent monitors
virtual switch/adapter modifications, tags the adapter and adds/deletes OVS
port as necessary to automate the VIF creation/deletion process.



The rest of this document describes:

1. Background of OVS port management on Hyper-V

2. Discovery agent functional specification

3. Implementation of discovery agent

4. Build/Deployment environment



For more questions, please contact dev at openvswitch.org



1) Background of OVS port management on Hyper-V



OVS kernel module on Hyper-V[3] is implemented as a extension [2] to the
virtual extensible switch[1] provided by Microsoft. The extension can be
enabled through Hyper-V Virtual Switch Manager GUI or Powershell command
once the OVS driver is installed.



The OVS kernel module recognizes any adapter that connects to such a switch
by requiring user to tag the Hyper-V adapter with an OVS port name and then
add the OVS port to ovsdb with ovs-vsctl command. A Powershell module
called OVS.psm1 has been implemented to facilitate the tagging. Once the
module is imported, admin can use the following command to tag a virtual
adapter with OVS port name:



$vnic | Set-VMNetworkAdapterOVSPort -OVSPortName $vifName



where $vnic is a VMNetworkAdapter instance and $vifName is the OVS port
name. Then the admin needs to add the OVS port by using:



ovs-vsctl add-port $bridge $vifName --set interface $vifName
external_ids:vm-id=$vmId \

external_ids:iface-status=active



where $bridge is the integration bridge name and $vmId is the Hyper-V VM
UUID. The VM ID is currently optional for reporting purposes and will not
affect the actual functionality of the OVS port.



In order to automate this process, the discovery agent needs to actively
monitor two events:

1. Creation/Deletion of a virtual switch that has OVS extension enabled.
This includes

enable/disable-ment of OVS extension on an existing virtual switch.

2. Connection/Disconnection of a VIF to OVS enabled virtual switch.



In order to capture these events, we utilize Windows Management
Instrumentation (WMI)[4] to register a callback [5] when a desired change
in virtualization namespace happens. WMI is also used to perform a full
sync of all existing virtual switches and virtual adapters during the
discovery agent's initial boot.



2) Discovery agent functional specification

---

The discovery agent performs the following three basic duties:

1. Tag(). Tag a virtual adapter with OVS port, by setting its "ElementName"
field in the WMI table "Msvm_EthernetPortAllocationSettingData" to an OVS
port name, such that it can be picked up by OVS kernel module and matched
against a corresponding entry in ovsdb. By default, the OVS port name of a
virtual adapter assigned by the discovery agent is the same as its UUID
assigned by Windows.

2. AddPort(). Add an OVS port to OVS bridge. If a virtual adapter is
connected to an OVS switch but it's missing in ovsdb, the daemon adds it to
a preconfigured integration bridge, as specified by the admin..

3. DelPort(). Delete an OVS port from the OVS integration bridge.



When the discovery agent starts, it scans all virtual adapters that are
connected to the virtual switch with OVS extension enabled. , It runs
 AddPort() for  adapters that are missing  in the preconfigured OVS
integration bridge.



After that, the discovery agent actively monitors the system for any
relevant virtual switch/adapter changes and performs the following actions:

1. When OVS extension is enabled on a virtual switch, perform AddPort() for
all adapters connected to the virtual switch.

2. When a virtual switch with OVS extension is deleted, or when OVS
extension is disabled on a virtual switch, perform DelPort() for all
adapters previously connected to the virtual switch.

3. When a virtual adapter is created 

[ovs-dev] RE

[Ms. Ella Golan]

I am Ms.Ella Golan, I am the Executive Vice President Banking Division with 
FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI).
I am getting in touch with you regarding an extremely important and urgent
matter. If you would oblige me the opportunity, I shall provide you with
details upon your response.

Faithfully,
Ms.Ella Golan

Antes de imprimir este mensaje, asegúrese que sea necesario. Cuidar el medio 
ambiente es tarea de todos.

Este e-mail y sus adjuntos son confidenciales y para el uso exclusivo del 
destinatario. Si usted ha recibido este e-mail por error eliminelo de sus 
sistema y, por favor, visite el siguiente link 
http://eling.com.ar/index.php?option=com_content=article=92. Muchas 
gracias.

This e-mail and its attachments are confidential, and for the exclusive use of 
the recipient. If you have received this mail wrongly, please delete it from 
your computer system, and visit the following link 
http://eling.com.ar/index.php?option=com_content=article=92. Thank you 
very much.

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [Openvswitch support NSH]

[võ phúc]

Thanks OVS team.

2016-11-21 19:26 GMT+07:00 Flavio Leitner :

> On Fri, Nov 18, 2016 at 08:02:30PM +0700, vő phúc wrote:
> > Dear OVS team,
> > I want install openstack with sfc, so i want to find ovs support with
> NSH ,
> > you can show me how to build ovs with NSH or version OVS support NSH?
> > Thank you.
>
> This is a work in progress to add NSH support to OVS which required
> changes to kernel and OVS. Currently the upstream kernel is ready,
> but OVS needs to use the new interface (patch posted already). Then
> there is another patchset to remove the need for L2 headers.
>
> After that we expect to be possible to add support for NSH.
>
> --
> Flavio
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/2] ovn-nbctl: Add NAT commands.

[Guru Shetty]

On 21 November 2016 at 07:56, nickcooper-zhangtonghao 
wrote:

> Hi Guru Shetty
> The logical_ip address or network should be SNATed to an external_ip in a
> gw router, then it's unnecessary that the logical_ip is mapped to
> multiple external IPs. The external_ip should also be DNATed to a
> logical_ip address, then it's unnecessary that external_ip is mapped to
> multiple logical IPs.
>
> The first condition check the logical ip or external ip according to nat
> type. If first condition check return true,
> we check external ip or logical ip for giving more details about the
> reason for the error.
>

Thanks for the explanation. I understand it now. I applied this.


>
>
> Thanks.
> Nick
>
> > On Nov 19, 2016, at 1:42 AM, Guru Shetty  wrote:
> >
> > Is there any reason why we need the is_snat check in the above 2
> conditions? It looks to me that we check the logical_ip and external_ip for
> all cases. Why is it important what the outer condition or inner condition
> is?
> >
> > Otherwise, this looks good to me.
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 4/4] ovs: optimize 'ip_parse_port' function.

[nickcooper-zhangtonghao]

Hi Guru Shetty

I folded in the following minor incremental just because ovs_scan_len() is only 
really meant for
situations where the 'n' offset is being incremented over several calls.

Thanks.
Nick

> On Nov 19, 2016, at 2:35 AM, Guru Shetty  wrote:
> 
> Can you tell why one is better than the other?
>  
> ---
>  lib/packets.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/packets.c b/lib/packets.c
> index 990c407..1d2d452 100644
> --- a/lib/packets.c
> +++ b/lib/packets.c
> @@ -436,15 +436,12 @@ char * OVS_WARN_UNUSED_RESULT
>  ip_parse_port(const char *s, ovs_be32 *ip, ovs_be16 *port)
>  {
>  int n = 0;
> -if (!ovs_scan_len(s, , IP_PORT_SCAN_FMT,
> -IP_PORT_SCAN_ARGS(ip, port))) {
> -return xasprintf("%s: invalid IP address or port number", s);
> +if (ovs_scan(s, IP_PORT_SCAN_FMT"%n", IP_PORT_SCAN_ARGS(ip, port), )
> +&& !s[n]) {
> +return NULL;
>  }
> 
> -if (s[n]) {
> -return xasprintf("%s: invalid IP address or port number", s);
> -}
> -return NULL;
> +return xasprintf("%s: invalid IP address or port number", s);
>  }

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] sflow: Expose ethernet and vlan stats via sFlow

[Robert Wojciechowicz]

On Fri, Nov 18, 2016 at 12:35:13PM -0700, Neil McKee wrote:
> That sounds like a robust way to do it,  yes.   Does it have the desired
> effect?  Does it eliminate this structure for all the virtual ethernet
> ports?  I believe there should only be <= 1 physical ethernet port on each

It eliminates this structure for all interfaces for which those
counters are not available (its value is equal to UINT_MAX).
I tested that for linux tap interface and dpdk vhost-user.
Both are virtual, but for the first one these ethernet counters
are available, but for the second one they aren't.
Basically the logic what statistics are avaialable for the given
interface is performed on the netdev (netdev-dpdk, netdev-linux,...) level.

> OVS bridge,  so the ethernet stats block should only be included for those.
> 
> It looks like ifType=ethernetcsmacd is hard-coded at this point:
> https://github.com/openvswitch/ovs/blob/master/ofproto/ofproto-dpif-sflow.c#L317
> But maybe we should at least add a comment to make sure we never fall into
> the trap of sending an ethernet structure for something that has a
> symbol-errors counter but is not strictly ethernet (e.g. infiniband or
> fiber-channel).   It's not as simple as testing for ifType==6 because it
> could be ifType 7,26,62,69 or 117 and still be ethernet.   So I think a
> comment would be OK for now.  What do you think?
> 

I'm thinking of adding something like this:

/* XXX Ethernet counters don't make sense for all interfaces,
 so let's check if there is available any data to send */
if (sflow_counter_test(_counters)) {
SFLADD_ELEMENT(cs, _elem);
}

So these counters will be sent only if there is indeed something
available on the netdev level.

Br,
Robert
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC] Output refactor for customized displays

[Aaron Conole]

Ben Pfaff  writes:

> On Fri, Nov 18, 2016 at 05:22:27PM -0500, Aaron Conole wrote:
>> During some recent face-to-face talks regarding debugging ovs, an issue
>> was raised regarding the output.  The gist of the conversation was that as
>> it stands, ovs output is less-than-friendly, and a different output would
>> be helpful.
>> 
>> Looking a bit into it, it appears that the output routines for most of the
>> openflow / ovs data uses the dynamic string library to just append as much
>> structure data as possible, in whatever form was originally useful.  This
>> is fine for ovs wizards, but some 'mere mortals' would prefer prettier
>> output with the ability to tweak / omit the data that comes out of the tools.
>
> I like the idea of a table printing framework, but can you explain why
> this library is separate from the one in lib/table.[ch]?

Yes I can - I completely missed table.{c,h}

Thanks for the review - I'll use the table library for my work.

-Aaron
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Dear trusted one

[Mrs. Lucy Farouk]

Dear trusted one,

I sent this mail hoping that it reaches you in good health because I myself am 
in a very critical health condition in which I go to bed every night knowing I 
may not be alive to see the next day. I am Mrs Lucy Farouk from Libya but I'm 
contacting you from a hospital bed where I wrote this mail in tears hoping to 
let you know of my ordeal. My husband who until his death in October 2005 was a 
secret agent to the now late president Muammar Gaddafi of Libya. We were 
married for 15 years without a child due to my fibroid problem. My husband died 
in his office in Burkina Faso as a result of heart attack and I made a decision 
to live out the rest of my life as his widow.

Very shortly before my husband's death, he made a deposit of ($11) Million 
Dollars. He deposited the money in his name as proceeds from an oil contract, 
but the fund was actually, an initial payment for a secret arm deal he was 
broke ring for his then master Gaddafi and the government of North Korea. Now 
with the deaths of my husband and that of President Muammar Gaddafi during the 
crisis in Libya, I'm now the only one who knows of this particular fund and 
presently I'm in this hospital bed dying of cancer since the doctor has made it 
clear that I'm no longer responding to medications, indicating that I will not 
be living much longer, but I will rather die in this hospital than go home and 
face more insults and humiliation from my husband relatives who took away all 
my money and jewels and left me uncarved-for just because I'm an orphan.

Having considered my position, I have decided to use you to carry out my plan. 
I will guide you to receive the ($11) Million Dollars from the bank in Burkina 
Faso and you will take 30% of it for yourself and your family while you will 
use the other 70% and build an orphanage home for the motherless children in 
your location or anywhere of your choice. This is because I'm an orphan and 
does not have any relative. This has been my wish before this sickness came 
between my plans. Please you must follow this directive or I will look for 
another person. The only reason I will not entrust the fund and project to 
someone around here is because I'm making it a top secret so that the news 
doesn't get to my husband relatives who will not allow the fund to be used for 
humanitarian work but will quickly confiscate the money and have it shared 
among them.

However, if you are not capable of handling this task or you do not have 
confidence in this message, please kindly delete it and accept my sincere 
apology for contacting you in this manner, but if you have confidence in it and 
can handle the task then kindly indicate by responding. 

Thanks and be Blessed.

Mrs. Lucy Farouk.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [ovs-dev, 03/17] dpif-netdev: Don't try to output on a device without txqs.

[Ilya Maximets]

On 16.11.2016 03:45, Daniele Di Proietto wrote:
> Tunnel devices have 0 txqs and don't support netdev_send().  While
> netdev_send() simply returns EOPNOTSUPP, the XPS logic is still executed
> on output, and that might be confused by devices with no txqs.
> 
> It seems better to have different structures in the fast path for ports
> that support netdev_{push,pop}_header (tunnel devices), and ports that
> support netdev_send.  With this we can also remove a branch in
> netdev_send().
> 
> This is also necessary for a future commit, which starts DPDK devices
> without txqs.
> 
> Signed-off-by: Daniele Di Proietto 
> ---
>  lib/dpif-netdev.c | 72 
> ---
>  lib/netdev.c  | 15 
>  lib/netdev.h  |  1 +
>  3 files changed, 64 insertions(+), 24 deletions(-)
> 
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 7b67b42..81366b2 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -422,7 +422,8 @@ struct rxq_poll {
>  struct ovs_list node;
>  };
>  
> -/* Contained by struct dp_netdev_pmd_thread's 'port_cache' or 'tx_ports'. */
> +/* Contained by struct dp_netdev_pmd_thread's 'send_port_cache',
> + * 'tnl_port_cache' or 'tx_ports'. */
>  struct tx_port {
>  struct dp_netdev_port *port;
>  int qid;
> @@ -504,11 +505,19 @@ struct dp_netdev_pmd_thread {
>   * read by the pmd thread. */
>  struct hmap tx_ports OVS_GUARDED;
>  
> -/* Map of 'tx_port' used in the fast path. This is a thread-local copy of
> - * 'tx_ports'. The instance for cpu core NON_PMD_CORE_ID can be accessed
> - * by multiple threads, and thusly need to be protected by 
> 'non_pmd_mutex'.
> - * Every other instance will only be accessed by its own pmd thread. */
> -struct hmap port_cache;
> +/* These are thread-local copies of 'tx_ports'.  One contains only tunnel
> + * ports (that support push_tunnel/pop_tunnel)  The other contains
> + * non-tunnel ports (that support send).
> + *
> + * These are kept separate to make sure that we don't try to execute
> + * OUTPUT on a tunnel device (which has 0 txqs) or PUSH/POP on a 
> non-tunnel
> + * device.
> + *
> + * The instance for cpu core NON_PMD_CORE_ID can be accessed by multiple
> + * threads, and thusly needs to be protected by 'non_pmd_mutex'.  Every
> + * other instance will only be accessed by its own pmd thread. */
> +struct hmap tnl_port_cache;
> +struct hmap send_port_cache;
>  
>  /* Only a pmd thread can write on its own 'cycles' and 'stats'.
>   * The main thread keeps 'stats_zero' and 'cycles_zero' as base
> @@ -3055,7 +3064,10 @@ pmd_free_cached_ports(struct dp_netdev_pmd_thread *pmd)
>  /* Free all used tx queue ids. */
>  dpif_netdev_xps_revalidate_pmd(pmd, 0, true);
>  
> -HMAP_FOR_EACH_POP (tx_port_cached, node, >port_cache) {
> +HMAP_FOR_EACH_POP (tx_port_cached, node, >tnl_port_cache) {
> +free(tx_port_cached);
> +}
> +HMAP_FOR_EACH_POP (tx_port_cached, node, >send_port_cache) {
>  free(tx_port_cached);
>  }
>  }
> @@ -3069,11 +3081,22 @@ pmd_load_cached_ports(struct dp_netdev_pmd_thread 
> *pmd)
>  struct tx_port *tx_port, *tx_port_cached;
>  
>  pmd_free_cached_ports(pmd);
> -hmap_shrink(>port_cache);
> +hmap_shrink(>send_port_cache);
> +hmap_shrink(>tnl_port_cache);
>  
>  HMAP_FOR_EACH (tx_port, node, >tx_ports) {
> +struct hmap *cache;
> +
> +if (netdev_has_tunnel_push_pop(tx_port->port->netdev)) {
> +cache = >tnl_port_cache;
> +} else if (netdev_n_txq(tx_port->port->netdev)) {
> +cache = >send_port_cache;
> +} else {
> +continue;
> +}

IMHO, this code introduces artificial limitations for netdev.
What about something like this:

if (has_pop _OR_ has_push) {
insert to 'tnl_port_cache';
}

if (netdev_n_txq(tx_port->port->netdev)) {
insert to 'send_port_cache';
}
?
i.e make all the checks independent.

Otherwise, it must be described in 'netdev-provider.h' that netdev
can have only tunnel related functions (both 'push' and 'pop') or
send function.

> +
>  tx_port_cached = xmemdup(tx_port, sizeof *tx_port_cached);
> -hmap_insert(>port_cache, _port_cached->node,
> +hmap_insert(cache, _port_cached->node,
>  hash_port_no(tx_port_cached->port->port_no));
>  }
>  }
> @@ -3309,7 +3332,8 @@ dp_netdev_configure_pmd(struct dp_netdev_pmd_thread 
> *pmd, struct dp_netdev *dp,
>  pmd->next_optimization = time_msec() + DPCLS_OPTIMIZATION_INTERVAL;
>  ovs_list_init(>poll_list);
>  hmap_init(>tx_ports);
> -hmap_init(>port_cache);
> +hmap_init(>tnl_port_cache);
> +hmap_init(>send_port_cache);
>  /* init the 'flow_cache' since there is no
>   * actual thread created for NON_PMD_CORE_ID. */
>  if (core_id ==