[ovs-dev] [PATCH] ofproto-dpif-xlate: native tunnel using valid tun_src specified by flow or port options

[wenxu]

From: wenxu 

native tunnel build tunnel with tun_src only from the route src and
not care about the options:local_ip.
Sometimes an virtual IP using for tun_src
dpdk-br:
inet 10.1.1.7/24 brd 10.1.1.255 scope global dpdk-br
inet 10.1.1.254/32 scope global dpdk-br

Interface: gre  options: {key=flow, local_ip="10.1.1.254", remote_ip=flow}

the native tunnel always using 10.1.1.7 as the tunnel_src but not 10.1.1.254.

This patch made valid tun_src specified by flow-action or gre port options
can be used for tunnel_src of packet. It stores the rtm_type for each route
and improve the priority RTN_LOCAL type(higher then userdef route).
Like the kernel space when lookup the route, if there are tun_src specified
by flow-action or port options. Check the tun_src wheather is a local
address, then lookup the route.

Signed-off-by: wenxu 
Signed-off-by: frank.zeng 
---
 lib/ovs-router.c |   38 +++---
 lib/ovs-router.h |2 +-
 lib/route-table.c|   10 --
 ofproto/ofproto-dpif-sflow.c |2 +-
 ofproto/ofproto-dpif-xlate.c |4 
 5 files changed, 45 insertions(+), 11 deletions(-)

diff --git a/lib/ovs-router.c b/lib/ovs-router.c
index 0f1103b..e1375a3 100644
--- a/lib/ovs-router.c
+++ b/lib/ovs-router.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "classifier.h"
 #include "command-line.h"
@@ -61,6 +62,7 @@ struct ovs_router_entry {
 struct in6_addr nw_addr;
 struct in6_addr src_addr;
 uint8_t plen;
+uint8_t rtm_type;
 uint8_t priority;
 uint32_t mark;
 };
@@ -97,13 +99,28 @@ ovs_router_lookup(uint32_t mark, const struct in6_addr 
*ip6_dst,
 const struct cls_rule *cr;
 struct flow flow = {.ipv6_dst = *ip6_dst, .pkt_mark = mark};
 
+if (src && ipv6_addr_is_set(src)) {
+const struct cls_rule *cr_src;
+struct flow flow_src = {.ipv6_dst = *src, .pkt_mark = mark};
+
+cr_src = classifier_lookup(, OVS_VERSION_MAX, _src, NULL);
+if (cr_src) {
+struct ovs_router_entry *p_src = ovs_router_entry_cast(cr_src);
+if (p_src->rtm_type != RTN_LOCAL) {
+return false;
+}
+} else {
+return false;
+}
+}
+
 cr = classifier_lookup(, OVS_VERSION_MAX, , NULL);
 if (cr) {
 struct ovs_router_entry *p = ovs_router_entry_cast(cr);
 
 ovs_strlcpy(output_bridge, p->output_bridge, IFNAMSIZ);
 *gw = p->gw;
-if (src) {
+if (src && !ipv6_addr_is_set(src)) {
 *src = p->src_addr;
 }
 return true;
@@ -184,7 +201,7 @@ out:
 }
 
 static int
-ovs_router_insert__(uint32_t mark, uint8_t priority,
+ovs_router_insert__(uint32_t mark, uint8_t priority, uint8_t rtm_type,
 const struct in6_addr *ip6_dst,
 uint8_t plen, const char output_bridge[],
 const struct in6_addr *gw)
@@ -204,6 +221,7 @@ ovs_router_insert__(uint32_t mark, uint8_t priority,
 p->mark = mark;
 p->nw_addr = match.flow.ipv6_dst;
 p->plen = plen;
+p->rtm_type = rtm_type;
 p->priority = priority;
 err = get_src_addr(ip6_dst, output_bridge, >src_addr);
 if (err && ipv6_addr_is_set(gw)) {
@@ -236,9 +254,10 @@ ovs_router_insert__(uint32_t mark, uint8_t priority,
 
 void
 ovs_router_insert(uint32_t mark, const struct in6_addr *ip_dst, uint8_t plen,
-  const char output_bridge[], const struct in6_addr *gw)
+  uint8_t rtm_type, const char output_bridge[], 
+  const struct in6_addr *gw)
 {
-ovs_router_insert__(mark, plen, ip_dst, plen, output_bridge, gw);
+ovs_router_insert__(mark, plen, rtm_type, ip_dst, plen, output_bridge, gw);
 }
 
 static void
@@ -345,7 +364,7 @@ ovs_router_add(struct unixctl_conn *conn, int argc,
 }
 }
 
-err = ovs_router_insert__(mark, plen + 32, , plen, argv[2], );
+err = ovs_router_insert__(mark, plen + 32, RTN_UNICAST, , plen, 
argv[2], );
 if (err) {
 unixctl_command_reply_error(conn, "Error while inserting route.");
 } else {
@@ -402,7 +421,12 @@ ovs_router_show(struct unixctl_conn *conn, int argc 
OVS_UNUSED,
 ipv6_format_mapped(>nw_addr, );
 plen = rt->plen;
 if (IN6_IS_ADDR_V4MAPPED(>nw_addr)) {
-plen -= 96;
+uint8_t plen_off = 96;
+
+if (rt->rtm_type == RTN_LOCAL) {
+plen_off += 64;
+}
+plen -= plen_off;
 }
 ds_put_format(, "/%"PRIu8, plen);
 if (rt->mark) {
@@ -426,7 +450,7 @@ static void
 ovs_router_lookup_cmd(struct unixctl_conn *conn, int argc,
   const char *argv[], void *aux OVS_UNUSED)
 {
-struct in6_addr gw, src;
+struct in6_addr gw, src = in6addr_any;
 char iface[IFNAMSIZ];
 struct in6_addr ip6;
 unsigned int plen;
diff --git 

Re: [ovs-dev] [PATCH] Makefile.am: Use correct path separator for Windows

[Yi-Hung Wei]

Looks good to me.

Acked-by: Yi-Hung Wei 


On Thu, Feb 1, 2018 at 5:03 PM, Shashank Ram  wrote:
> Signed-off-by: Shashank Ram 
> ---
>  Makefile.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 5988c02..1d336b6 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -398,7 +398,7 @@ CLEANFILES += flake8-check
>
>  include $(srcdir)/manpages.mk
>  $(srcdir)/manpages.mk: $(MAN_ROOTS) build-aux/sodepends.py 
> python/build/soutil.py
> -   @PYTHONPATH=$$PYTHONPATH:$(srcdir)/python $(PYTHON) 
> $(srcdir)/build-aux/sodepends.py -I. -I$(srcdir) $(MAN_ROOTS) >$(@F).tmp
> +   @PYTHONPATH=$$PYTHONPATH$(psep)$(srcdir)/python $(PYTHON) 
> $(srcdir)/build-aux/sodepends.py -I. -I$(srcdir) $(MAN_ROOTS) >$(@F).tmp
> @if cmp -s $(@F).tmp $@; then \
>   touch $@; \
>   rm -f $(@F).tmp; \
> --
> 2.9.3.windows.2
>
> ___
> 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

[ovs-dev] [PATCH] ovn-controller: processing matches precedes processing action in logical flow.

[Guoshuai Li]

This is to fix such a problem:
When the match field has "is_chassis_resident", and the chassis has no resident,
and the action has meter or group, the group/meter ID is assigned.

I hope to parse match field with the first, if there is no matches field,
we do not need to deal with the action field.

Signed-off-by: Guoshuai Li 
---
 ovn/controller/lflow.c | 63 +-
 tests/ovn.at   | 15 +++-
 2 files changed, 51 insertions(+), 27 deletions(-)

diff --git a/ovn/controller/lflow.c b/ovn/controller/lflow.c
index 1e79a5355..0d4a3d6d5 100644
--- a/ovn/controller/lflow.c
+++ b/ovn/controller/lflow.c
@@ -254,31 +254,6 @@ consider_logical_flow(struct controller_ctx *ctx,
 return;
 }
 
-/* Encode OVN logical actions into OpenFlow. */
-uint64_t ofpacts_stub[1024 / 8];
-struct ofpbuf ofpacts = OFPBUF_STUB_INITIALIZER(ofpacts_stub);
-struct lookup_port_aux aux = {
-.ovnsb_idl = ctx->ovnsb_idl,
-.dp = lflow->logical_datapath
-};
-struct ovnact_encode_params ep = {
-.lookup_port = lookup_port_cb,
-.aux = ,
-.is_switch = is_switch(ldp),
-.is_gateway_router = is_gateway_router(ldp, local_datapaths),
-.group_table = group_table,
-.meter_table = meter_table,
-
-.pipeline = ingress ? OVNACT_P_INGRESS : OVNACT_P_EGRESS,
-.ingress_ptable = OFTABLE_LOG_INGRESS_PIPELINE,
-.egress_ptable = OFTABLE_LOG_EGRESS_PIPELINE,
-.output_ptable = output_ptable,
-.mac_bind_ptable = OFTABLE_MAC_BINDING,
-};
-ovnacts_encode(ovnacts.data, ovnacts.size, , );
-ovnacts_free(ovnacts.data, ovnacts.size);
-ofpbuf_uninit();
-
 /* Translate OVN match into table of OpenFlow matches. */
 struct hmap matches;
 struct expr *expr;
@@ -296,11 +271,16 @@ consider_logical_flow(struct controller_ctx *ctx,
 VLOG_WARN_RL(, "error parsing match \"%s\": %s",
  lflow->match, error);
 expr_destroy(prereqs);
-ofpbuf_uninit();
 free(error);
+ovnacts_free(ovnacts.data, ovnacts.size);
+ofpbuf_uninit();
 return;
 }
 
+struct lookup_port_aux aux = {
+.ovnsb_idl = ctx->ovnsb_idl,
+.dp = lflow->logical_datapath
+};
 struct condition_aux cond_aux = { ctx->ovnsb_idl, chassis, active_tunnels,
   chassis_index};
 expr = expr_simplify(expr, is_chassis_resident_cb, _aux);
@@ -309,6 +289,37 @@ consider_logical_flow(struct controller_ctx *ctx,
);
 expr_destroy(expr);
 
+if (hmap_is_empty()) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
+VLOG_WARN_RL(, " \"%s\": matches is empty", lflow->match);
+free(error);
+ovnacts_free(ovnacts.data, ovnacts.size);
+ofpbuf_uninit();
+expr_matches_destroy();
+return;
+}
+
+/* Encode OVN logical actions into OpenFlow. */
+uint64_t ofpacts_stub[1024 / 8];
+struct ofpbuf ofpacts = OFPBUF_STUB_INITIALIZER(ofpacts_stub);
+struct ovnact_encode_params ep = {
+.lookup_port = lookup_port_cb,
+.aux = ,
+.is_switch = is_switch(ldp),
+.is_gateway_router = is_gateway_router(ldp, local_datapaths),
+.group_table = group_table,
+.meter_table = meter_table,
+
+.pipeline = ingress ? OVNACT_P_INGRESS : OVNACT_P_EGRESS,
+.ingress_ptable = OFTABLE_LOG_INGRESS_PIPELINE,
+.egress_ptable = OFTABLE_LOG_EGRESS_PIPELINE,
+.output_ptable = output_ptable,
+.mac_bind_ptable = OFTABLE_MAC_BINDING,
+};
+ovnacts_encode(ovnacts.data, ovnacts.size, , );
+ovnacts_free(ovnacts.data, ovnacts.size);
+ofpbuf_uninit();
+
 /* Prepare the OpenFlow matches for adding to the flow table. */
 struct expr_match *m;
 HMAP_FOR_EACH (m, hmap_node, ) {
diff --git a/tests/ovn.at b/tests/ovn.at
index 734dc6c1d..1632a981b 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -5972,8 +5972,10 @@ ovn_start
 ovn-nbctl ls-add lsw0
 ovn-nbctl --wait=sb lsp-add lsw0 lp1
 ovn-nbctl --wait=sb lsp-add lsw0 lp2
+ovn-nbctl --wait=sb lsp-add lsw0 lp3
 ovn-nbctl lsp-set-addresses lp1 f0:00:00:00:00:01
 ovn-nbctl lsp-set-addresses lp2 f0:00:00:00:00:02
+ovn-nbctl lsp-set-addresses lp3 f0:00:00:00:00:03
 ovn-nbctl lsp-set-port-security lp1 f0:00:00:00:00:01
 ovn-nbctl lsp-set-port-security lp2 f0:00:00:00:00:02
 ovn-nbctl --wait=sb sync
@@ -6032,7 +6034,7 @@ AT_CHECK([get_final_nw_tos], [0], [none
 check_tos 0
 
 # Mark DSCP with a valid value
-qos_id=$(ovn-nbctl --wait=hv -- --id=@lp1-qos create QoS priority=100 
action=dscp=48 match="inport\=\=\"lp1\"" direction="from-lport" -- set 
Logical_Switch lsw0 qos_rules=@lp1-qos)
+qos_id=$(ovn-nbctl --wait=hv -- --id=@lp1-qos create QoS priority=100 
action=dscp=48 match="inport\=\=\"lp1\"\ &&\ is_chassis_resident(\"lp1\")" 

Re: [ovs-dev] [PATCH V3] rhel: Fix support for root user using DPDK

[Marcos Felipe Schwarz]

Is there any reason why they couldn't be the same?

One reason in favor is that the option for running ovs as a non-root user
can't be deactivated correctly by the means in the documentation [1]. It
states that setting OVS_USER_ID to 'root:root', or commenting the variable
out in /etc/sysconfig/openvswitch should revert the behavior back to normal.
The patch above enforces the expected behaviour without requiring
tinkering both
ovs-vswitchd and ovsdb-server systemd scripts to remove the "--user
OVS_USER_ID" parameter that is hardcoded.

[1] Non-root User Support:
https://github.com/openvswitch/ovs/blob/master/rhl/README.RHEL.rst

On Thu, Feb 1, 2018 at 10:23 PM, Ben Pfaff  wrote:

> OK, I understand now that the goal is that passing "--user $UID" should
> not call setuid() or setgid().  In that case, though, why pass the
> --user option at all?  I believe that, with this patch, "--user $UID"
> and "" yield equivalent behavior.
>
> Thanks,
>
> Ben.
>
> On Thu, Feb 01, 2018 at 09:34:12PM -0200, Marcos Felipe Schwarz wrote:
> > Hi Ben,
> >
> > I agree that the purpose of the canges was not cleared in the patch. The
> > full discussion is at
> > https://mail.openvswitch.org/pipermail/ovs-discuss/2018-
> January/046061.html.
> > But in a nutshell, this change is a fancy way to avoid the actual
> problem,
> > that's why it's not intuitive. The actual problem is the current method
> to
> > change the ovs user at (daemon_become_new_user_linux), drops the
> > CAP_SYS_ADMIN capability, even when you are "changing" from root to
> itself,
> > which occurs in rhel based distros when you use OVS_USER="root:toot". My
> > PoC solution [2] was to force the CAP_SYS_ADMIN during the user change,
> but
> > this would give more permission to openvswitch process than necessary on
> > most of the situations, for instance when DPDK and UIO are not required.
> > The fix in the current patch was proposed by Aaron [3], which involves to
> > avoid changing the user when it is already the desired user (and group),
> > this fixes the problem without the downsides of the initial solution and
> > avoids unnecessary calls.
> >
> > [2]
> > https://mail.openvswitch.org/pipermail/ovs-discuss/2018-
> January/045959.html
> > [3]
> > https://mail.openvswitch.org/pipermail/ovs-discuss/2018-
> January/045973.html
> > Regards,
> >
> > Marcos Schwarz
> >
> > On Thu, Feb 1, 2018 at 7:27 PM, Ben Pfaff  wrote:
> >
> > > On Thu, Feb 01, 2018 at 03:42:03PM -0200, Marcos Felipe Schwarz wrote:
> > > >  Since 2.8.0 OVS runs as non-root user on rhel distros, but the
> current
> > > > implementation breaks the ability to run as root with DPDK and as a
> > > > consequence there is no way possible to use UIO drivers on kernel
> 4.0 and
> > > > newer [1, 2].
> > > > [1] http://dpdk.org/browse/dpdk/commit/?id=cdc242f260e766
> > > > bd95a658b5e0686a62ec04f5b0
> > > > [2] https://www.kernel.org/doc/Documentation/vm/pagemap.txt
> > > >
> > > > Fixes: e3e738a3d058 ("redhat: allow dpdk to also run as non-root
> user")
> > > > Signed-off-by: Marcos Schwarz 
> > > > Acked-by: Aaron Conole 
> > >
> > > Thanks for the patch.
> > >
> > > I understand from the commit message the ultimate goal of this patch.
> I
> > > don't yet understand what change it is actually making.  In particular,
> > > what is the purpose of the following change; what does it do?
> > >
> > > > --- a/lib/daemon-unix.c
> > > > +++ b/lib/daemon-unix.c
> > > > @@ -1047,5 +1047,6 @@ daemon_set_new_user(const char *user_spec)
> > > >  }
> > > >  }
> > > >
> > > > -switch_user = true;
> > > > +if (!uid_verify(uid) || !gid_verify(gid))
> > > > +switch_user = true;
> > > >  }
> > >
> > > Thanks,
> > >
> > > Ben.
> > >
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] Makefile.am: Use correct path separator for Windows

[Shashank Ram]

Signed-off-by: Shashank Ram 
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 5988c02..1d336b6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -398,7 +398,7 @@ CLEANFILES += flake8-check
 
 include $(srcdir)/manpages.mk
 $(srcdir)/manpages.mk: $(MAN_ROOTS) build-aux/sodepends.py 
python/build/soutil.py
-   @PYTHONPATH=$$PYTHONPATH:$(srcdir)/python $(PYTHON) 
$(srcdir)/build-aux/sodepends.py -I. -I$(srcdir) $(MAN_ROOTS) >$(@F).tmp
+   @PYTHONPATH=$$PYTHONPATH$(psep)$(srcdir)/python $(PYTHON) 
$(srcdir)/build-aux/sodepends.py -I. -I$(srcdir) $(MAN_ROOTS) >$(@F).tmp
@if cmp -s $(@F).tmp $@; then \
  touch $@; \
  rm -f $(@F).tmp; \
-- 
2.9.3.windows.2

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

Re: [ovs-dev] deleting chassis doesn't delete the lport and lflows from northd

[Ben Pfaff]

On Tue, Jan 30, 2018 at 03:12:10PM -0800, Ali Gin wrote:
> Sorry for the typo. I thought devs would catch that. So to summarize, I was
> concerned about two issues:
> 
> 1. killing the compute/HV gracefully should have deleted the chassis from
> southbound db along with the bindings which did not happen

"kill" doesn't trigger ovn-controller to shut down gracefully.  If you
want it to remove its own chassis, you can use "ovs-appctl -t
ovn-controller exit".
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovn-northd: Do not add lflows in lr_in_arp_resolve stage for disabled logical ports

[Ben Pfaff]

On Thu, Oct 26, 2017 at 06:56:46AM +0530, Numan Siddique wrote:
> On Thu, Oct 26, 2017 at 2:59 AM, Ben Pfaff  wrote:
> 
> > On Wed, Sep 27, 2017 at 09:36:18PM +0530, nusid...@redhat.com wrote:
> > > From: Numan Siddique 
> > >
> > > ovn-northd is adding the below logical flow for a disabled logical port
> > (with mac M
> > > and IP 'A')
> > >
> > > table=6 (lr_in_arp_resolve  ), match=(outport == "lrp-port" && reg0 ==
> > 'A'),
> > > action=(eth.dst = 'M'; next;)
> > >
> > > In the case of openstack load balancer 'octavia' service, it creates
> > logical
> > > ports 'P1' (M1 IP1) and 'P2' (M2 IP2). It then disables logical port P2
> > and
> > > adds IP2 to P1 - (M1 IP1 IP2).
> > >
> > > When another port tries to reach IP2, it doesn't get delivered to port
> > P1 because
> > > of the above flow.
> > >
> > > Signed-off-by: Numan Siddique 
> >
> > Thanks a lot, I applied this to master.
> >
> > Please let me know if I should backport it to 2.8 (or earlier).
> >
> 
> Thanks for the review. It would be great if it can be backported to 2.8.

Apparently I forgot to ever do that, but I did it now.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH V3] rhel: Fix support for root user using DPDK

[Ben Pfaff]

OK, I understand now that the goal is that passing "--user $UID" should
not call setuid() or setgid().  In that case, though, why pass the
--user option at all?  I believe that, with this patch, "--user $UID"
and "" yield equivalent behavior.

Thanks,

Ben.

On Thu, Feb 01, 2018 at 09:34:12PM -0200, Marcos Felipe Schwarz wrote:
> Hi Ben,
> 
> I agree that the purpose of the canges was not cleared in the patch. The
> full discussion is at
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-January/046061.html.
> But in a nutshell, this change is a fancy way to avoid the actual problem,
> that's why it's not intuitive. The actual problem is the current method to
> change the ovs user at (daemon_become_new_user_linux), drops the
> CAP_SYS_ADMIN capability, even when you are "changing" from root to itself,
> which occurs in rhel based distros when you use OVS_USER="root:toot". My
> PoC solution [2] was to force the CAP_SYS_ADMIN during the user change, but
> this would give more permission to openvswitch process than necessary on
> most of the situations, for instance when DPDK and UIO are not required.
> The fix in the current patch was proposed by Aaron [3], which involves to
> avoid changing the user when it is already the desired user (and group),
> this fixes the problem without the downsides of the initial solution and
> avoids unnecessary calls.
> 
> [2]
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-January/045959.html
> [3]
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-January/045973.html
> Regards,
> 
> Marcos Schwarz
> 
> On Thu, Feb 1, 2018 at 7:27 PM, Ben Pfaff  wrote:
> 
> > On Thu, Feb 01, 2018 at 03:42:03PM -0200, Marcos Felipe Schwarz wrote:
> > >  Since 2.8.0 OVS runs as non-root user on rhel distros, but the current
> > > implementation breaks the ability to run as root with DPDK and as a
> > > consequence there is no way possible to use UIO drivers on kernel 4.0 and
> > > newer [1, 2].
> > > [1] http://dpdk.org/browse/dpdk/commit/?id=cdc242f260e766
> > > bd95a658b5e0686a62ec04f5b0
> > > [2] https://www.kernel.org/doc/Documentation/vm/pagemap.txt
> > >
> > > Fixes: e3e738a3d058 ("redhat: allow dpdk to also run as non-root user")
> > > Signed-off-by: Marcos Schwarz 
> > > Acked-by: Aaron Conole 
> >
> > Thanks for the patch.
> >
> > I understand from the commit message the ultimate goal of this patch.  I
> > don't yet understand what change it is actually making.  In particular,
> > what is the purpose of the following change; what does it do?
> >
> > > --- a/lib/daemon-unix.c
> > > +++ b/lib/daemon-unix.c
> > > @@ -1047,5 +1047,6 @@ daemon_set_new_user(const char *user_spec)
> > >  }
> > >  }
> > >
> > > -switch_user = true;
> > > +if (!uid_verify(uid) || !gid_verify(gid))
> > > +switch_user = true;
> > >  }
> >
> > Thanks,
> >
> > Ben.
> >
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 3/3] xlate: call tnl_neigh_snoop() from terminate_native_tunnel()

[Justin Pettit]

I wasn't able to get this patch to apply to the tip of master.  Zoltan, can you 
rebase this patch and repost?  

The main thing my patch series does is make it so that packets that have a 
controller action aren't processed entirely in userspace.  If, for example, the 
patches expect packets to be in userspace without an explicit slow-path request 
when generating the datapath flow, then that would be a problem.

--Justin


> On Feb 1, 2018, at 2:17 PM, Ben Pfaff  wrote:
> 
> Justin, I think this is mainly a question about your patches, can you
> take a look?
> 
> On Fri, Jan 26, 2018 at 01:08:35PM +, Zoltán Balogh wrote:
>> Hi,
>> 
>> I've been investigating the failing unit test. I can confirm, it does fail
>> with my series on master. However, when I created the series and sent it to
>> the mailing list it did not. 
>> 
>> I've rebased my series to this commit before I sent it to the mailing list.
>>  commit f59cb331c481d08f9a851c07cf31e9d826650485
>>  Author: Yi Yang 
>>  Date:   Sat Jan 6 13:47:51 2018 +0800
>> 
>> If I apply the series to the commit below, the test does pass.
>> 
>> So, I started to search for any commits between the one from Yi Yang and the 
>> Last one on master which could make my series fail on the OVN unit test 
>> "/32 router IP address".
>> 
>> I found, that reverting the series of two commits from Justin Pettit below,
>> makes my series pass the unit test again. Even rebased to master.
>> 
>>  commit 74c4530dca939109f3fb79776b60b8722e149738
>>  Author: Justin Pettit 
>>  Date:   Wed Oct 18 23:16:22 2017 -0700
>> 
>>  ofproto-dpif: Don't slow-path controller actions with pause.
>> 
>>  A previous patch removed slow-pathing for controller actions with the
>>  exception of ones that specified "pause".  This commit removes that
>>  restriction so that no controller actions are slow-pathed.
>> 
>>  Signed-off-by: Justin Pettit 
>>  Acked-by: Ben Pfaff 
>> 
>>  commit d39ec23de38464ee35b3098b9f6c5f06d5191015
>>  Author: Justin Pettit 
>>  Date:   Wed Jul 5 15:17:52 2017 -0700
>> 
>>  ofproto-dpif: Don't slow-path controller actions.
>> 
>>  Controller actions have become more commonly used for purposes other
>>  than just making forwarding decisions (e.g., packet logging).  A packet
>>  that needs to be copied to the controller and forwarded would always be
>>  sent to ovs-vswitchd to be handled, which could negatively affect
>>  performance and cause heavier CPU utilization in ovs-vswitchd.
>> 
>>  This commit changes the behavior so that OpenFlow controller actions
>>  become userspace datapath actions while continuing to let packet
>>  forwarding and manipulation continue to be handled by the datapath
>>  directly.
>> 
>>  This patch still slow-paths controller actions with the "pause" flag
>>  set.  A future patch will stop slow-pathing these pause actions as
>>  well.
>> 
>>  Signed-off-by: Justin Pettit 
>>  Acked-by: Ben Pfaff 
>> 
>> The main difference, my series does compared to master, is not putting the 
>> ARP entry of {10.0.0.2, f0:00:00:01:02:04, br-int} into tunnel neighbor 
>> cache. All the OF rules are almost the same, except loading different 
>> numbers into NXM_NX_REGx and using different metadata. 
>> 
>> How should this be related to Justin's series?
>> 
>> If I modify the unit test and populate the missing ARP entry then the test 
>> does pass.
>> 
>> Should this entry be present in the ARP neighbor cache in order to make the
>> test pass? If yes, then why? 
>> 
>> Best regards,
>> Zoltan
>> 
>>> -Original Message-
>>> From: Ben Pfaff [mailto:b...@ovn.org]
>>> Sent: Tuesday, January 23, 2018 8:02 PM
>>> To: Zoltán Balogh 
>>> Cc: d...@openvswitch.org; Jan Scheurich 
>>> Subject: Re: [ovs-dev] [PATCH v3 3/3] xlate: call tnl_neigh_snoop() from 
>>> terminate_native_tunnel()
>>> 
>>> On Tue, Jan 09, 2018 at 07:54:33PM +0100, Zoltan Balogh wrote:
 Currenlty, OVS snoops any ARP or ND packets in any bridge and populates
 the tunnel neighbor cache with the retreived data. For instance, when
 ARP reply originated by a tenant is received in an overlay bridge, the
 ARP message is snooped and tunnel neighbor cache is filled with tenant
 data, however only tunnel neighbor data should be stored there.
 
 This patch moves tunnel neighbor snooping from do_xlate_actions() to
 terminate_native_tunnel() where native tunnel is terminated, in order to
 keep ARP neighbor cache clean, i.e. only packets comming from a native
 tunnel are snooped.
 
 By applying the patch, only ARP and Neighbor Advertisement messages
 addressing a tunnel endpoint (LOCAL port of underlay bridge) are
 snooped. In order to achieve this, IP addresses of the bridge are

Re: [ovs-dev] [PATCH] Ofproto: fix the bug wrong datapath flow with same in_port and output port was generated

[Ben Pfaff]

Thanks for the extra commentary.  It sounds like you see some spots that
we missed, but I don't understand that yet--can you explain further, or
send a patch?

Thanks,

Ben.

On Tue, Jan 23, 2018 at 12:33:08PM +0800, Huanle Han wrote:
> I have done a similar fix few months ago. The commit tries to avoid an
> inconsistent result caused by using different xcfg pointers.
> https://github.com/openvswitch/ovs/pull/210/commits/ec75e8d9bb0e16690447b40b39d2fd0fb0f7aae2
> 
> I think a few more place fixes needed for this patch:
>   update_mcast_snooping_table()
>   xlate_normal_mcast_send_group()
>   xlate_normal_mcast_send_mrouters()
>   xlate_normal_mcast_send_fports()
> 
> > Thank you for the analysis and the fix!  I applied this to master and
> > backported as far as branch-2.8.
> >
> > On Fri, Jan 19, 2018 at 08:12:30AM +, Lilijun (Jerry) wrote:
> >> Hi all,
> >>
> >> In my test, the new datapath flow which has the same in_port and actions 
> >> output port was found using ovs-appctl dpctl/dump-flows.
> >> Then the mac address will move from one port to another and back it again 
> >> in the physical switch. This problem result in the VM's traffic become 
> >> abnormal.
> >>
> >> My test key steps:
> >> 1) There are three VM using ovs bridge and intel 82599 nics as uplink 
> >> port, deployed in different hosts connecting to the same physical switch. 
> >> They can be named using VM-A, VM-B and VM-C, Host-A, Host-B, Host-C.
> >> 2) VM-A send many unicast packets to VM-B, and VM-B also send unicast 
> >> packets to VM-A.
> >> 3) VM-C ping VM-A continuously, and do ovs port add/delete testing in 
> >> Host-C ovs bridge.
> >> 4) In some abormal scence, the physical switch clear all the mac-entry 
> >> on each ports. Then Host-C ovs bridge's uplink port will receive two 
> >> direction packets(VM-A to VM-B, and VM-B to VM-A).
> >>
> >> The expected result is that this two direction packets should be droppd in 
> >> the uplink port. Because the dst port of this packets is the uplink port 
> >> which is also the src port by looking ovs bridge's mac-entry table learned 
> >> by ovs NORMAL rules.
> >> But the truth is some packets being sent back to uplink port and physical 
> >> switch. And then VM-A's mac was moved to the physical switch port of 
> >> Host-C from the port of Host-A, as a reulst, VM-C ping VM-A failed at this 
> >> time.
> >> When this problem occurs, the abnormal ovs datapath's flow "in_port(2) 
> >> actions:2" was found by executing the command "ovs-appctl 
> >> dpctl/dump-flows".
> >>
> >> Currently, xlate_normal() uses xbundle pointer compare to verify the 
> >> packet's dst port whether is same with its input port. This implemention 
> >> may be wrong while calling xlate_txn_start/xlate_txn_commit in type_run() 
> >> at the same time,
> >> because xcfg/xbridge/xbundle object was reallocated and copied just before 
> >> we lookup the dst mac_port and mac_xbundle. Then mac_xbundle and 
> >> in_xbundle are same related with the uplink port but not same object 
> >> pointer.
> >>
> >> And we can fix this bug by adding ofbundle check conditions shown in my 
> >> patch.
> >>
> >> Signed-off-by: Lilijun 
> >>
> >>
> >> diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> >> index d94e9dc..b7a8b55 100644
> >> --- a/ofproto/ofproto-dpif-xlate.c
> >> +++ b/ofproto/ofproto-dpif-xlate.c
> >> @@ -2604,7 +2604,9 @@ xlate_normal_mcast_send_rports(struct xlate_ctx *ctx,
> >>  xcfg = ovsrcu_get(struct xlate_cfg *, );
> >>  LIST_FOR_EACH(rport, node, >rport_list) {
> >>  mcast_xbundle = xbundle_lookup(xcfg, rport->port);
> >> -if (mcast_xbundle && mcast_xbundle != in_xbundle) {
> >> +if (mcast_xbundle
> >> +&& mcast_xbundle != in_xbundle
> >> +&& mcast_xbundle->ofbundle != in_xbundle->ofbundle) {
> >>  xlate_report(ctx, OFT_DETAIL,
> >>   "forwarding report to mcast flagged port");
> >>  output_normal(ctx, mcast_xbundle, xvlan);
> >> @@ -2626,6 +2628,7 @@ xlate_normal_flood(struct xlate_ctx *ctx, struct 
> >> xbundle *in_xbundle,
> >>  LIST_FOR_EACH (xbundle, list_node, >xbridge->xbundles) {
> >>  if (xbundle != in_xbundle
> >> +&& xbundle->ofbundle != in_xbundle->ofbundle
> >>  && xbundle_includes_vlan(xbundle, xvlan)
> >>  && xbundle->floodable
> >>  && !xbundle_mirror_out(ctx->xbridge, xbundle)) {
> >> @@ -2833,7 +2836,9 @@ xlate_normal(struct xlate_ctx *ctx)
> >>  if (mac_port) {
> >>  struct xlate_cfg *xcfg = ovsrcu_get(struct xlate_cfg *, 
> >> );
> >>  struct xbundle *mac_xbundle = xbundle_lookup(xcfg, mac_port);
> >> -if (mac_xbundle && mac_xbundle != in_xbundle) {
> >> +if (mac_xbundle
> >> +&& mac_xbundle != in_xbundle
> >> +&& mac_xbundle->ofbundle != in_xbundle->ofbundle) {
> >>  

Re: [ovs-dev] [PATCH v3 0/6] Add minimum network namespace support.

[Ben Pfaff]

On Fri, Jan 26, 2018 at 04:23:44PM -0200, Flavio Leitner wrote:
> Hi Ben,
> 
> 
> On Wed, Jan 10, 2018 at 04:07:38PM -0800, Ben Pfaff wrote:
> > Thanks for the series.  I actually think that it's pretty close.  For
> > me, this series falls into the category of "obviously the right
> > direction but impossible to fully validate before applying it".  It
> > builds fine and I was about to push it when I realized that it breaks
> > most of the unit tests with failures like:
> > 
> > --- /dev/null   2017-07-26 15:46:07.674034656 -0700
> > +++ /home/blp/nicira/ovs/_build/tests/testsuite.dir/at-groups/3/stdout  
> > 2018-01-10 16:03:35.309361001 -0800
> > @@ -0,0 +1 @@
> > +2018-01-11T00:03:35Z|7|dpif_netlink|WARN|Generic Netlink family 
> > 'ovs_datapath' does not exist. The Open vSwitch kernel module is probably 
> > not loaded.
> > 
> > The unit tests are supposed to work without the kernel module loaded (I
> > run them on a system that doesn't even have the module).  Previously
> > they didn't even try to interact with the kernel module and now clearly
> > they do.  Can you figure out how that changed?  It would be best to fix
> > it.
> 
> 
> When bridge is running, it will try to initialize the routing table
> and for that it will try get interface's flags (lo, NICs), or the addr
> list.  Both interfaces are now using netlink messages to find out if the
> interface is in the local network namespace or not[1] and that's when the
> netlink is initialized. If you don't have the module, the warn message
> is printed.
> 
> This patchset relies on netlink messages anyways to keep track of the
> interfaces, so it is preferred. It falls back to the old interfaces
> only if the kernel is not recent enough though.
> 
> One possible way to fix this is to try the old interface first and fall
> back to netlink only if that fails.  That's not ideal because we would
> need to keep track of return codes indicating the device is not in the
> local network namespace, or blindly try it again.  Another thing to
> consider is that we might be able to remove the old interface and only
> use netlink in the future to simplify the code.
> 
> It doesn't sound like a good idea to remove that message as it has value.
> 
> I can fix the testsuite vswitchd initialization to ignore that message,
> but after each test is completed, the testsuite checks for WARN messages
> and fails if there is one in the logs.
> 
> Ben, any thoughts? I don't know how bad it is to add a dependency to
> openvswitch module to decide whether the patchset must address that or
> if it's okay to fix the testsuite.
> 
> 
> [1] 
> netdev_linux_netnsid_is_remote
>  +- netdev_linux_netnsid_update__
>   +- dpif_netlink_vport_get
> (this uses openvswitch's  vport get cmd)

I see the following possibilities here.

* Do something to keep the code from trying to load the module.  It
  sounds like this is difficult or undesirable.

* Remove the message.  It has value since when it shows up in logs I can
  tell the user that's the problem.

* Downgrade the message to INFO level.  Maybe that is the right solution
  since now it's going to appear even if the user doesn't really need
  it, making it not anything to really warn about anymore.

* Ignore this message, too, in check_logs in tests/ofproto-macros.at.

* Downgrade the message to DBG level at the current point it's issued,
  but then issue it at WARN level later in dpif_netlink_open() since
  that's the place where it's clear that the user is trying to use
  something that's unavailable.

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

Re: [ovs-dev] [PATCH v3 3/3] xlate: call tnl_neigh_snoop() from terminate_native_tunnel()

[Ben Pfaff]

Justin, I think this is mainly a question about your patches, can you
take a look?

On Fri, Jan 26, 2018 at 01:08:35PM +, Zoltán Balogh wrote:
> Hi,
> 
> I've been investigating the failing unit test. I can confirm, it does fail
> with my series on master. However, when I created the series and sent it to
> the mailing list it did not. 
> 
> I've rebased my series to this commit before I sent it to the mailing list.
>   commit f59cb331c481d08f9a851c07cf31e9d826650485
>   Author: Yi Yang 
>   Date:   Sat Jan 6 13:47:51 2018 +0800
> 
> If I apply the series to the commit below, the test does pass.
> 
> So, I started to search for any commits between the one from Yi Yang and the 
> Last one on master which could make my series fail on the OVN unit test 
> "/32 router IP address".
> 
> I found, that reverting the series of two commits from Justin Pettit below,
> makes my series pass the unit test again. Even rebased to master.
> 
>   commit 74c4530dca939109f3fb79776b60b8722e149738
>   Author: Justin Pettit 
>   Date:   Wed Oct 18 23:16:22 2017 -0700
> 
>   ofproto-dpif: Don't slow-path controller actions with pause.
>   
>   A previous patch removed slow-pathing for controller actions with the
>   exception of ones that specified "pause".  This commit removes that
>   restriction so that no controller actions are slow-pathed.
>   
>   Signed-off-by: Justin Pettit 
>   Acked-by: Ben Pfaff 
> 
>   commit d39ec23de38464ee35b3098b9f6c5f06d5191015
>   Author: Justin Pettit 
>   Date:   Wed Jul 5 15:17:52 2017 -0700
> 
>   ofproto-dpif: Don't slow-path controller actions.
>   
>   Controller actions have become more commonly used for purposes other
>   than just making forwarding decisions (e.g., packet logging).  A packet
>   that needs to be copied to the controller and forwarded would always be
>   sent to ovs-vswitchd to be handled, which could negatively affect
>   performance and cause heavier CPU utilization in ovs-vswitchd.
>   
>   This commit changes the behavior so that OpenFlow controller actions
>   become userspace datapath actions while continuing to let packet
>   forwarding and manipulation continue to be handled by the datapath
>   directly.
>   
>   This patch still slow-paths controller actions with the "pause" flag
>   set.  A future patch will stop slow-pathing these pause actions as
>   well.
>   
>   Signed-off-by: Justin Pettit 
>   Acked-by: Ben Pfaff 
> 
> The main difference, my series does compared to master, is not putting the 
> ARP entry of {10.0.0.2, f0:00:00:01:02:04, br-int} into tunnel neighbor 
> cache. All the OF rules are almost the same, except loading different 
> numbers into NXM_NX_REGx and using different metadata. 
> 
> How should this be related to Justin's series?
> 
> If I modify the unit test and populate the missing ARP entry then the test 
> does pass.
> 
> Should this entry be present in the ARP neighbor cache in order to make the
> test pass? If yes, then why? 
> 
> Best regards,
> Zoltan
> 
> > -Original Message-
> > From: Ben Pfaff [mailto:b...@ovn.org]
> > Sent: Tuesday, January 23, 2018 8:02 PM
> > To: Zoltán Balogh 
> > Cc: d...@openvswitch.org; Jan Scheurich 
> > Subject: Re: [ovs-dev] [PATCH v3 3/3] xlate: call tnl_neigh_snoop() from 
> > terminate_native_tunnel()
> > 
> > On Tue, Jan 09, 2018 at 07:54:33PM +0100, Zoltan Balogh wrote:
> > > Currenlty, OVS snoops any ARP or ND packets in any bridge and populates
> > > the tunnel neighbor cache with the retreived data. For instance, when
> > > ARP reply originated by a tenant is received in an overlay bridge, the
> > > ARP message is snooped and tunnel neighbor cache is filled with tenant
> > > data, however only tunnel neighbor data should be stored there.
> > >
> > > This patch moves tunnel neighbor snooping from do_xlate_actions() to
> > > terminate_native_tunnel() where native tunnel is terminated, in order to
> > > keep ARP neighbor cache clean, i.e. only packets comming from a native
> > > tunnel are snooped.
> > >
> > > By applying the patch, only ARP and Neighbor Advertisement messages
> > > addressing a tunnel endpoint (LOCAL port of underlay bridge) are
> > > snooped. In order to achieve this, IP addresses of the bridge are
> > > retrieved and then stored in xbridge by calling xlate_xbridge_set().
> > > These data is then matched against the data extracted from an ARP or
> > > Neighbor Advertisement message in is_neighbor_reply_correct() which is
> > > invoked from terminate_native_tunnel().
> > >
> > > Signed-off-by: Zoltan Balogh 
> > 
> > Thanks a lot!
> > 
> > It appears to me that this patch makes the following test consistently
> > fail.  When I revert the test, it passes for 

Re: [ovs-dev] [PATCH] ofproto-dpif: Delete system tunnel interface when remove ovs bridge

[Ben Pfaff]

On Thu, Jan 25, 2018 at 09:22:56AM -0500, Eric Garver wrote:
> On Wed, Jan 24, 2018 at 12:48:38PM -0800, Ben Pfaff wrote:
> > On Wed, Jan 24, 2018 at 09:31:32AM -0500, Eric Garver wrote:
> > > On Tue, Jan 23, 2018 at 07:46:47PM -0800, Ben Pfaff wrote:
> > > > On Thu, Oct 26, 2017 at 10:24:46AM -0400, Eric Garver wrote:
> > > > > On Wed, Oct 25, 2017 at 11:41:27AM +0800, ju...@redhat.com wrote:
> > > > > > When there is only one bridge,create tunnel in the bridge,
> > > > > > then delete the bridge directly. the system tunnel interface
> > > > > > still in.
> > > > > > 
> > > > > > Cause of only one bridge, backer->refcount values 1, when
> > > > > > delete bridge, "close_dpif_backer" will delete the backer,
> > > > > > so type_run will return directly, doesn't delete the interface.
> > > > > > This patch delete the system interface before free the backer.
> > > > > 
> > > > > I'll add a bit more explanation..
> > > > > 
> > > > > This occurs when a tunnel is created with rtnetlink. With the compat 
> > > > > API
> > > > > the tunnel is created via the vport tunnel interface, so it can be
> > > > > implicitly cleaned up by the kernel when the dp is closed or the 
> > > > > module
> > > > > unloaded.  But with rtnetlink the kernel module is not involved with 
> > > > > the
> > > > > tunnel device creation (it's added to OVS as a netdev vport), so
> > > > > userspace needs to explicitly clean up the tunnel backers - type_run
> > > > > can't garbage collect them if the dpif is already deleted.
> > > > 
> > > > I guess this has been due to be applied for a long time!  I am sorry
> > > > that I missed it.
> > > > 
> > > > The code looks OK but I don't yet understand the consequences.  What
> > > > problem does this patch solve?
> > > > 
> > > 
> > > Bugzilla reference:
> > > 
> > >   https://bugzilla.redhat.com/show_bug.cgi?id=1505776
> > > 
> > > IIRC, there is a race between close_dpif_backer() and tnl_backers
> > > garbage collection which is done in the "if (backer->need_revalidate)"
> > > block of type_run(). Non-tunnel port types are immediately cleaned up by
> > > port_del(), but tunnel ports are only cleaned up during dpif
> > > revalidation. My theory is that we never noticed it in the compat
> > > interface because the openvswitch kernel module implicitly cleans up all
> > > the interfaces when the dpif is closed. In the rtnetlink case, the
> > > tunnel interfaces are created by OVS process not the openvswitch kernel
> > > module, so it doesn't know about them.
> > > 
> > > I think this may also be closing a tunnel port memory leak that occurs
> > > for both compat and rtnetlink when deleting the dpif backer. This occurs
> > > since the tunnel ports weren't garbage collected before the dpif backer
> > > disappeared.
> > > 
> > > Sorry if my explanation isn't that good. I'm not all that familiar with
> > > this code.
> > 
> > OK, thanks.
> > 
> > Is the following a fair description for the commit message?
> > 
> > When a user adds the first tunnel of a given type (e.g. the
> > first VXLAN tunnel) to an OVS bridge, OVS adds a vport of the
> > same type to the kernel datapath that backs the bridge.  There
> > is the corresponding expectation that, when the last tunnel of
> > that type is removed from the OVS bridges, OVS would remove the
> > vport that represents it from the backing kernel datapath, but
> > OVS was not doing that.  This commit fixes the problem.
> > 
> > What isn't clear to me is the higher-level consequence of failing to
> > delete the kernel datapath vport.  The bugzilla report doesn't say and I
> > don't see anything else that does.  Can anyone help me out?  I'm willing
> 
> short answer: I don't think there is any major concern about the
> lingering tunnel interface.
> 
> Longer answer follows:
> 
> The rtnetlink create will attempt to reuse a tunnel interface if it
> already exists. If that interface has the wrong parameters we attempt to
> delete and recreate it. So the lingering kernel interface is a non-issue
> for OVS. However, OVS shouldn't leave the interface hanging around if
> it's not using it anymore (this is what this patch fixes).
> 
> Tunnels created via rtnetlink are attached to the openvswitch kernel
> module by NETDEV vports. When the backer is closed those NETDEV vports
> are cleaned up by the kernel module. As such, they are disconnected from
> OVS so we won't get any wild packets appearing.
> 
> > to apply this patch without that information, but having it would allow
> > me to better understand the importance of the fix.
> 
> Thanks Ben.

Thanks for the extra info.  I applied this to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/1] debian: Do not modify pre-existing defaults file

[Ben Pfaff]

On Tue, Oct 17, 2017 at 04:29:40PM +0200, Frode Nordahl wrote:
> Currently, on installation or upgrade the openvswitch-switch deb package
> will in some circumstances modify a pre-existing
> /etc/default/openvswitch-switch configuration file.
> 
> This does not play well with modeling and configuration management tools
> and may lead to unnecessary restarts of the openvswitch-switch service
> after the initial restart done as part of the package upgrade. As
> restarting the openvswitch-switch affects the datapath this is
> something we should try to avoid.
> 
> I also believe the current behaviour to be in conflict with best practices
> set out in the config files section of the
> [Debian Policy](https://www.debian.org/doc/debian-policy/#s-config-files).
> 
> This commit addresses this by removing the part of the postinst script
> that attempts to append missing documentation parts of the template
> and leaves the installed defaults file alone when it exists.
> 
> Signed-off-by: Frode Nordahl 
> Reported-at: https://github.com/openvswitch/ovs-issues/issues/137

Thanks, this code was added in 2009 with the following commit.  It's
clearly past its "sell-by" date, so I applied your patch to OVS master.

commit 0aaa379d99f4fb48eb34b1ea5858b0954a5f8c8d
Author: Ben Pfaff 
Date:   Tue Jan 20 13:33:44 2009 -0800

Debian packaging: Add several new settings to /etc/default/openflow-switch.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovn-nbctl: Add QoS commands.

[Ben Pfaff]

On Fri, Jan 26, 2018 at 04:34:39PM +0800, Guoshuai Li wrote:
> This patch provides the command line to add/delete/list QoS rule on the
> logical switch.
> 
> Signed-off-by: Guoshuai Li 

Thanks!  Applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Cómo ser feliz en mi trabajo

[Aumente la productividad y rentabilidad]

 
Cómo ser feliz en mi trabajo
Febrero 21 - webinar Interactivo

Introducción:

Arturo Villegas es Conferencista Internacional, habiendo impartido más de 600 
conferencias en más de 10 años de trayectoria profesional. Es pionero y experto 
en el tema de la felicidad laboral aplicada a la productividad, y creó el 
programa educativo online más grande jamás hecho en Latinoamérica sobre cómo 
ser más felices para ser más productivos en las organizaciones.

Que ganarás con este webinar:
Renovar tu pasión y vocación para sentirte orgulloso de tu trabajo, tu empresa, 
tu jefe y colaboradores.
 Combatir positivamente situaciones estresantes para no dejarte llevar por la 
desmotivación. 
Orientarte sobre cómo la felicidad te puede ayudar a vivir una vida más plena y 
en bienestar.
  
 
Temario e Inscripciones:

Respondiendo por este medio "Trabajo"+TELÉFONO + NOMBRE o marcando al:

045 + 5515546630  



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

Re: [ovs-dev] [PATCH] tests: Make OVS_WAIT_UNTIL and OVS_WAIT_WHILE failures easier to debug.

[Ben Pfaff]

Thanks for the review!  I applied this to master.

On Thu, Feb 01, 2018 at 01:30:46PM -0800, Yifeng Sun wrote:
> Thanks for the change.
> 
> Tested-by: Yifeng Sun 
> 
> Reviewed-by: Yifeng Sun 
> 
> On Thu, Feb 1, 2018 at 10:08 AM, Ben Pfaff  wrote:
> 
> > Until now, when OVS_WAIT_UNTIL or OVS_WAIT_WHILE ran, little information
> > was available: usually nothing at all in the log, unless the wait failed,
> > in which case there was a line number.  This commit adds a note saying
> > what is being waited for in any case, and a message saying that the wait
> > failed if it does.
> >
> > Signed-off-by: Ben Pfaff 
> > ---
> >  tests/ovs-macros.at | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
> > index 324fdc887f78..f3ab3548a7fe 100644
> > --- a/tests/ovs-macros.at
> > +++ b/tests/ovs-macros.at
> > @@ -239,11 +239,13 @@ fi
> >  m4_divert_pop([PREPARE_TESTS])
> >
> >  m4_define([OVS_WAIT], [dnl
> > +AS_ECHO(["AS_ESCAPE([$3: waiting $4...])"]) >_MESSAGE_LOG_FD
> >  ovs_wait_cond () {
> >  $1
> >  }
> >  if ovs_wait; then :
> >  else
> > +AS_ECHO(["AS_ESCAPE([$3: wait failed])"]) >_MESSAGE_LOG_FD
> >  $2
> >  AT_FAIL_IF([:])
> >  fi
> > @@ -255,7 +257,8 @@ dnl Executes shell COMMAND in a loop until it returns
> >  dnl zero return code.  If COMMAND did not return
> >  dnl zero code within reasonable time limit, then
> >  dnl the test fails.
> > -m4_define([OVS_WAIT_UNTIL], [OVS_WAIT([$1], [$2])])
> > +m4_define([OVS_WAIT_UNTIL],
> > +  [OVS_WAIT([$1], [$2], [AT_LINE], [until $1])])
> >
> >  dnl OVS_WAIT_WHILE(COMMAND)
> >  dnl
> > @@ -264,7 +267,8 @@ dnl non-zero return code.  If COMMAND did not return
> >  dnl non-zero code within reasonable time limit, then
> >  dnl the test fails.
> >  m4_define([OVS_WAIT_WHILE],
> > -  [OVS_WAIT([if $1; then return 1; else return 0; fi], [$2])])
> > +  [OVS_WAIT([if $1; then return 1; else return 0; fi], [$2],
> > +[AT_LINE], [while $1])])
> >
> >  dnl OVS_APP_EXIT_AND_WAIT(DAEMON)
> >  dnl
> > --
> > 2.15.1
> >
> > ___
> > 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] tests: Make OVS_WAIT_UNTIL and OVS_WAIT_WHILE failures easier to debug.

[Yifeng Sun]

Thanks for the change.

Tested-by: Yifeng Sun 

Reviewed-by: Yifeng Sun 

On Thu, Feb 1, 2018 at 10:08 AM, Ben Pfaff  wrote:

> Until now, when OVS_WAIT_UNTIL or OVS_WAIT_WHILE ran, little information
> was available: usually nothing at all in the log, unless the wait failed,
> in which case there was a line number.  This commit adds a note saying
> what is being waited for in any case, and a message saying that the wait
> failed if it does.
>
> Signed-off-by: Ben Pfaff 
> ---
>  tests/ovs-macros.at | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
> index 324fdc887f78..f3ab3548a7fe 100644
> --- a/tests/ovs-macros.at
> +++ b/tests/ovs-macros.at
> @@ -239,11 +239,13 @@ fi
>  m4_divert_pop([PREPARE_TESTS])
>
>  m4_define([OVS_WAIT], [dnl
> +AS_ECHO(["AS_ESCAPE([$3: waiting $4...])"]) >_MESSAGE_LOG_FD
>  ovs_wait_cond () {
>  $1
>  }
>  if ovs_wait; then :
>  else
> +AS_ECHO(["AS_ESCAPE([$3: wait failed])"]) >_MESSAGE_LOG_FD
>  $2
>  AT_FAIL_IF([:])
>  fi
> @@ -255,7 +257,8 @@ dnl Executes shell COMMAND in a loop until it returns
>  dnl zero return code.  If COMMAND did not return
>  dnl zero code within reasonable time limit, then
>  dnl the test fails.
> -m4_define([OVS_WAIT_UNTIL], [OVS_WAIT([$1], [$2])])
> +m4_define([OVS_WAIT_UNTIL],
> +  [OVS_WAIT([$1], [$2], [AT_LINE], [until $1])])
>
>  dnl OVS_WAIT_WHILE(COMMAND)
>  dnl
> @@ -264,7 +267,8 @@ dnl non-zero return code.  If COMMAND did not return
>  dnl non-zero code within reasonable time limit, then
>  dnl the test fails.
>  m4_define([OVS_WAIT_WHILE],
> -  [OVS_WAIT([if $1; then return 1; else return 0; fi], [$2])])
> +  [OVS_WAIT([if $1; then return 1; else return 0; fi], [$2],
> +[AT_LINE], [while $1])])
>
>  dnl OVS_APP_EXIT_AND_WAIT(DAEMON)
>  dnl
> --
> 2.15.1
>
> ___
> 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] [PATCHv2] ovs-router: fix router entry cast

[Ben Pfaff]

On Wed, Jan 31, 2018 at 02:09:30PM -0800, William Tu wrote:
> The offsetof(struct ovs_router_entry, cr) should always be 0,
> thus the else statement should never be reached.
> 
> Signed-off-by: William Tu 

Thanks, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH V3] rhel: Fix support for root user using DPDK

[Ben Pfaff]

On Thu, Feb 01, 2018 at 03:42:03PM -0200, Marcos Felipe Schwarz wrote:
>  Since 2.8.0 OVS runs as non-root user on rhel distros, but the current
> implementation breaks the ability to run as root with DPDK and as a
> consequence there is no way possible to use UIO drivers on kernel 4.0 and
> newer [1, 2].
> [1] http://dpdk.org/browse/dpdk/commit/?id=cdc242f260e766
> bd95a658b5e0686a62ec04f5b0
> [2] https://www.kernel.org/doc/Documentation/vm/pagemap.txt
> 
> Fixes: e3e738a3d058 ("redhat: allow dpdk to also run as non-root user")
> Signed-off-by: Marcos Schwarz 
> Acked-by: Aaron Conole 

Thanks for the patch.

I understand from the commit message the ultimate goal of this patch.  I
don't yet understand what change it is actually making.  In particular,
what is the purpose of the following change; what does it do?

> --- a/lib/daemon-unix.c
> +++ b/lib/daemon-unix.c
> @@ -1047,5 +1047,6 @@ daemon_set_new_user(const char *user_spec)
>  }
>  }
> 
> -switch_user = true;
> +if (!uid_verify(uid) || !gid_verify(gid))
> +switch_user = true;
>  }

Thanks,

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

Re: [ovs-dev] [PATCH] packet-type-aware.at: Fix check failure

[Ben Pfaff]

On Mon, Jan 29, 2018 at 08:22:55AM -0800, Yifeng Sun wrote:
> The test (ptap - recirculate after packet_type change) failed because
> function format_odp_key_attr__ outputs src, dst and proto in the case of
> OVS_KEY_ATTR_IPV4.
> 
> Signed-off-by: Yifeng Sun 

Can you help me understand this change?  Without it, the test that it
changes passes for me; with it, the test fails.  Do you see the
opposite?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v1] doc: Added OVS Conntrack tutorial

[Ben Pfaff]

On Mon, Jan 29, 2018 at 08:48:56AM -0800, Ashish Varma wrote:
> OVS supports connection tracker related match fields and actions.
> Added a tutorial to demonstrate the basic use cases for some of these
> match fields and actions.
> 
> Signed-off-by: Ashish Varma 

Pretty cool.  Thanks for writing this.

I applied this to master.  I did not thoroughly review it.  I think that
the benefits of having it outweigh any possible mistakes in it,
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.7] docs: Use DPDK 16.11.4 stable release.

[Ben Pfaff]

On Tue, Jan 30, 2018 at 10:07:22AM +, Ian Stokes wrote:
> Modify docs and travis linux build script to use DPDK 16.11.4 stable
> branch to benefit from most recent bug fixes.
> 
> There are no new features introduced in the DPDK release, only back
> ported bug fixes. For completeness these bug fixes have been
> documented under the 16.11.4 section in the link below.
> 
> http://dpdk.org/doc/guides-16.11/rel_notes/release_16_11.html
> 
> Signed-off-by: Ian Stokes 

Who is the best person to review this?

Thanks,

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

Re: [ovs-dev] [PATCH] Add unixctl option for ovn-northd

[Ben Pfaff]

On Tue, Jan 30, 2018 at 03:12:32PM +0530, vkomm...@redhat.com wrote:
> From: Venkata Anil 
> 
> Signed-off-by: Venkata Anil 

Thanks, applied to master!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] learn: improve test case

[Ben Pfaff]

On Wed, Jan 31, 2018 at 06:32:29PM -0800, William Tu wrote:
> Current learn test cases use only ovs-ofctl add/del flows.
> The patch add a new test case for learn with delete_learned and
> limit option enabled.
> 
> Signed-off-by: William Tu 

Thanks, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVS DPDK: dpdk_merge pull request for branch-2.9

[Ben Pfaff]

On Wed, Jan 31, 2018 at 08:15:35PM +, Stokes, Ian wrote:
> Hi Ben,
> 
> The following changes since commit 448a18458328655539599eb4d24b525d311d13df:
> 
>   netdev-dpdk: Fix xstats leak on port destruction. (2018-01-26 20:40:52 
> +)
> 
> are available in the git repository at:
> 
>   https://github.com/istokes/ovs dpdk_merge_2_9
> 
> for you to fetch changes up to a0b62aacb5021e5a16e6a916b4add61e1b68ec01:
> 
>   netdev-dpdk: Add support for vHost dequeue zero copy (experimental) 
> (2018-01-31 18:44:10 +)

Thanks, I merged this into branch-2.9.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVS DPDK: dpdk_merge pull request for master

[Ben Pfaff]

Thanks!  I merged this into master.

On Wed, Jan 31, 2018 at 08:15:22PM +, Stokes, Ian wrote:
> Hi Ben,
> 
> The following changes since commit 186667a83c2b09ed9ae08b35c596987cf7d33cfb:
> 
>   classifier: Fix typo in comment. (2018-01-30 13:00:52 -0800)
> 
> are available in the git repository at:
> 
>   https://github.com/istokes/ovs dpdk_merge
> 
> for you to fetch changes up to 10087cba9deec95aaea080c49f2cbe648ebe92c8:
> 
>   netdev-dpdk: Add support for vHost dequeue zero copy (experimental) 
> (2018-01-31 14:04:35 +)
> 
> 
> Ciara Loftus (1):
>   netdev-dpdk: Add support for vHost dequeue zero copy (experimental)
> 
>  Documentation/intro/install/dpdk.rst |  2 ++
>  Documentation/topics/dpdk/vhost-user.rst | 73 
> +
>  NEWS |  1 +
>  lib/netdev-dpdk.c| 18 ++
>  vswitchd/vswitch.xml | 11 +++
>  5 files changed, 105 insertions(+)
> 
> Thanks
> Ian
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 3/3] mirror: do not mirror packet on recirculation

[Ben Pfaff]

Thanks a lot for the extra details.

I'm having some trouble getting the setup just right so that I can
reproduce your results.  So far, I've managed to set it up, but I don't
yet see the duplication.  Can you help me by providing a full set of
commands?

On Tue, Jan 30, 2018 at 11:12:34PM +0800, Huanle Han wrote:
> Thanks for your review.
> 
> Here is a test case:
> 1. add a trunk, balance-tcp bond to a bridge
> 2. add a access port tag=xxx to same bridge
> 3. add a mirror, which mirrors all ports in vlan=xxx to another out port
> 4. send packet from access port to bond (simply use arp). as a result,
> *mirror send 2 duplicated packets to outport *
> 
> Commands for example：
> br=br1
> src_port=vnet1
> mirror_port=vnet12
> 
> ovs-vsctl --if-exists del-port $mirror_port -- add-port $br $mirror_port
> ovs-vsctl --if-exists del-port $src_port -- add-port $br $src_port tag=199
> 
> ovs-vsctl -- set Bridge $br mirrors=@m --  \
> --id=@p0 get Port $mirror_port -- \
> --id=@m create Mirror select_all=true name=mm select_vlan=199
> output_port=@p0
> 
> Result of datapath flows: 11,which is the mirror outport, is outputed twice.
> recirc_id(0x2),dp_hash(0xb8/0xff),in_port(10),eth_type(0x8100),vlan(vid=199),encap(eth_type(0x0806),
> packets:9, bytes:414, used:0.605s, actions:9,11
> recirc_id(0),in_port(10),eth(src=fa:da:41:1d:30:0e,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=7.7.7.18,tip=7.7.7.192,op=1/0xff),
> packets:9, bytes:378, used:0.604s,
> actions:push_vlan(vid=199,pcp=0),11,pop_vlan,7,push_vlan(vid=199,pcp=0),12,hash(hash_l4(0),recirc(0x2)
> 
> About patch:
> I didn't notice 'frozen_state' thing util you pointed it out. And
> after review the code, I think ovs doesn't save the mirror information
> in frozen_state for bond recirc. My old patch is naive. I would
> appreciate it if you would fix it.
> 
> 
> On Thu, Jan 25, 2018 at 3:30 AM, Ben Pfaff  wrote:
> > On Wed, Jan 24, 2018 at 09:41:12AM -0800, Ben Pfaff wrote:
> >> From: Huanle Han 
> >>
> >> Signed-off-by: Huanle Han 
> >> ---
> >>  ofproto/ofproto-dpif-xlate.c | 4 
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> >> index 9d6ca94afc82..23938c8c8cf3 100644
> >> --- a/ofproto/ofproto-dpif-xlate.c
> >> +++ b/ofproto/ofproto-dpif-xlate.c
> >> @@ -1931,6 +1931,10 @@ mirror_packet(struct xlate_ctx *ctx, struct xbundle 
> >> *xbundle,
> >>  return;
> >>  }
> >>
> >> +if (ctx->xin->flow.recirc_id != 0) {
> >> +return;
> >> +}
> >> +
> >
> > Can you help me understand what cases this addresses?  The frozen_state
> > that comes along with a recirculation should keep track of what mirrors
> > have already been output, which should prevent duplicate mirroring on
> > recirculation.  If it doesn't work in every case, then probably we
> > should address that instead of just disabling mirroring on
> > recirculation.
> >
> > Thanks,
> >
> > Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] VMWare Users

[Julia Baxter]

Hi, 

Hope this email finds you well.

I'm Julia and I'm reaching out to check if you are interested in acquiring
"VMWare Users ", with verified direct emails from cross industry. 

We maintain  users like: AWS, Openstack, Openshift , Kubernetes, Cloudstack,
Docker, azure, Opendaylight, devops, Hyper-V and many more users.

 If this is within your interest, please drop me a note. I'll revert with
further information and a sample file for your review.

I look forward to hearing from you.

 Regards, 

Julia Baxter | Marketing Manager, USA, Canada & UK 

P Consider the environment. Please don't print this e-mail unless you really
need to

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

[ovs-dev] Una buena gestión para alcanzar sus metas

[Balanced Scorecard]

Logre sus objetivos a través de una gestión estratégica 

Balanced Scorecard: Una herramienta para la estrategia empresarial
15 de Febrero- C.P. Hugo Coca Chávez - 9am- 8pm

El Balanced Scorecard da una serie de resultados que favorecen la 
administración de su organización, a través de la implementación y aplicación 
de una metodología, con la que se obtienen ventajas como la formación de los 
empleados hacia la visión de la empresa, la comunicación hacia todo el personal 
de los objetivos y su cumplimiento, replanteamiento de la estrategia con base 
en resultados, mejoría en los indicadores financieros entre muchas otras. 

BENEFICIOS DE ASISTIR: 

- Elaborará los objetivos de su empresa y los unificará con la planeación 
estratégica.
- Conocerá los objetivos y la forma de medir el desempeño.
- Aprenderá lo que es el mapa estratégico, así como la forma en la que se 
construye.
- Identificará los sistemas: gráfico de información gerencial, de control de 
gestión y de remuneración por resultados. 

¿Requiere la información a la Brevedad? responda este email con la palabra: 
Balanced + nombre - teléfono - correo.


centro telefónico:018002120744 


 


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

Re: [ovs-dev] [PATCH v2 1/5] xlate: fix packets loopback caused by duplicate read of xcfgp.

[Ben Pfaff]

Thanks, I applied this to master and branch-2.9.

Would you mind reviewing or testing the rest of the series, especially
patches 4 and 5?  Thanks!

On Tue, Jan 30, 2018 at 11:28:27PM +0800, Huanle Han wrote:
> That 'ctx->xcfg' can't be null in my previous patch. This patch looks
> good to me.
> 
> On Thu, Jan 25, 2018 at 3:40 AM, Ben Pfaff  wrote:
> > From: Huanle Han 
> >
> > Some functions, such as xlate_normal_mcast_send_mrouters, test xbundle
> > pointers equality to avoid sending packet back to in bundle. However,
> > xbundle pointers port from different xcfgp for same port are inequal.
> > This may lead to the packet loopback.
> >
> > This commit stores xcfgp on ctx at first and always uses the same xcfgp
> > during one packet process period.
> >
> > Signed-off-by: Huanle Han 
> > Signed-off-by: Ben Pfaff 
> > ---
> >  ofproto/ofproto-dpif-xlate.c | 43 
> > ++-
> >  1 file changed, 14 insertions(+), 29 deletions(-)
> >
> > diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> > index 40c04cc4fb4a..f767224941cf 100644
> > --- a/ofproto/ofproto-dpif-xlate.c
> > +++ b/ofproto/ofproto-dpif-xlate.c
> > @@ -182,6 +182,7 @@ struct xlate_ctx {
> >  struct xlate_in *xin;
> >  struct xlate_out *xout;
> >
> > +struct xlate_cfg *xcfg;
> >  const struct xbridge *xbridge;
> >
> >  /* Flow at the last commit. */
> > @@ -514,7 +515,6 @@ static struct xlate_cfg *new_xcfg = NULL;
> >
> >  typedef void xlate_actions_handler(const struct ofpact *, size_t 
> > ofpacts_len,
> > struct xlate_ctx *, bool);
> > -
> >  static bool may_receive(const struct xport *, struct xlate_ctx *);
> >  static void do_xlate_actions(const struct ofpact *, size_t ofpacts_len,
> >   struct xlate_ctx *, bool);
> > @@ -1965,8 +1965,7 @@ mirror_packet(struct xlate_ctx *ctx, struct xbundle 
> > *xbundle,
> >
> >  /* Send the packet to the mirror. */
> >  if (out) {
> > -struct xlate_cfg *xcfg = ovsrcu_get(struct xlate_cfg *, 
> > );
> > -struct xbundle *out_xbundle = xbundle_lookup(xcfg, out);
> > +struct xbundle *out_xbundle = xbundle_lookup(ctx->xcfg, out);
> >  if (out_xbundle) {
> >  output_normal(ctx, out_xbundle, );
> >  }
> > @@ -2234,7 +2233,6 @@ output_normal(struct xlate_ctx *ctx, const struct 
> > xbundle *out_xbundle,
> >  xport = CONTAINER_OF(ovs_list_front(_xbundle->xports), struct 
> > xport,
> >   bundle_node);
> >  } else {
> > -struct xlate_cfg *xcfg = ovsrcu_get(struct xlate_cfg *, );
> >  struct flow_wildcards *wc = ctx->wc;
> >  struct ofport_dpif *ofport;
> >
> > @@ -2256,7 +2254,7 @@ output_normal(struct xlate_ctx *ctx, const struct 
> > xbundle *out_xbundle,
> >
> >  ofport = bond_choose_output_slave(out_xbundle->bond,
> >>xin->flow, wc, vid);
> > -xport = xport_lookup(xcfg, ofport);
> > +xport = xport_lookup(ctx->xcfg, ofport);
> >
> >  if (!xport) {
> >  /* No slaves enabled, so drop packet. */
> > @@ -2525,7 +2523,6 @@ update_mcast_snooping_table(const struct xlate_ctx 
> > *ctx,
> >  const struct dp_packet *packet)
> >  {
> >  struct mcast_snooping *ms = ctx->xbridge->ms;
> > -struct xlate_cfg *xcfg;
> >  struct xbundle *mcast_xbundle;
> >  struct mcast_port_bundle *fport;
> >
> > @@ -2537,9 +2534,8 @@ update_mcast_snooping_table(const struct xlate_ctx 
> > *ctx,
> >  /* Don't learn from flood ports */
> >  mcast_xbundle = NULL;
> >  ovs_rwlock_wrlock(>rwlock);
> > -xcfg = ovsrcu_get(struct xlate_cfg *, );
> >  LIST_FOR_EACH(fport, node, >fport_list) {
> > -mcast_xbundle = xbundle_lookup(xcfg, fport->port);
> > +mcast_xbundle = xbundle_lookup(ctx->xcfg, fport->port);
> >  if (mcast_xbundle == in_xbundle) {
> >  break;
> >  }
> > @@ -2566,13 +2562,11 @@ xlate_normal_mcast_send_group(struct xlate_ctx *ctx,
> >const struct xvlan *xvlan)
> >  OVS_REQ_RDLOCK(ms->rwlock)
> >  {
> > -struct xlate_cfg *xcfg;
> >  struct mcast_group_bundle *b;
> >  struct xbundle *mcast_xbundle;
> >
> > -xcfg = ovsrcu_get(struct xlate_cfg *, );
> >  LIST_FOR_EACH(b, bundle_node, >bundle_lru) {
> > -mcast_xbundle = xbundle_lookup(xcfg, b->port);
> > +mcast_xbundle = xbundle_lookup(ctx->xcfg, b->port);
> >  if (mcast_xbundle && mcast_xbundle != in_xbundle) {
> >  xlate_report(ctx, OFT_DETAIL, "forwarding to mcast group 
> > port");
> >  output_normal(ctx, mcast_xbundle, xvlan);
> > @@ -2594,13 +2588,11 @@ xlate_normal_mcast_send_mrouters(struct xlate_ctx 
> > *ctx,
> >

Re: [ovs-dev] [PATCH] ofctrl: Remove unused declaration.

[Ben Pfaff]

On Mon, Jan 29, 2018 at 01:44:26PM -0800, Han Zhou wrote:
> Signed-off-by: Han Zhou 

Thanks, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovn-nbctl: update manpage for lsp-set-type.

[Ben Pfaff]

On Mon, Jan 29, 2018 at 02:04:48PM -0800, Han Zhou wrote:
> Signed-off-by: Han Zhou 

Thanks, applied to master and branch-2.9.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 5/5] ovs-vswitchd: Avoid or suppress memory leak warning for glibc aio.

[Ben Pfaff]

On Mon, Jan 29, 2018 at 02:31:31PM -0800, William Tu wrote:
> On Thu, Jan 25, 2018 at 3:39 PM, Ben Pfaff  wrote:
> > The asynchronous IO library in glibc starts threads that show up as memory
> > leaks in valgrind.  This commit attempts to avoid the warnings by flushing
> > all the asynchronous I/O to the log file before exiting.  This only does
> > part of the job for glibc since it keeps the threads around for some
> > undefined idle time before killing them, so in addition this commit adds a
> > valgrind suppression to stop displaying these warnings in any case.
> >
> > Signed-off-by: Ben Pfaff 
> > ---
> 
> Looks good to me.
> Acked-by: William Tu 

Thank you for the reviews.  I applied this series to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] util: Document and rely on ovs_assert() always evaluating its argument.

[Ben Pfaff]

Thank you for the review  I applied this to master.

On Wed, Jan 31, 2018 at 02:57:01PM -0800, Yifeng Sun wrote:
> Thanks, looks good to me.
> 
> Reviewed-by: Yifeng Sun 
> 
> On Wed, Jan 31, 2018 at 11:23 AM, Ben Pfaff  wrote:
> 
> > The ovs_assert() macro always evaluates its argument, even when NDEBUG is
> > defined so that failure is ignored.  This behavior wasn't documented, and
> > thus a lot of code didn't rely on it.  This commit documents the behavior
> > and simplifies bits of code that heretofore didn't rely on it.
> >
> > Signed-off-by: Ben Pfaff 
> > ---
> >  include/openvswitch/util.h   |  7 +--
> >  lib/cmap.c   |  6 ++
> >  lib/conntrack.c  |  6 ++
> >  lib/hmapx.c  |  6 ++
> >  lib/odp-execute.c|  5 +
> >  lib/odp-util.c   |  5 +
> >  lib/ofp-msgs.c   | 32 
> >  lib/ofp-util.c   | 11 ---
> >  lib/ovsdb-data.c |  4 +---
> >  lib/shash.c  |  3 +--
> >  lib/sset.c   |  6 ++
> >  ofproto/ofproto-dpif-xlate.c |  7 +++
> >  ovsdb/ovsdb-server.c |  4 +---
> >  ovsdb/replication.c  |  3 +--
> >  14 files changed, 34 insertions(+), 71 deletions(-)
> >
> > diff --git a/include/openvswitch/util.h b/include/openvswitch/util.h
> > index ad1b184f78d9..b4d49ee21804 100644
> > --- a/include/openvswitch/util.h
> > +++ b/include/openvswitch/util.h
> > @@ -44,8 +44,11 @@ const char *ovs_get_program_version(void);
> >   : (X) <= UINT_MAX / (Y) ? (unsigned int) (X) * (unsigned int) (Y)  \
> >   : UINT_MAX)
> >
> > -/* Like the standard assert macro, except writes the failure message to
> > the
> > - * log. */
> > +/* Like the standard assert macro, except:
> > + *
> > + *- Writes the failure message to the log.
> > + *
> > + *- Always evaluates the condition, even with NDEBUG. */
> >  #ifndef NDEBUG
> >  #define ovs_assert(CONDITION)   \
> >  (OVS_LIKELY(CONDITION)  \
> > diff --git a/lib/cmap.c b/lib/cmap.c
> > index af29639b049c..07719a8fd286 100644
> > --- a/lib/cmap.c
> > +++ b/lib/cmap.c
> > @@ -843,11 +843,9 @@ cmap_replace(struct cmap *cmap, struct cmap_node
> > *old_node,
> >  struct cmap_impl *impl = cmap_get_impl(cmap);
> >  uint32_t h1 = rehash(impl, hash);
> >  uint32_t h2 = other_hash(h1);
> > -bool ok;
> >
> > -ok = cmap_replace__(impl, old_node, new_node, hash, h1)
> > -|| cmap_replace__(impl, old_node, new_node, hash, h2);
> > -ovs_assert(ok);
> > +ovs_assert(cmap_replace__(impl, old_node, new_node, hash, h1) ||
> > +   cmap_replace__(impl, old_node, new_node, hash, h2));
> >
> >  if (!new_node) {
> >  impl->n--;
> > diff --git a/lib/conntrack.c b/lib/conntrack.c
> > index 562e767833d1..fe5fd0fe8be1 100644
> > --- a/lib/conntrack.c
> > +++ b/lib/conntrack.c
> > @@ -3080,11 +3080,9 @@ repl_ftp_v6_addr(struct dp_packet *pkt, struct
> > ct_addr v6_addr_rep,
> >  return 0;
> >  }
> >
> > -const char *rc;
> >  char v6_addr_str[IPV6_SCAN_LEN] = {0};
> > -rc = inet_ntop(AF_INET6, _addr_rep.ipv6_aligned, v6_addr_str,
> > -  IPV6_SCAN_LEN - 1);
> > -ovs_assert(rc != NULL);
> > +ovs_assert(inet_ntop(AF_INET6, _addr_rep.ipv6_aligned, v6_addr_str,
> > + IPV6_SCAN_LEN - 1));
> >
> >  size_t replace_addr_size = strlen(v6_addr_str);
> >
> > diff --git a/lib/hmapx.c b/lib/hmapx.c
> > index 0440767c9c97..eadfe640ac11 100644
> > --- a/lib/hmapx.c
> > +++ b/lib/hmapx.c
> > @@ -116,8 +116,7 @@ hmapx_add(struct hmapx *map, void *data)
> >  void
> >  hmapx_add_assert(struct hmapx *map, void *data)
> >  {
> > -bool added OVS_UNUSED = hmapx_add(map, data);
> > -ovs_assert(added);
> > +ovs_assert(hmapx_add(map, data));
> >  }
> >
> >  /* Removes all of the nodes from 'map'. */
> > @@ -156,8 +155,7 @@ hmapx_find_and_delete(struct hmapx *map, const void
> > *data)
> >  void
> >  hmapx_find_and_delete_assert(struct hmapx *map, const void *data)
> >  {
> > -bool deleted OVS_UNUSED = hmapx_find_and_delete(map, data);
> > -ovs_assert(deleted);
> > +ovs_assert(hmapx_find_and_delete(map, data));
> >  }
> >
> >  /* Searches for 'data' in 'map'.  Returns its node, if found, otherwise a
> > null
> > diff --git a/lib/odp-execute.c b/lib/odp-execute.c
> > index 20f33eb57acb..12bba83ea32c 100644
> > --- a/lib/odp-execute.c
> > +++ b/lib/odp-execute.c
> > @@ -198,10 +198,7 @@ odp_set_sctp(struct dp_packet *packet, const struct
> > ovs_key_sctp *key,
> >  static void
> >  odp_set_tunnel_action(const struct nlattr *a, struct flow_tnl *tun_key)
> >  {
> > -enum odp_key_fitness fitness;
> > -
> > -fitness = odp_tun_key_from_attr(a, tun_key);
> > -ovs_assert(fitness != ODP_FIT_ERROR);
> > +

Re: [ovs-dev] [PATCH] learn: improve test case

[William Tu]

> Thanks William.
> I have question - is this test case trying to delineate some related bug or
> observed special behavior ?

We suspect that there might be a memory leak in learn action. So I
created this test.

> I am asking because I don't immediately see the intersection b/w the
> delete_learned and limit options ?

I observe some cases that the learn action creates more than 1,000 rules,
so testing delete_learned and limit to make sure the created rules operate ok.

>
> BTW, what is "limit with packet" as opposed to just "limit"

I mean using packets to trigger the learn action.
Because the previous similar tests do not use packets.

>
>
>>
>> +OVS_VSWITCHD_START(
>> +[add-port br0 p1 -- set Interface p1 type=dummy ofport_request=1 --\
>> + add-port br0 p2 -- set Interface p2 type=dummy ofport_request=2])
>> +
>> +# Add some initial flows and check that it was successful.
>> +AT_DATA([flows.txt], [dnl
>> +table=0 actions=set_field:0x2->reg7,set_field:0xabcdef01->metadata,
>> resubmit(,1)
>> +table=1
>> actions=learn(table=10,delete_learned,cookie=0x123,limit=3,result_dst=NXM_NX_REG6[[0]],NXM_OF_ETH_DST[[]]=NXM_OF_ETH_SRC[[]],OXM_OF_METADATA[[]],output:NXM_NX_REG7)
>> +])
>> +
>> +AT_CHECK([ovs-ofctl add-flows br0 flows.txt])
>> +AT_CHECK([ovs-ofctl dump-flows br0 --no-stats | sort], [0], [dnl
>> +
>> actions=load:0x2->NXM_NX_REG7[[]],load:0xabcdef01->OXM_OF_METADATA[[]],resubmit(,1)
>> + table=1,
>> actions=learn(table=10,delete_learned,cookie=0x123,limit=3,result_dst=NXM_NX_REG6[[0]],NXM_OF_ETH_DST[[]]=NXM_OF_ETH_SRC[[]],OXM_OF_METADATA[[]],output:NXM_NX_REG7[[]])
>> +])
>> +
>> +dnl Each packet will generate its own flow at table=10, except last one
>> +AT_CHECK([ovs-appctl netdev-dummy/receive p1
>> 'in_port(1),eth(src=50:54:00:00:00:01,dst=50:54:00:00:00:ff),eth_type(0x1234)'])
>> +AT_CHECK([ovs-appctl netdev-dummy/receive p1
>> 'in_port(1),eth(src=50:54:00:00:00:02,dst=50:54:00:00:00:ff),eth_type(0x1234)'])
>> +AT_CHECK([ovs-appctl netdev-dummy/receive p1
>> 'in_port(1),eth(src=50:54:00:00:00:03,dst=50:54:00:00:00:ff),eth_type(0x1234)'])
>> +AT_CHECK([ovs-appctl netdev-dummy/receive p1
>> 'in_port(1),eth(src=50:54:00:00:00:04,dst=50:54:00:00:00:ff),eth_type(0x1234)'])
>> +
>> +AT_CHECK([ovs-ofctl dump-flows br0 table=10 --no-stats | sort], [0], [dnl
>> + cookie=0x123, table=10, metadata=0xabcdef01,dl_dst=50:54:00:00:00:01
>> actions=output:2
>> + cookie=0x123, table=10, metadata=0xabcdef01,dl_dst=50:54:00:00:00:02
>> actions=output:2
>> + cookie=0x123, table=10, metadata=0xabcdef01,dl_dst=50:54:00:00:00:03
>> actions=output:2
>> +])
>> +
>> +ovs-appctl revalidator/wait
>> +
>> +AT_CHECK([ovs-ofctl del-flows br0 'table=1'])
>> +AT_CHECK([ovs-ofctl dump-flows br0 table=10 --no-stats | sort], [0], [dnl
>
>
> It looks odd to sort an expected empty list.
>

Right, I should remove it.

Thanks
William
>
>>
>> +])
>> +
>> +OVS_VSWITCHD_STOP
>> +AT_CLEANUP
>> +
>>  AT_SETUP([learning action - limit])
>>  OVS_VSWITCHD_START
>>  AT_CHECK([ovs-appctl vlog/set dpif:dbg dpif_netdev:dbg])
>> --
>> 2.7.4
>>
>> ___
>> 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 10/15] ovsdb-server: Add new RPC "set_db_change_aware".

[Ben Pfaff]

Thanks for the review and for your valuable corrections!

On Wed, Jan 31, 2018 at 06:24:14PM -0800, Justin Pettit wrote:
> > On Dec 31, 2017, at 9:16 PM, Ben Pfaff  wrote:
> > 
> > +  Traditionally, ovsdb-server disconnects all of its 
> > clients
> > +  when a significant configuration change occurs, because this prompts 
> > a
> > +  well-written client to reassess what is available from the server 
> > when it
> > +  reconnects.  Because this table provides an alternative and more
> > +  efficient way to find out about those changes, OVS 2.9 also 
> > introduces
> > +  the set_db_change_aware RPC, documented in
> > +  ovsdb-server(1), to allow clients to suppress this
> > +  disconnection behavior.
> 
> Is that in section 1 or 7 of the ovsdb-server man pages?

7.  Fixed.

> > +  When a database is removed from the server, in addition to
> > +  Database table updates, the server sends 
> > cancel
> > +  messages, as described in RFC 7047 section 4.1.4, in reply to 
> > outstanding
> > +  transactions for the removed database.  The server also cancels any
> > +  outstanding monitoring initiated by monitor or
> > +  monitor_cond requested on the removed database, sending 
> > the
> > +  monitor_canceled RPC described in
> > +  ovsdb-server(5).  Only clients that disable 
> > disconnection
> > +  with set_db_change_aware receive these messages.
> 
> I believe this file is section 5 of the ovsdb-server man page.  Should
> it also be section 7?

Yes.  Fixed.

> > @@ -333,17 +331,20 @@ ovsdb_jsonrpc_server_free_remote_status(
> > free(status->locks_lost);
> > }
> > 
> > -/* Forces all of the JSON-RPC sessions managed by 'svr' to disconnect and
> > - * reconnect. */
> > +/* Makes all of the JSON-RPC sessions managed by 'svr' to disconnect.  
> > (They
> > + * will then generally reconnect.).
> 
> I think you should drop "to".

Done, thanks.

> > @@ -432,6 +433,20 @@ struct ovsdb_jsonrpc_session {
> > struct ovsdb_session up;
> > struct ovsdb_jsonrpc_remote *remote;
> > 
> > +/* RFC 7047 does not contemplate how to alert clients to changes to 
> > the set
> > + * of databases, e.g. databases that are added or removed while the
> > + * database server is running.  Traditionally, ovsdb-server 
> > disconnects all
> > + * of its clients when this happens; a well-written client will 
> > reassess
> > + * what is available from the server upon reconnection.
> > + *
> > + * OVS 2.9 introduces a way for clients to monitor changes to the 
> > databases
> > + * being served, through the Database table in the _Server database 
> > that
> > + * OVSDB adds in this version.  ovsdb-server suppresses the connection
> > + * close for clients that identify themselves as taking advantage of 
> > this
> > + * mechanism.
> > + */
> > +bool db_change_aware;
> 
> I think it might be worth being explicit that setting this flag to
> true indicates that the client has requested this suppression to
> occur.

Thanks, I added a sentence.

> > +/* Database 'db' is about to be removed from the database server.  To 
> > prepare,
> > + * this function removes all references to 'db' from session 's'. */
> > +static void
> > +ovsdb_jsonrpc_session_preremove_db(struct ovsdb_jsonrpc_remote *remote,
> > +   struct ovsdb *db)
> 
> The argument looks to be 'db', not 's', which may contain more than
> one session.

Thanks, fixed.

> > +/* Makes all of the JSON-RPC sessions managed by 'remove' to disconnect.  
> > (They
> > + * will then generally reconnect.).
> > + *
> > + * If 'force' is true, disconnects all sessions.  Otherwise, disconnects 
> > only
> > + * sesions that aren't database change aware. */
> > static void
> > +ovsdb_jsonrpc_session_reconnect_all(struct ovsdb_jsonrpc_remote *remote,
> > +bool force)
> 
> The comment should be 'remote' instead of 'remove'.

Thanks, fixed.

> Acked-by: Justin Pettit 

Thanks for the review!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 09/15] ovsdb-server: Add support for a built-in _Server database.

[Justin Pettit]

> On Feb 1, 2018, at 11:10 AM, Ben Pfaff  wrote:
> 
> I think that these are the same things that are getting allocated in
> open_db() for "real" databases, so they should be getting freed in the
> same way.  (Maybe there is a memory leak in that case too, but I do not
> see it yet.)

That makes sense.  Thank you.

--Justin


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

Re: [ovs-dev] [PATCH 09/15] ovsdb-server: Add support for a built-in _Server database.

[Ben Pfaff]

On Thu, Feb 01, 2018 at 11:05:35AM -0800, Justin Pettit wrote:
> 
> > On Feb 1, 2018, at 10:59 AM, Ben Pfaff  wrote:
> > 
> > On Tue, Jan 30, 2018 at 03:27:18PM -0800, Justin Pettit wrote:
> >> 
> >>> On Dec 31, 2017, at 9:16 PM, Ben Pfaff  wrote:
> >>> 
> >>> @@ -328,6 +333,7 @@ main(int argc, char *argv[])
> >>>ovs_fatal(0, "%s", error);
> >>>}
> >>>}
> >>> +add_server_db(_config);
> >> 
> >> I don't think there's anything that frees 'server_config'.  Not a huge
> >> deal since it would be on shutdown, but it's always nice to have a
> >> clean valgrind run.
> > 
> > server_config is a local variable, and not a pointer.  What kind of
> > freeing would you like to see?
> 
> I meant the things that were allocated in add_server_db().

OK.

I think that these are the same things that are getting allocated in
open_db() for "real" databases, so they should be getting freed in the
same way.  (Maybe there is a memory leak in that case too, but I do not
see it yet.)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 09/15] ovsdb-server: Add support for a built-in _Server database.

[Justin Pettit]

> On Feb 1, 2018, at 10:59 AM, Ben Pfaff  wrote:
> 
> On Tue, Jan 30, 2018 at 03:27:18PM -0800, Justin Pettit wrote:
>> 
>>> On Dec 31, 2017, at 9:16 PM, Ben Pfaff  wrote:
>>> 
>>> @@ -328,6 +333,7 @@ main(int argc, char *argv[])
>>>ovs_fatal(0, "%s", error);
>>>}
>>>}
>>> +add_server_db(_config);
>> 
>> I don't think there's anything that frees 'server_config'.  Not a huge
>> deal since it would be on shutdown, but it's always nice to have a
>> clean valgrind run.
> 
> server_config is a local variable, and not a pointer.  What kind of
> freeing would you like to see?

I meant the things that were allocated in add_server_db().

--Justin


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

Re: [ovs-dev] [PATCH 09/15] ovsdb-server: Add support for a built-in _Server database.

[Ben Pfaff]

On Tue, Jan 30, 2018 at 03:27:18PM -0800, Justin Pettit wrote:
> 
> > On Dec 31, 2017, at 9:16 PM, Ben Pfaff  wrote:
> > 
> > @@ -5,6 +7,7 @@
> > /ovsdb-idlc
> > /ovsdb-server
> > /ovsdb-server.1
> > +/ovsdb-server.5
> 
> Do you need to add the new man page to the distributions?

Yes.  Thanks, fixed.

>   debian/openvswitch-switch.manpages
>   rhel/openvswitch-fedora.spec.in
>   rhel/openvswitch.spec.in
>   xenserver/openvswitch-xen.spec.in
> 
> Also, I think you may want to add a reference to 
> "Documentation/ref/index.rst".

Yes.  Thanks, fixed.

> > +# _Server schema documentation
> > +EXTRA_DIST += ovsdb/_server.xml
> > +CLEANFILES += ovsdb/ovsdb-server.5
> > +man_MANS += ovsdb/ovsdb-server.5
> > +ovsdb/ovsdb-server.5: \
> > +   ovsdb/ovsdb-doc ovsdb/_server.xml ovsdb/_server.ovsschema \
> > +   $(VSWITCH_PIC)
> 
> Did you intend to include VSWITCH_PIC?

No.  Removed.

> > @@ -328,6 +333,7 @@ main(int argc, char *argv[])
> > ovs_fatal(0, "%s", error);
> > }
> > }
> > +add_server_db(_config);
> 
> I don't think there's anything that frees 'server_config'.  Not a huge
> deal since it would be on shutdown, but it's always nice to have a
> clean valgrind run.

server_config is a local variable, and not a pointer.  What kind of
freeing would you like to see?

> > +/* Add the internal _Server database to the server configuration. */
> > +static void
> > +add_server_db(struct server_config *config)
> > +{
> > +struct json *schema_json = json_from_string(
> > +#include "ovsdb/_server.ovsschema.inc"
> > +);
> > +ovs_assert(schema_json->type == JSON_OBJECT);
> > +
> > +struct ovsdb_schema *schema;
> > +struct ovsdb_error *error OVS_UNUSED = 
> > ovsdb_schema_from_json(schema_json,
> > +  );
> > +ovs_assert(!error);
> > +json_destroy(schema_json);
> > +
> > +struct db *db = xzalloc(sizeof *db);
> > +db->filename = xstrdup("");
> > +db->db = ovsdb_create(schema);
> > +add_db(config, db->db->schema->name, db);
> > +}
> 
> Probably not a huge deal, since there's a single instance that runs as
> long as the process, but I don't think there's anything that free the
> memory allocated from this internal database.

It's not really different from other databases, other than it being
updated from the ovsdb-server main loop rather than from JSON-RPC
clients, so I think that any freeing (or not freeing) applied to other
databases should work equally well (or badly) for this one.

> > +/* Updates the Database table in the _Server database. */
> > +static void
> > +update_server_status(struct shash *all_dbs)
> > +{
> > +struct db *server_db = shash_find_data(all_dbs, "_Server");
> > +struct ovsdb_table *database_table = shash_find_data(
> > +_db->db->tables, "Database");
> > +struct ovsdb_txn *txn = ovsdb_txn_create(server_db->db);
> > +
> > +/* Update rows for databases that still exist.
> > + * Delete rows for databases that no longer exist. */
> > +const struct ovsdb_row *row, *next_row;
> > +HMAP_FOR_EACH_SAFE (row, next_row, hmap_node, _table->rows) {
> > +const char *name;
> > +ovsdb_util_read_string_column(row, "name", );
> > +struct db *db = shash_find_data(all_dbs, name);
> > +if (!db || !db->db) {
> > +ovsdb_txn_row_delete(txn, row);
> > +} else {
> > +update_database_status(ovsdb_txn_row_modify(txn, row), db);
> > }
> > }
> > +
> > +/* Add rows for new databases.
> > + *
> > + * This is O(n**2) but usually there are only 2 or 3 databases. */
> > +struct shash_node *node;
> > +SHASH_FOR_EACH (node, all_dbs) {
> > +struct db *db = node->data;
> > +
> > +if (!db->db) {
> > +continue;
> > +}
> > +
> > +HMAP_FOR_EACH (row, hmap_node, _table->rows) {
> > +const char *name;
> > +ovsdb_util_read_string_column(row, "name", );
> > +if (!strcmp(name, node->name)) {
> > +goto next;
> > +}
> > +}
> > +
> > +/* Add row. */
> > +struct ovsdb_row *row = ovsdb_row_create(database_table);
> > +uuid_generate(ovsdb_row_get_uuid_rw(row));
> > +update_database_status(row, db);
> > +ovsdb_txn_row_insert(txn, row);
> > +
> > +next:;
> > +}
> > +
> > +commit_txn(txn, "_Server");
> > }
> 
> I see a memory leak when I run unit tests (e.g., "testing database 
> multiplexing implementation") under valgrind:
> 
> ==123484== 6 bytes in 6 blocks are definitely lost in loss record 4 of 115
> ==123484==at 0x4C2DB8F: malloc (in 
> /usr/lib/valgrind/vgpreload_memcheck-amd6
> 4-linux.so)
> ==123484==by 0x437084: xmalloc (util.c:120)
> ==123484==by 0x4370B3: xmemdup (util.c:142)
> ==123484==by 0x4257BE: ovsdb_atom_init_default (ovsdb-data.c:77)
> ==123484==by 0x42580D: 

Re: [ovs-dev] [PATCH v3 3/3] Support accepting and displaying table names in OVS tools.

[Ben Pfaff]

Thanks for the review!  I applied this series to master.

On Thu, Feb 01, 2018 at 09:57:24AM -0800, Yifeng Sun wrote:
> Thanks for the nice feature. It looks good to me.
> 
> Reviewed-by: Yifeng Sun 
> 
> 
> On Wed, Jan 31, 2018 at 11:36 AM, Ben Pfaff  wrote:
> 
> > OpenFlow has little-known support for naming tables.  Open vSwitch has
> > supported table names for ages, but it has never used or displayed them
> > outside of commands dedicated to table manipulation.  This commit adds
> > support for table names in ovs-ofctl.  When a table has a name, it displays
> > that name in flows and actions, so that, for example, the following:
> > table=1, arp, actions=resubmit(,2)
> > might become:
> > table=ingress_acl, arp, actions=resubmit(,mac_learning)
> > given appropriately named tables.
> >
> > For backward compatibility, only interactive ovs-ofctl commands by default
> > display table names; to display them in scripts, use the new --names
> > option.
> >
> > This feature was inspired by a talk that Kei Nohguchi presented at Open
> > vSwitch 2017 Fall Conference.
> >
> > CC: Kei Nohguchi 
> > Signed-off-by: Ben Pfaff 
> > ---
> >  NEWS  |   8 ++
> >  include/openvswitch/ofp-actions.h |   2 +
> >  include/openvswitch/ofp-parse.h   |  20 ++-
> >  include/openvswitch/ofp-print.h   |  12 +-
> >  include/openvswitch/ofp-util.h|   8 ++
> >  lib/learn.c   |  20 ++-
> >  lib/learn.h   |   6 +-
> >  lib/learning-switch.c |   2 +-
> >  lib/ofp-actions.c |  45 +++---
> >  lib/ofp-parse.c   |  80 +++
> >  lib/ofp-print.c   | 202 --
> >  lib/ofp-util.c| 109 --
> >  lib/vconn.c   |  10 +-
> >  ofproto/ofproto-dpif.c|   4 +-
> >  ofproto/ofproto.c |   2 +-
> >  ovn/controller/ofctrl.c   |  12 +-
> >  ovn/controller/pinctrl.c  |   2 +-
> >  ovn/utilities/ovn-sbctl.c |   2 +-
> >  ovn/utilities/ovn-trace.c |   2 +-
> >  tests/ofproto.at  |  89 
> >  utilities/ovs-ofctl.8.in  |  90 +++-
> >  utilities/ovs-ofctl.c | 294 ++
> > +---
> >  utilities/ovs-testcontroller.c|   2 +-
> >  23 files changed, 736 insertions(+), 287 deletions(-)
> >
> > diff --git a/NEWS b/NEWS
> > index 726589ce3896..d76958b8adc0 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -2,6 +2,14 @@ Post-v2.9.0
> >  
> >  - ovs-vswitchd:
> >* New options --l7 and --l7-len to "ofproto/trace" command.
> > +   - ovs-ofctl:
> > + * ovs-ofctl now accepts and display table names in place of
> > numbers.  By
> > +   default it always accepts names and in interactive use it displays
> > them;
> > +   use --names or --no-names to override.  See ovs-ofctl(8) for
> > details.
> > +   - ovs-vswitchd:
> > + * Previous versions gave OpenFlow tables default names of the form
> > +   "table#".  These are not helpful names for the purpose of accepting
> > +   and displaying table names, so now tables by default have no names.
> >
> >
> >  v2.9.0 - xx xxx 
> > diff --git a/include/openvswitch/ofp-actions.h b/include/openvswitch/ofp-
> > actions.h
> > index 454c705ccf73..cba027b1d945 100644
> > --- a/include/openvswitch/ofp-actions.h
> > +++ b/include/openvswitch/ofp-actions.h
> > @@ -1068,6 +1068,7 @@ uint32_t ofpacts_get_meter(const struct ofpact[],
> > size_t ofpacts_len);
> >  struct ofpact_format_params {
> >  /* Input. */
> >  const struct ofputil_port_map *port_map;
> > +const struct ofputil_table_map *table_map;
> >
> >  /* Output. */
> >  struct ds *s;
> > @@ -1080,6 +1081,7 @@ const char *ofpact_name(enum ofpact_type);
> >  struct ofpact_parse_params {
> >  /* Input. */
> >  const struct ofputil_port_map *port_map;
> > +const struct ofputil_table_map *table_map;
> >
> >  /* Output. */
> >  struct ofpbuf *ofpacts;
> > diff --git a/include/openvswitch/ofp-parse.h b/include/openvswitch/ofp-
> > parse.h
> > index 013a8f3edf70..c4228a50358f 100644
> > --- a/include/openvswitch/ofp-parse.h
> > +++ b/include/openvswitch/ofp-parse.h
> > @@ -45,26 +45,33 @@ enum ofputil_protocol;
> >
> >  char *parse_ofp_str(struct ofputil_flow_mod *, int command, const char
> > *str_,
> >  const struct ofputil_port_map *,
> > +const struct ofputil_table_map *,
> >  enum ofputil_protocol *usable_protocols)
> >  OVS_WARN_UNUSED_RESULT;
> >
> >  char *parse_ofp_flow_mod_str(struct ofputil_flow_mod *, const char
> > *string,
> > - const struct ofputil_port_map *, int command,
> > + const struct ofputil_port_map *,
> > + 

[ovs-dev] [PATCH] tests: Make OVS_WAIT_UNTIL and OVS_WAIT_WHILE failures easier to debug.

[Ben Pfaff]

Until now, when OVS_WAIT_UNTIL or OVS_WAIT_WHILE ran, little information
was available: usually nothing at all in the log, unless the wait failed,
in which case there was a line number.  This commit adds a note saying
what is being waited for in any case, and a message saying that the wait
failed if it does.

Signed-off-by: Ben Pfaff 
---
 tests/ovs-macros.at | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
index 324fdc887f78..f3ab3548a7fe 100644
--- a/tests/ovs-macros.at
+++ b/tests/ovs-macros.at
@@ -239,11 +239,13 @@ fi
 m4_divert_pop([PREPARE_TESTS])
 
 m4_define([OVS_WAIT], [dnl
+AS_ECHO(["AS_ESCAPE([$3: waiting $4...])"]) >_MESSAGE_LOG_FD
 ovs_wait_cond () {
 $1
 }
 if ovs_wait; then :
 else
+AS_ECHO(["AS_ESCAPE([$3: wait failed])"]) >_MESSAGE_LOG_FD
 $2
 AT_FAIL_IF([:])
 fi
@@ -255,7 +257,8 @@ dnl Executes shell COMMAND in a loop until it returns
 dnl zero return code.  If COMMAND did not return
 dnl zero code within reasonable time limit, then
 dnl the test fails.
-m4_define([OVS_WAIT_UNTIL], [OVS_WAIT([$1], [$2])])
+m4_define([OVS_WAIT_UNTIL],
+  [OVS_WAIT([$1], [$2], [AT_LINE], [until $1])])
 
 dnl OVS_WAIT_WHILE(COMMAND)
 dnl
@@ -264,7 +267,8 @@ dnl non-zero return code.  If COMMAND did not return
 dnl non-zero code within reasonable time limit, then
 dnl the test fails.
 m4_define([OVS_WAIT_WHILE],
-  [OVS_WAIT([if $1; then return 1; else return 0; fi], [$2])])
+  [OVS_WAIT([if $1; then return 1; else return 0; fi], [$2],
+[AT_LINE], [while $1])])
 
 dnl OVS_APP_EXIT_AND_WAIT(DAEMON)
 dnl
-- 
2.15.1

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

Re: [ovs-dev] [PATCH v2 2/3] ofp-util: New data structure for mapping between table names and numbers.

[Yifeng Sun]

Sure, I just reviewed the 3rd patch.

On Wed, Jan 31, 2018 at 11:36 AM, Ben Pfaff  wrote:

> Thanks for the reviews of patches 1 and 2.  Do you plan to review patch
> 3 as well?  I rebased and sent out v3 just now.
>
> On Tue, Jan 30, 2018 at 01:29:56PM -0800, Yifeng Sun wrote:
> > Looks good to me, thanks.
> >
> > Reviewed-by: Yifeng Sun 
> >
> >
> > On Fri, Jan 12, 2018 at 12:57 PM, Ben Pfaff  wrote:
> >
> > > This shares the infrastructure for mapping port names and numbers.  It
> will
> > > be used in an upcoming commit.
> > >
> > > Signed-off-by: Ben Pfaff 
> > > ---
> > >  include/openvswitch/ofp-util.h |  33 +++--
> > >  lib/ofp-util.c | 150 ++
> > > ---
> > >  2 files changed, 138 insertions(+), 45 deletions(-)
> > >
> > > diff --git a/include/openvswitch/ofp-util.h b/include/openvswitch/ofp-
> > > util.h
> > > index 296078a2fe8b..d9780dd44582 100644
> > > --- a/include/openvswitch/ofp-util.h
> > > +++ b/include/openvswitch/ofp-util.h
> > > @@ -43,15 +43,24 @@ union ofp_action;
> > >  struct ofpact_set_field;
> > >  struct vl_mff_map;
> > >
> > > -/* Mapping between port numbers and names. */
> > > -struct ofputil_port_map {
> > > +/* Name-number mapping.
> > > + *
> > > + * This is not exported directly but only through specializations for
> port
> > > + * name-number and table name-number mappings. */
> > > +struct ofputil_name_map {
> > >  struct hmap by_name;
> > >  struct hmap by_number;
> > >  };
> > > -
> > > -#define OFPUTIL_PORT_MAP_INITIALIZER(MAP)  \
> > > +#define OFPUTIL_NAME_MAP_INITIALIZER(MAP)  \
> > >  { HMAP_INITIALIZER(&(MAP)->by_name), HMAP_INITIALIZER(&(MAP)->by_
> number)
> > > }
> > >
> > > +/* Mapping between port numbers and names. */
> > > +struct ofputil_port_map {
> > > +struct ofputil_name_map map;
> > > +};
> > > +#define OFPUTIL_PORT_MAP_INITIALIZER(MAP) \
> > > +{ OFPUTIL_NAME_MAP_INITIALIZER(&(MAP)->map) }
> > > +
> > >  void ofputil_port_map_init(struct ofputil_port_map *);
> > >  const char *ofputil_port_map_get_name(const struct ofputil_port_map
> *,
> > >ofp_port_t);
> > > @@ -791,6 +800,22 @@ struct ofputil_table_mod_prop_vacancy {
> > >  uint8_t vacancy; /* Current vacancy (%). */
> > >  };
> > >
> > > +/* Mapping between table numbers and names. */
> > > +struct ofputil_table_map {
> > > +struct ofputil_name_map map;
> > > +};
> > > +#define OFPUTIL_TABLE_MAP_INITIALIZER(MAP) \
> > > +{ OFPUTIL_NAME_MAP_INITIALIZER((MAP).map) }
> > > +
> > > +void ofputil_table_map_init(struct ofputil_table_map *);
> > > +const char *ofputil_table_map_get_name(const struct
> ofputil_table_map *,
> > > +   uint8_t);
> > > +uint8_t ofputil_table_map_get_number(const struct ofputil_table_map
> *,
> > > + const char *name);
> > > +void ofputil_table_map_put(struct ofputil_table_map *,
> > > +   uint8_t, const char *name);
> > > +void ofputil_table_map_destroy(struct ofputil_table_map *);
> > > +
> > >  /* Abstract ofp_table_mod. */
> > >  struct ofputil_table_mod {
> > >  uint8_t table_id; /* ID of the table, 0xff indicates all
> > > tables. */
> > > diff --git a/lib/ofp-util.c b/lib/ofp-util.c
> > > index 597112e4f84e..f3b2e3f6108c 100644
> > > --- a/lib/ofp-util.c
> > > +++ b/lib/ofp-util.c
> > > @@ -7454,12 +7454,14 @@ ofputil_port_to_string(ofp_port_t port,
> > >  snprintf(namebuf, bufsize, "%"PRIu32, port);
> > >  }
> > >
> > > -/* ofputil_port_map.  */
> > > -struct ofputil_port_map_node {
> > > +/* ofputil_name_map.  */
> > > +
> > > +struct ofputil_name_map_node {
> > >  struct hmap_node name_node;
> > >  struct hmap_node number_node;
> > > -ofp_port_t ofp_port;/* Port number. */
> > > -char *name; /* Port name. */
> > > +
> > > +uint32_t number;
> > > +char *name;
> > >
> > >  /* OpenFlow doesn't require port names to be unique, although
> that's
> > > the
> > >   * only sensible way.  However, even in Open vSwitch it's possible
> > > for two
> > > @@ -7469,22 +7471,25 @@ struct ofputil_port_map_node {
> > >   * corner case.
> > >   *
> > >   * OpenFlow does require port numbers to be unique.  We check for
> > > duplicate
> > > - * ports numbers just in case a switch has a bug. */
> > > + * ports numbers just in case a switch has a bug.
> > > + *
> > > + * OpenFlow doesn't require table names to be unique and Open
> vSwitch
> > > + * doesn't try to make them unique. */
> > >  bool duplicate;
> > >  };
> > >
> > > -void
> > > -ofputil_port_map_init(struct ofputil_port_map *map)
> > > +static void
> > > +ofputil_name_map_init(struct ofputil_name_map *map)
> > >  {
> > >  hmap_init(>by_name);
> > >  hmap_init(>by_number);
> > >  }
> > >
> > > -static struct 

Re: [ovs-dev] [PATCH v3 3/3] Support accepting and displaying table names in OVS tools.

[Yifeng Sun]

Thanks for the nice feature. It looks good to me.

Reviewed-by: Yifeng Sun 


On Wed, Jan 31, 2018 at 11:36 AM, Ben Pfaff  wrote:

> OpenFlow has little-known support for naming tables.  Open vSwitch has
> supported table names for ages, but it has never used or displayed them
> outside of commands dedicated to table manipulation.  This commit adds
> support for table names in ovs-ofctl.  When a table has a name, it displays
> that name in flows and actions, so that, for example, the following:
> table=1, arp, actions=resubmit(,2)
> might become:
> table=ingress_acl, arp, actions=resubmit(,mac_learning)
> given appropriately named tables.
>
> For backward compatibility, only interactive ovs-ofctl commands by default
> display table names; to display them in scripts, use the new --names
> option.
>
> This feature was inspired by a talk that Kei Nohguchi presented at Open
> vSwitch 2017 Fall Conference.
>
> CC: Kei Nohguchi 
> Signed-off-by: Ben Pfaff 
> ---
>  NEWS  |   8 ++
>  include/openvswitch/ofp-actions.h |   2 +
>  include/openvswitch/ofp-parse.h   |  20 ++-
>  include/openvswitch/ofp-print.h   |  12 +-
>  include/openvswitch/ofp-util.h|   8 ++
>  lib/learn.c   |  20 ++-
>  lib/learn.h   |   6 +-
>  lib/learning-switch.c |   2 +-
>  lib/ofp-actions.c |  45 +++---
>  lib/ofp-parse.c   |  80 +++
>  lib/ofp-print.c   | 202 --
>  lib/ofp-util.c| 109 --
>  lib/vconn.c   |  10 +-
>  ofproto/ofproto-dpif.c|   4 +-
>  ofproto/ofproto.c |   2 +-
>  ovn/controller/ofctrl.c   |  12 +-
>  ovn/controller/pinctrl.c  |   2 +-
>  ovn/utilities/ovn-sbctl.c |   2 +-
>  ovn/utilities/ovn-trace.c |   2 +-
>  tests/ofproto.at  |  89 
>  utilities/ovs-ofctl.8.in  |  90 +++-
>  utilities/ovs-ofctl.c | 294 ++
> +---
>  utilities/ovs-testcontroller.c|   2 +-
>  23 files changed, 736 insertions(+), 287 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 726589ce3896..d76958b8adc0 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -2,6 +2,14 @@ Post-v2.9.0
>  
>  - ovs-vswitchd:
>* New options --l7 and --l7-len to "ofproto/trace" command.
> +   - ovs-ofctl:
> + * ovs-ofctl now accepts and display table names in place of
> numbers.  By
> +   default it always accepts names and in interactive use it displays
> them;
> +   use --names or --no-names to override.  See ovs-ofctl(8) for
> details.
> +   - ovs-vswitchd:
> + * Previous versions gave OpenFlow tables default names of the form
> +   "table#".  These are not helpful names for the purpose of accepting
> +   and displaying table names, so now tables by default have no names.
>
>
>  v2.9.0 - xx xxx 
> diff --git a/include/openvswitch/ofp-actions.h b/include/openvswitch/ofp-
> actions.h
> index 454c705ccf73..cba027b1d945 100644
> --- a/include/openvswitch/ofp-actions.h
> +++ b/include/openvswitch/ofp-actions.h
> @@ -1068,6 +1068,7 @@ uint32_t ofpacts_get_meter(const struct ofpact[],
> size_t ofpacts_len);
>  struct ofpact_format_params {
>  /* Input. */
>  const struct ofputil_port_map *port_map;
> +const struct ofputil_table_map *table_map;
>
>  /* Output. */
>  struct ds *s;
> @@ -1080,6 +1081,7 @@ const char *ofpact_name(enum ofpact_type);
>  struct ofpact_parse_params {
>  /* Input. */
>  const struct ofputil_port_map *port_map;
> +const struct ofputil_table_map *table_map;
>
>  /* Output. */
>  struct ofpbuf *ofpacts;
> diff --git a/include/openvswitch/ofp-parse.h b/include/openvswitch/ofp-
> parse.h
> index 013a8f3edf70..c4228a50358f 100644
> --- a/include/openvswitch/ofp-parse.h
> +++ b/include/openvswitch/ofp-parse.h
> @@ -45,26 +45,33 @@ enum ofputil_protocol;
>
>  char *parse_ofp_str(struct ofputil_flow_mod *, int command, const char
> *str_,
>  const struct ofputil_port_map *,
> +const struct ofputil_table_map *,
>  enum ofputil_protocol *usable_protocols)
>  OVS_WARN_UNUSED_RESULT;
>
>  char *parse_ofp_flow_mod_str(struct ofputil_flow_mod *, const char
> *string,
> - const struct ofputil_port_map *, int command,
> + const struct ofputil_port_map *,
> + const struct ofputil_table_map *,
> + int command,
>   enum ofputil_protocol *usable_protocols)
>  OVS_WARN_UNUSED_RESULT;
>
>  char *parse_ofp_packet_out_str(struct ofputil_packet_out *po, const char
> *str_,
> const struct ofputil_port_map *,
> +

[ovs-dev] [PATCH V3] rhel: Fix support for root user using DPDK

[Marcos Felipe Schwarz]

 Since 2.8.0 OVS runs as non-root user on rhel distros, but the current
implementation breaks the ability to run as root with DPDK and as a
consequence there is no way possible to use UIO drivers on kernel 4.0 and
newer [1, 2].
[1] http://dpdk.org/browse/dpdk/commit/?id=cdc242f260e766
bd95a658b5e0686a62ec04f5b0
[2] https://www.kernel.org/doc/Documentation/vm/pagemap.txt

Fixes: e3e738a3d058 ("redhat: allow dpdk to also run as non-root user")
Signed-off-by: Marcos Schwarz 
Acked-by: Aaron Conole 
---
 lib/daemon-unix.c   | 3 ++-
 rhel/usr_lib_systemd_system_ovs-vswitchd.service.in | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/daemon-unix.c b/lib/daemon-unix.c
index adb549c98..06528e9ab 100644
--- a/lib/daemon-unix.c
+++ b/lib/daemon-unix.c
@@ -1047,5 +1047,6 @@ daemon_set_new_user(const char *user_spec)
 }
 }

-switch_user = true;
+if (!uid_verify(uid) || !gid_verify(gid))
+switch_user = true;
 }
diff --git a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in b/rhel/
usr_lib_systemd_system_ovs-vswitchd.service.in
index c6d9aa1b8..9b01c9271 100644
--- a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
+++ b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
@@ -14,7 +14,7 @@ Environment=HOME=/var/run/openvswitch
 EnvironmentFile=/etc/openvswitch/default.conf
 EnvironmentFile=-/etc/sysconfig/openvswitch
 @begin_dpdk@
-ExecStartPre=-/usr/bin/chown :hugetlbfs /dev/hugepages
+ExecStartPre=-/bin/sh -c '/usr/bin/chown :${OVS_USER_ID##*:}
/dev/hugepages'
 ExecStartPre=-/usr/bin/chmod 0775 /dev/hugepages
 @end_dpdk@
 ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \
--
2.16.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Póliza de Excel - 12 Temas

[Excel para Negocios]

Herramientas Indispensables de EXCEL para Negocios
RRHH, Contabilidad, Ventas, Cobranza y MUCHO MÁS
Este mes de Febrero le invitamos a adquirir una de nuestras pólizas de 
Capacitación online, los cuáles constan de 12 Temas que son utilizables durante 
3 meses, las 24 hrs del día, las veces que usted así lo requiera. En Específico 
le ofrecemos La póliza de Excel para Negocios.

Hoy en día millones de empresas en el mundo simplemente no podrían operar sin 
este programa, y para los actuales profesionales ya es casi un requisito 
excluyente no poseer los conocimientos necesarios en esta herramienta. 

1.- Microsoft, Excel y los Negocios.
2.- Un Repaso Por Excel Básico. 
3.- Avancemos Con Excel Intermedio.
4.- Excel Para Contabilidad.
5.- Excel Para Presupuestos.
6.- Excel Para Estados Financieros. 
7.- Excel Para Cuentas Por Cobrar Y Cuentas Por Pagar.
8.- Excel Para Tesorería.
9.- Excel Para rrhh, Nóminas Y Evaluaciones De Personal.
10.- Excel Para Compras, Almacenes E Inventarios.
11.- Excel Para Ventas, Comisiones Y Metas Comerciales.
12.- Excel para Indicadores –Balanced Scorecard– 



Para que usted recibá la información completa de esta póliza, le solicitamos 
por favor enviarnos la palabra Póliza -EXCEL junto los siguientes datos: 

Nombre:
Teléfono:
Empresa: 


Y le haremos llegar el Temario Completo para que usted revise más a detalle.

Centro telefónico: 018002129393



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

Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode

[Eric Garver]

On Thu, Feb 01, 2018 at 02:25:37AM +, Yang, Yi Y wrote:
> It still failed. Does "encap ip" require any special kernel module?

CONFIG_LWTUNNEL, but that should already be enabled for OVS.

I was unable to reproduce on RHEL-7.4 with a v4.13 kernel and iproute
4.11.0 (I also tried 4.9.0).

# uname -a
Linux dev-rhel7 4.13.0 #40 SMP Thu Feb 1 10:28:06 EST 2018 x86_64
x86_64 x86_64 GNU/Linux

# yum info iproute
Version : 4.11.0
Release : 13.el7

> 
> vagrant@gbpsfc4:~/ovs-nsh-test$ export 
> PATH=/home/vagrant/iproute2-4.9.0/ip:$PATH
> vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip link add dev at_vxlan1 type vxlan 
> dstport 4790 external gpe
> vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip addr add dev at_vxlan1 10.1.1.1/24
> vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip link set dev at_vxlan1 mtu 1450 up
> vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip route add 10.1.1.2/32 encap ip id 
> 0 dst 172.31.1.100 dev at_vxlan1
> RTNETLINK answers: Operation not supported
> vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip route add 10.1.1.2/32 encap ip id 
> 1 dst 172.31.1.100 dev at_vxlan1
> RTNETLINK answers: Operation not supported
> vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip route add 10.1.1.2/32 encap ip dst 
> 172.31.1.100 dev at_vxlan1
> RTNETLINK answers: Operation not supported
> vagrant@gbpsfc4:~/ovs-nsh-test$ lsmod
> Module  Size  Used by
> vxlan  53248  0
> ip6_udp_tunnel 16384  1 vxlan
> udp_tunnel 16384  1 vxlan
> ip6_tunnel 32768  0
> tunnel616384  1 ip6_tunnel
> ipip   16384  0
> tunnel416384  1 ipip
> ip_tunnel  24576  1 ipip
> veth   16384  0
> nf_conntrack_ipv6  20480  0
> nf_defrag_ipv6 36864  1 nf_conntrack_ipv6
> xt_addrtype16384  2
> xt_conntrack   16384  1
> ipt_MASQUERADE 16384  1
> nf_nat_masquerade_ipv416384  1 ipt_MASQUERADE
> iptable_nat16384  1
> dm_crypt   36864  0
> nf_conntrack_ipv4  16384  3
> nf_defrag_ipv4 16384  1 nf_conntrack_ipv4
> nf_nat_ipv416384  1 iptable_nat
> nf_nat 28672  2 nf_nat_masquerade_ipv4,nf_nat_ipv4
> nf_conntrack  131072  7 
> nf_conntrack_ipv6,nf_conntrack_ipv4,ipt_MASQUERADE,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat
> bridge143360  0
> stp16384  1 bridge
> llc16384  2 bridge,stp
> dm_thin_pool   65536  1
> dm_persistent_data 69632  1 dm_thin_pool
> dm_bio_prison  20480  1 dm_thin_pool
> dm_bufio   28672  1 dm_persistent_data
> libcrc32c  16384  3 nf_conntrack,dm_persistent_data,nf_nat
> nfsd  299008  2
> iptable_filter 16384  1
> ip_tables  24576  2 iptable_filter,iptable_nat
> x_tables   36864  5 
> ip_tables,iptable_filter,ipt_MASQUERADE,xt_addrtype,xt_conntrack
> auth_rpcgss57344  1 nfsd
> nfs_acl16384  1 nfsd
> nfs   241664  0
> lockd  90112  2 nfsd,nfs
> grace  16384  2 nfsd,lockd
> sunrpc327680  6 auth_rpcgss,nfsd,nfs_acl,lockd,nfs
> fscache65536  1 nfs
> psmouse   139264  0
> e1000 139264  0
> ppdev  20480  0
> parport_pc 32768  0
> i2c_piix4  24576  0
> mac_hid16384  0
> sb_edac24576  0
> serio_raw  16384  0
> lp 20480  0
> parport49152  3 lp,parport_pc,ppdev
> pata_acpi  16384  0
> video  40960  0
> vagrant@gbpsfc4:~/ovs-nsh-test$
> -Original Message-
> From: Eric Garver [mailto:e...@erig.me] 
> Sent: Thursday, February 1, 2018 5:10 AM
> To: Yang, Yi Y 
> Cc: d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel 
> compat mode
> 
> On Wed, Jan 31, 2018 at 02:12:14PM +, Yang, Yi Y wrote:
> > Hi, Eric
> > 
> > My kernel is 4.13.0-rc6, so I'm very sure it can support vxlan-gpe, I 
> > can add vxlan-gpe port without any issue by command line, so I don't 
> > know what happened.
> 
> Your output below indicates this is failing on this line:
> 
> 25  NS_CHECK_EXEC([at_ns0], [ip route add 10.1.1.2/32 encap ip id 0 dst 
> 172.31.1.100 dev at_vxlan1])
> 
> It does not appear to be an OVS issue. Maybe encap id 0 is not accepted on 
> older kernels. Try changing it to a non-zero value.
> 
> > 
> > Greg, I checked unit tests in tests/system-traffic.at and 
> > tests/system-layer3-tunnels.at for vxlan and vxlan-gpe, I think they are 
> > very tricky, for NSH, they won't work, current test infrastructure can't 
> > handle NSH unit test in kernel data path, so I don't think I can add it. I 
> > have posted v2 patch series, I have sfc test environment in my machine and 
> > have verified kernel data path, my 

Re: [ovs-dev] [PATCH v4] openvswitch: Remove padding from packet before L3+ conntrack processing

[David Miller]

From: Ed Swierk 
Date: Wed, 31 Jan 2018 18:48:02 -0800

> IPv4 and IPv6 packets may arrive with lower-layer padding that is not
> included in the L3 length. For example, a short IPv4 packet may have
> up to 6 bytes of padding following the IP payload when received on an
> Ethernet device with a minimum packet length of 64 bytes.
> 
> Higher-layer processing functions in netfilter (e.g. nf_ip_checksum(),
> and help() in nf_conntrack_ftp) assume skb->len reflects the length of
> the L3 header and payload, rather than referring back to
> ip_hdr->tot_len or ipv6_hdr->payload_len, and get confused by
> lower-layer padding.
> 
> In the normal IPv4 receive path, ip_rcv() trims the packet to
> ip_hdr->tot_len before invoking netfilter hooks. In the IPv6 receive
> path, ip6_rcv() does the same using ipv6_hdr->payload_len. Similarly
> in the br_netfilter receive path, br_validate_ipv4() and
> br_validate_ipv6() trim the packet to the L3 length before invoking
> netfilter hooks.
> 
> Currently in the OVS conntrack receive path, ovs_ct_execute() pulls
> the skb to the L3 header but does not trim it to the L3 length before
> calling nf_conntrack_in(NF_INET_PRE_ROUTING). When
> nf_conntrack_proto_tcp encounters a packet with lower-layer padding,
> nf_ip_checksum() fails causing a "nf_ct_tcp: bad TCP checksum" log
> message. While extra zero bytes don't affect the checksum, the length
> in the IP pseudoheader does. That length is based on skb->len, and
> without trimming, it doesn't match the length the sender used when
> computing the checksum.
> 
> In ovs_ct_execute(), trim the skb to the L3 length before higher-layer
> processing.
> 
> Signed-off-by: Ed Swierk 

Applied, thank you Ed.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev