Li, Ni (UI Health Care | 6 Feb 12:04 2016
Picon

re


I Have A Proposal For You, For details email me via: mrshuachan <at> qq.com

________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications
Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the
intended recipient, you are hereby notified that any retention, dissemination, distribution, or
copying of this communication is strictly prohibited.  Please reply to the sender that you have received
the message in error, then delete it.  Thank you.
________________________________
_______________________________________________
dev mailing list
dev <at> openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Aditi Dhale | 6 Feb 05:06 2016
Picon

Doubt about Packet flow in Openvswitch

Dear Sir,
How do I get into the packet that comes through the flow in the openvswitch
code. But I am not able to reach out to lib/packets.c even by tracing any
pre-defined action. I am stuck at function HMAP_FOR_EACH_WITH_HASH()
defined in lib/hmap.h and called at ofpact_raw_lookup() function in
ofp-actions.c. May be I am not able to understand the significance of hmap.
_______________________________________________
dev mailing list
dev <at> openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
William Tu | 6 Feb 05:04 2016
Picon

[PATCH v4] ovs-bugtool: Create OVN plugin and add output.

Create a new ovn/utilities/bugtool directory, add ovn.xml to bugtool
plugins, and add ovn-nbctl show, ovn-sbctl show, and ovn-sbctl
lflow-list.

Signed-off-by: William Tu <u9012063 <at> gmail.com>
---
v4:
fix the unmatched file names at ovn.xml to 
  ovn-bugtool-nbctl-show
  ovn-bugtool-sbctl-show
  ovn-bugtool-sbctl-lflow-list
---
 ovn/utilities/automake.mk                          |  2 ++
 ovn/utilities/bugtool/automake.mk                  |  9 +++++++++
 ovn/utilities/bugtool/ovn-bugtool-nbctl-show       | 19 ++++++++++++++++++
 ovn/utilities/bugtool/ovn-bugtool-sbctl-lflow-list | 19 ++++++++++++++++++
 ovn/utilities/bugtool/ovn-bugtool-sbctl-show       | 19 ++++++++++++++++++
 .../bugtool/plugins/network-status/ovn.xml         | 23 ++++++++++++++++++++++
 utilities/bugtool/automake.mk                      |  6 ++++--
 7 files changed, 95 insertions(+), 2 deletions(-)
 create mode 100644 ovn/utilities/bugtool/automake.mk
 create mode 100644 ovn/utilities/bugtool/ovn-bugtool-nbctl-show
 create mode 100644 ovn/utilities/bugtool/ovn-bugtool-sbctl-lflow-list
 create mode 100644 ovn/utilities/bugtool/ovn-bugtool-sbctl-show
 create mode 100644 ovn/utilities/bugtool/plugins/network-status/ovn.xml

diff --git a/ovn/utilities/automake.mk b/ovn/utilities/automake.mk
index afeb38f..d84368c 100644
--- a/ovn/utilities/automake.mk
+++ b/ovn/utilities/automake.mk
(Continue reading)

Jarno Rajahalme | 6 Feb 02:40 2016

[PATCH nf-next v7 0/7] openvswitch: NAT support.

This series adds NAT support to openvswitch kernel module.  A few
changes are needed to the netfilter code to facilitate this (patches
1-2/7).  Patches 3-6 make the openvswitch kernel module ready for the
patch 7 that adds the NAT support by calling into netfilter NAT code
from the openvswitch conntrack action.

This version addresses all the comments received on prior versions and
rebases to current nf-next.

The OVS master now has the corresponding OVS userspace support to use
and test the NAT features.  Below if a walk through of a simple use
case.

In this case ports 1 and 2 are in different namespaces.  The OpenFlow
table below only allows IPv4 connections initiated from port 1, and
applies source NAT to those connections:

   in_port=1,ip,action=ct(commit,zone=1,nat(src=10.1.1.240-10.1.1.255)),2
   in_port=2,ct_state=-trk,ip,action=ct(table=0,zone=1,nat)
   in_port=2,ct_state=+est,ct_zone=1,ip,action=1

This flow table matches all IPv4 traffic from port 1, runs them
through conntrack in zone 1 and NATs them.  The NAT is initialized to
do source IP mapping to the given range for the first packet of each
connection, after which the new connection is committed (confirmed).
For further packets of already tracked connections NAT is done
according to the connection state and the commit is a no-op.  Each
packet that is not flagged as a drop by the CT action is forwarded to
port 2.  The CT action does an implicit fragmentation reassembly, so
that only complete packets are run through conntrack.  Reassembled
(Continue reading)

Ben Pfaff | 6 Feb 01:02 2016

[PATCH] ovs-benchmark: Remove.

This utility was completely broken and no one noticed for the time of a
full release, so I think that's a safe sign that we should remove it.

Signed-off-by: Ben Pfaff <blp <at> ovn.org>
---
 NEWS                               |   2 +
 debian/openvswitch-common.install  |   1 -
 debian/openvswitch-common.manpages |   1 -
 rhel/openvswitch-fedora.spec.in    |   6 +-
 rhel/openvswitch.spec.in           |   4 +-
 utilities/.gitignore               |   2 -
 utilities/automake.mk              |   7 -
 utilities/ovs-benchmark.1.in       | 198 ------------
 utilities/ovs-benchmark.c          | 634 -------------------------------------
 xenserver/openvswitch-xen.spec.in  |   4 +-
 10 files changed, 6 insertions(+), 853 deletions(-)
 delete mode 100644 utilities/ovs-benchmark.1.in
 delete mode 100644 utilities/ovs-benchmark.c

diff --git a/NEWS b/NEWS
index c133838..3e33871 100644
--- a/NEWS
+++ b/NEWS
 <at>  <at>  -10,6 +10,8  <at>  <at>  Post-v2.5.0
    - DPDK:
      * New option "n_rxq" for PMD interfaces.
        Old 'other_config:n-dpdk-rxqs' is no longer supported.
+   - ovs-benchmark: This utility has been removed due to lack of use and
+     bitrot.

(Continue reading)

Ben Pfaff | 6 Feb 00:30 2016

[PATCH 1/3] ofproto-macros: Fix definition of add_of_ports.

This definition just didn't work, and caused lots of tests to inadvertently
be effectively skipped.

Signed-off-by: Ben Pfaff <blp <at> ovn.org>
---
 tests/ofproto-macros.at | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/ofproto-macros.at b/tests/ofproto-macros.at
index 354a384..c6c3321 100644
--- a/tests/ofproto-macros.at
+++ b/tests/ofproto-macros.at
 <at>  <at>  -338,8 +338,8  <at>  <at>  check_logs () {
 add_of_ports () {
     local args
     local br=$1; shift
-    for $pnum; do
-        AS_VAR_APPEND([args], [" -- $br p$pnum -- set Interface p$pnum type=dummy ofport_request=$pnum"])
+    for pnum; do
+        AS_VAR_APPEND([args], [" -- add-port $br p$pnum -- set Interface p$pnum type=dummy ofport_request=$pnum"])
     done
     ovs-vsctl $args
 }
--

-- 
2.1.3

_______________________________________________
dev mailing list
dev <at> openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
(Continue reading)

Ben Pfaff | 6 Feb 00:05 2016

[PATCH] ofproto-macros: Fix definition of add_of_ports.

This definition just didn't work, and caused lots of tests to inadvertently
be effectively skipped.

Signed-off-by: Ben Pfaff <blp <at> ovn.org>
---
 tests/ofproto-macros.at | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/ofproto-macros.at b/tests/ofproto-macros.at
index 354a384..c6c3321 100644
--- a/tests/ofproto-macros.at
+++ b/tests/ofproto-macros.at
 <at>  <at>  -338,8 +338,8  <at>  <at>  check_logs () {
 add_of_ports () {
     local args
     local br=$1; shift
-    for $pnum; do
-        AS_VAR_APPEND([args], [" -- $br p$pnum -- set Interface p$pnum type=dummy ofport_request=$pnum"])
+    for pnum; do
+        AS_VAR_APPEND([args], [" -- add-port $br p$pnum -- set Interface p$pnum type=dummy ofport_request=$pnum"])
     done
     ovs-vsctl $args
 }
--

-- 
2.1.3

_______________________________________________
dev mailing list
dev <at> openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
(Continue reading)

Han Zhou | 5 Feb 23:53 2016
Picon

[PATCH v3] ovn: Connect to remote lports through localnet port.

Before this patch, inter-chassis communication between VIFs of same
lswitch will always go through tunnel, which end up of modeling a
single physical network with many lswitches and pairs of lports, and
complexity in CMS like OpenStack neutron to manage the lswitches and
lports.

With this patch, inter-chassis communication can go through physical
networks via localnet port with a 1:1 mapping between lswitches and
physical networks. The pipeline becomes:

Ingress -> Egress (local) -> Ingress (remote) -> Egress

The original tunneling mechanism will still be used if there is no
localnet port configured on the lswitch.

Signed-off-by: Han Zhou <zhouhan <at> gmail.com>
---

Notes:
    v1->v2: rebase on master, and more updates on documents
    v2->v3: updated based on Russell's comments

 ovn/controller/binding.c        | 14 ++++-----
 ovn/controller/ovn-controller.c | 18 +++++------
 ovn/controller/ovn-controller.h | 10 ++++++
 ovn/controller/patch.c          | 17 +++++++++--
 ovn/controller/physical.c       | 67 ++++++++++++++++++++++++++++++++++++-----
 ovn/controller/physical.h       |  3 +-
 ovn/ovn-nb.xml                  | 13 ++++++--
 ovn/ovn-sb.xml                  |  5 ++-
(Continue reading)

Ben Pfaff | 5 Feb 23:20 2016

Re: [PATCH] [ovn-controller] [RFC] Poor man's lflow incremental processing

On Fri, Feb 05, 2016 at 03:41:24PM -0600, Ryan Moats wrote:
> Ben Pfaff <blp <at> ovn.org> wrote on 02/05/2016 01:01:56 PM:
> 
> > From: Ben Pfaff <blp <at> ovn.org>
> > To: Ryan Moats/Omaha/IBM <at> IBMUS
> > Cc: dev <at> openvswitch.org
> > Date: 02/05/2016 01:02 PM
> > Subject: Re: [ovs-dev] [PATCH] [ovn-controller] [RFC] Poor man's
> > lflow incremental processing
> >
> > On Wed, Feb 03, 2016 at 04:20:23PM -0600, RYAN D. MOATS wrote:
> > > Add incremental processing of lflows in ovn-controller by
> > > taking the simple approach of marking each lflow dirty when
> > > touched and have lflow_run only process dirty flows.
> > >
> > > This needs unit test code before the RFC tag comes off.
> > >
> > > Signed-off-by: RYAN D. MOATS <rmoats <at> us.ibm.com>
> >
> > I was envisioning something that would incrementally determine on a
> > per-flow basis whether anything needed to be recalculated.  Starting
> > with a per-logical-datapath approach, as this patch does, is a nice
> > place to start because it is presumably easier, so I think it's a good
> > idea.
> 
> I suspect we'll get to that point eventually, but I figured this would be
> easier to start with...
> 
> > I don't understand how this particular patch is going to make a
> > difference, though, since ldp_run() appears to always dirty every
(Continue reading)

Ben Pfaff | 5 Feb 23:18 2016

[PATCH] ovn-controller: Fix typo in comment.

Too much asss.

Signed-off-by: Ben Pfaff <blp <at> ovn.org>
---
 ovn/controller/lflow.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ovn/controller/lflow.c b/ovn/controller/lflow.c
index e586365..d53213c 100644
--- a/ovn/controller/lflow.c
+++ b/ovn/controller/lflow.c
 <at>  <at>  -285,7 +285,7  <at>  <at>  lflow_run(struct controller_ctx *ctx, struct hmap *flow_table,

     const struct sbrec_logical_flow *lflow;
     SBREC_LOGICAL_FLOW_FOR_EACH (lflow, ctx->ovnsb_idl) {
-        /* Find the "struct logical_datapath" asssociated with this
+        /* Find the "struct logical_datapath" associated with this
          * Logical_Flow row.  If there's no such struct, that must be because
          * no logical ports are bound to that logical datapath, so there's no
          * point in maintaining any flows for it anyway, so skip it. */
--

-- 
2.1.3

_______________________________________________
dev mailing list
dev <at> openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Ben Pfaff | 5 Feb 21:54 2016

[PATCH v4] vtep: Support per-tunnel tunnel key in schema.

From: Ofer Ben Yacov <ofer.benyacov <at> gmail.com>

Currently the scenario of single logical bridge that use multiple locators
with different tunnel key on each of the locators is not supported.
In order to support much more flexibility in the tunnel settings, we need
to add tunnel key column to the Physical_Locator table.

This patch is needed to support the usage of neutron L2GW as an inter-cloud
gateway. The tunnel key that is set in the logical bridge will be used
'internally' to connect the L2GW to the compute hosts and the key that
is set in the physical locator will be used to connect the L2GW to a
remote L2GW to form a tunnel between 2 clouds. In this case, the
'external' connection will use single 'dst_ip' on all the locators with
different tunnel key for each L2 domain.

The Neutron spec is available here:
	https://review.openstack.org/#/c/270786/
The new code depend on the ability to use different keys in multiple
tunnels in the same logical switch.

Signed-off-by: Ofer Ben-Yacov <ofer.benyacov <at> gmail.com>
[blp <at> ovn.org added and clarified documentation]
Signed-off-by: Ben Pfaff <blp <at> ovn.org>
---
 vtep/vtep.ovsschema |  9 +++++----
 vtep/vtep.xml       | 51 ++++++++++++++++++++++++++++++---------------------
 2 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/vtep/vtep.ovsschema b/vtep/vtep.ovsschema
index 1375173..cf3538f 100644
(Continue reading)


Gmane