date:20181022

[ovs-dev] [PATCH v1 3/3] [3/3]: Routing policies, ovn-northd changes to handle routing policy commands.

2018-10-22 Thread Mary Manohar

This Series:
Policy-Based Routing.

This Patch:
Changes in ovn-northd to handle routing policy commands.
---
 ovn/northd/ovn-northd.c | 144 ++--
 tests/ovn-nbctl.at  |  47 
 2 files changed, 185 insertions(+), 6 deletions(-)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 439651f..554ea2a 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -141,9 +141,10 @@ enum ovn_stage {
 PIPELINE_STAGE(ROUTER, IN,  ND_RA_OPTIONS,  5, "lr_in_nd_ra_options") \
 PIPELINE_STAGE(ROUTER, IN,  ND_RA_RESPONSE, 6, "lr_in_nd_ra_response") \
 PIPELINE_STAGE(ROUTER, IN,  IP_ROUTING, 7, "lr_in_ip_routing")   \
-PIPELINE_STAGE(ROUTER, IN,  ARP_RESOLVE,8, "lr_in_arp_resolve")  \
-PIPELINE_STAGE(ROUTER, IN,  GW_REDIRECT,9, "lr_in_gw_redirect")  \
-PIPELINE_STAGE(ROUTER, IN,  ARP_REQUEST,10, "lr_in_arp_request")  \
+PIPELINE_STAGE(ROUTER, IN,  POLICY, 8, "lr_in_policy")   \
+PIPELINE_STAGE(ROUTER, IN,  ARP_RESOLVE,9, "lr_in_arp_resolve")  \
+PIPELINE_STAGE(ROUTER, IN,  GW_REDIRECT,10, "lr_in_gw_redirect")  \
+PIPELINE_STAGE(ROUTER, IN,  ARP_REQUEST,11, "lr_in_arp_request")  \
   \
 /* Logical router egress stages. */   \
 PIPELINE_STAGE(ROUTER, OUT, UNDNAT,0, "lr_out_undnat")\
@@ -4598,6 +4599,111 @@ find_lrp_member_ip(const struct ovn_port *op, const 
char *ip_s)
 return NULL;
 }
 
+static struct ovn_port*
+get_outport_for_routing_policy_nexthop(struct ovn_datapath *od,
+   struct hmap *ports,
+   int priority, const char *nexthop)
+{
+if (nexthop == NULL)
+return NULL;
+
+unsigned int plen = 0;
+ovs_be32 nexthop_be32;
+/* Verify that the next hop is an IP address with an all-ones mask. */
+char *error = ip_parse_cidr(nexthop, _be32, );
+if (!error) {
+if (plen != 32) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
+VLOG_WARN_RL(, "bad next hop ip %s for routing policy "
+ "with priority %d, error: %s ",
+ nexthop, priority, error);
+return NULL;
+}
+} else {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
+VLOG_WARN_RL(, "Failed to parse cidr %s for routing policy "
+ "with priority %d ",
+ nexthop, priority);
+free(error);
+return NULL;
+}
+
+/* find the router port matching the next hop. */
+int i;
+struct ovn_port *out_port = NULL;
+const char *lrp_addr_s = NULL;
+for (i = 0; i < od->nbr->n_ports; i++) {
+   struct nbrec_logical_router_port *lrp = od->nbr->ports[i];
+   out_port = ovn_port_find(ports, lrp->name);
+   if (!out_port) {
+  /* This should not happen. */
+   continue;
+   }
+   lrp_addr_s = find_lrp_member_ip(out_port, nexthop);
+   if (lrp_addr_s) {
+break;
+   } else {
+   out_port = NULL;
+   }
+}
+if (!out_port) {
+/* There is no matched out port. */
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
+VLOG_WARN_RL(, "No path for routing policy priority %d; next hop 
%s",
+ priority, nexthop);
+return NULL;
+}
+return out_port;
+}
+
+static void
+build_routing_policy_flow(struct hmap *lflows, struct ovn_datapath *od,
+  struct hmap *ports,
+  const struct nbrec_logical_router_policy *rule)
+{
+struct ds match = DS_EMPTY_INITIALIZER;
+struct ds actions = DS_EMPTY_INITIALIZER;
+
+if (!strcmp(rule->action, "reroute")) {
+struct ovn_port *out_port = NULL;
+const char *lrp_addr_s = NULL;
+out_port = get_outport_for_routing_policy_nexthop(
+od, ports, rule->priority, rule->nexthop);
+if (out_port == NULL) {
+   return;
+} else {
+   lrp_addr_s = find_lrp_member_ip(out_port, rule->nexthop);
+   if (!lrp_addr_s) {
+   static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
+   VLOG_WARN_RL(, "lrp_addr not found for routing policy "
+" priority %d nexthop %s",
+rule->priority, rule->nexthop);
+   return;
+   } else {
+   ds_put_format(, "reg0 = %s; "
+  "reg1 = %s; "
+  "eth.src = %s; "
+  "outport = %s; "
+  "flags.loopback = 1; "
+  "next;",
+  rule->nexthop,
+  lrp_addr_s,
+  out_port->lrp_networks.ea_s,
+  out_port->json_key);
+   }
+}
+

[ovs-dev] [PATCH v1 1/3] [1/3]: Routing policies, add config in schema

2018-10-22 Thread Mary Manohar

This Series:
Policy-Based Routing.

This Patch:
Add routing policies in the northbound schema.
---
 ovn/ovn-nb.ovsschema | 20 -
 ovn/ovn-nb.xml   | 63 
 2 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/ovn/ovn-nb.ovsschema b/ovn/ovn-nb.ovsschema
index 705cc27..8465f12 100644
--- a/ovn/ovn-nb.ovsschema
+++ b/ovn/ovn-nb.ovsschema
@@ -1,7 +1,7 @@
 {
 "name": "OVN_Northbound",
 "version": "5.13.1",
-"cksum": "749176366 20467",
+"cksum": "3389984310 21532",
 "tables": {
 "NB_Global": {
 "columns": {
@@ -241,6 +241,11 @@
 "refType": "strong"},
"min": 0,
"max": "unlimited"}},
+"policies": {"type": {"key": {"type": "uuid",
+  "refTable": 
"Logical_Router_Policy",
+  "refType": "strong"},
+   "min": 0,
+   "max": "unlimited"}},
 "enabled": {"type": {"key": "boolean", "min": 0, "max": 1}},
 "nat": {"type": {"key": {"type": "uuid",
  "refTable": "NAT",
@@ -302,6 +307,19 @@
 "type": {"key": "string", "value": "string",
  "min": 0, "max": "unlimited"}}},
 "isRoot": false},
+"Logical_Router_Policy": {
+"columns": {
+"name": {"type": {"key": {"type": "string",
+  "maxLength": 63},
+  "min": 0, "max": 1}},
+"priority": {"type": {"key": {"type": "integer",
+  "minInteger": 0,
+  "maxInteger": 32767}}},
+"match": {"type": "string"},
+"action": {"type": {"key": {"type": "string",
+"enum": ["set", ["allow", "drop", 
"reroute"]]}}},
+"nexthop": {"type": {"key": "string", "min": 0, "max": 1}}},
+"isRoot": false},
 "NAT": {
 "columns": {
 "external_ip": {"type": "string"},
diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
index c0739fe..496bcf6 100644
--- a/ovn/ovn-nb.xml
+++ b/ovn/ovn-nb.xml
@@ -1225,6 +1225,10 @@
   One or more static routes for the router.
 
 
+
+  One or more routing policies for the router.
+
+
 
   This column is used to administratively set router state.  If this column
   is empty or is set to true, the router is enabled.  If this
@@ -1782,6 +1786,65 @@
 
   
 
+  
+
+  Each row in this table represents one routing policy for a logical router
+  that points to it through its  column.  The  column for the highest-
+  matching row in this table determines a packet's treatment.  If no row
+  matches, packets are allowed by default. (Default-deny treatment is
+  possible: add a rule with  0, 0 as
+  , and drop as .)
+
+ 
+  A name for the router policy.  Names are ASCII and must match
+  [a-zA-Z_.][a-zA-Z_.0-9]*.
+
+ 
+  
+The routing policy's priority.  Rules with numerically higher priority
+take precedence over those with lower. A rule is uniquely identified
+by the priority and match string.
+  
+
+ 
+  
+The packets that the routing policy should match, in the same 
expression
+language used for the  column in the OVN Southbound database's
+ table.  The
+outport logical port is only available in the
+to-lport direction (the inport is
+available in both directions).
+  
+   
+By default all traffic is allowed.  When writing a more
+restrictive policy, it is important to remember to allow flows
+such as ARP and IPv6 neighbor discovery packets.
+  
+
+ 
+  The action to take when the routing policy matches:
+  
+
+  allow: Forward the packet.
+
+ 
+  drop: Silently drop the packet.
+
+ 
+  reroute: Reroute packet to nexthop
+
+  
+
+ 
+  
+Nexthop IP address for this route.  Nexthop IP address should be the IP
+address of a connected router port or the IP address of a logical port.
+  
+
+  
+
   
 
   Each record represents a NAT rule.
-- 
1.8.3.1

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

[ovs-dev] [PATCH v1 2/3] [2/3] Routing policies, add routing-policies in ovn-nbctl

2018-10-22 Thread Mary Manohar

This Series:
Policy-Based Routing

This patch:
Add commands to ovn-nbctl to add/delete/list routing policies.

Routing-policy commands:
lr-policy-add ROUTER PRIORITY MATCH ACTION [NEXTHOP]
add a policy to router
lr-policy-del ROUTER [PRIORITY [MATCH]]
lr-policy-list ROUTER print policies for ROUTER
lr-policy-add : A policy is uniquely identified by priority and match.
Multiple policies can have the same priority.

lr-policy-del : takes priority and match as optional parameters. If priority is 
not specified, all the rules would be deleted. If priority is specified, all 
rules with that priority are deleted. If priority and match are specified, the 
policy with the given priority and match is deleted.

lr-policy-list : mandates ROUTER parameter.

Sample CLI:
ovn-nbctl lr-policy-add lr1 10 "ip4.src == 1.1.1.0/24" drop
ovn-nbctl lr-policy-del lr1 10
ovn-nbctl lr-policy-list lr1
---
 ovn/utilities/ovn-nbctl.c | 196 ++
 1 file changed, 196 insertions(+)

diff --git a/ovn/utilities/ovn-nbctl.c b/ovn/utilities/ovn-nbctl.c
index 798c972..920024b 100644
--- a/ovn/utilities/ovn-nbctl.c
+++ b/ovn/utilities/ovn-nbctl.c
@@ -642,6 +642,13 @@ Route commands:\n\
 remove routes from ROUTER\n\
   lr-route-list ROUTER  print routes for ROUTER\n\
 \n\
+Policy commands:\n\
+  lr-policy-add ROUTER PRIORITY MATCH ACTION [NEXTHOP]\n\
+add a policy to router\n\
+  lr-policy-del ROUTER [PRIORITY [MATCH]]\n\
+remove policies from ROUTER\n\
+  lr-policy-list ROUTER   print policies for ROUTER\n\
+\n\
 NAT commands:\n\
   lr-nat-add ROUTER TYPE EXTERNAL_IP LOGICAL_IP [LOGICAL_PORT EXTERNAL_MAC]\n\
 add a NAT to ROUTER\n\
@@ -3395,6 +3402,187 @@ normalize_prefix_str(const char *orig_prefix)
 return normalize_ipv6_prefix(ipv6, plen);
 }
 }
+
+static void
+nbctl_lr_policy_add(struct ctl_context *ctx)
+{
+const struct nbrec_logical_router *lr;
+int64_t priority = 0;
+char *error = lr_by_name_or_uuid(ctx, ctx->argv[1], true, );
+if (error) {
+ctx->error = error;
+return;
+}
+error = parse_priority(ctx->argv[2], );
+if (error) {
+ctx->error = error;
+return;
+}
+const char *action = ctx->argv[4];
+char *next_hop = NULL;
+/* Validate action. */
+if (strcmp(action, "allow") && strcmp(action, "drop")
+&& strcmp(action, "reroute")) {
+ctl_error(ctx, "%s: action must be one of \"allow\", \"drop\", "
+  "and \"reroute\"", action);
+}
+if (!strcmp(action, "reroute")) {
+if (ctx->argc < 6) {
+ctl_error(ctx, "Nexthop is not specified when action is reroute.");
+}
+}
+/* Check if same routing policy already exists. 
+ * A policy is uniquely identified by priority and match */
+for (int i = 0; i < lr->n_policies; i++) {
+const struct nbrec_logical_router_policy *policy = lr->policies[i];
+if ((policy->priority == priority) &&
+(!strcmp(policy->match, ctx->argv[3]))) {
+   ctl_error(ctx, "Same routing policy already existed on the "
+   "logical router %s.", ctx->argv[1]);
+}
+}
+if (ctx->argc == 6) {
+next_hop = normalize_prefix_str(ctx->argv[5]);
+if (!next_hop) {
+ctl_error(ctx, "bad next hop argument: %s", ctx->argv[5]);
+}
+}
+struct nbrec_logical_router_policy *policy;
+policy = nbrec_logical_router_policy_insert(ctx->txn);
+nbrec_logical_router_policy_set_priority(policy, priority);
+nbrec_logical_router_policy_set_match(policy, ctx->argv[3]);
+nbrec_logical_router_policy_set_action(policy, action);
+if (ctx->argc == 6) {
+nbrec_logical_router_policy_set_nexthop(policy, next_hop);
+}
+nbrec_logical_router_verify_policies(lr);
+struct nbrec_logical_router_policy **new_policies
+= xmalloc(sizeof *new_policies * (lr->n_policies + 1));
+memcpy(new_policies, lr->policies,
+   sizeof *new_policies * lr->n_policies);
+new_policies[lr->n_policies] = policy;
+nbrec_logical_router_set_policies(lr, new_policies,
+   lr->n_policies + 1);
+free(new_policies);
+if (next_hop != NULL)
+free(next_hop);
+}
+
+static void
+nbctl_lr_policy_del(struct ctl_context *ctx)
+{
+const struct nbrec_logical_router *lr;
+int64_t priority = 0;
+char *error = lr_by_name_or_uuid(ctx, ctx->argv[1], true, );
+if (error) {
+ctx->error = error;
+return;
+}
+ if (ctx->argc == 2) {
+/* If a priority is not specified, delete all policies. */
+nbrec_logical_router_set_policies(lr, NULL, 0);
+return;
+}
+error = parse_priority(ctx->argv[2], );
+if (error) {
+ctx->error = error;
+return;
+}
+/* If match is not

[ovs-dev] [PATCH v1 0/3] Policy-based routing

2018-10-22 Thread Mary Manohar

This patch series implements policy-based routing.
Policy-based routing (PBR) provides a mechanism to configure permit/deny and 
reroute policies on the router.
Permit/deny policies are similar to OVN ACLs, but exist on the logical-router.
Reroute policies are needed for service-insertion and service-chaining.
Currently, we support only stateless policies.

To achieve this, we introduced a new table in the ingress pipeline of the 
Logical-router.
The new table is between the ‘IP Routing’ and the ‘ARP/ND resolution’ table.
This way, PBR can override routing decisions and provide a different next-hop.

Mary Manohar (3):
  [1/3]: Routing policies, add config in schema
  [2/3] Routing policies, add routing-policies in ovn-nbctl
  [3/3]: Routing policies, ovn-northd changes to handle routing policy
commands.

 ovn/northd/ovn-northd.c   | 144 --
 ovn/ovn-nb.ovsschema  |  20 -
 ovn/ovn-nb.xml|  63 +++
 ovn/utilities/ovn-nbctl.c | 196 ++
 tests/ovn-nbctl.at|  47 +++
 5 files changed, 463 insertions(+), 7 deletions(-)

-- 
1.8.3.1

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

Re: [ovs-dev] [v2.10 1/2] Set release date for 2.10.1.

2018-10-22 Thread Ben Pfaff

On Mon, Oct 22, 2018 at 10:42:19AM +0100, Markos Chandras wrote:
> Hello Justin,
> 
> On 20/10/2018 00:51, Justin Pettit wrote:
> > 
> >> On Oct 17, 2018, at 9:47 AM, Ben Pfaff  wrote:
> >>
> >> All of these seem fine to me.
> > 
> > Thanks. I pushed them to all the various branches. I’ll get the releases 
> > out soon. 
> > 
> > --Justin
> > 
> 
> Could you also push the tags for these releases as well? Thank you

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

Re: [ovs-dev] [PATCH] ovn-nbctl: Fix the ovn-nbctl test "LBs - daemon" which fails during rpm build

2018-10-22 Thread Mark Michelson


On 10/22/2018 11:49 AM, nusid...@redhat.com wrote:

From: Numan Siddique 

The test "ovn-nbctl: LBs - daemon" fails when it runs the command
"ovn-nbctl lb-add lb0 30.0.0.1a 192.168.10.10:80,192.168.10.20:80". ovn-nbctl
extracts the vip by calling the socket util function 'inet_parse_active()',
and this function blocks when it calls dns_resolve(). It blocks because
networking is disabled with mock rpm build.

To address this issue, this patch adds a new function -
inet_parse_active_address_and_port() which expects IP:[port] address
in the 'target_' argument and disables resolving the host.

This new function is now used in ovn-northd and ovn-nbctl. It is fine to
use this function as load balancer VIP cannot be a hostname.


I think the change should also be made in ovn-trace.c, parse_lb_option().



Reported-by: Timothy Redaelli 
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1641672
Signed-off-by: Numan Siddique 
---
  lib/socket-util.c | 49 ---
  lib/socket-util.h |  2 ++
  ovn/northd/ovn-northd.c   |  2 +-
  ovn/utilities/ovn-nbctl.c |  6 ++---
  4 files changed, 42 insertions(+), 17 deletions(-)

diff --git a/lib/socket-util.c b/lib/socket-util.c
index df9b01a9e..fcd1e5dc5 100644
--- a/lib/socket-util.c
+++ b/lib/socket-util.c
@@ -512,18 +512,9 @@ exit:
  return false;
  }
  
-/* Parses 'target', which should be a string in the format "[:]".

- * , which is required, may be an IPv4 address or an IPv6 address
- * enclosed in square brackets.  If 'default_port' is nonnegative then 
- * is optional and defaults to 'default_port' (use 0 to make the kernel choose
- * an available port, although this isn't usually appropriate for active
- * connections).  If 'default_port' is negative, then  is required.
- *
- * On success, returns true and stores the parsed remote address into '*ss'.
- * On failure, logs an error, stores zeros into '*ss', and returns false. */
-bool
-inet_parse_active(const char *target_, int default_port,
-  struct sockaddr_storage *ss)
+static bool
+inet_parse_active__(const char *target_, int default_port,
+  struct sockaddr_storage *ss, bool resolve_host)
  {
  char *target = xstrdup(target_);
  char *port, *host;
@@ -538,7 +529,7 @@ inet_parse_active(const char *target_, int default_port,
  ok = false;
  } else {
  ok = parse_sockaddr_components(ss, host, port, default_port,
-   target_, true);
+   target_, resolve_host);
  }
  if (!ok) {
  memset(ss, 0, sizeof *ss);
@@ -547,6 +538,38 @@ inet_parse_active(const char *target_, int default_port,
  return ok;
  }
  
+/* Parses 'target', which should be a string in the format "[:]".

+ * , which is required, may be an IPv4 address or an IPv6 address


I see that the difference between this and 
inet_parse_active_address_and_port() is that you use the term  
instead of . However, the text still only mentions that  may 
be an IPv4 or IPv6 address. I think also specifying that a hostname is 
accepted would make the description more clear.



+ * enclosed in square brackets.  If 'default_port' is nonnegative then 
+ * is optional and defaults to 'default_port' (use 0 to make the kernel choose
+ * an available port, although this isn't usually appropriate for active
+ * connections).  If 'default_port' is negative, then  is required.
+ *
+ * On success, returns true and stores the parsed remote address into '*ss'.
+ * On failure, logs an error, stores zeros into '*ss', and returns false. */
+bool
+inet_parse_active(const char *target_, int default_port,
+  struct sockaddr_storage *ss)
+{
+return inet_parse_active__(target_, default_port, ss, true);
+}
+
+/* Parses 'target', which should be a string in the format "[:]".
+ * , which is required, should be an IPv4 address or an IPv6 address
+ * and may be enclosed in square brackets.  If 'default_port' is nonnegative
+ * then  is optional and defaults to 'default_port' (use 0 to make the
+ * kernel choose an available port, although this isn't usually appropriate for
+ * active connections).  If 'default_port' is negative, then  is
+ * required.
+ *
+ * On success, returns true and stores the parsed remote address into '*ss'.
+ * On failure, logs an error, stores zeros into '*ss', and returns false. */
+bool
+inet_parse_active_address_and_port(const char *target_, int default_port,
+   struct sockaddr_storage *ss)
+{
+return inet_parse_active__(target_, default_port, ss, false);
+}
  
  /* Opens a non-blocking IPv4 or IPv6 socket of the specified 'style' and

   * connects to 'target', which should be a string in the format
diff --git a/lib/socket-util.h b/lib/socket-util.h
index 6d386304d..447a12cfc 100644
--- a/lib/socket-util.h
+++ b/lib/socket-util.h
@@ -50,6 +50,8 @@ void inet_parse_host_port_tokens(char *s, char **hostp,

Re: [ovs-dev] [PATCH] ovn-nbctl: Fix the ovn-nbctl test "LBs - daemon" which fails during rpm build

2018-10-22 Thread Timothy Redaelli

On Mon, 22 Oct 2018 21:19:35 +0530
nusid...@redhat.com wrote:

> From: Numan Siddique 
> 
> The test "ovn-nbctl: LBs - daemon" fails when it runs the command
> "ovn-nbctl lb-add lb0 30.0.0.1a 192.168.10.10:80,192.168.10.20:80". ovn-nbctl
> extracts the vip by calling the socket util function 'inet_parse_active()',
> and this function blocks when it calls dns_resolve(). It blocks because
> networking is disabled with mock rpm build.
> 
> To address this issue, this patch adds a new function -
> inet_parse_active_address_and_port() which expects IP:[port] address
> in the 'target_' argument and disables resolving the host.
> 
> This new function is now used in ovn-northd and ovn-nbctl. It is fine to
> use this function as load balancer VIP cannot be a hostname.
> 
> Reported-by: Timothy Redaelli 
> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1641672
> Signed-off-by: Numan Siddique 
> ---

Hi,
I tested this both by building an OVS package with mock (with make
check enabled) and manually using the following command lines:

$ cd ovs
$ ./boot.sh && ./configure && make -j$(nproc)
$ sudo unshare -mn -- sh -c 'ip addr add dev lo 127.0.0.1 && \
  mount --bind /dev/null /etc/resolv.conf && runuser $SUDO_USER'
$ make sandbox SANDBOXFLAGS="--ovn"
$ ovn-nbctl -vsocket_util:off lb-add lb0 30.0.0.1a \
  192.168.10.10:80,192.168.10.20:80

Without this patch the 'ovn-nbctl' command stay blocked for more than
1 minutes. strace shows up it's trying to contact 127.0.0.1 on port 53
in order to resolve "30.0.0.1a".

With this patch, instead, the 'ovn-nbctl' command instantaneously
returns with retcode = 1 and "ovn-nbctl: 30.0.0.1a: should be an IP
address (or an IP address and a port number with : as a separator)." is
printed on stderr.

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

[ovs-dev] [PATCH] ovn-nbctl: Fix the ovn-nbctl test "LBs - daemon" which fails during rpm build

2018-10-22 Thread nusiddiq

From: Numan Siddique 

The test "ovn-nbctl: LBs - daemon" fails when it runs the command
"ovn-nbctl lb-add lb0 30.0.0.1a 192.168.10.10:80,192.168.10.20:80". ovn-nbctl
extracts the vip by calling the socket util function 'inet_parse_active()',
and this function blocks when it calls dns_resolve(). It blocks because
networking is disabled with mock rpm build.

To address this issue, this patch adds a new function -
inet_parse_active_address_and_port() which expects IP:[port] address
in the 'target_' argument and disables resolving the host.

This new function is now used in ovn-northd and ovn-nbctl. It is fine to
use this function as load balancer VIP cannot be a hostname.

Reported-by: Timothy Redaelli 
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1641672
Signed-off-by: Numan Siddique 
---
 lib/socket-util.c | 49 ---
 lib/socket-util.h |  2 ++
 ovn/northd/ovn-northd.c   |  2 +-
 ovn/utilities/ovn-nbctl.c |  6 ++---
 4 files changed, 42 insertions(+), 17 deletions(-)

diff --git a/lib/socket-util.c b/lib/socket-util.c
index df9b01a9e..fcd1e5dc5 100644
--- a/lib/socket-util.c
+++ b/lib/socket-util.c
@@ -512,18 +512,9 @@ exit:
 return false;
 }
 
-/* Parses 'target', which should be a string in the format "[:]".
- * , which is required, may be an IPv4 address or an IPv6 address
- * enclosed in square brackets.  If 'default_port' is nonnegative then 
- * is optional and defaults to 'default_port' (use 0 to make the kernel choose
- * an available port, although this isn't usually appropriate for active
- * connections).  If 'default_port' is negative, then  is required.
- *
- * On success, returns true and stores the parsed remote address into '*ss'.
- * On failure, logs an error, stores zeros into '*ss', and returns false. */
-bool
-inet_parse_active(const char *target_, int default_port,
-  struct sockaddr_storage *ss)
+static bool
+inet_parse_active__(const char *target_, int default_port,
+  struct sockaddr_storage *ss, bool resolve_host)
 {
 char *target = xstrdup(target_);
 char *port, *host;
@@ -538,7 +529,7 @@ inet_parse_active(const char *target_, int default_port,
 ok = false;
 } else {
 ok = parse_sockaddr_components(ss, host, port, default_port,
-   target_, true);
+   target_, resolve_host);
 }
 if (!ok) {
 memset(ss, 0, sizeof *ss);
@@ -547,6 +538,38 @@ inet_parse_active(const char *target_, int default_port,
 return ok;
 }
 
+/* Parses 'target', which should be a string in the format "[:]".
+ * , which is required, may be an IPv4 address or an IPv6 address
+ * enclosed in square brackets.  If 'default_port' is nonnegative then 
+ * is optional and defaults to 'default_port' (use 0 to make the kernel choose
+ * an available port, although this isn't usually appropriate for active
+ * connections).  If 'default_port' is negative, then  is required.
+ *
+ * On success, returns true and stores the parsed remote address into '*ss'.
+ * On failure, logs an error, stores zeros into '*ss', and returns false. */
+bool
+inet_parse_active(const char *target_, int default_port,
+  struct sockaddr_storage *ss)
+{
+return inet_parse_active__(target_, default_port, ss, true);
+}
+
+/* Parses 'target', which should be a string in the format "[:]".
+ * , which is required, should be an IPv4 address or an IPv6 address
+ * and may be enclosed in square brackets.  If 'default_port' is nonnegative
+ * then  is optional and defaults to 'default_port' (use 0 to make the
+ * kernel choose an available port, although this isn't usually appropriate for
+ * active connections).  If 'default_port' is negative, then  is
+ * required.
+ *
+ * On success, returns true and stores the parsed remote address into '*ss'.
+ * On failure, logs an error, stores zeros into '*ss', and returns false. */
+bool
+inet_parse_active_address_and_port(const char *target_, int default_port,
+   struct sockaddr_storage *ss)
+{
+return inet_parse_active__(target_, default_port, ss, false);
+}
 
 /* Opens a non-blocking IPv4 or IPv6 socket of the specified 'style' and
  * connects to 'target', which should be a string in the format
diff --git a/lib/socket-util.h b/lib/socket-util.h
index 6d386304d..447a12cfc 100644
--- a/lib/socket-util.h
+++ b/lib/socket-util.h
@@ -50,6 +50,8 @@ void inet_parse_host_port_tokens(char *s, char **hostp, char 
**portp);
 void inet_parse_port_host_tokens(char *s, char **portp, char **hostp);
 bool inet_parse_active(const char *target, int default_port,
struct sockaddr_storage *ssp);
+bool inet_parse_active_address_and_port(const char *target, int default_port,
+struct sockaddr_storage *ssp);
 int inet_open_active(int style, const char *target, int default_port,

Re: [ovs-dev] OVS-DPDK public meeting

2018-10-22 Thread Kevin Traynor

Next meeting 14th November 2018 16:00 UTC.

Minutes for 17th October (apologies for delay)
Attendees: Johann, Flavio, Simon, Pieter, Ian, Frikkie, Tiago, Yipeng,
Jason, Ophir, Tiago, Kevin.

===
GENERAL
===
- 16.11 eol
-- 16.11.9 (Dec) is the last planned stable release for DPDK 16.11
-- fyi OVS 2.7 uses this

- Latest dot releases for 16.11/17.11
-- they have new stable bugfix releases
-- patches submitted for it
-- should be straightforward
-- Kevin to review
-- (since merged)

OVS release dates are here
-
http://docs.openvswitch.org/en/latest/internals/release-process/#release-scheduling


PERFORMANCE/FEATURES

- dpdk-latest branch
-- Ian is planning to rebase at the end of each week
-- Ophir talked about the dev_attach/detach deprecation..
-- It is intended that by 18.11 release, there will be an
non-experimental alternatives

- dpdk-hwol branch
-- hwol is wip
-- Ian discussing internally who will be looking at hwol

- 0-day
-- positive reaction so far from DPDK lab folks to running some 0-day
checks in the DPDK lab

- Ericsson PMD auto-load balancing (Kevin)
-- New RFC for this feature submitted by Ericsson
-- Needs reviews
-- Kevin planning to review

On 07/25/2017 02:25 PM, Kevin Traynor wrote:
> Hi All,
> 
> The OVS-DPDK public meetings have moved to Wednesday's at the same time.
> Everyone is welcome, it's a chance to share status/plans etc.
> 
> It's scheduled for every 2 weeks starting 26th July. Meeting time is
> currently @ 4pm UTC.
> 
> You can connect through Bluejeans or through dial in:
> 
> https://bluejeans.com/139318596
> 
> US: +1.408.740.7256 
> UK: +44.203.608.5256 
> Germany: +49.32.221.091256 
> Ireland: +353.1.697.1256 
> Other numbers at https://www.bluejeans.com/numbers
> Meeting ID: 139318596
> 
> thanks,
> Kevin.
> 

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

[ovs-dev] Issues configuring OVS-DPDK in openstack queens

2018-10-22 Thread Manojawa Paritala

Hello All,

On a 3 node (one controller + 2 compute), we configured Openstack
Queens using OSA with OVS. On all the nodes, we defined br-mgmt as
linux bridge, br-tun as private network and br-flat as external.
Installation was successful and we could create networks and
instances on Openstack.

Below are the versions of the OVS packages used on each node.

Controller :- openstack-vswitch - 2.9.0
Computes :- openstack-vswitch-dpdk - 2.9.0 (as we wanted to
configure dpdk on the compute hosts)

The openstack-vswitch-dpdk 2.9.0 package that we installed
had dpdk version 17.11.3. When we tried to enable DPDK it failed
with the below error.

dpdk|ERR|DPDK not supported in this copy of Open vSwitch

So, we downloaded the sources for dpdk 17.11.4 and openvswitch 2.9.2,
built openvswitch with dpdk as suggested in the below official link.
No issues on Openstack or OVS.
http://docs.openvswitch.org/en/latest/intro/install/dpdk/

Then, we added the below parameters to OVS and everything looked ok.
No issues in Openstack or OVS.

$ovs-vsctl get Open_vSwitch . other_config
{dpdk-extra="-n 2", dpdk-init="true", dpdk-lcore-mask="0x3000",
dpdk-socket-mem="4096,4096", pmd-cpu-mask="0xf3c",
vhost-iommu-support="true"}

Then on the compute node, in openvswitch_agent.ini file - OVS section,
I added the below (based on the link
https://docs.openstack.org/neutron/pike/contributor/internals/ovs_vhostuser.html
)
and restarted neutron-openmvswitch-agent service.

datapath_type=netdev
vhostuser_socket_dir=/var/run/openvswitch

After the above change, bridge br-flat is getting deleted from OVS.
Attached are the logs after I restart the neutron-openmvswitch-agent
service on the compute now. Not sure what the issue is.

Can any of you please let me know if we are missing anything?

Best Regards,
PVMJ
2018-10-22T13:55:28.531Z|00338|rconn|INFO|br-flat1<->tcp:127.0.0.1:6633: 
connection closed by peer
2018-10-22T13:55:28.532Z|00339|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: 
connection closed by peer
2018-10-22T13:55:28.532Z|00340|rconn|INFO|br-vlan<->tcp:127.0.0.1:6633: 
connection closed by peer
2018-10-22T13:55:28.532Z|00341|rconn|INFO|br-int<->tcp:127.0.0.1:6633: 
connection closed by peer
2018-10-22T13:55:28.532Z|00342|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: 
connection closed by peer
2018-10-22T13:55:28.823Z|00343|rconn|INFO|br-flat1<->tcp:127.0.0.1:6633: 
connecting...
2018-10-22T13:55:28.823Z|00344|rconn|WARN|br-flat1<->tcp:127.0.0.1:6633: 
connection failed (Connection refused)
2018-10-22T13:55:28.823Z|00345|rconn|INFO|br-flat1<->tcp:127.0.0.1:6633: 
waiting 2 seconds before reconnect
2018-10-22T13:55:28.824Z|00346|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: 
connecting...
2018-10-22T13:55:28.824Z|00347|rconn|WARN|br-vxlan<->tcp:127.0.0.1:6633: 
connection failed (Connection refused)
2018-10-22T13:55:28.824Z|00348|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: 
waiting 2 seconds before reconnect
2018-10-22T13:55:28.824Z|00349|rconn|INFO|br-vlan<->tcp:127.0.0.1:6633: 
connecting...
2018-10-22T13:55:28.824Z|00350|rconn|WARN|br-vlan<->tcp:127.0.0.1:6633: 
connection failed (Connection refused)
2018-10-22T13:55:28.824Z|00351|rconn|INFO|br-vlan<->tcp:127.0.0.1:6633: waiting 
2 seconds before reconnect
2018-10-22T13:55:28.824Z|00352|rconn|INFO|br-int<->tcp:127.0.0.1:6633: 
connecting...
2018-10-22T13:55:28.824Z|00353|rconn|WARN|br-int<->tcp:127.0.0.1:6633: 
connection failed (Connection refused)
2018-10-22T13:55:28.824Z|00354|rconn|INFO|br-int<->tcp:127.0.0.1:6633: waiting 
2 seconds before reconnect
2018-10-22T13:55:28.824Z|00355|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: 
connecting...
2018-10-22T13:55:28.824Z|00356|rconn|WARN|br-tun<->tcp:127.0.0.1:6633: 
connection failed (Connection refused)
2018-10-22T13:55:28.824Z|00357|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: waiting 
2 seconds before reconnect
2018-10-22T13:55:30.823Z|00358|rconn|INFO|br-flat1<->tcp:127.0.0.1:6633: 
connecting...
2018-10-22T13:55:30.823Z|00359|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: 
connecting...
2018-10-22T13:55:30.823Z|00360|rconn|INFO|br-vlan<->tcp:127.0.0.1:6633: 
connecting...
2018-10-22T13:55:30.824Z|00361|rconn|INFO|br-int<->tcp:127.0.0.1:6633: 
connecting...
2018-10-22T13:55:30.824Z|00362|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: 
connecting...
2018-10-22T13:55:30.870Z|00363|rconn|INFO|br-flat1<->tcp:127.0.0.1:6633: 
connected
2018-10-22T13:55:30.870Z|00364|rconn|INFO|br-vxlan<->tcp:127.0.0.1:6633: 
connected
2018-10-22T13:55:30.870Z|00365|rconn|INFO|br-vlan<->tcp:127.0.0.1:6633: 
connected
2018-10-22T13:55:30.871Z|00366|rconn|INFO|br-int<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:30.871Z|00367|rconn|INFO|br-tun<->tcp:127.0.0.1:6633: connected
2018-10-22T13:55:30.939Z|00368|bridge|INFO|bridge br-int: deleted interface 
int-br-vlan on port 2
2018-10-22T13:55:30.940Z|00369|bridge|INFO|bridge br-int: deleted interface 
br-int on port 65534
2018-10-22T13:55:30.940Z|00370|bridge|INFO|bridge br-int: deleted interface 
patch-tun on port 4

Re: [ovs-dev] [PATCH v11 06/14] dp-packet: Handle multi-seg mbufs in helper funcs.

2018-10-22 Thread Stokes, Ian

> Most helper functions in dp-packet assume that the data held by a
> dp_packet is contiguous, and perform operations such as pointer arithmetic
> under that assumption. However, with the introduction of multi-segment
> mbufs, where data is non-contiguous, such assumptions are no longer
> possible. Some examples of Such helper functions are dp_packet_tail(),
> dp_packet_tailroom(), dp_packet_end(),
> dp_packet_get_allocated() and dp_packet_at().
> 
> Thus, instead of assuming contiguous data in dp_packet, they  now iterate
> over the (non-contiguous) data in mbufs to perform their calculations.
> 
> Finally, dp_packet_use__() has also been modified to perform the
> initialisation of the packet (and setting the source) before continuing to
> set its size and data length, which now depends on the type of packet.
> 
> Co-authored-by: Mark Kavanagh 
> 
> Signed-off-by: Mark Kavanagh 
> Signed-off-by: Tiago Lam 
> Acked-by: Eelco Chaudron 
> Acked-by: Flavio Leitner 

Thanks for this Tiago,

It looks ok on inspection, will need a rebase however in the next revision.

Ian

> ---
>  lib/dp-packet.c |   4 +-
>  lib/dp-packet.h | 191
> +++-
>  2 files changed, 177 insertions(+), 18 deletions(-)
> 
> diff --git a/lib/dp-packet.c b/lib/dp-packet.c index 782e7c2..2aaeaae
> 100644
> --- a/lib/dp-packet.c
> +++ b/lib/dp-packet.c
> @@ -41,11 +41,11 @@ static void
>  dp_packet_use__(struct dp_packet *b, void *base, size_t allocated,
>   enum dp_packet_source source)  {
> +dp_packet_init__(b, allocated, source);
> +
>  dp_packet_set_base(b, base);
>  dp_packet_set_data(b, base);
>  dp_packet_set_size(b, 0);
> -
> -dp_packet_init__(b, allocated, source);
>  }
> 
>  /* Initializes 'b' as an empty dp_packet that contains the 'allocated'
> bytes of diff --git a/lib/dp-packet.h b/lib/dp-packet.h index
> 223efe2..78c6f7f 100644
> --- a/lib/dp-packet.h
> +++ b/lib/dp-packet.h
> @@ -133,6 +133,10 @@ static inline void *dp_packet_at(const struct
> dp_packet *, size_t offset,
>   size_t size);  static inline void
> *dp_packet_at_assert(const struct dp_packet *,
>  size_t offset, size_t size);
> +#ifdef DPDK_NETDEV
> +static inline const struct rte_mbuf *
> +dp_packet_mbuf_from_offset(const struct dp_packet *b, size_t *offset);
> +#endif
>  static inline void *dp_packet_tail(const struct dp_packet *);  static
> inline void *dp_packet_end(const struct dp_packet *);
> 
> @@ -185,9 +189,25 @@ dp_packet_delete(struct dp_packet *b)  static inline
> void *  dp_packet_at(const struct dp_packet *b, size_t offset, size_t
> size)  {
> -return offset + size <= dp_packet_size(b)
> -   ? (char *) dp_packet_data(b) + offset
> -   : NULL;
> +if (offset + size > dp_packet_size(b)) {
> +return NULL;
> +}
> +
> +#ifdef DPDK_NETDEV
> +if (b->source == DPBUF_DPDK) {
> +struct rte_mbuf *buf = CONST_CAST(struct rte_mbuf *, >mbuf);
> +
> +while (buf && offset > buf->data_len) {
> +offset -= buf->data_len;
> +
> +buf = buf->next;
> +}
> +
> +return buf ? rte_pktmbuf_mtod_offset(buf, char *, offset) : NULL;
> +}
> +#endif
> +
> +return (char *) dp_packet_data(b) + offset;
>  }
> 
>  /* Returns a pointer to byte 'offset' in 'b', which must contain at least
> @@ -196,13 +216,23 @@ static inline void *  dp_packet_at_assert(const
> struct dp_packet *b, size_t offset, size_t size)  {
>  ovs_assert(offset + size <= dp_packet_size(b));
> -return ((char *) dp_packet_data(b)) + offset;
> +return dp_packet_at(b, offset, size);
>  }
> 
>  /* Returns a pointer to byte following the last byte of data in use in
> 'b'. */  static inline void *  dp_packet_tail(const struct dp_packet *b)
> {
> +#ifdef DPDK_NETDEV
> +if (b->source == DPBUF_DPDK) {
> +struct rte_mbuf *buf = CONST_CAST(struct rte_mbuf *, >mbuf);
> +/* Find last segment where data ends, meaning the tail of the
> chained
> + *  mbufs must be there */
> +buf = rte_pktmbuf_lastseg(buf);
> +
> +return rte_pktmbuf_mtod_offset(buf, void *, buf->data_len);
> +}
> +#endif
>  return (char *) dp_packet_data(b) + dp_packet_size(b);  }
> 
> @@ -211,6 +241,15 @@ dp_packet_tail(const struct dp_packet *b)  static
> inline void *  dp_packet_end(const struct dp_packet *b)  {
> +#ifdef DPDK_NETDEV
> +if (b->source == DPBUF_DPDK) {
> +struct rte_mbuf *buf = CONST_CAST(struct rte_mbuf *,
> +&(b->mbuf));
> +
> +buf = rte_pktmbuf_lastseg(buf);
> +
> +return (char *) buf->buf_addr + buf->buf_len;
> +}
> +#endif
>  return (char *) dp_packet_base(b) + dp_packet_get_allocated(b);  }
> 
> @@ -236,6 +275,15 @@ dp_packet_tailroom(const struct dp_packet *b)  static
> inline void  dp_packet_clear(struct dp_packet *b)  {
> +#ifdef DPDK_NETDEV
> +if (b->source == DPBUF_DPDK) {
> +

Re: [ovs-dev] [PATCH] RFC for support of PMD Auto load balancing

2018-10-22 Thread Nitin Katiyar

Hi,
Gentle reminder for review.

Regards,
Nitin

-Original Message-
From: Nitin Katiyar 
Sent: Friday, October 12, 2018 10:49 AM
To: ovs-dev@openvswitch.org
Cc: Rohith Basavaraja 
Subject: RE: [PATCH] RFC for support of PMD Auto load balancing

Hi,
I forgot to mention that this patch does not handle frequent rx scheduling of 
queues due to auto load balancing. That is something we had identified and 
changes need to be done to dampen the frequent scheduling of rx queues across 
PMDs.

Regards,
Nitin

-Original Message-
From: Nitin Katiyar
Sent: Friday, October 12, 2018 1:30 AM
To: ovs-dev@openvswitch.org
Cc: Nitin Katiyar ; Rohith Basavaraja 

Subject: [PATCH] RFC for support of PMD Auto load balancing

Port rx queues that have not been statically assigned to PMDs are currently 
assigned based on periodically sampled load measurements.
The assignment is performed at specific instances – port addition, port 
deletion, upon reassignment request via CLI etc.

Over time it can cause uneven load among the PMDs due to change in traffic 
pattern and thus resulting in lower overall throughout.

This patch enables the support of auto load balancing of PMDs based on measured 
load of RX queues. Each PMD measures the processing load for each of its 
associated queues every 10 seconds. If the aggregated PMD load exceeds a 
configured threshold for 6 consecutive intervals and if there are receive 
packet drops at the NIC the PMD considers itself to be overloaded.

If any PMD considers itself to be overloaded, a dry-run of the PMD assignment 
algorithm is performed by OVS main thread. The dry-run does NOT change the 
existing queue to PMD assignments.

If the resultant mapping of dry-run indicates an improved distribution of the 
load then the actual reassignment will be performed. The automatic rebalancing 
will be disabled by default and has to be enabled via configuration option. 
Load thresholds, improvement factor etc are also configurable.

Following example commands can be used to set the auto-lb params:
ovs-vsctl set open_vswitch . other_config:pmd-auto-lb="true"
ovs-vsctl set open_vswitch . other_config:pmd-auto-lb-thresh="80"
ovs-vsctl set open_vswitch . other_config:pmd-auto-lb-min-improvement="5"
ovs-vsctl set open_vswitch . other_config:pmd-auto-lb-drop-check="true"

Co-authored-by: Rohith Basavaraja 

Signed-off-by: Nitin Katiyar 
Signed-off-by: Rohith Basavaraja 
---
 lib/dpif-netdev.c | 589 +++---
 1 file changed, 561 insertions(+), 28 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c index e322f55..28593cc 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -80,6 +80,26 @@

 VLOG_DEFINE_THIS_MODULE(dpif_netdev);

+/* Auto Load Balancing Defaults */
+#define ACCEPT_IMPROVE_DEFAULT   (25)
+#define PMD_LOAD_THRE_DEFAULT(99)
+#define PMD_AUTO_LB_DISABLE  false
+#define SKIP_DROP_CHECK_DEFAULT  false
+
+//TODO: Should we make it configurable??
+#define PMD_MIN_NUM_DROPS(1)
+#define PMD_MIN_NUM_QFILLS   (1)
+#define PMD_REBALANCE_POLL_TIMER_INTERVAL 6
+
+extern uint32_t log_q_thr;
+
+static bool pmd_auto_lb = PMD_AUTO_LB_DISABLE; static bool 
+auto_lb_skip_drop_check = SKIP_DROP_CHECK_DEFAULT; static float 
+auto_lb_pmd_load_ther = PMD_LOAD_THRE_DEFAULT; static unsigned int 
+auto_lb_accept_improve = ACCEPT_IMPROVE_DEFAULT; static long long int 
+pmd_rebalance_poll_timer = 0;
+
+
 #define FLOW_DUMP_MAX_BATCH 50
 /* Use per thread recirc_depth to prevent recirculation loop. */  #define 
MAX_RECIRC_DEPTH 6 @@ -393,6 +413,8 @@ enum rxq_cycles_counter_type {
interval. */
 RXQ_CYCLES_PROC_HIST,   /* Total cycles of all intervals that are used
during rxq to pmd assignment. */
+RXQ_CYCLES_IDLE_CURR,   /* Cycles spent in idling. */
+RXQ_CYCLES_IDLE_HIST,   /* Total cycles of all idle intervals. */
 RXQ_N_CYCLES
 };

@@ -429,6 +451,14 @@ static struct ovsthread_once offload_thread_once

 #define XPS_TIMEOUT 50LL/* In microseconds. */

+typedef struct {
+unsigned long long prev_drops;
+} q_drops;
+typedef struct {
+unsigned int num_vhost_qfill;
+unsigned int prev_num_vhost_qfill;
+} vhost_qfill;
+
 /* Contained by struct dp_netdev_port's 'rxqs' member.  */  struct 
dp_netdev_rxq {
 struct dp_netdev_port *port;
@@ -439,6 +469,10 @@ struct dp_netdev_rxq {
   particular core. */
 unsigned intrvl_idx;   /* Write index for 'cycles_intrvl'. */
 struct dp_netdev_pmd_thread *pmd;  /* pmd thread that polls this queue. */
+struct dp_netdev_pmd_thread *dry_run_pmd;
+   /* During auto lb trigger, pmd thread
+  associated with this q during dry
+  run. */
 bool is_vhost; /* Is rxq of a vhost port.

[ovs-dev] Logo products for your company

2018-10-22 Thread Lilly Koller


Hi,

I didn’t know if you had received my email from last week?
Can you direct me to the person that handles your company  promo items?
Do you have any upcoming events, tradeshows or promotional needs?
We manufacture ALL custom LOGO and branded products.
The most asked about product that we make, is the custom printed USB flash
drives!

We can print your logo on them and load your digital images, videos and
files!
If you need marketing, advertising, gifts or incentives, USB flash drives
are the solution!

Here is what we include:
-Any size memory you need: 64MB up to 128GB
-We will print your logo on both sides, just ask!
-Very Low Order Minimums
-Need them quickly?  Not a problem, we offer Rush Service

NEW:   We can make a custom shaped USB drive to look like your Logo or
product!
Email over a copy of your logo and we will create a design mock up for you
at no cost!
Our higher memory sizes are a really good option right now!

Ask about the “Double Your Memory” upgrade promotion going on right
now!
Pricing is low right now, so let us know what you need and we will get you
a quick quote.

We will beat any competitors pricing, send us your last invoice and we will
beat it!

We always offer great rates for schools and nonprofits as well.
Regards,

Lilly Koller
Logo USB Account Manager

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

[ovs-dev] Logo products for your company

2018-10-22 Thread Lilly Koller


Hi,

I didn’t know if you had received my email from last week?
Can you direct me to the person that handles your company  promo items?
Do you have any upcoming events, tradeshows or promotional needs?
We manufacture ALL custom LOGO and branded products.
The most asked about product that we make, is the custom printed USB flash
drives!

We can print your logo on them and load your digital images, videos and
files!
If you need marketing, advertising, gifts or incentives, USB flash drives
are the solution!

Here is what we include:
-Any size memory you need: 64MB up to 128GB
-We will print your logo on both sides, just ask!
-Very Low Order Minimums
-Need them quickly?  Not a problem, we offer Rush Service

NEW:   We can make a custom shaped USB drive to look like your Logo or
product!
Email over a copy of your logo and we will create a design mock up for you
at no cost!
Our higher memory sizes are a really good option right now!

Ask about the “Double Your Memory” upgrade promotion going on right
now!
Pricing is low right now, so let us know what you need and we will get you
a quick quote.

We will beat any competitors pricing, send us your last invoice and we will
beat it!

We always offer great rates for schools and nonprofits as well.
Regards,

Lilly Koller
Logo USB Account Manager

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

[ovs-dev] Máster en Project Management

2018-10-22 Thread Coordinación de proyectos











 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 

---
Este correo electrónico ha sido comprobado en busca de virus por AVG.
http://www.avg.com
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Performance Based Search Ranking!

2018-10-22 Thread Andrea Jones

Hi, 

Greetings,

Is your business on the first page of Google results? If no, we can help you
get there!

We are trusted digital marketing agency for more than 10 years, our team of
200+ technology specialists, has enabled 1000+ clients to gain a prominent
presence on Google and other leading search engines. 

We have a unique model to share with you which are a 100% Risk Free and Cost
effective. Our unique pay for performance model ensures high ROI, as you PAY
ONLY WHEN YOUR KEYWORDS RANK. 

Salient features of our services include:

 

.Assured top ranks in major search engines.

.No monthly fee.

.No contractual payout. 

.Minimum one time set-up fee.

Sounds Intriguing?

Get your website evaluated NOW, Just reply us your requirement along with
contact details and we'll be in touch shortly.

Looking forward to talk to you soon!

 

Warm Regards,

Andrea Jones
Marketing Manager
Head Office: San Jose, CA 95120

 

Disclaimer:  We are using this domain for marketing. If you are interested
and want to know about us, just reply to this email, if we have offended you
by sending this to you by mistake, we apologize. Please reply "NO" or
"UNSUBSCRIBE" to this email if not interested, so that we shall add you to
our "Do Not Contact Again" list.

 

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

Re: [ovs-dev] [PATCH v11 05/14] dp-packet: Fix data_len handling multi-seg mbufs.

2018-10-22 Thread Stokes, Ian

> When a dp_packet is from a DPDK source, and it contains multi-segment
> mbufs, the data_len is not equal to the packet size, pkt_len. Instead, the
> data_len of each mbuf in the chain should be considered while distributing
> the new (provided) size.
> 
> To account for the above dp_packet_set_size() has been changed so that, in
> the multi-segment mbufs case, only the data_len on the last mbuf of the
> chain and the total size of the packet, pkt_len, are changed. The data_len
> on the intermediate mbufs preceeding the last mbuf is not changed by
> dp_packet_set_size(). Furthermore, in some cases
> dp_packet_set_size() may be used to set a smaller size than the current
> packet size, thus effectively trimming the end of the packet. In the
> multi-segment mbufs case this may lead to lingering mbufs that may need
> freeing.
> 
> __dp_packet_set_data() now also updates an mbufs' data_len after setting
> the data offset. This is so that both fields are always in sync for each
> mbuf in a chain.
> 
> Co-authored-by: Michael Qiu 
> Co-authored-by: Mark Kavanagh 
> Co-authored-by: Przemyslaw Lal 
> Co-authored-by: Marcin Ksiadz 
> Co-authored-by: Yuanhan Liu 
> 
> Signed-off-by: Michael Qiu 
> Signed-off-by: Mark Kavanagh 
> Signed-off-by: Przemyslaw Lal 
> Signed-off-by: Marcin Ksiadz 
> Signed-off-by: Yuanhan Liu 
> Signed-off-by: Tiago Lam 
> Acked-by: Eelco Chaudron 
> ---
>  lib/dp-packet.h | 83 
> -
>  1 file changed, 71 insertions(+), 12 deletions(-)
> 
> diff --git a/lib/dp-packet.h b/lib/dp-packet.h index 6376039..223efe2
> 100644
> --- a/lib/dp-packet.h
> +++ b/lib/dp-packet.h
> @@ -426,20 +426,60 @@ dp_packet_size(const struct dp_packet *b)
>  return b->mbuf.pkt_len;
>  }
> 
> +/* Sets the size of the packet 'b' to 'v'. For non-DPDK packets this
> +only means
> + * setting b->size_, but if used in a DPDK packet it means adjusting
> +the first
> + * mbuf pkt_len and last mbuf data_len, to reflect the real size, which
> +can
> + * lead to free'ing tail mbufs that are no longer used.
> + *
> + * This function should be used for setting the size only, and if
> +there's an
> + * assumption that the tail end of 'b' will be trimmed. For adjustng

Minor typo above 'adjustng' -> 'adjusting'.

> +the head
> + * 'end' of 'b', dp_packet_pull() should be used instead. */
>  static inline void
>  dp_packet_set_size(struct dp_packet *b, uint32_t v)  {
> -/* netdev-dpdk does not currently support segmentation; consequently,
> for
> - * all intents and purposes, 'data_len' (16 bit) and 'pkt_len' (32
> bit) may
> - * be used interchangably.
> - *
> - * On the datapath, it is expected that the size of packets
> - * (and thus 'v') will always be <= UINT16_MAX; this means that there
> is no
> - * loss of accuracy in assigning 'v' to 'data_len'.
> - */
> -b->mbuf.data_len = (uint16_t)v;  /* Current seg length. */
> -b->mbuf.pkt_len = v; /* Total length of all segments
> linked to
> -  * this segment. */
> +if (b->source == DPBUF_DPDK) {
> +struct rte_mbuf *mbuf = >mbuf;
> +uint16_t new_len = v;
> +uint16_t data_len;
> +uint16_t nb_segs = 0;
> +uint16_t pkt_len = 0;
> +
> +/* Trim 'v' length bytes from the end of the chained buffers,
> freeing

A general comment on the code block below, there is a number of conditions at 
play here. In reviewing I had to go pen to paper to keep track of the cases and 
see what would be the outcome in each case.

It might be worth outlining these cases in a comment first before the block 
i.e. what happens when v is larger/smaller than mbuf->data len. What happens 
when mbuf->next is already null. The relationship between mbuf->buf_len and 
mbuf->data_len would be useful also to give context when assigning more mbufs.

> +   any buffers that may be left floating */
> +while (mbuf) {
> +data_len = MIN(new_len, mbuf->data_len);
> +mbuf->data_len = data_len;
> +
> +if (new_len - data_len <= 0) {
> +/* Free the rest of chained mbufs */
> +free_dpdk_buf(CONTAINER_OF(mbuf->next, struct dp_packet,
> +   mbuf));
> +mbuf->next = NULL;
> +} else if (!mbuf->next) {
> +/* Don't assign more than what we have available */
> +mbuf->data_len = MIN(new_len,
> + mbuf->buf_len - mbuf->data_off);
> +}
> +
> +new_len -= data_len;
> +nb_segs += 1;
> +pkt_len += mbuf->data_len;
> +mbuf = mbuf->next;
> +}
> +
> +/* pkt_len != v would effectively mean that pkt_len < than 'v'
> (as
> + * being bigger is logically impossible). Being < than 'v' would
> mean
> + * the 'v' provided was bigger than the available room,

Re: [ovs-dev] [v2.10 1/2] Set release date for 2.10.1.

2018-10-22 Thread Markos Chandras

Hello Justin,

On 20/10/2018 00:51, Justin Pettit wrote:
> 
>> On Oct 17, 2018, at 9:47 AM, Ben Pfaff  wrote:
>>
>> All of these seem fine to me.
> 
> Thanks. I pushed them to all the various branches. I’ll get the releases out 
> soon. 
> 
> --Justin
> 

Could you also push the tags for these releases as well? Thank you

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 0/2] Add support to offload GRE tunnels

2018-10-22 Thread Roi Dayan




On 22/10/2018 10:53, Simon Horman wrote:
> 
> 
> On Mon, 22 Oct 2018 at 09:16, Roi Dayan  > wrote:
> 
> 
> 
> On 14/10/2018 10:26, Roi Dayan wrote:
> >
> >
> > On 12/10/2018 13:05, Simon Horman wrote:
> >> On Thu, Oct 11, 2018 at 10:06:41AM +0300, Roi Dayan wrote:
> >>> Hi,
> >>>
> >>> The first patch is to add support to offload to GRE tunnels using tc.
> >>> THe second patch is to offload the tunnel csum option correctly.
> >>
> >> Thanks Roi,
> >>
> >> this looks good to me:
> >>
> >> Reviewed-by: Simon Horman  >
> >>
> >> Let me see if I can get master clean wrt travis-ci so I can test
> >> your patchset there before applying.
> >>
> >
> > Thanks
> >
> > we also tested using travis and noticed a test failure
> > that reproduced on master branch.
> > we didnt get a chance to deep dive and help there,
> > but looks like our patches dont add more failures.
> >
> > travis log with our patches
> > https://travis-ci.org/roidayan/ovs/builds/439526807 
> 
> >
> > travis log with master
> > https://travis-ci.org/roidayan/ovs/builds/439523018 
> 
> >
> 
> 
> Hi Simon,
> 
> I noticed the second patch in the series is merged but not the first.
> 
> Thanks,
> Roi
> 
> 
> Hi Roi,
> 
> I am a little confused.
> 
> In the master branch I see:
> 
> bafb398bf6df dpdk: Use DPDK 17.11.4 release.
> ...
> d9677a1f0eaf netdev-tc-offloads: TC csum option is not matched with tunnel 
> configuration
> 5e63eaa969a3 netdev-vport: Make gre netdev type to use TC rules
> 

oh sorry. i had some filter when checked for commits and i missed it.
i thought i disabled my filters and checked again but i guess i didn't.

thanks again!
Roi
___
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.10

2018-10-22 Thread Stokes, Ian

> On Fri, Oct 19, 2018 at 04:07:42PM +, Stokes, Ian wrote:
> > Hi Ben,
> >
> > The following changes since commit
> 22595b3b763b9eaaf661eec40cc6926557c8696b:
> >
> >   Revert "Work around Python/C JSON unicode differences" (2018-10-15
> 14:44:18 -0700)
> >
> > are available in the git repository at:
> >
> >   https://github.com/istokes/ovs dpdk_merge_2_10
> >
> > for you to fetch changes up to 3b2e6400ec58aa4fe8dd453c1c4a255287ef35f3:
> >
> >   dpdk: Use DPDK 17.11.4 release. (2018-10-19 11:59:42 +0100)
> 
> Thanks for the pull requests.  I merged all of them for 2.6 to 2.10.

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

Re: [ovs-dev] [PATCH 0/2] Add support to offload GRE tunnels

2018-10-22 Thread Simon Horman

On Mon, 22 Oct 2018 at 09:16, Roi Dayan  wrote:

>
>
> On 14/10/2018 10:26, Roi Dayan wrote:
> >
> >
> > On 12/10/2018 13:05, Simon Horman wrote:
> >> On Thu, Oct 11, 2018 at 10:06:41AM +0300, Roi Dayan wrote:
> >>> Hi,
> >>>
> >>> The first patch is to add support to offload to GRE tunnels using tc.
> >>> THe second patch is to offload the tunnel csum option correctly.
> >>
> >> Thanks Roi,
> >>
> >> this looks good to me:
> >>
> >> Reviewed-by: Simon Horman 
> >>
> >> Let me see if I can get master clean wrt travis-ci so I can test
> >> your patchset there before applying.
> >>
> >
> > Thanks
> >
> > we also tested using travis and noticed a test failure
> > that reproduced on master branch.
> > we didnt get a chance to deep dive and help there,
> > but looks like our patches dont add more failures.
> >
> > travis log with our patches
> > https://travis-ci.org/roidayan/ovs/builds/439526807
> >
> > travis log with master
> > https://travis-ci.org/roidayan/ovs/builds/439523018
> >
>
>
> Hi Simon,
>
> I noticed the second patch in the series is merged but not the first.
>
> Thanks,
> Roi
>

Hi Roi,

I am a little confused.

In the master branch I see:

bafb398bf6df dpdk: Use DPDK 17.11.4 release.
...
d9677a1f0eaf netdev-tc-offloads: TC csum option is not matched with tunnel
configuration
5e63eaa969a3 netdev-vport: Make gre netdev type to use TC rules
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 0/2] Add support to offload GRE tunnels

2018-10-22 Thread Roi Dayan




On 14/10/2018 10:26, Roi Dayan wrote:
> 
> 
> On 12/10/2018 13:05, Simon Horman wrote:
>> On Thu, Oct 11, 2018 at 10:06:41AM +0300, Roi Dayan wrote:
>>> Hi,
>>>
>>> The first patch is to add support to offload to GRE tunnels using tc.
>>> THe second patch is to offload the tunnel csum option correctly.
>>
>> Thanks Roi,
>>
>> this looks good to me:
>>
>> Reviewed-by: Simon Horman 
>>
>> Let me see if I can get master clean wrt travis-ci so I can test
>> your patchset there before applying.
>>
> 
> Thanks
> 
> we also tested using travis and noticed a test failure
> that reproduced on master branch.
> we didnt get a chance to deep dive and help there,
> but looks like our patches dont add more failures.
> 
> travis log with our patches
> https://travis-ci.org/roidayan/ovs/builds/439526807
> 
> travis log with master
> https://travis-ci.org/roidayan/ovs/builds/439523018
> 


Hi Simon,

I noticed the second patch in the series is merged but not the first.

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

Re: [ovs-dev] [PATCH v8 0/3] Support dynamic rebalancing of offloaded flows

2018-10-22 Thread Simon Horman

Hi Eelco,

Thanks for your review and sorry for missing it. I trust that Sriharsha
will address it in follow-up patches.


2018/10/19 15:27 Eelco Chaudron :

> Hi Simon,
>
> You might have missed my general comments email before you committed the
> patchset to master.
>
> Just now I also sent my full review, and it looks like there is one
> nasty memory trashing one in 3/3 which need fixing. It’s the
> x2nrealloc() always allocating 1 entry, but we write to other offsets.
>
> //Eelco
>
>
> On 19 Oct 2018, at 11:28, Simon Horman wrote:
>
> > On Thu, Oct 18, 2018 at 09:43:11PM +0530, Sriharsha Basavapatna via
> > dev wrote:
> >> With the current OVS offload design, when an offload-device fails to
> >> add a
> >> flow rule and returns an error, OVS adds the rule to the kernel
> >> datapath.
> >> The flow gets processed by the kernel datapath for the entire life of
> >> that
> >> flow. This is fine when an error is returned by the device due to
> >> lack of
> >> support for certain keys or actions.
> >>
> >> But when an error is returned due to temporary conditions such as
> >> lack of
> >> resources to add a flow rule, the flow continues to be processed by
> >> kernel
> >> even when resources become available later. That is, those flows
> >> never get
> >> offloaded again. This problem becomes more pronounced when a flow
> >> that has
> >> been initially offloaded may have a smaller packet rate than a later
> >> flow
> >> that could not be offloaded due to lack of resources. This leads to
> >> inefficient use of HW resources and wastage of host CPU cycles.
> >>
> >> This patch-set addresses this issue by providing a way to detect
> >> temporary
> >> offload resource constraints (Out-Of-Resource or OOR condition) and
> >> to
> >> selectively and dynamically offload flows with a higher
> >> packets-per-second
> >> (pps) rate. This dynamic rebalancing is done periodically on netdevs
> >> that
> >> are in OOR state until resources become available to offload all
> >> pending
> >> flows.
> >>
> >> The patch-set involves the following changes at a high level:
> >>
> >> 1. Detection of Out-Of-Resources (OOR) condition on an
> >> offload-capable
> >>netdev.
> >> 2. Gathering flow offload selection criteria for all flows on an OOR
> >> netdev;
> >>i.e, packets-per-second (pps) rate of flows for offloaded and
> >>non-offloaded (pending) flows.
> >> 3. Dynamically replacing offloaded flows with a lower pps-rate, with
> >>non-offloaded flows with a higher pps-rate, on an OOR netdev. A
> >> new
> >>OpenvSwitch configuration option - "offload-rebalance" to enable
> >>this policy.
> >>
> >> Cost/benefits data points:
> >>
> >> 1. Rough cost of the new rebalancing, in terms of CPU time:
> >>
> >>Ran a test that replaced 256 low pps-rate flows(pings) with 256
> >> high
> >>pps-rate flows(iperf), in a system with 4 cpus (Intel Xeon E5 @
> >> 2.40GHz;
> >>2 cores with hw threads enabled, rest disabled). The data showed
> >> that cpu
> >>utilization increased by about ~20%. This increase occurs during
> >> the
> >>specific second in which rebalancing is done. And subsequently
> >> (from the
> >>next second), cpu utilization decreases significantly due to
> >> offloading
> >>of higher pps-rate flows. So effectively there's a bump in cpu
> >> utilization
> >>at the time of rebalancing, that is more than compensated by
> >> reduced cpu
> >>utilization once the right flows get offloaded.
> >>
> >> 2. Rough benefits to the user in terms of offload performance:
> >>
> >>The benefits to the user is reduced cpu utilization in the host,
> >> since
> >>higher pps-rate flows get offloaded, replacing lower pps-rate
> >> flows.
> >>Replacing a single offloaded flood ping flow with an iperf flow
> >> (multiple
> >>connections), shows that the cpu %used that was originally 100% on
> >> a
> >>single cpu (rebalancing disabled) goes down to 35% (rebalancing
> >> enabled).
> >>That is, cpu utilization decreased 65% after rebalancing.
> >>
> >> 3. Circumstances under which the benefits would show up:
> >>
> >>The rebalancing benefits would show up once offload resources are
> >>exhausted and new flows with higher pps-rate are initiated, that
> >> would
> >>otherwise be handled by kernel datapath costing host cpu cycles.
> >>
> >>This can be observed using 'ovs appctl dpctl/ dump-flows' command.
> >> Prior
> >>to rebalancing, any high pps-rate flows that couldn't be offloaded
> >> due to
> >>resource crunch would show up in the output of 'dump-flows
> >> type=ovs' and
> >>after rebalancing such flows would appear in the output of
> >>'dump-flows type=offloaded'.
> >
> > Thanks, applied to master.
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list

[ovs-dev] [PATCH v1 3/3] [3/3]: Routing policies, ovn-northd changes to handle routing policy commands.

[ovs-dev] [PATCH v1 1/3] [1/3]: Routing policies, add config in schema

[ovs-dev] [PATCH v1 2/3] [2/3] Routing policies, add routing-policies in ovn-nbctl

[ovs-dev] [PATCH v1 0/3] Policy-based routing

Re: [ovs-dev] [v2.10 1/2] Set release date for 2.10.1.

Re: [ovs-dev] [PATCH] ovn-nbctl: Fix the ovn-nbctl test "LBs - daemon" which fails during rpm build

Re: [ovs-dev] [PATCH] ovn-nbctl: Fix the ovn-nbctl test "LBs - daemon" which fails during rpm build

[ovs-dev] [PATCH] ovn-nbctl: Fix the ovn-nbctl test "LBs - daemon" which fails during rpm build

Re: [ovs-dev] OVS-DPDK public meeting

[ovs-dev] Issues configuring OVS-DPDK in openstack queens

Re: [ovs-dev] [PATCH v11 06/14] dp-packet: Handle multi-seg mbufs in helper funcs.

Re: [ovs-dev] [PATCH] RFC for support of PMD Auto load balancing

[ovs-dev] Logo products for your company

[ovs-dev] Logo products for your company

[ovs-dev] Máster en Project Management

[ovs-dev] Performance Based Search Ranking!

Re: [ovs-dev] [PATCH v11 05/14] dp-packet: Fix data_len handling multi-seg mbufs.

Re: [ovs-dev] [v2.10 1/2] Set release date for 2.10.1.

Re: [ovs-dev] [PATCH 0/2] Add support to offload GRE tunnels

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

Re: [ovs-dev] [PATCH 0/2] Add support to offload GRE tunnels

Re: [ovs-dev] [PATCH 0/2] Add support to offload GRE tunnels

Re: [ovs-dev] [PATCH v8 0/3] Support dynamic rebalancing of offloaded flows

23 matches

Site Navigation

Mail list logo

Footer information