Re: [ovs-dev] [PATCH 0/8] Linux upstream kernel backports and updates

2018-02-14 Thread Justin Pettit
Pravin, thank you for integrating Greg's 4.14 series.  We'd like to release OVS 
2.9 in the next couple of days.  Would you be able to look at this series and 
see if it's appropriate to bring into OVS 2.9?  I'm sorry for the short notice, 
but it doesn't look like it should be too bad a series.  I understand if you 
won't have a chance, though.  Can you just let me know?

Thanks!

--Justin


> On Feb 14, 2018, at 3:18 PM, Greg Rose  wrote:
> 
> Pull in the remaining available upstream bug fixes for the openvswitch
> Linux kernel datapath.  In addition, allow building the openvswitch
> OOT kernel datapath on kernels up to and including Linux kernel release
> 4.15.
> 
> Travis build is here - Note that the errors are not related to this
> patch series:
> 
> https://travis-ci.org/gvrose8192/ovs-experimental/builds/341649151
> 
> The patches can be pulled from here in case that is easier for review.
> 
> https://github.com/gvrose8192/ovs-experimental/tree/linux-4.15
> 
> The patches are based on commit in the master branch:
> f50c1eb4a6 ("docs: Update supported DPDK versions.")
> 
> After this series the remaining upstream patches for openvswitch are
> all erspan related.  The erspan patches will be sent separately at a
> later date.
> 
> Christopher Díaz Riveros (1):
>  datapath: Remove unneeded semicolons
> 
> Ed Swierk (1):
>  datapath: Remove padding from packet before L3+ conntrack processing
> 
> Eric Garver (1):
>  datapath: Fix pop_vlan action for double tagged frames
> 
> Greg Rose (2):
>  acinclude: Enable building for Linux kernel 4.15
>  travis: Update Linux kernel test list
> 
> Julia Lawall (1):
>  datapath: drop unneeded newline
> 
> Yang Shi (1):
>  datapath: remove unused hardirq.h
> 
> paolo abeni (1):
>  datapath: do not propagate headroom updates to internal port
> 
> .travis.yml   | 13 +++--
> acinclude.m4  |  4 ++--
> datapath/conntrack.c  | 38 --
> datapath/flow.c   | 15 ---
> datapath/flow_netlink.c   |  4 ++--
> datapath/vport-internal_dev.c | 20 +---
> 6 files changed, 60 insertions(+), 34 deletions(-)
> 
> -- 
> 1.8.3.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


[ovs-dev] Sua fatura NET por e-mail - 02/2018 - D158BD1470

2018-02-14 Thread Fatura Net




Untitled Document












  

  


  



  

  

  
 
  

  
 
  


  
   


  
 




Prezado(a) 
  

  

  

   


  


  

  
 
  

  

  

  
 
  

  
 

  

  

  

  
Consulte os serviços, tarifas que fazem parte 
do seu pacote e todos os detalhes da sua fatura que encontra-se anexada neste 
e-mail. 

E para facilitar, segue um resumo com as 
principais informações logo abaixo:
 



    


  
 
  

  

  

  

  
Data de vencimento: 16/02/2018
  Valor: 217,38
  Contrato: 003/329648442



 
  


   


  


 
  

  

  

  Caso você tenha alguma duvida em relação a sua 
fatura, clique aqui e fale conosco.
 


  
 
  

  
A atualização do seu cadastro é muito importante para o 
nosso relacionamento.
 
  


  
 
 
  

  
 
  


  
 
  


  
  


 





  

  

  

  

  

  

  

   



   
   
   
   
   


  
 
 
  


   


  
 
  


   


  

Não responda a este e-mail. Esta é uma mensagem gerada automaticamente.



3580D1369BD1460CFACF358ACF3258

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


Re: [ovs-dev] [PATCH v2] ofproto-dpif-ipfix: Fix an issue in flow key part

2018-02-14 Thread Ben Pfaff
On Wed, Feb 14, 2018 at 05:52:07PM -0800, Daniel Benli Ye wrote:
> From: Benli Ye 
> 
> As struct ipfix_data_record_flow_key_iface didn't calculate
> its length in flow key part, it may cause problem when flow
> key part length is not enough. Use MAX_IF_LEN and MAX_IF_DESCR
> to pre-allocate memory for ipfix_data_record_flow_key_iface.
> 
> v1 -> v2: Use strnlen() to limit the max length.
> 
> Signed-off-by: Daniel Benli Ye 

Looks good to me.  Thank you!  I'll give Michal a day or so to comment.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] ovsdb-tool: Indicate "db" and "schema" are optional in man page.

2018-02-14 Thread Justin Pettit


> On Feb 14, 2018, at 4:54 PM, Ben Pfaff  wrote:
> 
> On Fri, Feb 09, 2018 at 04:05:11PM -0800, Justin Pettit wrote:
>> Signed-off-by: Justin Pettit 
> 
> Acked-by: Ben Pfaff 

Thanks.  I pushed this to master and branch-2.9.

--Justin


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


[ovs-dev] [PATCH v2] ofproto-dpif-ipfix: Fix an issue in flow key part

2018-02-14 Thread Daniel Benli Ye
From: Benli Ye 

As struct ipfix_data_record_flow_key_iface didn't calculate
its length in flow key part, it may cause problem when flow
key part length is not enough. Use MAX_IF_LEN and MAX_IF_DESCR
to pre-allocate memory for ipfix_data_record_flow_key_iface.

v1 -> v2: Use strnlen() to limit the max length.

Signed-off-by: Daniel Benli Ye 
---
 ofproto/ofproto-dpif-ipfix.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/ofproto/ofproto-dpif-ipfix.c b/ofproto/ofproto-dpif-ipfix.c
index c7ddeb9..4d9fe78 100644
--- a/ofproto/ofproto-dpif-ipfix.c
+++ b/ofproto/ofproto-dpif-ipfix.c
@@ -314,6 +314,7 @@ BUILD_ASSERT_DECL(sizeof(struct 
ipfix_data_record_flow_key_common) == 20);
 /* Part of data record flow key for interface information. Since some of the
  * elements have variable length, members of this structure should be appended
  * to the 'struct dp_packet' one by one. */
+OVS_PACKED(
 struct ipfix_data_record_flow_key_iface {
 ovs_be32 if_index; /* (INGRESS | EGRESS)_INTERFACE */
 ovs_be32 if_type; /* (INGRESS | EGRESS)_INTERFACE_TYPE */
@@ -321,7 +322,9 @@ struct ipfix_data_record_flow_key_iface {
 char *if_name;
 uint8_t if_descr_len; /* Variable length element: INTERFACE_DESCRIPTION */
 char *if_descr;
-};
+});
+BUILD_ASSERT_DECL(sizeof(struct ipfix_data_record_flow_key_iface) ==
+  10 + 2 * sizeof(char *));
 
 /* Part of data record flow key for VLAN entities. */
 OVS_PACKED(
@@ -511,8 +514,21 @@ BUILD_ASSERT_DECL(sizeof(struct 
ipfix_data_record_aggregated_tcp) == 48);
  */
 #define MAX_TUNNEL_KEY_LEN 8
 
+#define MAX_IF_NAME_LEN 64
+#define MAX_IF_DESCR_LEN 128
+
+/*
+ * Calculate interface information length in flow key.
+ * This is used to calculate max flow key length.
+ */
+#define FLOW_KEY_IFACE_LEN  \
+(sizeof(struct ipfix_data_record_flow_key_iface)\
+ - 2 * sizeof(char *)   \
+ + MAX_IF_NAME_LEN + MAX_IF_DESCR_LEN)
+
 #define MAX_FLOW_KEY_LEN\
 (sizeof(struct ipfix_data_record_flow_key_common)   \
+ + FLOW_KEY_IFACE_LEN   \
  + sizeof(struct ipfix_data_record_flow_key_vlan)   \
  + sizeof(struct ipfix_data_record_flow_key_ip) \
  + MAX(sizeof(struct ipfix_data_record_flow_key_ipv4),  \
@@ -2030,9 +2046,11 @@ ipfix_get_iface_data_record(const struct dpif_ipfix *di, 
odp_port_t port_no,
 
 smap_destroy(_status);
 data->if_index = htonl(port->ifindex);
-data->if_descr_len = data->if_descr ? strlen(data->if_descr) : 0;
+data->if_descr_len = data->if_descr ? strnlen(data->if_descr,
+  MAX_IF_DESCR_LEN) : 0;
 data->if_name = nullable_xstrdup(netdev_get_name(port->ofport->netdev));
-data->if_name_len = data->if_name ? strlen(data->if_name) : 0;
+data->if_name_len = data->if_name ? strnlen(data->if_name,
+MAX_IF_NAME_LEN) : 0;
 
 return 0;
 }
-- 
2.7.4

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


Re: [ovs-dev] [PATCH] ovsdb-tool: Indicate "db" and "schema" are optional in man page.

2018-02-14 Thread Ben Pfaff
On Fri, Feb 09, 2018 at 04:05:11PM -0800, Justin Pettit wrote:
> Signed-off-by: Justin Pettit 

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


Re: [ovs-dev] [PATCH v3] ovn-controller: Support multiple gateway port on a distributed router

2018-02-14 Thread Ben Pfaff
Hi Guru.  Are you willing to take a look at this patch?

Thanks,

Ben.

On Fri, Feb 09, 2018 at 03:34:55PM +0800, Guoshuai Li wrote:
> The main application scenario of this patch is that the user flow wants to
> different destination addresses through different external networks.
> This scenario requires a distributed route to be associated with
> multiple external network logical switches.
> 
> Change l3dgw_port to l3dgw_ports in ovn_datapath,and change
> l3redirect_port to ovn_port. Then in a distributed router, the NAT
> logical flow table is generated based on the external IP lookup
> distributed router port, otherwise not generated. And LB is the same.
> 
> When the destination address of the packet is an external IP of the NAT rule,
> and the ingress port is not a gateway, it is necessary to route to the actual
> outgoing port.
> 
> Signed-off-by: Guoshuai Li 
> ---
>  ovn/northd/ovn-northd.8.xml |  22 +---
>  ovn/northd/ovn-northd.c | 273 
> +---
>  ovn/ovn-nb.xml  |  12 +-
>  tests/system-ovn.at | 162 +++---
>  4 files changed, 315 insertions(+), 154 deletions(-)
> 
> ---
> 
> I submitted this patch long ago, I think it might be useful,
> so resend it for more comments, thanks.
> 
> v1 -> v2:
>   1. rebase from master.
>   2. add test case.
> v2 -> v3:
>   fixed build failed.
> 
> ---
> 
> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index 6bc2dd6af..ff523614a 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -1732,16 +1732,6 @@ output;
>  
>
>  
> -  For distributed logical routers where one of the logical router
> -  ports specifies a redirect-chassis, a priority-300
> -  logical flow with match REGBIT_NAT_REDIRECT == 1 has
> -  actions ip.ttl--; next;.  The outport
> -  will be set later in the Gateway Redirect table.
> -
> -  
> -
> -  
> -
>IPv4 routing table.  For each route to IPv4 network N 
> with
>netmask M, on router port P with IP address
>A and Ethernet
> @@ -1827,12 +1817,12 @@ next;
>  
>
>  
> -  For distributed logical routers where one of the logical router
> -  ports specifies a redirect-chassis, a priority-200
> -  logical flow with match REGBIT_NAT_REDIRECT == 1 has
> -  actions eth.dst = E; next;, where
> -  E is the ethernet address of the router's distributed
> -  gateway port.
> +  For distributed logical routers where router port P
> +  specifies a redirect-chassis, a priority-200
> +  logical flow with match REGBIT_NAT_REDIRECT == 1
> +  and outport == P has actions
> +  eth.dst = E; next;, where E
> +  is the ethernet address of the router's distributed gateway port.
>  
>
>  
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 4d95a3d9d..d38efcbed 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -418,12 +418,10 @@ struct ovn_datapath {
>  
>  /* OVN northd only needs to know about the logical router gateway port 
> for
>   * NAT on a distributed router.  This "distributed gateway port" is
> - * populated only when there is a "redirect-chassis" specified for one of
> - * the ports on the logical router.  Otherwise this will be NULL. */
> -struct ovn_port *l3dgw_port;
> -/* The "derived" OVN port representing the instance of l3dgw_port on
> - * the "redirect-chassis". */
> -struct ovn_port *l3redirect_port;
> + * populated only when there is a "redirect-chassis" specified for the
> + * ports on the logical router.  Otherwise this will be NULL. */
> +struct ovn_port **l3dgw_ports;
> +size_t n_l3dgw_ports;
>  struct ovn_port *localnet_port;
>  };
>  
> @@ -472,6 +470,7 @@ ovn_datapath_destroy(struct hmap *datapaths, struct 
> ovn_datapath *od)
>  free(od->ipam_info);
>  }
>  free(od->router_ports);
> +free(od->l3dgw_ports);
>  free(od);
>  }
>  }
> @@ -796,6 +795,10 @@ struct ovn_port {
>  bool derived; /* Indicates whether this is an additional port
> * derived from nbsp or nbrp. */
>  
> +/* The "derived" OVN port representing the instance of l3dgw_port on
> + * the "redirect-chassis". Otherwise this will be NULL. */
> +struct ovn_port *l3redirect_port;
> +
>  /* The port's peer:
>   *
>   * - A switch port S of type "router" has a router port R as a peer,
> @@ -1479,7 +1482,7 @@ join_logical_ports(struct northd_context *ctx,
>   "on L3 gateway router", nbrp->name);
>  continue;
>  }
> -if (od->l3dgw_port || od->l3redirect_port) {
> +if 

Re: [ovs-dev] [PATCH] ovn-controller: Fix crash when sending GARP when openflow disconnection.

2018-02-14 Thread Ben Pfaff
On Mon, Feb 12, 2018 at 04:17:47PM +0800, Guoshuai Li wrote:
> This is call stack:
> Program received signal SIGABRT, Aborted.
> 1  0x76a4f8e8 in __GI_abort () at abort.c:90
> 2  0x004765d6 in ofputil_protocol_to_ofp_version (protocol= out>) at lib/ofp-util.c:769
> 3  0x0047c19e in ofputil_encode_packet_out 
> (po=po@entry=0x7fffa0e0, protocol=) at lib/ofp-util.c:7060
> 4  0x00410870 in send_garp (garp=0x83cfe0, 
> current_time=current_time@entry=1200375400) at ovn/controller/pinctrl.c:1738
> 5  0x0041430f in send_garp_run (active_tunnels=, 
> local_datapaths=0x7fffc0a0, chassis_index=, 
> chassis=0x8194d0, br_int=, ctx=0x7fffc080) at 
> ovn/controller/pinctrl.c:2069
> 
> Signed-off-by: Guoshuai Li 

Thanks for fixing the bug!

I think we should not log a warning about this.  It is pretty much
unavoidable that sometimes the controller will be disconnected from the
switch, especially at controller startup.  WARN level log messages
should be reserved for situations that are likely to indicate a problem.
It might make sense to log something at INFO level, but the code for
maintaining OpenFlow connections already logs plenty of INFO messages
about connecting and disconnecting, so I don't think we really need
another one here.

Like Mark, I am not sure that the test is necessary.

Will you submit a v2?

Thanks,

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


Re: [ovs-dev] [PATCH] ovn-northd: Support logical router port with config CIDR, such as 192.168.1.0/24.

2018-02-14 Thread Ben Pfaff
Guru, does it make sense for you to look at this?  You understand
gateways better than me.

On Wed, Feb 07, 2018 at 12:21:35PM +0800, Guoshuai Li wrote:
> Support logical router port who is gateway can configure CIDR whitout IP 
> address,
> so as to save the public network IP when connecting to the external network.
> 
> With this configuration, the gateway's default snat functionality will not be 
> available and
> VMs accessing the external network can only pass floatingip(snat_and_dnat).
> 
> The modify:
> 
> 1. Logical switch Ingress table 11: ARP reply for logical router port IPs.
>- Do not reply ARP when logical router port without IP.
> 
> 2. Logical router ingress table 5: IP Routing.
>- Use floatingIp (sNat IP) for routeing source IP in static routing.
>- Use floatingIp (sNat IP) for routeing source IP in direct routing.
> 
> 3. Local router ingress table 6: ARP Resolution.
>- Do not reply ARP when logical router port without IP.
> 
> 4. Logical router ingress table 1: IP Input for IPv4.
>- Do not reply ARP for the router own when logical router port without IP.
> 
> Signed-off-by: Guoshuai Li 
> ---
>  ovn/northd/ovn-northd.c | 114 
> +++-
>  ovn/ovn-nb.xml  |   7 +++
>  tests/system-ovn.at |   8 
>  3 files changed, 118 insertions(+), 11 deletions(-)
> 
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 4d95a3d9d..c98bf2ab6 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -3548,6 +3548,17 @@ build_stateful(struct ovn_datapath *od, struct hmap 
> *lflows)
>  }
>  }
>  
> +/* Return to whether Port is only configured cidr. */
> +static bool
> +op_is_v4_network_cidr(const struct ipv4_netaddr *ipv4_addrs)
> +{
> +if ((ipv4_addrs->plen != 32) &&
> +(ipv4_addrs->addr == ipv4_addrs->network)) {
> +return true;
> +}
> +return false;
> +}
> +
>  static void
>  build_lswitch_flows(struct hmap *datapaths, struct hmap *ports,
>  struct hmap *lflows, struct hmap *mcgroups)
> @@ -3679,6 +3690,10 @@ build_lswitch_flows(struct hmap *datapaths, struct 
> hmap *ports,
>  
>  for (size_t i = 0; i < op->n_lsp_addrs; i++) {
>  for (size_t j = 0; j < op->lsp_addrs[i].n_ipv4_addrs; j++) {
> +if (!strcmp(op->nbsp->type, "router") &&
> +op_is_v4_network_cidr(>lsp_addrs[i].ipv4_addrs[j])) {
> +continue;
> +}
>  ds_clear();
>  ds_put_format(, "arp.tpa == %s && arp.op == 1",
>op->lsp_addrs[i].ipv4_addrs[j].addr_s);
> @@ -4100,8 +4115,32 @@ lrport_is_enabled(const struct 
> nbrec_logical_router_port *lrport)
>  return !lrport->enabled || *lrport->enabled;
>  }
>  
> +/* Returns a string of the net external_ip of the router port 'op'.
> + * If one is not found, returns NULL.
> + *
> + * The caller must not free the returned string. */
> +static const char *
> +find_lrp_external_ip(const struct ovn_port *op)
> +{
> +for (int i = 0; i < op->lrp_networks.n_ipv4_addrs; i++) {
> +const struct ipv4_netaddr *na = >lrp_networks.ipv4_addrs[i];
> +for (size_t j = 0; j < op->od->nbr->n_nat; j++) {
> +const struct nbrec_nat *nat = op->od->nbr->nat[j];
> +ovs_be32 external_ip;
> +if (!ip_parse(nat->external_ip, _ip)) {
> +continue;
> +}
> +if (!((na->network ^ external_ip) & na->mask)) {
> +return nat->external_ip;
> +}
> +}
> +}
> +return NULL;
> +}
> +
>  /* Returns a string of the IP address of the router port 'op' that
> - * overlaps with 'ip_s".  If one is not found, returns NULL.
> + * overlaps with 'ip_s". Or Returns a string of the nat external_ip
> + * address of the router port 'op', If one is not found, returns NULL.
>   *
>   * The caller must not free the returned string. */
>  static const char *
> @@ -4118,15 +4157,27 @@ find_lrp_member_ip(const struct ovn_port *op, const 
> char *ip_s)
>  return NULL;
>  }
>  
> +bool find_port = false;
>  for (int i = 0; i < op->lrp_networks.n_ipv4_addrs; i++) {
>  const struct ipv4_netaddr *na = >lrp_networks.ipv4_addrs[i];
>  
>  if (!((na->network ^ ip) & na->mask)) {
> +find_port = true;
>  /* There should be only 1 interface that matches the
>   * supplied IP.  Otherwise, it's a configuration error,
>   * because subnets of a router's interfaces should NOT
>   * overlap. */
> -return na->addr_s;
> +if (na->addr != na->network) {
> +return na->addr_s;
> +}
> +}
> +}
> +
> +if (find_port) {
> +/* Get NAT external IP addresses. */
> +

Re: [ovs-dev] [PATCH] Refer to database manpages in *ctl manpages

2018-02-14 Thread Ben Pfaff
On Mon, Feb 12, 2018 at 02:17:53PM -0600, Mark Michelson wrote:
> The ovn-nbctl, ovn-sbctl, and ovs-vsctl manpages are inconsistent in
> their "Database Commands" section when it comes to referring to what
> database tables exist. This commit amends this by making each *ctl
> manpage reference the corresponding database manpage instead.
> 
> Signed-off-by: Mark Michelson 
> ---
> While having a look through the manpages for ovn-nbctl, ovn-sbctl, and
> ovs-vsctl, I noticed that each of them were different with regards to
> referring to tables:
> 
> * ovn-nbctl listed tables but the list was incomplete.
> * ovn-sbctl listed no tables at all.
> * ovs-vsctl listed all tables.
> 
> To me, there were two ways to go here: list all tables in each of the
> three manpages, or list no tables in the three manpages. In the end, I
> decided to make a reference to the database manpages. This way we're not
> repeating table listings and there's no risk of omitting tables. The
> database manpages are better references anyway for tables and their
> columns.

Thanks for working on the documentation!

The main point of having the list of tables in ovs-vsctl(8) is not
actually to list the tables but to let people know what names they can
use for rows in those tables.  This patch loses that information for
ovs-vsctl.

However, this stuff is encoded into the ctl_table_class structs in each
ctl program, such as the one starting around line 2363 in ovs-vsctl.c:
static const struct ctl_table_class tables[OVSREC_N_TABLES] = {
...
};
so it probably wouldn't be too hard to write a function that prints this
info in a human-readable form and then call that function for --help
output.  And then every one of these programs would have correct and
up-to-date helpful output all the time, and we could delete it from the
manpages while still keeping my conscience clear that it was available.

Any chance you'd be willing to work on that?

Thanks,

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


Re: [ovs-dev] [PATCH 4/8] datapath: remove unused hardirq.h

2018-02-14 Thread Yang Shi



On 2/14/18 3:18 PM, Greg Rose wrote:

From: Yang Shi 

Upstream commit:
 commit 419091f1cc8afce943fd12af0df26201ee20c1c0
 Author: Yang Shi 
 Date:   Tue Jan 9 03:52:53 2018 +0800

 net: ovs: remove unused hardirq.h

 Preempt counter APIs have been split out, currently, hardirq.h just
 includes irq_enter/exit APIs which are not used by openvswitch at all.

 So, remove the unused hardirq.h.

 Signed-off-by: Yang Shi 
 Acked-by: Pravin B Shelar 
 Cc: "David S. Miller" 
 Cc: d...@openvswitch.org
 Signed-off-by: David S. Miller 

Cc: Yang Shi 



Acked-by: Yang Shi 



Signed-off-by: Greg Rose 
---
  datapath/vport-internal_dev.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/datapath/vport-internal_dev.c b/datapath/vport-internal_dev.c
index 9bb8751..f48684b 100644
--- a/datapath/vport-internal_dev.c
+++ b/datapath/vport-internal_dev.c
@@ -16,7 +16,6 @@
   * 02110-1301, USA
   */
  
-#include 

  #include 
  #include 
  #include 


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


Re: [ovs-dev] [PATCH 3/3] OVN: add acl reject support using icmp4 action

2018-02-14 Thread Ben Pfaff
On Tue, Feb 13, 2018 at 03:43:52PM +0100, Lorenzo Bianconi wrote:
> Whenever the acl reject rule is hit send back an ICMPv4 destination
> unreachable packet and do not handle reject rule as drop one.
> Treat TCP connections as DROP for the moment since tcp_reset{} action
> has not been implemented yet.
> 
> Signed-off-by: Lorenzo Bianconi 

Same as Mark, I'd prefer to see some tests.

Thanks,

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


Re: [ovs-dev] [PATCH 2/3] OVN: add icmp4{} action support

2018-02-14 Thread Ben Pfaff
On Tue, Feb 13, 2018 at 03:43:51PM +0100, Lorenzo Bianconi wrote:
> icmp4 action is used to replace the IPv4 packet been processed with
> an ICMPv4 packet initialized based on incoming IPv4 one.
> Ethernet and IPv4 fields not listed are not changed:
> - ip.proto = 1 (ICMPv4)
> - ip.frag = 0 (not a fragment)
> - icmp4.type = 3 (destination unreachable)
> - icmp4.code = 1 (host unreachable)
> Prerequisite: ip4
> 
> Signed-off-by: Lorenzo Bianconi 

Thanks for the patch!  It looks really good.

I'm appending a few changes I suggest folding in: usually we write hex
numbers preceded by 0x (which the # flag does), and because the two
lines that get deleted aren't really needed.

There's some inconsistency in naming between "icmp" and "icmp4".  I
guess I like icmp4 better because it seems likely that we'll eventually
add an icmp6.

Did you consider the tos value passed to packet_set_ipv4()?  I'd be
somewhat inclined to use ip_flow->nw_tos.

The documentation says that IPv4 values not listed are not changed, so
either we should update the documentation or the code regarding TTL and
TOS.

I'd add some parsing tests to the "ovn -- action parsing" test in
tests/ovn.at.

Thanks,

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


Re: [ovs-dev] [PATCH 1/3] OVN: rename encode_nested_neighbor_actions in encode_nested_actions

2018-02-14 Thread Ben Pfaff
On Tue, Feb 13, 2018 at 03:43:50PM +0100, Lorenzo Bianconi wrote:
> Rename encode_nested_neighbor_actions routine in encode_nested_actions
> in order to have a more general name for nested actions encoder.
> 
> Signed-off-by: Lorenzo Bianconi 

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


[ovs-dev] [PATCH 8/8] travis: Update Linux kernel test list

2018-02-14 Thread Greg Rose
Add newly supported 4.15 release and also update the kernel test list
to the LTS list at www.kernel.org.

Signed-off-by: Greg Rose 
---
 .travis.yml | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index cfd9b6f..ef907ca 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -27,14 +27,15 @@ sudo: false
 
 env:
   - OPTS="--disable-ssl"
-  - TESTSUITE=1 KERNEL=3.16.53
+  - TESTSUITE=1 KERNEL=3.16.54
   - TESTSUITE=1 OPTS="--enable-shared"
   - BUILD_ENV="-m32" OPTS="--disable-ssl"
-  - KERNEL=3.16.53 DPDK=1
-  - KERNEL=3.16.53 DPDK=1 OPTS="--enable-shared"
-  - KERNEL=4.14.15
-  - KERNEL=4.9.78
-  - KERNEL=4.4.113
+  - KERNEL=3.16.54 DPDK=1
+  - KERNEL=3.16.54 DPDK=1 OPTS="--enable-shared"
+  - KERNEL=4.15.3
+  - KERNEL=4.14.19
+  - KERNEL=4.9.81
+  - KERNEL=4.4.115
   - KERNEL=4.1.49
   - KERNEL=3.10.108
   - TESTSUITE=1 LIBS=-ljemalloc
-- 
1.8.3.1

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


[ovs-dev] [PATCH 7/8] acinclude: Enable building for Linux kernel 4.15

2018-02-14 Thread Greg Rose
Signed-off-by: Greg Rose 
---
 acinclude.m4 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/acinclude.m4 b/acinclude.m4
index c8cfbe1..b5f62cc 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -151,10 +151,10 @@ AC_DEFUN([OVS_CHECK_LINUX], [
 AC_MSG_RESULT([$kversion])
 
 if test "$version" -ge 4; then
-   if test "$version" = 4 && test "$patchlevel" -le 14; then
+   if test "$version" = 4 && test "$patchlevel" -le 15; then
   : # Linux 4.x
else
-  AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version 
newer than 4.14.x is not supported (please refer to the FAQ for advice)])
+  AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version 
newer than 4.15.x is not supported (please refer to the FAQ for advice)])
fi
 elif test "$version" = 3 && test "$patchlevel" -ge 10; then
: # Linux 3.x
-- 
1.8.3.1

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


[ovs-dev] [PATCH 6/8] datapath: Remove padding from packet before L3+ conntrack processing

2018-02-14 Thread Greg Rose
From: Ed Swierk 

Upstream commit:
commit 9382fe71c0058465e942a633869629929102843d
Author: Ed Swierk 
Date:   Wed Jan 31 18:48:02 2018 -0800

openvswitch: Remove padding from packet before L3+ conntrack processing

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 
Acked-by: Pravin B Shelar 
Signed-off-by: David S. Miller 

Cc: Ed Swierk 
Signed-off-by: Greg Rose 
---
 datapath/conntrack.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/datapath/conntrack.c b/datapath/conntrack.c
index d58240b..e53b8e3 100644
--- a/datapath/conntrack.c
+++ b/datapath/conntrack.c
@@ -1138,6 +1138,36 @@ static int ovs_ct_commit(struct net *net, struct 
sw_flow_key *key,
return 0;
 }
 
+/* Trim the skb to the length specified by the IP/IPv6 header,
+ * removing any trailing lower-layer padding. This prepares the skb
+ * for higher-layer processing that assumes skb->len excludes padding
+ * (such as nf_ip_checksum). The caller needs to pull the skb to the
+ * network header, and ensure ip_hdr/ipv6_hdr points to valid data.
+ */
+static int ovs_skb_network_trim(struct sk_buff *skb)
+{
+   unsigned int len;
+   int err;
+
+   switch (skb->protocol) {
+   case htons(ETH_P_IP):
+   len = ntohs(ip_hdr(skb)->tot_len);
+   break;
+   case htons(ETH_P_IPV6):
+   len = sizeof(struct ipv6hdr)
+   + ntohs(ipv6_hdr(skb)->payload_len);
+   break;
+   default:
+   len = skb->len;
+   }
+
+   err = pskb_trim_rcsum(skb, len);
+   if (err)
+   kfree_skb(skb);
+
+   return err;
+}
+
 /* Returns 0 on success, -EINPROGRESS if 'skb' is stolen, or other nonzero
  * value if 'skb' is freed.
  */
@@ -1152,6 +1182,10 @@ int ovs_ct_execute(struct net *net, struct sk_buff *skb,
nh_ofs = skb_network_offset(skb);
skb_pull_rcsum(skb, nh_ofs);
 
+   err = ovs_skb_network_trim(skb);
+   if (err)
+   return err;
+
if (key->ip.frag != OVS_FRAG_TYPE_NONE) {
err = handle_fragments(net, key, info->zone.id, skb);
if (err)
-- 
1.8.3.1

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


[ovs-dev] [PATCH 5/8] datapath: Remove unneeded semicolons

2018-02-14 Thread Greg Rose
From: Christopher Díaz Riveros 

Upstream commit:
commit 89290b831ec1a0b233fdc7aaad84acdf4ebbf6aa
Author: Christopher Díaz Riveros 
Date:   Wed Jan 17 16:10:28 2018 -0500

flow_netlink: Remove unneeded semicolons

Trivial fix removes unneeded semicolons after if blocks.

This issue was detected by using the Coccinelle software.

Signed-off-by: Christopher Díaz Riveros 
Signed-off-by: David S. Miller 

Cc: Christopher Díaz Riveros 
Signed-off-by: Greg Rose 
---
 datapath/flow_netlink.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/datapath/flow_netlink.c b/datapath/flow_netlink.c
index 8eabc16..e2ccf91 100644
--- a/datapath/flow_netlink.c
+++ b/datapath/flow_netlink.c
@@ -2458,7 +2458,7 @@ static int validate_geneve_opts(struct sw_flow_key *key)
 
option = (struct geneve_opt *)((u8 *)option + len);
opts_len -= len;
-   };
+   }
 
key->tun_key.tun_flags |= crit_opt ? TUNNEL_CRIT_OPT : 0;
 
@@ -2491,7 +2491,7 @@ static int validate_and_copy_set_tun(const struct nlattr 
*attr,
case OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS:
break;
}
-   };
+   }
 
start = add_nested_action_start(sfa, OVS_ACTION_ATTR_SET, log);
if (start < 0)
-- 
1.8.3.1

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


[ovs-dev] [PATCH 4/8] datapath: remove unused hardirq.h

2018-02-14 Thread Greg Rose
From: Yang Shi 

Upstream commit:
commit 419091f1cc8afce943fd12af0df26201ee20c1c0
Author: Yang Shi 
Date:   Tue Jan 9 03:52:53 2018 +0800

net: ovs: remove unused hardirq.h

Preempt counter APIs have been split out, currently, hardirq.h just
includes irq_enter/exit APIs which are not used by openvswitch at all.

So, remove the unused hardirq.h.

Signed-off-by: Yang Shi 
Acked-by: Pravin B Shelar 
Cc: "David S. Miller" 
Cc: d...@openvswitch.org
Signed-off-by: David S. Miller 

Cc: Yang Shi 
Signed-off-by: Greg Rose 
---
 datapath/vport-internal_dev.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/datapath/vport-internal_dev.c b/datapath/vport-internal_dev.c
index 9bb8751..f48684b 100644
--- a/datapath/vport-internal_dev.c
+++ b/datapath/vport-internal_dev.c
@@ -16,7 +16,6 @@
  * 02110-1301, USA
  */
 
-#include 
 #include 
 #include 
 #include 
-- 
1.8.3.1

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


[ovs-dev] [PATCH 3/8] datapath: drop unneeded newline

2018-02-14 Thread Greg Rose
From: Julia Lawall 

Upstream commit:
commit e0b10844d9e617a1a5ce2ddf73d38aaa0a47a2a4
Author: Julia Lawall 
Date:   Wed Dec 27 15:51:38 2017 +0100

openvswitch: drop unneeded newline

OVS_NLERR prints a newline at the end of the message string, so the
message string does not need to include a newline explicitly.  Done
using Coccinelle.

Signed-off-by: Julia Lawall 
Signed-off-by: David S. Miller 

Cc: Julia Lawall 
Signed-off-by: Greg Rose 
---
 datapath/conntrack.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/datapath/conntrack.c b/datapath/conntrack.c
index a75ae3c..d58240b 100644
--- a/datapath/conntrack.c
+++ b/datapath/conntrack.c
@@ -1315,14 +1315,14 @@ static int parse_nat(const struct nlattr *attr,
/* Do not allow flags if no type is given. */
if (info->range.flags) {
OVS_NLERR(log,
- "NAT flags may be given only when NAT range 
(SRC or DST) is also specified.\n"
+ "NAT flags may be given only when NAT range 
(SRC or DST) is also specified."
  );
return -EINVAL;
}
info->nat = OVS_CT_NAT;   /* NAT existing connections. */
} else if (!info->commit) {
OVS_NLERR(log,
- "NAT attributes may be specified only when CT COMMIT 
flag is also specified.\n"
+ "NAT attributes may be specified only when CT COMMIT 
flag is also specified."
  );
return -EINVAL;
}
-- 
1.8.3.1

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


[ovs-dev] [PATCH 2/8] datapath: Fix pop_vlan action for double tagged frames

2018-02-14 Thread Greg Rose
From: Eric Garver 

Upstream commit:
commit c48e74736fccf25fb32bb015426359e1c2016e3b
Author: Eric Garver 
Date:   Wed Dec 20 15:09:22 2017 -0500

openvswitch: Fix pop_vlan action for double tagged frames

skb_vlan_pop() expects skb->protocol to be a valid TPID for double
tagged frames. So set skb->protocol to the TPID and let skb_vlan_pop()
shift the true ethertype into position for us.

Fixes: 5108bbaddc37 ("openvswitch: add processing of L3 packets")
Signed-off-by: Eric Garver 
Reviewed-by: Jiri Benc 
Signed-off-by: David S. Miller 

Cc: Eric Garver 
Fixes: a27c454ee0 ("datapath: add processing of L3 packets")
Signed-off-by: Greg Rose 
---
 datapath/flow.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/datapath/flow.c b/datapath/flow.c
index e345ec9..fadc074 100644
--- a/datapath/flow.c
+++ b/datapath/flow.c
@@ -584,6 +584,7 @@ static int key_extract(struct sk_buff *skb, struct 
sw_flow_key *key)
return -EINVAL;
 
skb_reset_network_header(skb);
+   key->eth.type = skb->protocol;
} else {
eth = eth_hdr(skb);
ether_addr_copy(key->eth.src, eth->h_source);
@@ -597,16 +598,24 @@ static int key_extract(struct sk_buff *skb, struct 
sw_flow_key *key)
if (unlikely(parse_vlan(skb, key)))
return -ENOMEM;
 
-   skb->protocol = parse_ethertype(skb);
-   if (unlikely(skb->protocol == htons(0)))
+   key->eth.type = parse_ethertype(skb);
+   if (unlikely(key->eth.type == htons(0)))
return -ENOMEM;
 
+   /* Multiple tagged packets need to retain TPID to satisfy
+* skb_vlan_pop(), which will later shift the ethertype into
+* skb->protocol.
+*/
+   if (key->eth.cvlan.tci & htons(VLAN_TAG_PRESENT))
+   skb->protocol = key->eth.cvlan.tpid;
+   else
+   skb->protocol = key->eth.type;
+
skb_reset_network_header(skb);
__skb_push(skb, skb->data - skb_mac_header(skb));
}
 
skb_reset_mac_len(skb);
-   key->eth.type = skb->protocol;
 
/* Network layer. */
if (key->eth.type == htons(ETH_P_IP)) {
-- 
1.8.3.1

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


[ovs-dev] [PATCH 1/8] datapath: do not propagate headroom updates to internal port

2018-02-14 Thread Greg Rose
From: paolo abeni 

Upstream commit:
commit 183dea5818315c0a172d21ecbcd2554894bf01e3
Author: Paolo Abeni 
Date:   Thu Nov 30 15:35:33 2017 +0100

openvswitch: do not propagate headroom updates to internal port

After commit 3a927bc7cf9d ("ovs: propagate per dp max headroom to
all vports") the need_headroom for the internal vport is updated
accordingly to the max needed headroom in its datapath.

That avoids the pskb_expand_head() costs when sending/forwarding
packets towards tunnel devices, at least for some scenarios.

We still require such copy when using the ovs-preferred configuration
for vxlan tunnels:

br_int
  /   \
tap  vxlan
   (remote_ip:X)

br_phy
 \
NIC

where the route towards the IP 'X' is via 'br_phy'.

When forwarding traffic from the tap towards the vxlan device, we
will call pskb_expand_head() in vxlan_build_skb() because
br-phy->needed_headroom is equal to tun->needed_headroom.

With this change we avoid updating the internal vport needed_headroom,
so that in the above scenario no head copy is needed, giving 5%
performance improvement in UDP throughput test.

As a trade-off, packets sent from the internal port towards a tunnel
device will now experience the head copy overhead. The rationale is
that the latter use-case is less relevant performance-wise.

Signed-off-by: paolo abeni 
Acked-by: Pravin B Shelar 
Signed-off-by: David S. Miller 

Cc: paolo abeni 
Signed-off-by: Greg Rose 
---
 datapath/vport-internal_dev.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/datapath/vport-internal_dev.c b/datapath/vport-internal_dev.c
index 0aa331a..9bb8751 100644
--- a/datapath/vport-internal_dev.c
+++ b/datapath/vport-internal_dev.c
@@ -149,13 +149,6 @@ internal_get_stats(struct net_device *dev, struct 
rtnl_link_stats64 *stats)
}
 }
 
-#ifdef HAVE_IFF_PHONY_HEADROOM
-static void internal_set_rx_headroom(struct net_device *dev, int new_hr)
-{
-   dev->needed_headroom = new_hr < 0 ? 0 : new_hr;
-}
-#endif
-
 static const struct net_device_ops internal_dev_netdev_ops = {
.ndo_open = internal_dev_open,
.ndo_stop = internal_dev_stop,
@@ -165,13 +158,6 @@ static const struct net_device_ops internal_dev_netdev_ops 
= {
.ndo_change_mtu = internal_dev_change_mtu,
 #endif
.ndo_get_stats64 = (void *)internal_get_stats,
-#ifdef HAVE_IFF_PHONY_HEADROOM
-#ifndef HAVE_NET_DEVICE_OPS_WITH_EXTENDED
-   .ndo_set_rx_headroom = internal_set_rx_headroom,
-#else
-   .extended.ndo_set_rx_headroom = internal_set_rx_headroom,
-#endif
-#endif
 };
 
 static struct rtnl_link_ops internal_dev_link_ops __read_mostly = {
@@ -189,7 +175,7 @@ static void do_setup(struct net_device *netdev)
 
netdev->priv_flags &= ~IFF_TX_SKB_SHARING;
netdev->priv_flags |= IFF_LIVE_ADDR_CHANGE | IFF_OPENVSWITCH |
- IFF_PHONY_HEADROOM | IFF_NO_QUEUE;
+ IFF_NO_QUEUE;
 #ifndef HAVE_NEEDS_FREE_NETDEV
netdev->destructor = internal_dev_destructor;
 #else
@@ -239,9 +225,6 @@ static struct vport *internal_dev_create(const struct 
vport_parms *parms)
goto error_free_netdev;
}
 
-#ifdef HAVE_IFF_PHONY_HEADROOM
-   vport->dev->needed_headroom = vport->dp->max_headroom;
-#endif
dev_net_set(vport->dev, ovs_dp_get_net(vport->dp));
internal_dev = internal_dev_priv(vport->dev);
internal_dev->vport = vport;
-- 
1.8.3.1

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


[ovs-dev] [PATCH 0/8] Linux upstream kernel backports and updates

2018-02-14 Thread Greg Rose
Pull in the remaining available upstream bug fixes for the openvswitch
Linux kernel datapath.  In addition, allow building the openvswitch
OOT kernel datapath on kernels up to and including Linux kernel release
4.15.

Travis build is here - Note that the errors are not related to this
patch series:

https://travis-ci.org/gvrose8192/ovs-experimental/builds/341649151

The patches can be pulled from here in case that is easier for review.

https://github.com/gvrose8192/ovs-experimental/tree/linux-4.15

The patches are based on commit in the master branch:
f50c1eb4a6 ("docs: Update supported DPDK versions.")

After this series the remaining upstream patches for openvswitch are
all erspan related.  The erspan patches will be sent separately at a
later date.

Christopher Díaz Riveros (1):
  datapath: Remove unneeded semicolons

Ed Swierk (1):
  datapath: Remove padding from packet before L3+ conntrack processing

Eric Garver (1):
  datapath: Fix pop_vlan action for double tagged frames

Greg Rose (2):
  acinclude: Enable building for Linux kernel 4.15
  travis: Update Linux kernel test list

Julia Lawall (1):
  datapath: drop unneeded newline

Yang Shi (1):
  datapath: remove unused hardirq.h

paolo abeni (1):
  datapath: do not propagate headroom updates to internal port

 .travis.yml   | 13 +++--
 acinclude.m4  |  4 ++--
 datapath/conntrack.c  | 38 --
 datapath/flow.c   | 15 ---
 datapath/flow_netlink.c   |  4 ++--
 datapath/vport-internal_dev.c | 20 +---
 6 files changed, 60 insertions(+), 34 deletions(-)

-- 
1.8.3.1

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


[ovs-dev] Despedir Empleados - en Línea

2018-02-14 Thread Evite Riesgos de Demandas
 En línea y en Vivo / Para todo su Equipo con una sola Conexión 

Cómo Despedir Empleados en el marco de la ley
22 de febrero - Online en Vivo - 10:00 a 13:00 y de 15:00 a 18:00 Hrs
 
Despedir a una persona es un delicado proceso invadido de “bombas” legales. No 
importa qué tan preparado se sienta o qué tan acertada sea su decisión, 
no hacerlo de la manera correcta lo pone en riesgo de una demanda.

  ¡Ningún gerente debe comenzar el proceso sin antes asistir a esta 
Capacitación! 
 

TEMARIO: 

1.- Antes de tomar la decisión de realizar un despido.
2.- Su mejor defensa legal: cómo integrar la documentación legal necesaria.
3.- Cuando todo falla: cuándo y cómo despedir legalmente a un empleado.

...¡Y mucho más
 
¿Requiere la información a la Brevedad?
responda este email con la palabra: 
Despedir.
Nombre:
Teléfono:
Empresa:

centro telefónico: 018002129393
 

Lic. Manuel Ravell
Coordinador de Evento


 
¿Demasiados mensajes en su cuenta? Responda este mensaje indicando que solo 
desea recibir CALENDARIO y sólo recibirá un correo al mes. Si desea cancelar la 
suscripción, solicite su BAJA. 


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


Re: [ovs-dev] [PATCHv2 2/2] xlate: add backward resubmit trace log.

2018-02-14 Thread Ben Pfaff
On Wed, Feb 14, 2018 at 10:56:09AM -0800, William Tu wrote:
> When hitting max translation depth of 64, printing the full
> ofproto trace is huge and consumes too much log.  The patch
> adds a short trace log, which prints the 64 backward resubmit
> table IDs during the translation.
> 
> VMWare-BZ: #2054659
> Signed-off-by: William Tu 
> ---
> An example output:
> 2018-02-14T18:13:09.723Z|00084|ofproto_dpif_xlate|WARN|over max translation 
> depth 64, table ID: [9, 8, 7, 6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2, 9, 8, 7, 
> 6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 
> 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2] while processing 
> in_port=1,vlan_tci=0x,dl_src=50:54:00:00:00:01,dl_dst=50:54:00:00:00:ff,dl_type=0x1234
>  on bridge br0

That's kind of a lot of output!  I was thinking of something shorter
that just summarized the most common table and the number of times it
was jumped to.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCHv2 1/2] xlate: auto ofproto trace when recursion too deep

2018-02-14 Thread Ben Pfaff
On Wed, Feb 14, 2018 at 10:56:08AM -0800, William Tu wrote:
> Usually ofproto/trace is used to debug the flow translation error.
> When translation error such as recursion too deep or too many resubmit,
> the issue might happen momentary; flows causing the recursion expire
> when users try to debug it.  This patch enables the ofproto trace
> automatically when recursion is too deep or too many resubmit, by
> invoking the translation again, and log the ofproto trace as warnings.
> Since the log will be huge, rate limit to one per minute.
> 
> VMWare-BZ: #2054659
> Signed-off-by: William Tu 
> Tested-by: Greg Rose 
> Reviewed-by: Greg Rose 

Thanks for working on this!

Some of the data passed to ofproto_trace() is also passed to the
xlate_actions() call, indirectly.  Did you check whether that data is
possibly modified by xlate_actions()?  If it is, then we might have to
reconsider this approach, because flow data, etc. is very large and I
don't think that we can afford to always make a copy of it in advance on
the chance that the original might be needed for tracing later.

I think that VLOG_WARN is a very high log level for this data.  I would
tend to use DBG.

Thanks,

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


[ovs-dev] Gestión de Empresas Familiares

2018-02-14 Thread Reglas claras, Empresas sanas
 
Gestión de empresas familiares 
Marzo 02 - webinar Interactivo

Objetivo:

Descubrir cómo administrar adecuadamente su empresa a pesar y a través de la 
problemática del negocio familiar. 

Temas:

-  Conozca y aplique estrategias de institucionalización de la organización que 
se traducen en una mejor estructura a largo plazo.
- Analice las decisiones trascendentales que debe tomar el fundador.
- Estudie casos probados de éxito y su aplicación a su propio negocio.
- Aprenda a tomar decisiones antes que la vida las tome por usted.  
 
Temario e Inscripciones:

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

045 + 5515546458  



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


[ovs-dev] [PATCH] osv-ofctl: Make ofp-print able to read raw data from a file.

2018-02-14 Thread Ben Pfaff
Occasionally someone sends me raw OpenFlow data in a file and this saves
time converting it to hex.

Signed-off-by: Ben Pfaff 
---
 utilities/ovs-ofctl.c | 57 +--
 1 file changed, 33 insertions(+), 24 deletions(-)

diff --git a/utilities/ovs-ofctl.c b/utilities/ovs-ofctl.c
index e47891ddb353..27a9fc431397 100644
--- a/utilities/ovs-ofctl.c
+++ b/utilities/ovs-ofctl.c
@@ -153,6 +153,9 @@ static int show_stats = 1;
 /* --pcap: Makes "compose-packet" print a pcap on stdout. */
 static int print_pcap = 0;
 
+/* --raw: Makes "ofp-print" read binary data from stdin. */
+static int raw = 0;
+
 static const struct ovs_cmdl_command *get_all_commands(void);
 
 OVS_NO_RETURN static void usage(void);
@@ -239,6 +242,7 @@ parse_options(int argc, char *argv[])
 {"color", optional_argument, NULL, OPT_COLOR},
 {"may-create", no_argument, NULL, OPT_MAY_CREATE},
 {"pcap", no_argument, _pcap, 1},
+{"raw", no_argument, , 1},
 {"read-only", no_argument, NULL, OPT_READ_ONLY},
 DAEMON_LONG_OPTIONS,
 OFP_VERSION_LONG_OPTIONS,
@@ -4629,43 +4633,48 @@ ofctl_encode_error_reply(struct ovs_cmdl_context *ctx)
 ofpbuf_delete(reply);
 }
 
-/* "ofp-print HEXSTRING [VERBOSITY]": Converts the hex digits in HEXSTRING into
- * binary data, interpreting them as an OpenFlow message, and prints the
- * OpenFlow message on stdout, at VERBOSITY (level 2 by default).
+/* Usage:
+ *ofp-print HEXSTRING [VERBOSITY]
+ *ofp-print - [VERBOSITY] < HEXSTRING_FILE
+ *ofp-print --raw - [VERBOSITY] < RAW_FILE
  *
- * Alternative usage: "ofp-print [VERBOSITY] - < HEXSTRING_FILE", where
- * HEXSTRING_FILE contains the HEXSTRING. */
+ * Converts the hex digits in HEXSTRING into binary data, interpreting them as
+ * an OpenFlow message, and prints the OpenFlow message on stdout, at VERBOSITY
+ * (level 2 by default).  With -, hex data is read from HEXSTRING_FILE, and
+ * with --raw -, raw binary data is read from RAW_FILE. */
 static void
 ofctl_ofp_print(struct ovs_cmdl_context *ctx)
 {
-struct ofpbuf packet;
-char *buffer;
-int verbosity = 2;
-struct ds line;
+int verbosity = ctx->argc > 2 ? atoi(ctx->argv[2]) : 2;
 
-ds_init();
+struct ofpbuf packet;
+ofpbuf_init(, 0);
 
-if (!strcmp(ctx->argv[ctx->argc-1], "-")) {
-if (ds_get_line(, stdin)) {
-   VLOG_FATAL("Failed to read stdin");
+char *buffer = NULL;
+if (!strcmp(ctx->argv[1], "-")) {
+if (raw) {
+for (;;) {
+int c = getchar();
+if (c == EOF) {
+break;
+}
+ofpbuf_put(, , 1);
+}
+} else {
+struct ds line = DS_EMPTY_INITIALIZER;
+if (ds_get_line(, stdin)) {
+VLOG_FATAL("Failed to read stdin");
+}
+buffer = ds_steal_cstr();
 }
-
-buffer = line.string;
-verbosity = ctx->argc > 2 ? atoi(ctx->argv[1]) : verbosity;
-} else if (ctx->argc > 2) {
-buffer = ctx->argv[1];
-verbosity = atoi(ctx->argv[2]);
-} else {
+} else  {
 buffer = ctx->argv[1];
 }
-
-ofpbuf_init(, strlen(buffer) / 2);
-if (ofpbuf_put_hex(, buffer, NULL)[0] != '\0') {
+if (buffer && ofpbuf_put_hex(, buffer, NULL)[0] != '\0') {
 ovs_fatal(0, "trailing garbage following hex bytes");
 }
 ofp_print(stdout, packet.data, packet.size, NULL, NULL, verbosity);
 ofpbuf_uninit();
-ds_destroy();
 }
 
 /* "encode-hello BITMAP...": Encodes each BITMAP as an OpenFlow hello message
-- 
2.16.1

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


[ovs-dev] [PATCH] ofp-meter: Fix use-after-free for decoding meter mods.

2018-02-14 Thread Ben Pfaff
Found by libfuzzer-ngram.

Reported-by: Bhargava Shastry 
Signed-off-by: Ben Pfaff 
---
 lib/ofp-meter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/ofp-meter.c b/lib/ofp-meter.c
index 204f035ec290..4f77f508d396 100644
--- a/lib/ofp-meter.c
+++ b/lib/ofp-meter.c
@@ -98,12 +98,12 @@ ofputil_decode_meter_mod(const struct ofp_header *oh,
 mm->meter.flags & OFPMF13_PKTPS) {
 return OFPERR_OFPMMFC_BAD_FLAGS;
 }
-mm->meter.bands = bands->data;
 
 error = ofputil_pull_bands(, b.size, >meter.n_bands, bands);
 if (error) {
 return error;
 }
+mm->meter.bands = bands->data;
 }
 return 0;
 }
-- 
2.16.1

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


Re: [ovs-dev] [PATCH] conntrack: Support conntrack flush by ct 5-tuple

2018-02-14 Thread Ben Pfaff
Thanks Yi-Hung and Darrell.  I applied this to master.

On Mon, Feb 12, 2018 at 05:12:24PM -0800, Darrell Ball wrote:
> Nice.
> 
> Acked-by: Darrell Ball 
> 
> On Mon, Feb 12, 2018 at 4:26 PM, Darrell Ball  wrote:
> 
> > Thanks Yi-hung
> >
> > I will try it out.
> >
> > Darrell
> >
> > On Mon, Feb 12, 2018 at 2:02 PM, Yi-Hung Wei  wrote:
> >
> >> This patch adds support of flushing a conntrack entry specified by the
> >> conntrack 5-tuple in dpif-netdev.
> >>
> >> Signed-off-by: Yi-Hung Wei 
> >> ---
> >> Respin this patch since userspace conntrack now clears out the expectation
> >> when a conntrack entry is deleted.
> >> ---
> >>  lib/conntrack.c  | 72 ++
> >> ++
> >>  lib/conntrack.h  |  3 ++
> >>  lib/dpif-netdev.c|  2 +-
> >>  tests/system-kmod-macros.at  |  8 -
> >>  tests/system-traffic.at  |  1 -
> >>  tests/system-userspace-macros.at | 10 --
> >>  6 files changed, 76 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/lib/conntrack.c b/lib/conntrack.c
> >> index fe5fd0fe8be1..c05b3901d7af 100644
> >> --- a/lib/conntrack.c
> >> +++ b/lib/conntrack.c
> >> @@ -2368,6 +2368,10 @@ delete_conn(struct conn *conn)
> >>  free(conn);
> >>  }
> >>
> >> +/* Convert a conntrack address 'a' into an IP address 'b' based on
> >> 'dl_type'.
> >> + *
> >> + * Note that 'dl_type' should be either "ETH_TYPE_IP" or "ETH_TYPE_IPv6"
> >> + * in network-byte order. */
> >>  static void
> >>  ct_endpoint_to_ct_dpif_inet_addr(const struct ct_addr *a,
> >>   union ct_dpif_inet_addr *b,
> >> @@ -2380,6 +2384,22 @@ ct_endpoint_to_ct_dpif_inet_addr(const struct
> >> ct_addr *a,
> >>  }
> >>  }
> >>
> >> +/* Convert an IP address 'a' into a conntrack address 'b' based on
> >> 'dl_type'.
> >> + *
> >> + * Note that 'dl_type' should be either "ETH_TYPE_IP" or "ETH_TYPE_IPv6"
> >> + * in network-byte order. */
> >> +static void
> >> +ct_dpif_inet_addr_to_ct_endpoint(const union ct_dpif_inet_addr *a,
> >> + struct ct_addr *b,
> >> + ovs_be16 dl_type)
> >> +{
> >> +if (dl_type == htons(ETH_TYPE_IP)) {
> >> +b->ipv4_aligned = a->ip;
> >> +} else if (dl_type == htons(ETH_TYPE_IPV6)){
> >> +b->ipv6_aligned = a->in6;
> >> +}
> >> +}
> >> +
> >>  static void
> >>  conn_key_to_tuple(const struct conn_key *key, struct ct_dpif_tuple
> >> *tuple)
> >>  {
> >> @@ -2405,6 +2425,35 @@ conn_key_to_tuple(const struct conn_key *key,
> >> struct ct_dpif_tuple *tuple)
> >>  }
> >>
> >>  static void
> >> +tuple_to_conn_key(const struct ct_dpif_tuple *tuple, uint16_t zone,
> >> +  struct conn_key *key)
> >> +{
> >> +if (tuple->l3_type == AF_INET) {
> >> +key->dl_type = htons(ETH_TYPE_IP);
> >> +} else if (tuple->l3_type == AF_INET6) {
> >> +key->dl_type = htons(ETH_TYPE_IPV6);
> >> +}
> >> +key->nw_proto = tuple->ip_proto;
> >> +ct_dpif_inet_addr_to_ct_endpoint(>src, >src.addr,
> >> + key->dl_type);
> >> +ct_dpif_inet_addr_to_ct_endpoint(>dst, >dst.addr,
> >> + key->dl_type);
> >> +
> >> +if (tuple->ip_proto == IPPROTO_ICMP || tuple->ip_proto ==
> >> IPPROTO_ICMPV6) {
> >> +key->src.icmp_id = tuple->icmp_id;
> >> +key->src.icmp_type = tuple->icmp_type;
> >> +key->src.icmp_code = tuple->icmp_code;
> >> +key->dst.icmp_id = tuple->icmp_id;
> >> +key->dst.icmp_type = reverse_icmp_type(tuple->icmp_type);
> >> +key->dst.icmp_code = tuple->icmp_code;
> >> +} else {
> >> +key->src.port = tuple->src_port;
> >> +key->dst.port = tuple->dst_port;
> >> +}
> >> +key->zone = zone;
> >> +}
> >> +
> >> +static void
> >>  conn_to_ct_dpif_entry(const struct conn *conn, struct ct_dpif_entry
> >> *entry,
> >>long long now, int bkt)
> >>  {
> >> @@ -2517,6 +2566,29 @@ conntrack_flush(struct conntrack *ct, const
> >> uint16_t *zone)
> >>  }
> >>
> >>  int
> >> +conntrack_flush_tuple(struct conntrack *ct, const struct ct_dpif_tuple
> >> *tuple,
> >> +  uint16_t zone)
> >> +{
> >> +struct conn_lookup_ctx ctx;
> >> +int error = 0;
> >> +
> >> +memset(, 0, sizeof(ctx));
> >> +tuple_to_conn_key(tuple, zone, );
> >> +ctx.hash = conn_key_hash(, ct->hash_basis);
> >> +unsigned bucket = hash_to_bucket(ctx.hash);
> >> +
> >> +ct_lock_lock(>buckets[bucket].lock);
> >> +conn_key_lookup(>buckets[bucket], , time_msec());
> >> +if (ctx.conn) {
> >> +conn_clean(ct, ctx.conn, >buckets[bucket]);
> >> +} else {
> >> +error = ENOENT;
> >> +}
> >> +ct_lock_unlock(>buckets[bucket].lock);
> >> +return error;
> >> +}
> >> +
> >> +int
> >>  conntrack_set_maxconns(struct 

Re: [ovs-dev] [RFC] ovn-northd: Store computed logical flow hash in SBDB.

2018-02-14 Thread Ben Pfaff
On Tue, Feb 13, 2018 at 02:57:40PM +0100, Jakub Sitnicki wrote:
> Each time ovn-northd processes the NBDB contents it has to compute the
> hash of every logical flow stored in the SBDB in order to identify ones
> that need adding to or deleting from SBDB (build_lflows()).
> 
> Avoid it by storing the logical flow hash together with its fields the
> moment we first add it to SBDB. This saves us the hash computations
> afterwards, every time ovn-northd processes the logical flows to find
> candidates for removal/addition.
> 
> In a simple micro-benchmark that adds 15 logical switches with 100
> logical ports each, perf tool shows a drop of 7% in CPU cycles
> ('cycles:ppp' event) spent in ovn_lflow_find() where we compute the hash
> of each logical flow found in SBDB:
> 
> Children  Self  Command Shared Object   Symbol
> before:   10.61% 0.17%  ovn-northd  ovn-northd  [.] ovn_lflow_find
> after: 2.82% 0.19%  ovn-northd  ovn-northd  [.] ovn_lflow_find

This is good work, thanks for figuring this out.

I think that it is better if this kind of thing is not actually stored
in the database.  It adds a risk that the hash could get out of sync
with the rest of a row, and there is no guarantee that the hash function
is the same from one version of OVS to the next or between little and
big endian architectures on the same version of OVS.

However, we can still do better by calculating the hash only a single
time on the client and only recalculating it if the row otherwise
changes.  I had a branch a while back that implemented something more
ambitious than this, so I cut it down and polished it up and this is
what I came up with:
https://patchwork.ozlabs.org/project/openvswitch/list/?series=28651

Would you mind testing it to see whether its performance benefit is
similar to what you observed?

Thanks,

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


[ovs-dev] [PATCH 4/4] ovn-northd: Reduce amount of flow hashing.

2018-02-14 Thread Ben Pfaff
Jakub Sitnicki demonstrated that repeatedly calculating row hashes is
expensive, so this should improve ovn-northd performance.

Reported-by: Jakub Sitnicki 
Reported-at: 
https://mail.openvswitch.org/pipermail/ovs-dev/2018-February/344404.html
Signed-off-by: Ben Pfaff 
---
 ovn/lib/ovn-sb-idl.ann  | 20 
 ovn/lib/ovn-util.c  | 27 +++
 ovn/lib/ovn-util.h  |  7 +++
 ovn/northd/ovn-northd.c | 28 +---
 4 files changed, 71 insertions(+), 11 deletions(-)

diff --git a/ovn/lib/ovn-sb-idl.ann b/ovn/lib/ovn-sb-idl.ann
index 2dfc64e3c4a7..e51238b92e97 100644
--- a/ovn/lib/ovn-sb-idl.ann
+++ b/ovn/lib/ovn-sb-idl.ann
@@ -7,3 +7,23 @@
 
 s["idlPrefix"] = "sbrec_"
 s["idlHeader"] = "\"ovn/lib/ovn-sb-idl.h\""
+
+s["hDecls"] = '#include "ovn/lib/ovn-util.h"'
+
+# Adds an integer column named 'column' to 'table' in 's'.  The column
+# values is calculated with 'expression' based on the values of the columns
+# named in the array 'dependencies'.
+def synthesize_integer_column(s, table, column, dependencies, expression):
+s["tables"][table]["columns"][column] = {
+"type": "integer",
+"extensions": {
+"dependencies": dependencies,
+"parse": "row->%s = %s;" % (column, expression),
+"synthetic": True
+}
+}
+
+synthesize_integer_column(s, "Logical_Flow", "hash",
+  ["logical_datapath", "table_id", "pipeline",
+   "priority", "match", "actions"],
+  "sbrec_logical_flow_hash(row)")
diff --git a/ovn/lib/ovn-util.c b/ovn/lib/ovn-util.c
index a554c23f5ae8..e9464e926d74 100644
--- a/ovn/lib/ovn-util.c
+++ b/ovn/lib/ovn-util.c
@@ -17,6 +17,7 @@
 #include "dirs.h"
 #include "openvswitch/vlog.h"
 #include "ovn/lib/ovn-nb-idl.h"
+#include "ovn/lib/ovn-sb-idl.h"
 
 VLOG_DEFINE_THIS_MODULE(ovn_util);
 
@@ -329,3 +330,29 @@ ovn_is_known_nb_lsp_type(const char *type)
 
 return false;
 }
+
+uint32_t
+sbrec_logical_flow_hash(const struct sbrec_logical_flow *lf)
+{
+const struct sbrec_datapath_binding *ld = lf->logical_datapath;
+if (!ld) {
+return 0;
+}
+
+return ovn_logical_flow_hash(>header_.uuid,
+ lf->table_id, lf->pipeline,
+ lf->priority, lf->match, lf->actions);
+}
+
+uint32_t
+ovn_logical_flow_hash(const struct uuid *logical_datapath,
+  uint8_t table_id, const char *pipeline,
+  uint16_t priority,
+  const char *match, const char *actions)
+{
+size_t hash = uuid_hash(logical_datapath);
+hash = hash_2words((table_id << 16) | priority, hash);
+hash = hash_string(pipeline, hash);
+hash = hash_string(match, hash);
+return hash_string(actions, hash);
+}
diff --git a/ovn/lib/ovn-util.h b/ovn/lib/ovn-util.h
index 9b456426dc67..7ff9f9a1c73b 100644
--- a/ovn/lib/ovn-util.h
+++ b/ovn/lib/ovn-util.h
@@ -19,6 +19,7 @@
 #include "lib/packets.h"
 
 struct nbrec_logical_router_port;
+struct sbrec_logical_flow;
 struct uuid;
 
 struct ipv4_netaddr {
@@ -69,4 +70,10 @@ const char *default_sb_db(void);
 
 bool ovn_is_known_nb_lsp_type(const char *type);
 
+uint32_t sbrec_logical_flow_hash(const struct sbrec_logical_flow *);
+uint32_t ovn_logical_flow_hash(const struct uuid *logical_datapath,
+   uint8_t table_id, const char *pipeline,
+   uint16_t priority,
+   const char *match, const char *actions);
+
 #endif
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 4d95a3d9d40e..5d764f6e9404 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -194,6 +194,13 @@ ovn_stage_get_pipeline(enum ovn_stage stage)
 return (stage >> 8) & 1;
 }
 
+/* Returns the pipeline name to which 'stage' belongs. */
+static const char *
+ovn_stage_get_pipeline_name(enum ovn_stage stage)
+{
+return ovn_stage_get_pipeline(stage) == P_IN ? "ingress" : "egress";
+}
+
 /* Returns the table to which 'stage' belongs. */
 static uint8_t
 ovn_stage_get_table(enum ovn_stage stage)
@@ -2271,10 +2278,11 @@ struct ovn_lflow {
 static size_t
 ovn_lflow_hash(const struct ovn_lflow *lflow)
 {
-size_t hash = uuid_hash(>od->key);
-hash = hash_2words((lflow->stage << 16) | lflow->priority, hash);
-hash = hash_string(lflow->match, hash);
-return hash_string(lflow->actions, hash);
+return ovn_logical_flow_hash(>od->key,
+ ovn_stage_get_table(lflow->stage),
+ ovn_stage_get_pipeline_name(lflow->stage),
+ lflow->priority, lflow->match,
+ lflow->actions);
 }
 
 static bool
@@ -2331,7 +2339,7 @@ ovn_lflow_add_at(struct hmap *lflow_map, struct 
ovn_datapath *od,
 static struct ovn_lflow *
 ovn_lflow_find(struct hmap 

[ovs-dev] [PATCH 3/4] ovsdb-idlc: Implement synthetic columns.

2018-02-14 Thread Ben Pfaff
A synthetic column is one that is not present in the actual database but
instead calculated by code in the client based on columns in the row.  This
can be useful to avoid repeatedly calculating the same function of a row.

Signed-off-by: Ben Pfaff 
---
 lib/ovsdb-idl-provider.h |  1 +
 lib/ovsdb-idl.c  | 14 ++--
 ovsdb/ovsdb-idlc.1   | 31 -
 ovsdb/ovsdb-idlc.in  | 89 +---
 4 files changed, 127 insertions(+), 8 deletions(-)

diff --git a/lib/ovsdb-idl-provider.h b/lib/ovsdb-idl-provider.h
index b0ebed44f83a..4268dc54c659 100644
--- a/lib/ovsdb-idl-provider.h
+++ b/lib/ovsdb-idl-provider.h
@@ -94,6 +94,7 @@ struct ovsdb_idl_column {
 char *name;
 struct ovsdb_type type;
 bool is_mutable;
+bool is_synthetic;
 void (*parse)(struct ovsdb_idl_row *, const struct ovsdb_datum *);
 void (*unparse)(struct ovsdb_idl_row *);
 };
diff --git a/lib/ovsdb-idl.c b/lib/ovsdb-idl.c
index 29f893116aee..b027f8cad35d 100644
--- a/lib/ovsdb-idl.c
+++ b/lib/ovsdb-idl.c
@@ -1560,9 +1560,16 @@ ovsdb_idl_send_monitor_request__(struct ovsdb_idl *idl,
 columns = table->need_table ? json_array_create_empty() : NULL;
 for (j = 0; j < tc->n_columns; j++) {
 const struct ovsdb_idl_column *column = >columns[j];
-if (table->modes[j] & OVSDB_IDL_MONITOR) {
-if (table_schema
-&& !sset_contains(table_schema, column->name)) {
+bool db_has_column = (table_schema &&
+  sset_contains(table_schema, column->name));
+if (column->is_synthetic) {
+if (db_has_column) {
+VLOG_WARN("%s table in %s database has synthetic "
+  "column %s", table->class_->name,
+  idl->class_->database, column->name);
+}
+} else if (table->modes[j] & OVSDB_IDL_MONITOR) {
+if (table_schema && !db_has_column) {
 VLOG_WARN("%s table in %s database lacks %s column "
   "(database needs upgrade?)",
   table->class_->name, idl->class_->database,
@@ -3815,6 +3822,7 @@ ovsdb_idl_txn_write__(const struct ovsdb_idl_row *row_,
 size_t column_idx;
 bool write_only;
 
+ovs_assert(!column->is_synthetic);
 if (ovsdb_idl_row_is_synthetic(row)) {
 goto discard_datum;
 }
diff --git a/ovsdb/ovsdb-idlc.1 b/ovsdb/ovsdb-idlc.1
index f1659b4a63b7..cc78b66c40e0 100644
--- a/ovsdb/ovsdb-idlc.1
+++ b/ovsdb/ovsdb-idlc.1
@@ -55,8 +55,37 @@ after the \fB#include\fR directives in those files.
 This member is optional.  If specified, it is an object whose contents
 describes extensions to the OVSDB schema language, for the purpose of
 specifying interpretation by the IDL.
-No extensions are supported yet.
 .
+.IP "\fB""\fBsynthetic\fR"" member of  ""\fBextensions\fR"" 
object"
+If this optional member is set to \fBtrue\fR, then it indicates that
+the column is not expected to be found in the actual database.
+Instead, code supplied by the IDL's client fills in the desired
+structure members based on the value of one or more other database
+columns.  This can be used to cache the result of a calculation, for
+example.
+.
+.IP "\fB""\fBparse\fR"" member of  ""\fBextensions\fR"" object"
+This member should be present if and only if the column is synthetic.
+It should be a string that contains C code to set the value of the
+column's member in an object named \fBrow\fR, e.g. "\fBrow->column =
+1;" if the column's name is \fBcolumn\fR and has integer type.  The
+code may rely on the columns named in \fBdependencies\fR to be
+initialized.  The function can get called for rows that do not satisfy
+the constraints in the schema, e.g. that a pointer to another is
+nonnull, so it must not rely on those constraints.
+.
+.IP "\fB""\fBunparse\fR"" member of  ""\fBextensions\fR"" 
object"
+This member is honored only if the column is synthetic.  It should be
+a string that contains C code to free the data in the column's member
+in an object named \fBrow\fR, e.g. "\fBfree(row->column);" if the
+column's name is \fBcolumn\fR and points to data that was allocated by
+the \fBparse\fR function and needs to be freed.
+.
+.IP "\fB""\fBdependencies\fR"" member of  ""\fBextensions\fR"" 
object"
+This member should be a list of the names of columns whose values are
+used by the code in \fBparse\fR and \fBunparse\fR.  The IDL ensures
+that dependencies are parsed before the columns that depends on them,
+and vice versa for unparsing.
 .SS "Commands"
 .IP "\fBannotate\fI schema annotations\fR"
 Reads \fIschema\fR, which should be a file in JSON format (ordinarily
diff --git a/ovsdb/ovsdb-idlc.in b/ovsdb/ovsdb-idlc.in
index 95bb9f4ca9e0..1ea2115c0e74 100755
--- a/ovsdb/ovsdb-idlc.in
+++ b/ovsdb/ovsdb-idlc.in
@@ -119,8 +119,42 @@ def 

[ovs-dev] [PATCH 1/4] ovsdb-idlc: Add "cDecls" and "hDecls" IDL schema extensions.

2018-02-14 Thread Ben Pfaff
An IDL schema is an OVSDB schema with some extra stuff in it: an idlPrefix
and an idlHeader at the top level to indicate what ovsdb-idlc needs to
generate the interface definitions.  This commit adds support for two more
optional IDL schema extensions that allow extra code to be written to the
.c and .h file that ovsdb-idlc generates.

Signed-off-by: Ben Pfaff 
---
 ovsdb/ovsdb-idlc.1  |  6 ++
 ovsdb/ovsdb-idlc.in | 10 +++---
 python/ovs/db/schema.py | 11 +--
 3 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/ovsdb/ovsdb-idlc.1 b/ovsdb/ovsdb-idlc.1
index af68e93e16f8..e1910d9dce66 100644
--- a/ovsdb/ovsdb-idlc.1
+++ b/ovsdb/ovsdb-idlc.1
@@ -39,6 +39,12 @@ It will be output on an \fB#include\fR line in the source 
file
 generated by the C bindings.  It should include the bracketing
 \fB""\fR or \fB<>\fR.
 .
+.IP "\fB""\fBcDecls\fR"" member of "
+.IQ "\fB""\fBhDecls\fR"" member of "
+These optional members may specify arbitrary code to include in the
+generated \fB.c\fR or \fB.h\fR file, respectively, in each case just
+after the \fB#include\fR directives in those files.
+.
 .SS "Commands"
 .IP "\fBannotate\fI schema annotations\fR"
 Reads \fIschema\fR, which should be a file in JSON format (ordinarily
diff --git a/ovsdb/ovsdb-idlc.in b/ovsdb/ovsdb-idlc.in
index 2edb9ef54eda..95bb9f4ca9e0 100755
--- a/ovsdb/ovsdb-idlc.in
+++ b/ovsdb/ovsdb-idlc.in
@@ -167,7 +167,8 @@ def printCIDLHeader(schemaFile):
 #ifdef  __cplusplus
 extern "C" {
 #endif
-''' % {'prefix': prefix.upper()})
+%(hDecls)s''' % {'prefix': prefix.upper(),
+'hDecls': schema.hDecls})
 
 for tableName, table in sorted(schema.tables.items()):
 structName = "%s%s" % (prefix, tableName.lower())
@@ -359,14 +360,17 @@ def printCIDLSource(schemaFile):
 /* Generated automatically -- do not modify!-*- buffer-read-only: t -*- */
 
 #include 
-#include %s
+#include %(header)s
 #include 
 #include "ovs-thread.h"
 #include "ovsdb-data.h"
 #include "ovsdb-error.h"
 #include "util.h"
 
-''' % schema.idlHeader)
+%(cDecls)s
+
+''' % {'header': schema.idlHeader,
+   'cDecls': schema.cDecls})
 
 # Cast functions.
 for tableName, table in sorted(schema.tables.items()):
diff --git a/python/ovs/db/schema.py b/python/ovs/db/schema.py
index b68c19e00e0b..5f1f6c41a52b 100644
--- a/python/ovs/db/schema.py
+++ b/python/ovs/db/schema.py
@@ -125,24 +125,31 @@ class DbSchema(object):
 
 
 class IdlSchema(DbSchema):
-def __init__(self, name, version, tables, idlPrefix, idlHeader):
+def __init__(self, name, version, tables, idlPrefix, idlHeader,
+ cDecls, hDecls):
 DbSchema.__init__(self, name, version, tables)
 self.idlPrefix = idlPrefix
 self.idlHeader = idlHeader
+self.cDecls = cDecls
+self.hDecls = hDecls
 
 @staticmethod
 def from_json(json):
 parser = ovs.db.parser.Parser(json, "IDL schema")
 idlPrefix = parser.get("idlPrefix", six.string_types)
 idlHeader = parser.get("idlHeader", six.string_types)
+cDecls = parser.get_optional("cDecls", six.string_types, "")
+hDecls = parser.get_optional("hDecls", six.string_types, "")
 
 subjson = dict(json)
 del subjson["idlPrefix"]
 del subjson["idlHeader"]
+subjson.pop("cDecls", None)
+subjson.pop("hDecls", None)
 schema = DbSchema.from_json(subjson)
 
 return IdlSchema(schema.name, schema.version, schema.tables,
- idlPrefix, idlHeader)
+ idlPrefix, idlHeader, cDecls, hDecls)
 
 
 def column_set_from_json(json, columns):
-- 
2.16.1

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


[ovs-dev] [PATCH 2/4] ovsdb-idlc: Add infrastructure for IDL schema extensions.

2018-02-14 Thread Ben Pfaff
An IDL schema is an OVSDB schema with some extra stuff in it.  So far, all
of the extras have been at the top level.  This commit makes it possible
for IDL schemas to have extra information at the table and column levels as
long as it is in an "extensions" member.

No extensions are actually supported yet.

Signed-off-by: Ben Pfaff 
---
 ovsdb/ovsdb-idlc.1  | 12 
 python/ovs/db/schema.py | 37 ++---
 2 files changed, 38 insertions(+), 11 deletions(-)

diff --git a/ovsdb/ovsdb-idlc.1 b/ovsdb/ovsdb-idlc.1
index e1910d9dce66..f1659b4a63b7 100644
--- a/ovsdb/ovsdb-idlc.1
+++ b/ovsdb/ovsdb-idlc.1
@@ -1,4 +1,9 @@
 .\" -*- nroff -*-
+.de IQ
+.  br
+.  ns
+.  IP "\\$1"
+..
 .TH ovsdb\-idlc 1 "November 2009" "Open vSwitch" "Open vSwitch Manual"
 .ds PN ovsdb\-idlc
 .
@@ -45,6 +50,13 @@ These optional members may specify arbitrary code to include 
in the
 generated \fB.c\fR or \fB.h\fR file, respectively, in each case just
 after the \fB#include\fR directives in those files.
 .
+.IP "\fB""\fBextensions\fR"" member of "
+.IQ "\fB""\fBextensions\fR"" member of "
+This member is optional.  If specified, it is an object whose contents
+describes extensions to the OVSDB schema language, for the purpose of
+specifying interpretation by the IDL.
+No extensions are supported yet.
+.
 .SS "Commands"
 .IP "\fBannotate\fI schema annotations\fR"
 Reads \fIschema\fR, which should be a file in JSON format (ordinarily
diff --git a/python/ovs/db/schema.py b/python/ovs/db/schema.py
index 5f1f6c41a52b..55c8ae7f3531 100644
--- a/python/ovs/db/schema.py
+++ b/python/ovs/db/schema.py
@@ -32,7 +32,7 @@ def _check_id(name, json):
 class DbSchema(object):
 """Schema for an OVSDB database."""
 
-def __init__(self, name, version, tables):
+def __init__(self, name, version, tables, allow_extensions=False):
 self.name = name
 self.version = version
 self.tables = tables
@@ -64,7 +64,7 @@ class DbSchema(object):
 return n_root
 
 @staticmethod
-def from_json(json):
+def from_json(json, allow_extensions=False):
 parser = ovs.db.parser.Parser(json, "database schema")
 name = parser.get("name", ['id'])
 version = parser.get_optional("version", six.string_types)
@@ -80,7 +80,8 @@ class DbSchema(object):
 tables = {}
 for tableName, tableJson in six.iteritems(tablesJson):
 _check_id(tableName, json)
-tables[tableName] = TableSchema.from_json(tableJson, tableName)
+tables[tableName] = TableSchema.from_json(tableJson, tableName,
+  allow_extensions)
 
 return DbSchema(name, version, tables)
 
@@ -146,7 +147,7 @@ class IdlSchema(DbSchema):
 del subjson["idlHeader"]
 subjson.pop("cDecls", None)
 subjson.pop("hDecls", None)
-schema = DbSchema.from_json(subjson)
+schema = DbSchema.from_json(subjson, allow_extensions=True)
 
 return IdlSchema(schema.name, schema.version, schema.tables,
  idlPrefix, idlHeader, cDecls, hDecls)
@@ -173,22 +174,27 @@ def column_set_from_json(json, columns):
 
 class TableSchema(object):
 def __init__(self, name, columns, mutable=True, max_rows=sys.maxsize,
- is_root=True, indexes=[]):
+ is_root=True, indexes=[], extensions={}):
 self.name = name
 self.columns = columns
 self.mutable = mutable
 self.max_rows = max_rows
 self.is_root = is_root
 self.indexes = indexes
+self.extensions = extensions
 
 @staticmethod
-def from_json(json, name):
+def from_json(json, name, allow_extensions=False):
 parser = ovs.db.parser.Parser(json, "table schema for table %s" % name)
 columns_json = parser.get("columns", [dict])
 mutable = parser.get_optional("mutable", [bool], True)
 max_rows = parser.get_optional("maxRows", [int])
 is_root = parser.get_optional("isRoot", [bool], False)
 indexes_json = parser.get_optional("indexes", [list], [])
+if allow_extensions:
+extensions = parser.get_optional("extensions", [dict], {})
+else:
+extensions = {}
 parser.finish()
 
 if max_rows is None:
@@ -203,7 +209,8 @@ class TableSchema(object):
 for column_name, column_json in six.iteritems(columns_json):
 _check_id(column_name, json)
 columns[column_name] = ColumnSchema.from_json(column_json,
-  column_name)
+  column_name,
+  allow_extensions)
 
 indexes = []
 for index_json in indexes_json:
@@ -218,7 +225,8 @@ class TableSchema(object):
   "not be indexed" % column.name, json)

[ovs-dev] [PATCHv2 1/2] xlate: auto ofproto trace when recursion too deep

2018-02-14 Thread William Tu
Usually ofproto/trace is used to debug the flow translation error.
When translation error such as recursion too deep or too many resubmit,
the issue might happen momentary; flows causing the recursion expire
when users try to debug it.  This patch enables the ofproto trace
automatically when recursion is too deep or too many resubmit, by
invoking the translation again, and log the ofproto trace as warnings.
Since the log will be huge, rate limit to one per minute.

VMWare-BZ: #2054659
Signed-off-by: William Tu 
Tested-by: Greg Rose 
Reviewed-by: Greg Rose 
---
 ofproto/ofproto-dpif-trace.c  |  7 +--
 ofproto/ofproto-dpif-trace.h  |  6 ++
 ofproto/ofproto-dpif-upcall.c | 22 +-
 tests/ofproto-dpif.at | 25 +
 4 files changed, 53 insertions(+), 7 deletions(-)

diff --git a/ofproto/ofproto-dpif-trace.c b/ofproto/ofproto-dpif-trace.c
index 4071cc0ffd65..7211eac8e1a5 100644
--- a/ofproto/ofproto-dpif-trace.c
+++ b/ofproto/ofproto-dpif-trace.c
@@ -23,11 +23,6 @@
 #include "ofproto-dpif-xlate.h"
 #include "unixctl.h"
 
-static void ofproto_trace(struct ofproto_dpif *, const struct flow *,
-  const struct dp_packet *packet,
-  const struct ofpact[], size_t ofpacts_len,
-  struct ovs_list *next_ct_states,
-  struct ds *);
 static void oftrace_node_destroy(struct oftrace_node *);
 
 /* Creates a new oftrace_node, populates it with the given 'type' and a copy of
@@ -661,7 +656,7 @@ ofproto_trace__(struct ofproto_dpif *ofproto, const struct 
flow *flow,
  *
  * If 'ofpacts' is nonnull then its 'ofpacts_len' bytes specify the actions to
  * trace, otherwise the actions are determined by a flow table lookup. */
-static void
+void
 ofproto_trace(struct ofproto_dpif *ofproto, const struct flow *flow,
   const struct dp_packet *packet,
   const struct ofpact ofpacts[], size_t ofpacts_len,
diff --git a/ofproto/ofproto-dpif-trace.h b/ofproto/ofproto-dpif-trace.h
index 5e51771b19b0..ea6cb3fc01ac 100644
--- a/ofproto/ofproto-dpif-trace.h
+++ b/ofproto/ofproto-dpif-trace.h
@@ -28,6 +28,8 @@
  * each action (OFT_ACTION) executed in the table.
  */
 
+#include "openvswitch/dynamic-string.h"
+#include "ofproto/ofproto-dpif.h"
 #include "openvswitch/compiler.h"
 #include "openvswitch/list.h"
 #include "flow.h"
@@ -79,6 +81,10 @@ struct oftrace_next_ct_state {
 };
 
 void ofproto_dpif_trace_init(void);
+void ofproto_trace(struct ofproto_dpif *ofproto, const struct flow *flow,
+  const struct dp_packet *packet,
+  const struct ofpact *, size_t ofpacts_len,
+  struct ovs_list *next_ct_states, struct ds *output);
 
 struct oftrace_node *oftrace_report(struct ovs_list *, enum oftrace_node_type,
 const char *text);
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index 5eb20f7cc236..1741741fb5c5 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -34,6 +34,7 @@
 #include "ofproto-dpif-sflow.h"
 #include "ofproto-dpif-xlate.h"
 #include "ofproto-dpif-xlate-cache.h"
+#include "ofproto-dpif-trace.h"
 #include "ovs-rcu.h"
 #include "packets.h"
 #include "openvswitch/poll-loop.h"
@@ -1130,7 +1131,9 @@ upcall_xlate(struct udpif *udpif, struct upcall *upcall,
  struct ofpbuf *odp_actions, struct flow_wildcards *wc)
 {
 struct dpif_flow_stats stats;
+enum xlate_error xerr;
 struct xlate_in xin;
+struct ds output;
 
 stats.n_packets = 1;
 stats.n_bytes = dp_packet_size(upcall->packet);
@@ -1165,7 +1168,24 @@ upcall_xlate(struct udpif *udpif, struct upcall *upcall,
 upcall->dump_seq = seq_read(udpif->dump_seq);
 upcall->reval_seq = seq_read(udpif->reval_seq);
 
-xlate_actions(, >xout);
+xerr = xlate_actions(, >xout);
+
+/* Translate again and log the ofproto trace for
+ * these two error types. */
+if (xerr == XLATE_RECURSION_TOO_DEEP ||
+xerr == XLATE_TOO_MANY_RESUBMITS) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
+
+/* This is a huge log, so be conservative. */
+if (!VLOG_DROP_WARN()) {
+ds_init();
+ofproto_trace(upcall->ofproto, upcall->flow,
+  upcall->packet, NULL, 0, NULL, );
+VLOG_WARN("%s", ds_cstr());
+ds_destroy();
+}
+}
+
 if (wc) {
 /* Convert the input port wildcard from OFP to ODP format. There's no
  * real way to do this for arbitrary bitmasks since the numbering 
spaces
diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index 600afdda8528..fd78c5d9b593 100644
--- a/tests/ofproto-dpif.at
+++ b/tests/ofproto-dpif.at
@@ -8473,6 +8473,31 @@ AT_CHECK([grep -c 'over max translation depth 64' 
stdout],
 OVS_VSWITCHD_STOP(["/resubmit actions 

[ovs-dev] [PATCHv2 2/2] xlate: add backward resubmit trace log.

2018-02-14 Thread William Tu
When hitting max translation depth of 64, printing the full
ofproto trace is huge and consumes too much log.  The patch
adds a short trace log, which prints the 64 backward resubmit
table IDs during the translation.

VMWare-BZ: #2054659
Signed-off-by: William Tu 
---
An example output:
2018-02-14T18:13:09.723Z|00084|ofproto_dpif_xlate|WARN|over max translation 
depth 64, table ID: [9, 8, 7, 6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2, 9, 8, 7, 
6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 
4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2, 9, 8, 7, 6, 5, 4, 3, 2] while processing 
in_port=1,vlan_tci=0x,dl_src=50:54:00:00:00:01,dl_dst=50:54:00:00:00:ff,dl_type=0x1234
 on bridge br0
---
 ofproto/ofproto-dpif-xlate.c | 20 ++--
 tests/ofproto-dpif.at|  3 +++
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index cc450a896948..4bc91549798e 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -237,6 +237,7 @@ struct xlate_ctx {
  */
 int depth;  /* Current resubmit nesting depth. */
 int resubmits;  /* Total number of resubmits. */
+uint8_t bw_resubmit[MAX_DEPTH]; /* Track backward resubmit table IDs. */
 bool in_group;  /* Currently translating ofgroup, if true. */
 bool in_action_set; /* Currently translating action_set, if true. 
*/
 bool in_packet_out; /* Currently translating a packet_out msg, if
@@ -3912,8 +3913,11 @@ xlate_recursively(struct xlate_ctx *ctx, struct 
rule_dpif *rule,
 rule_dpif_credit_stats(rule, ctx->xin->resubmit_stats);
 }
 
-ctx->resubmits++;
+if (deepens) {
+ctx->bw_resubmit[ctx->depth] = ctx->table_id;
+}
 
+ctx->resubmits++;
 ctx->depth += deepens;
 ctx->rule = rule;
 ctx->rule_cookie = rule->up.flow_cookie;
@@ -3929,7 +3933,19 @@ static bool
 xlate_resubmit_resource_check(struct xlate_ctx *ctx)
 {
 if (ctx->depth >= MAX_DEPTH) {
-xlate_report_error(ctx, "over max translation depth %d", MAX_DEPTH);
+struct ds output;
+int i;
+
+ds_init();
+for (i = 0; i < MAX_DEPTH - 1; i++) {
+ds_put_format(, "%d, ", ctx->bw_resubmit[i]);
+}
+ds_put_format(, "%d", ctx->bw_resubmit[i]);
+
+xlate_report_error(ctx, "over max translation depth %d, "
+"table ID: [%s]",
+MAX_DEPTH, ds_cstr());
+ds_destroy();
 ctx->error = XLATE_RECURSION_TOO_DEEP;
 } else if (ctx->resubmits >= MAX_RESUBMITS) {
 xlate_report_error(ctx, "over %d resubmit actions", MAX_RESUBMITS);
diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index fd78c5d9b593..b00faee5cf44 100644
--- a/tests/ofproto-dpif.at
+++ b/tests/ofproto-dpif.at
@@ -8494,6 +8494,9 @@ AT_CHECK([grep -c "^ *resubmit" ovs-vswitchd.log],
   [0], [66
 ])
 
+dnl make sure the short backward table trace is present
+AT_CHECK([grep "65, 64, 63, 62, 61, 60, 59, 58, 57, 56, 55, 54, 53, 52, 51, 
50, 49, 48, 47, 46, 45, 44, 43, 42, 41, 40, 39, 38, 37, 36, 35, 34, 33, 32, 31, 
30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 
10, 9, 8, 7, 6, 5, 4, 3, 2" ovs-vswitchd.log], [0], [stdout])
+
 OVS_VSWITCHD_STOP(["/over max translation depth/d
 /ofproto_dpif_upcall/d"])
 AT_CLEANUP
-- 
2.7.4

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


Re: [ovs-dev] [PATCH v1] ofproto-dpif-ipfix: Fix an issue in flow key part

2018-02-14 Thread Ben Pfaff
On Wed, Feb 14, 2018 at 01:58:31AM -0800, Daniel Benli Ye wrote:
> From: Benli Ye 
> 
> As struct ipfix_data_record_flow_key_iface didn't calculate
> its length in flow key part, it may cause problem when flow
> key part length is not enough. Use MAX_IF_LEN and MAX_IF_DESCR
> to pre-allocate memory for ipfix_data_record_flow_key_iface.
> 
> Signed-off-by: Daniel Benli Ye 

Thanks for the patch.

It looks like this fixes commit cd32509e4af4, so I'd add the following
tags to the commit message (and I'm CCing Michal):

CC: Michal Weglicki 
Fixes: cd32509e4af4 ("ofproto-dpif-ipfix: add interface Information Elements to 
flow key")


> @@ -2030,9 +2045,11 @@ ipfix_get_iface_data_record(const struct dpif_ipfix 
> *di, odp_port_t port_no,
>  
>  smap_destroy(_status);
>  data->if_index = htonl(port->ifindex);
> -data->if_descr_len = data->if_descr ? strlen(data->if_descr) : 0;
> +data->if_descr_len = data->if_descr ? strlen(data->if_descr) > 
> MAX_IF_DESCR_LEN
> + ? MAX_IF_DESCR_LEN : strlen(data->if_descr) : 0;
>  data->if_name = nullable_xstrdup(netdev_get_name(port->ofport->netdev));
> -data->if_name_len = data->if_name ? strlen(data->if_name) : 0;
> +data->if_name_len = data->if_name ? strlen(data->if_name) > 
> MAX_IF_NAME_LEN
> +? MAX_IF_NAME_LEN : strlen(data->if_name) : 0;

It's unusual and always a little confusing to see a ? b ? c : d : e.
I think that these can be rewritten using strnlen, e.g.:

data->if_descr ? strnlen(data->if_descr, MAX_IF_DESCR_LEN) : 0;

If you agree, would you mind posting v2?

Michal, any comments?

Thanks,

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


Re: [ovs-dev] Statment of accounts

2018-02-14 Thread Accounting Department
 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v2 00/11] Add upstream Linux 4.14 kernel support

2018-02-14 Thread Gregory Rose

On 2/14/2018 12:57 AM, Pravin Shelar wrote:

On Wed, Feb 7, 2018 at 7:49 AM, Greg Rose  wrote:

This patch set includes new features from upstream Linux kernel
4.14 as well as some additional bug fixes specific to the new
feature.  It also updates the travis build kernel list and makes
a few other small changes so OVS can compile on Linux 4.14
kernels.  This patch set is dependent on the first 10 patches
posted here:

https://mail.openvswitch.org/pipermail/ovs-dev/2018-February/344253.html

V2 of this patch set addresses some suggested changes and also
fixes up the .travis.yml file to include libelf-dev as a required
package.

Andy Zhou (3):
   datapath: export get_dp() API
   datapath: Add meter netlink definitions
   datapath: Add meter infrastructure

Greg Rose (3):
   Documentation: Update NEWS and faq
   acinclude.m4: Enable Linux 4.14
   travis: Update kernel test list from kernel.org

Gustavo A. R. Silva (2):
   datapath: meter: fix NULL pointer dereference in
 ovs_meter_cmd_reply_start
   datapath: meter: Use 64-bit arithmetic instead of 32-bit

Jiri Benc (1):
   datapath: reliable interface indentification in port dumps

Wei Yongjun (2):
   datapath: Fix return value check in ovs_meter_cmd_features()
   datapath: Using kfree_rcu() to simplify the code


I fixed couple conflicts occurred due to NSH patch series and pushed
it to master.
Thanks,
Pravin.

Thank you Pravin!

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


[ovs-dev] Payment declined: Update your information so we can ship your order

2018-02-14 Thread Amazon Consumer Service

[Amazon.com]
Payment Declined


Hello

We are having trouble authorizing your payment for the item below. Please 
verify or update your payment method. If your payment information is correct 
(such as expiry date and billing address), please contact your bank for more 
details.*



Update your billing address



Order Details


Order #111-4292470-4766639
Placed
 on Monday, February 10, 2018





___
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

2018-02-14 Thread Stokes, Ian
> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Tuesday, February 13, 2018 4:43 PM
> To: Stokes, Ian 
> Cc: ovs-dev@openvswitch.org
> Subject: Re: OVS DPDK: dpdk_merge pull request for master
> 
> Thanks for all the pull requests.  I merged all of these.

Thanks Ben.

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


[ovs-dev] [PATCH v1] ofproto-dpif-ipfix: Fix an issue in flow key part

2018-02-14 Thread Daniel Benli Ye
From: Benli Ye 

As struct ipfix_data_record_flow_key_iface didn't calculate
its length in flow key part, it may cause problem when flow
key part length is not enough. Use MAX_IF_LEN and MAX_IF_DESCR
to pre-allocate memory for ipfix_data_record_flow_key_iface.

Signed-off-by: Daniel Benli Ye 
---
 ofproto/ofproto-dpif-ipfix.c | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/ofproto/ofproto-dpif-ipfix.c b/ofproto/ofproto-dpif-ipfix.c
index c7ddeb9..1058927 100644
--- a/ofproto/ofproto-dpif-ipfix.c
+++ b/ofproto/ofproto-dpif-ipfix.c
@@ -314,6 +314,7 @@ BUILD_ASSERT_DECL(sizeof(struct 
ipfix_data_record_flow_key_common) == 20);
 /* Part of data record flow key for interface information. Since some of the
  * elements have variable length, members of this structure should be appended
  * to the 'struct dp_packet' one by one. */
+OVS_PACKED(
 struct ipfix_data_record_flow_key_iface {
 ovs_be32 if_index; /* (INGRESS | EGRESS)_INTERFACE */
 ovs_be32 if_type; /* (INGRESS | EGRESS)_INTERFACE_TYPE */
@@ -321,7 +322,9 @@ struct ipfix_data_record_flow_key_iface {
 char *if_name;
 uint8_t if_descr_len; /* Variable length element: INTERFACE_DESCRIPTION */
 char *if_descr;
-};
+});
+BUILD_ASSERT_DECL(sizeof(struct ipfix_data_record_flow_key_iface) ==
+  10 + 2 * sizeof(char *));
 
 /* Part of data record flow key for VLAN entities. */
 OVS_PACKED(
@@ -511,8 +514,21 @@ BUILD_ASSERT_DECL(sizeof(struct 
ipfix_data_record_aggregated_tcp) == 48);
  */
 #define MAX_TUNNEL_KEY_LEN 8
 
+#define MAX_IF_NAME_LEN 64
+#define MAX_IF_DESCR_LEN 128
+
+/*
+ * Calculate interface information length in flow key.
+ * This is used to calculate max flow key length.
+ */
+#define FLOW_KEY_IFACE_LEN  \
+(sizeof(struct ipfix_data_record_flow_key_iface)\
+ - 2 * sizeof(char *)   \
+ + MAX_IF_NAME_LEN + MAX_IF_DESCR_LEN)
+
 #define MAX_FLOW_KEY_LEN\
 (sizeof(struct ipfix_data_record_flow_key_common)   \
+ + FLOW_KEY_IFACE_LEN   \
  + sizeof(struct ipfix_data_record_flow_key_vlan)   \
  + sizeof(struct ipfix_data_record_flow_key_ip) \
  + MAX(sizeof(struct ipfix_data_record_flow_key_ipv4),  \
@@ -1396,7 +1412,6 @@ ipfix_define_template_fields(enum ipfix_proto_l2 l2, enum 
ipfix_proto_l3 l3,
 DEF(ETHERNET_TYPE);
 DEF(ETHERNET_HEADER_LENGTH);
 
-/* Interface Information Elements */
 DEF(INGRESS_INTERFACE);
 DEF(INGRESS_INTERFACE_TYPE);
 DEF(INTERFACE_NAME);
@@ -2030,9 +2045,11 @@ ipfix_get_iface_data_record(const struct dpif_ipfix *di, 
odp_port_t port_no,
 
 smap_destroy(_status);
 data->if_index = htonl(port->ifindex);
-data->if_descr_len = data->if_descr ? strlen(data->if_descr) : 0;
+data->if_descr_len = data->if_descr ? strlen(data->if_descr) > 
MAX_IF_DESCR_LEN
+ ? MAX_IF_DESCR_LEN : strlen(data->if_descr) : 0;
 data->if_name = nullable_xstrdup(netdev_get_name(port->ofport->netdev));
-data->if_name_len = data->if_name ? strlen(data->if_name) : 0;
+data->if_name_len = data->if_name ? strlen(data->if_name) > MAX_IF_NAME_LEN
+? MAX_IF_NAME_LEN : strlen(data->if_name) : 0;
 
 return 0;
 }
-- 
1.9.1

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


Re: [ovs-dev] [PATCH v2 00/11] Add upstream Linux 4.14 kernel support

2018-02-14 Thread Pravin Shelar
On Wed, Feb 7, 2018 at 7:49 AM, Greg Rose  wrote:
> This patch set includes new features from upstream Linux kernel
> 4.14 as well as some additional bug fixes specific to the new
> feature.  It also updates the travis build kernel list and makes
> a few other small changes so OVS can compile on Linux 4.14
> kernels.  This patch set is dependent on the first 10 patches
> posted here:
>
> https://mail.openvswitch.org/pipermail/ovs-dev/2018-February/344253.html
>
> V2 of this patch set addresses some suggested changes and also
> fixes up the .travis.yml file to include libelf-dev as a required
> package.
>
> Andy Zhou (3):
>   datapath: export get_dp() API
>   datapath: Add meter netlink definitions
>   datapath: Add meter infrastructure
>
> Greg Rose (3):
>   Documentation: Update NEWS and faq
>   acinclude.m4: Enable Linux 4.14
>   travis: Update kernel test list from kernel.org
>
> Gustavo A. R. Silva (2):
>   datapath: meter: fix NULL pointer dereference in
> ovs_meter_cmd_reply_start
>   datapath: meter: Use 64-bit arithmetic instead of 32-bit
>
> Jiri Benc (1):
>   datapath: reliable interface indentification in port dumps
>
> Wei Yongjun (2):
>   datapath: Fix return value check in ovs_meter_cmd_features()
>   datapath: Using kfree_rcu() to simplify the code
>
I fixed couple conflicts occurred due to NSH patch series and pushed
it to master.

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


Re: [ovs-dev] DPDK: How to send packets from one OVS bridge to another OVS bridge while running in the same user space ?

2018-02-14 Thread Jan Scheurich
Hi Kapil,

I am afraid there is no really efficient way today to connect a user-space 
(netdev-dpdk) datapath in OVS to kernel interfaces (such as internal/tap ports 
or veth pairs) today. Communication works but packet I/O is very slow compared 
to DPDK interfaces (both ethernet and vhostuser). The PMD threads polling the 
DPDK interfaces are heavily slowed down when sending packets to kernel ports 
and in the other direction all kernel interfaces are polled by the main 
ovs-vswitchd thread.

If your other bridge also uses DPDK in user space, you can try with DPDK ring 
ports as interface between the two bridges. DPDK ring ports should be supported 
in OVS.

Another almost as efficient solution for sending packets from the OVS DPDK 
datapath to another DPDK vSwitch would be to run the other vSwitch in a VM and 
connect it to OVS-DPDK on the host through a vhostuser port. The DPDK vSwitch 
in the VM would then use the virtio PMD, I expect this to be supported by all 
DPDK vSwitches.

BR, Jan

From: Kapil A [mailto:kapil20...@gmail.com]
Sent: Wednesday, 14 February, 2018 03:47
To: Jan Scheurich 
Cc: disc...@openvswitch.org; d...@openvswitch.org
Subject: Re: [ovs-dev] DPDK: How to send packets from one OVS bridge to another 
OVS bridge while running in the same user space ?


Hi Jan,

Thanks for the clarification. I also came across patch port as the best option 
between ovs Bridges. But, is it possible to use patch ports to an external 
OpenFlow bridge? Like one bridge is OVS, other is Lagopus bridge or LINC 
bridge? For my use case, I want to send packets from OVS Bridge to another 
OpenFlow bridge(like a loopback port) as OVS doesn't support the functionality 
I am looking for.

On Tue, Feb 13, 2018, 21:22 Jan Scheurich 
> wrote:
Hi Kapil,

This is what patch ports are for. They are only traversed for the first packet 
of a flow in the slow path. The resulting datapath flow entry collapses the 
processing in both bridges into a single megaflow. So there is no performance 
overhead compared to having a single bridge.

Regards, Jan

> -Original Message-
> From: ovs-dev-boun...@openvswitch.org 
> [mailto:ovs-dev-boun...@openvswitch.org]
>  On Behalf Of Kapil A
> Sent: Tuesday, 13 February, 2018 16:44
> To: disc...@openvswitch.org; 
> d...@openvswitch.org
> Subject: [ovs-dev] DPDK: How to send packets from one OVS bridge to another 
> OVS bridge while running in the same user space ?
>
> Hello,
>
> In my setup, i have two DPDK ports, where dpdk0 is part of br0 and and
> dpdk1 is part of br1. How can i send packets from br0 to br1 in an
> efficient way within userspace with good performance?
> I came across, veth pair as one option, but i couldn't find if it will
> provide good performance in userspace while running in dpdk mode ?
>
> My query might sound odd, but i have a use case where i need to send the
> packets across bridges within the same userspace, so appreciate some help
> on this.
>
> Regards
> Kapil
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev


--

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