Re: [ovs-dev] [branch-2.8 2/2] Prepare for 2.8.2.

2017-09-28 Thread Justin Pettit 

> On Sep 26, 2017, at 3:58 PM, Ben Pfaff  wrote:
> 
> On Tue, Sep 26, 2017 at 01:37:37PM -0700, Justin Pettit wrote:
>> Signed-off-by: Justin Pettit 
> 
> Acked-by: Ben Pfaff 

Thanks.  I pushed the series to branch-2.8.

--Justin



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

Re: [ovs-dev] [PATCH] dpif-netdev: Use portable error code for zero rate meter band

2017-09-28 Thread Joe Stringer 
On 28 September 2017 at 12:39, Andy Zhou  wrote:
> 'EBADRQC' is only defined on the Linux platform. Without this fix,
> The travis MacOS build fails. Switching to using EDOM which is more
> portable.
>
> Fixes: 2029ce9ac3a601 (dpif-netdev: Fix a zero-rate bug for meter)
> CC: Ali Volkan ATLI 
> Signed-off-by: Andy Zhou 

LGTM.

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

Re: [ovs-dev] [PATCH v4 2/2] ofproto-dpif-ipfix: add interface Information Elements to flow key

2017-09-28 Thread Greg Rose 

On 09/26/2017 04:53 AM, Michal Weglicki wrote:

Extend flow key part of data record to include following Information Elements:
- ingressInterface
- ingressInterfaceType
- egressInterface
- egressInterfaceType
- interfaceName
- interfaceDescription


Michal,

I'm testing this patch and so far it looks good testing wise but there is a 
clang
error.  Can you look into it?  I noted it below.

Here's a link to the travis build with the clang errors:

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

Thanks,

- Greg



In case of input sampling we don't have information about egress port.
Define templates depending not only on protocol types, but also on flow
direction. Only egress flow will include egress information elements.

With this change, dpif_ipfix_exporter stores every port in hmap rather
than only tunnel ports. It allows to easily retrieve required
information about interfaces during sampling upcalls.

v1->v2
* Add interfaceType and interfaceDescription
* Rework ipfix_get_iface_data_record function
v2->v3: Code rebase.
v3->v4: Minor comments applied.

Co-authored-by: Michal Weglicki 
Signed-off-by: Michal Weglicki 
Signed-off-by: Przemyslaw Szczerbik 
---
  ofproto/ofproto-dpif-ipfix.c | 358 +++
  ofproto/ofproto-dpif-ipfix.h |   6 +-
  ofproto/ofproto-dpif-xlate.c |   4 +-
  ofproto/ofproto-dpif.c   |  19 +--
  4 files changed, 277 insertions(+), 110 deletions(-)

diff --git a/ofproto/ofproto-dpif-ipfix.c b/ofproto/ofproto-dpif-ipfix.c
index 472c272..ab9192b 100644
--- a/ofproto/ofproto-dpif-ipfix.c
+++ b/ofproto/ofproto-dpif-ipfix.c
@@ -115,11 +115,12 @@ struct dpif_ipfix_global_stats {
  };
  
  struct dpif_ipfix_port {

-struct hmap_node hmap_node; /* In struct dpif_ipfix's "tunnel_ports" hmap. 
*/
+struct hmap_node hmap_node; /* In struct dpif_ipfix's "ports" hmap. */
  struct ofport *ofport;  /* To retrieve port stats. */
  odp_port_t odp_port;
  enum dpif_ipfix_tunnel_type tunnel_type;
  uint8_t tunnel_key_length;
+uint32_t ifindex;
  };
  
  struct dpif_ipfix_exporter {

@@ -157,9 +158,9 @@ struct dpif_ipfix_flow_exporter_map_node {
  struct dpif_ipfix {
  struct dpif_ipfix_bridge_exporter bridge_exporter;
  struct hmap flow_exporter_map;  /* dpif_ipfix_flow_exporter_map_node. */
-struct hmap tunnel_ports;   /* Contains "struct dpif_ipfix_port"s.
- * It makes tunnel port lookups faster in
- * sampling upcalls. */
+struct hmap ports;  /* Contains "struct dpif_ipfix_port"s.
+ * It makes port lookups faster in sampling
+ * upcalls. */
  struct ovs_refcount ref_cnt;
  };
  
@@ -293,7 +294,8 @@ BUILD_ASSERT_DECL(sizeof(struct ipfix_template_field_specifier) == 8);

  /* Cf. IETF RFC 5102 Section 5.11.6. */
  enum ipfix_flow_direction {
  INGRESS_FLOW = 0x00,
-EGRESS_FLOW = 0x01
+EGRESS_FLOW = 0x01,
+NUM_IPFIX_FLOW_DIRECTION
  };
  
  /* Part of data record flow key for common metadata and Ethernet entities. */

@@ -308,6 +310,18 @@ struct ipfix_data_record_flow_key_common {
  });
  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. */
+struct ipfix_data_record_flow_key_iface {
+ovs_be32 if_index; /* (INGRESS | EGRESS)_INTERFACE */
+ovs_be32 if_type; /* (INGRESS | EGRESS)_INTERFACE_TYPE */
+uint8_t if_name_len;   /* Variable length element: INTERFACE_NAME */
+char *if_name;
+uint8_t if_descr_len; /* Variable length element: INTERFACE_DESCRIPTION */
+char *if_descr;
+};
+
  /* Part of data record flow key for VLAN entities. */
  OVS_PACKED(
  struct ipfix_data_record_flow_key_vlan {
@@ -745,7 +759,7 @@ dpif_ipfix_find_port(const struct dpif_ipfix *di,
  struct dpif_ipfix_port *dip;
  
  HMAP_FOR_EACH_IN_BUCKET (dip, hmap_node, hash_odp_port(odp_port),

- >tunnel_ports) {
+ >ports) {
  if (dip->odp_port == odp_port) {
  return dip;
  }
@@ -754,82 +768,116 @@ dpif_ipfix_find_port(const struct dpif_ipfix *di,
  }
  
  static void

-dpif_ipfix_del_port(struct dpif_ipfix *di,
+dpif_ipfix_del_port__(struct dpif_ipfix *di,
struct dpif_ipfix_port *dip)
  OVS_REQUIRES(mutex)
  {
-hmap_remove(>tunnel_ports, >hmap_node);
+hmap_remove(>ports, >hmap_node);
  free(dip);
  }
  
+static enum dpif_ipfix_tunnel_type

+dpif_ipfix_tunnel_type(const struct ofport *ofport)
+{
+const char *type = netdev_get_type(ofport->netdev);
+
+if (type == NULL) {
+return

Re: [ovs-dev] [PATCH] connmgr: Fix violation of flow monitoring protocol description.

2017-09-28 Thread Ben Pfaff 
On Thu, Sep 28, 2017 at 02:35:41PM -0700, Guru Shetty wrote:
> On 28 September 2017 at 10:38, Ben Pfaff  wrote:
> 
> > nicira-ext.h says:
> >
> >  * 1. OVS sends an NXT_FLOW_MONITOR_PAUSED message to the controller,
> > following
> >  *all the already queued notifications.  After it receives this
> > message,
> >  *the controller knows that its view of the flow table, as represented
> > by
> >  *flow monitor notifications, is incomplete.
> >
> > The actual implementation could send NXT_FLOW_MONITOR_PAUSED in the middle
> > of a series of queued notifications.  This fixes it to always send it after
> > those notifications.  Possibly this confused some controllers, since the
> > documentation said that NXFME_ADD and NXFME_MODIFIED notifications wouldn't
> > be sent between "pause" and "resume" messages, but this bug could cause
> > them to be sent just after "pause".
> >
> > Signed-off-by: Ben Pfaff 
> >
> 
> Acked-by: Gurucharan Shetty 

Thank you!  I applied this to master and backported as far as
branch-2.4.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Recursos Humanos Rumbo al 2018

2017-09-28 Thread Un poco de Presión siempre ayuda 
Buenas tardes,

En gusto compartirle la información de nuestra más reciente Póliza de 
Capacitación Online que se encuentra en fase de PREVENTA con un precio especial 
¡a casi 40% del precio real!

Este programa está orientado a todo el personal involucrado con los Recursos 
Humanos de su empresa y le permitirá conocer las herramientas más actualizadas 
para reclutar personal, las actualizaciones en los contratos laborales y los 
CFDI de nóminas así como le enseñará a como elevar la productividad en su 
equipo de trabajo teniendo objetivos claros y medibles.
Aproveche la oportunidad de adquirir nuestras conferencias online que incluyen 
además material de apoyo y cuestionario de aprovechamiento. ¡La capacitación 
online más efectiva del mercado!

Los módulos que incluye son los siguientes:

1. Contratos Laborales en México.
2. Reclutamiento 3.0.
3. Pruebas Psicométricas de Personalidad.
4. Cómo son los CFDI de Nóminas a partir del 2017.
5. Gestión por competencias / Gestión por conocimientos.
6. Sistema de Incentivos por Objetivos.
7. Desarrollo de Talento a través de Entornos Digitales.
8. Evaluación del Clima Organizacional. 
9. Trabajadores Comprometidos hasta la Médula. 
10. Cómo Registrar e Implementar el plan y Programas de Capacitación, 
Adiestramiento y Productividad ante la STPS.
11. Certificación Well.
12. Un poco de Presión siempre ayuda.

Solicite la información completa que incluye temarios, información de 
expositores y beneficios adicionales de adquirir el programa enviándonos la 
palabra RRHH junto con los datos siguientes:

Nombre: 
Teléfono:
Empresa:

centro telefónico: 018002129393


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

Re: [ovs-dev] [PATCH] connmgr: Fix violation of flow monitoring protocol description.

2017-09-28 Thread Guru Shetty 
On 28 September 2017 at 10:38, Ben Pfaff  wrote:

> nicira-ext.h says:
>
>  * 1. OVS sends an NXT_FLOW_MONITOR_PAUSED message to the controller,
> following
>  *all the already queued notifications.  After it receives this
> message,
>  *the controller knows that its view of the flow table, as represented
> by
>  *flow monitor notifications, is incomplete.
>
> The actual implementation could send NXT_FLOW_MONITOR_PAUSED in the middle
> of a series of queued notifications.  This fixes it to always send it after
> those notifications.  Possibly this confused some controllers, since the
> documentation said that NXFME_ADD and NXFME_MODIFIED notifications wouldn't
> be sent between "pause" and "resume" messages, but this bug could cause
> them to be sent just after "pause".
>
> Signed-off-by: Ben Pfaff 
>

Acked-by: Gurucharan Shetty 


> VMware-BZ: #1919454
> ---
>  ofproto/connmgr.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/ofproto/connmgr.c b/ofproto/connmgr.c
> index c0ce828ce00a..30c627f43d9f 100644
> --- a/ofproto/connmgr.c
> +++ b/ofproto/connmgr.c
> @@ -2237,22 +2237,22 @@ ofmonitor_flush(struct connmgr *mgr)
>  struct ofconn *ofconn;
>
>  LIST_FOR_EACH (ofconn, node, >all_conns) {
> -struct ofpbuf *msg;
> +struct rconn_packet_counter *counter = ofconn->monitor_counter;
>
> +struct ofpbuf *msg;
>  LIST_FOR_EACH_POP (msg, list_node, >updates) {
> -unsigned int n_bytes;
> -
> -ofconn_send(ofconn, msg, ofconn->monitor_counter);
> -n_bytes = rconn_packet_counter_n_bytes(
> ofconn->monitor_counter);
> -if (!ofconn->monitor_paused && n_bytes > 128 * 1024) {
> -struct ofpbuf *pause;
> -
> -COVERAGE_INC(ofmonitor_pause);
> -ofconn->monitor_paused = monitor_seqno++;
> -pause = ofpraw_alloc_xid(OFPRAW_NXT_FLOW_MONITOR_PAUSED,
> - OFP10_VERSION, htonl(0), 0);
> -ofconn_send(ofconn, pause, ofconn->monitor_counter);
> -}
> +ofconn_send(ofconn, msg, counter);
> +}
> +
> +if (!ofconn->monitor_paused
> +&& rconn_packet_counter_n_bytes(counter) > 128 * 1024) {
> +struct ofpbuf *pause;
> +
> +COVERAGE_INC(ofmonitor_pause);
> +ofconn->monitor_paused = monitor_seqno++;
> +pause = ofpraw_alloc_xid(OFPRAW_NXT_FLOW_MONITOR_PAUSED,
> + OFP10_VERSION, htonl(0), 0);
> +ofconn_send(ofconn, pause, counter);
>  }
>  }
>  }
> --
> 2.10.2
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovn/actions: Improve OVN load-balancing performance.

2017-09-28 Thread Guru Shetty 
On 28 September 2017 at 13:48, Ben Pfaff  wrote:

> On Thu, Sep 28, 2017 at 01:58:04AM -0700, Gurucharan Shetty wrote:
> > Currently, we send the first packet of every new connection
> > to userspace to figure out the target IP address of load-balancing.
> >
> > With this patch, we use the selection method of dp_hash to prevent
> > that situation.
> >
> > Signed-off-by: Gurucharan Shetty 
>
> Acked-by: Ben Pfaff 
>

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

Re: [ovs-dev] [PATCH] ovn/actions: Improve OVN load-balancing performance.

2017-09-28 Thread Ben Pfaff 
On Thu, Sep 28, 2017 at 01:58:04AM -0700, Gurucharan Shetty wrote:
> Currently, we send the first packet of every new connection
> to userspace to figure out the target IP address of load-balancing.
> 
> With this patch, we use the selection method of dp_hash to prevent
> that situation.
> 
> Signed-off-by: Gurucharan Shetty 

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

Re: [ovs-dev] [PATCH] datapath-windows: Fix bugs in cleaner threads

2017-09-28 Thread Guru Shetty 
On 22 September 2017 at 14:24, Shashank Ram  wrote:

> Conntrack, Conntrack-related, Stt, and IP fragmentation
> have cleaner threads that run periodically to clean
> up their respective tables. During driver unload,
> OvsExtDetach() calls into routines that are meant
> for explicitly cleaning these tables up and freeing
> the resources associated with these threads.
>
> If during driver unload, these cleaner threads run
> immediately after the resources are freed, such as locks
> used by these threads, then the cleaner threads result
> in a kernel crash since they try to acquire locks
> that have already been freed.
>
> For eg, OvsIpFragmentEntryCleaner() caused a kernel
> crash because it tried to acquire a lock that was
> already freed by OvsCleanupIpFragment().
>
> The fix is to simply exit the cleaner thread if the
> lock associated with the thread is not initialized,
> because the only way the threads can run when the lock
> is invalid is when the lock has been freed up during
> driver unload.
>
> Testint done:
> Verified that cleaner threads run as expected without
> crashing during driver unload.
>
> Signed-off-by: Shashank Ram 
>
Applied to master and 2.8. Thanks!


> ---
>  datapath-windows/ovsext/Conntrack-related.c | 6 +-
>  datapath-windows/ovsext/Conntrack.c | 6 +-
>  datapath-windows/ovsext/IpFragment.c| 6 +-
>  datapath-windows/ovsext/Stt.c   | 4 
>  4 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/datapath-windows/ovsext/Conntrack-related.c
> b/datapath-windows/ovsext/Conntrack-related.c
> index 16ed6f7..ec4b536 100644
> --- a/datapath-windows/ovsext/Conntrack-related.c
> +++ b/datapath-windows/ovsext/Conntrack-related.c
> @@ -181,10 +181,14 @@ OvsCtRelatedEntryCleaner(PVOID data)
>  POVS_CT_THREAD_CTX context = (POVS_CT_THREAD_CTX)data;
>  PLIST_ENTRY link, next;
>  POVS_CT_REL_ENTRY entry;
> +LOCK_STATE_EX lockState;
>  BOOLEAN success = TRUE;
>
>  while (success) {
> -LOCK_STATE_EX lockState;
> +if (ovsCtRelatedLockObj == NULL) {
> +/* Lock has been freed by 'OvsCleanupCtRelated()' */
> +break;
> +}
>  NdisAcquireRWLockWrite(ovsCtRelatedLockObj, , 0);
>  if (context->exit) {
>  NdisReleaseRWLock(ovsCtRelatedLockObj, );
> diff --git a/datapath-windows/ovsext/Conntrack.c
> b/datapath-windows/ovsext/Conntrack.c
> index f0d135b..3203411 100644
> --- a/datapath-windows/ovsext/Conntrack.c
> +++ b/datapath-windows/ovsext/Conntrack.c
> @@ -980,10 +980,14 @@ OvsConntrackEntryCleaner(PVOID data)
>  POVS_CT_THREAD_CTX context = (POVS_CT_THREAD_CTX)data;
>  PLIST_ENTRY link, next;
>  POVS_CT_ENTRY entry;
> +LOCK_STATE_EX lockState;
>  BOOLEAN success = TRUE;
>
>  while (success) {
> -LOCK_STATE_EX lockState;
> +if (ovsConntrackLockObj == NULL) {
> +/* Lock has been freed by 'OvsCleanupConntrack()' */
> +break;
> +}
>  NdisAcquireRWLockWrite(ovsConntrackLockObj, , 0);
>  if (context->exit) {
>  NdisReleaseRWLock(ovsConntrackLockObj, );
> diff --git a/datapath-windows/ovsext/IpFragment.c
> b/datapath-windows/ovsext/IpFragment.c
> index fee361a..ad48834 100644
> --- a/datapath-windows/ovsext/IpFragment.c
> +++ b/datapath-windows/ovsext/IpFragment.c
> @@ -444,10 +444,14 @@ OvsIpFragmentEntryCleaner(PVOID data)
>  POVS_IPFRAG_THREAD_CTX context = (POVS_IPFRAG_THREAD_CTX)data;
>  PLIST_ENTRY link, next;
>  POVS_IPFRAG_ENTRY entry;
> +LOCK_STATE_EX lockState;
>  BOOLEAN success = TRUE;
>
>  while (success) {
> -LOCK_STATE_EX lockState;
> +if (ovsIpFragmentHashLockObj == NULL) {
> +/* Lock has been freed by 'OvsCleanupIpFragment()' */
> +break;
> +}
>  NdisAcquireRWLockWrite(ovsIpFragmentHashLockObj, , 0);
>  if (context->exit) {
>  NdisReleaseRWLock(ovsIpFragmentHashLockObj, );
> diff --git a/datapath-windows/ovsext/Stt.c b/datapath-windows/ovsext/Stt.c
> index b6236fd..f98070f 100644
> --- a/datapath-windows/ovsext/Stt.c
> +++ b/datapath-windows/ovsext/Stt.c
> @@ -551,6 +551,10 @@ OvsSttDefragCleaner(PVOID data)
>  BOOLEAN success = TRUE;
>
>  while (success) {
> +if ( == NULL) {
> +/* Lock has been freed by 'OvsCleanupSttDefragmentation()' */
> +break;
> +}
>  NdisAcquireSpinLock();
>  if (context->exit) {
>  NdisReleaseSpinLock();
> --
> 2.9.3.windows.2
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] dpif-netdev: Use portable error code for zero rate meter band

2017-09-28 Thread Andy Zhou 
'EBADRQC' is only defined on the Linux platform. Without this fix,
The travis MacOS build fails. Switching to using EDOM which is more
portable.

Fixes: 2029ce9ac3a601 (dpif-netdev: Fix a zero-rate bug for meter)
CC: Ali Volkan ATLI 
Signed-off-by: Andy Zhou 
---
 lib/dpif-netdev.c  | 2 +-
 ofproto/ofproto-dpif.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 0fce94e0e409..d5eb8305c8a2 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -4285,7 +4285,7 @@ dpif_netdev_meter_set(struct dpif *dpif, ofproto_meter_id 
*meter_id,
 /* Validate rates */
 for (i = 0; i < config->n_bands; i++) {
 if (config->bands[i].rate == 0) {
-return EBADRQC; /* rate must be non-zero */
+return EDOM; /* rate must be non-zero */
 }
 }
 
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index d99dc9d88788..43d670a15c3f 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -5695,7 +5695,7 @@ meter_set(struct ofproto *ofproto_, ofproto_meter_id 
*meter_id,
 return OFPERR_OFPMMFC_OUT_OF_BANDS;
 case ENODEV: /* Unsupported band type */
 return OFPERR_OFPMMFC_BAD_BAND;
-case EBADRQC: /* Rate must be non-zero */
+case EDOM: /* Rate must be non-zero */
 return OFPERR_OFPMMFC_BAD_RATE;
 default:
 return OFPERR_OFPMMFC_UNKNOWN;
-- 
1.8.3.1

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

[ovs-dev] [PATCH] ovn/actions: Improve OVN load-balancing performance.

2017-09-28 Thread Gurucharan Shetty 
Currently, we send the first packet of every new connection
to userspace to figure out the target IP address of load-balancing.

With this patch, we use the selection method of dp_hash to prevent
that situation.

Signed-off-by: Gurucharan Shetty 
---
 ovn/lib/actions.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ovn/lib/actions.c b/ovn/lib/actions.c
index d0d73b6..c987643 100644
--- a/ovn/lib/actions.c
+++ b/ovn/lib/actions.c
@@ -983,7 +983,7 @@ encode_CT_LB(const struct ovnact_ct_lb *cl,
 : MFF_LOG_DNAT_ZONE - MFF_REG0;
 
 struct ds ds = DS_EMPTY_INITIALIZER;
-ds_put_format(, "type=select");
+ds_put_format(, "type=select,selection_method=dp_hash");
 
 BUILD_ASSERT(MFF_LOG_CT_ZONE >= MFF_REG0);
 BUILD_ASSERT(MFF_LOG_CT_ZONE < MFF_REG0 + FLOW_N_REGS);
-- 
1.9.1

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

[ovs-dev] New Arrivals

2017-09-28 Thread Bonesca - Jona 
    [ View in browser ]( http://r.newsletter.bonescamail.nl/7xa28jy3ioatrf.html 
)   
 
[
]( http://r.newsletter.bonescamail.nl/track/click/vp48y7sdpaoatrd ) 
 
New arrivals :
 
Tomorrow and Monday unloading.
 
Jona Trevally Indonesia IWP 500-1000 grs & 1-3 kg 10 kilo / 3-5 kg in 20 kilo 
box
Jona Black Pomfret Indonesia IWP 800gr+ 10 kilo 
Horse / Jackmackerels XL 500-900 grs from Chili 500-900 grs 20 kilo block
Bonemer Black Tiger Shrimps HLSO ezp 16/20 & 26/30 10 x 1 kilo Bangladesh
 
Scroll down for some pictures
 
 
Interested? Please contact us    
























   [ Click here to find our offers! ]( 
http://r.newsletter.bonescamail.nl/track/click/vp48y7sehqoatrd )     
This email was sent to d...@openvswitch.org
You received this email because you are registered with Bonesca Import en 
Export BV
 
[ Unsubscribe here ]( http://r.newsletter.bonescamail.nl/7xa28jy3ioatrg.html )  

Sent by
[  ]( http://r.newsletter.bonescamail.nl/track/click/vp48y7sfa6oatrd )     
© 2017 Bonesca Import en Export BV  

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

Re: [ovs-dev] [PATCH net-next v9] openvswitch: enable NSH support

2017-09-28 Thread Pravin Shelar 
On Tue, Sep 26, 2017 at 6:39 PM, Yang, Yi  wrote:
> On Tue, Sep 26, 2017 at 06:49:14PM +0800, Jiri Benc wrote:
>> On Tue, 26 Sep 2017 12:55:39 +0800, Yang, Yi wrote:
>> > After push_nsh, the packet won't be recirculated to flow pipeline, so
>> > key->eth.type must be set explicitly here, but for pop_nsh, the packet
>> > will be recirculated to flow pipeline, it will be reparsed, so
>> > key->eth.type will be set in packet parse function, we needn't handle it
>> > in pop_nsh.
>>
>> This seems to be a very different approach than what we currently have.
>> Looking at the code, the requirement after "destructive" actions such
>> as pushing or popping headers is to recirculate.
>
> This is optimization proposed by Jan Scheurich, recurculating after push_nsh
> will impact on performance, recurculating after pop_nsh is unavoidable, So
> also cc jan.scheur...@ericsson.com.
>
> Actucally all the keys before push_nsh are still there after push_nsh,
> push_nsh has updated all the nsh keys, so recirculating remains avoidable.
>


We should keep existing model for this patch. Later you can submit
optimization patch with specific use cases and performance
improvement. So that we can evaluate code complexity and benefits.

>>
>> Setting key->eth.type to satisfy conditions in the output path without
>> updating the rest of the key looks very hacky and fragile to me. There
>> might be other conditions and dependencies that are not obvious.
>> I don't think the code was written with such code path in mind.
>>
>> I'd like to hear what Pravin thinks about this.
>>
>>  Jiri
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] connmgr: Fix violation of flow monitoring protocol description.

2017-09-28 Thread Ben Pfaff 
nicira-ext.h says:

 * 1. OVS sends an NXT_FLOW_MONITOR_PAUSED message to the controller, following
 *all the already queued notifications.  After it receives this message,
 *the controller knows that its view of the flow table, as represented by
 *flow monitor notifications, is incomplete.

The actual implementation could send NXT_FLOW_MONITOR_PAUSED in the middle
of a series of queued notifications.  This fixes it to always send it after
those notifications.  Possibly this confused some controllers, since the
documentation said that NXFME_ADD and NXFME_MODIFIED notifications wouldn't
be sent between "pause" and "resume" messages, but this bug could cause
them to be sent just after "pause".

Signed-off-by: Ben Pfaff 
VMware-BZ: #1919454
---
 ofproto/connmgr.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/ofproto/connmgr.c b/ofproto/connmgr.c
index c0ce828ce00a..30c627f43d9f 100644
--- a/ofproto/connmgr.c
+++ b/ofproto/connmgr.c
@@ -2237,22 +2237,22 @@ ofmonitor_flush(struct connmgr *mgr)
 struct ofconn *ofconn;
 
 LIST_FOR_EACH (ofconn, node, >all_conns) {
-struct ofpbuf *msg;
+struct rconn_packet_counter *counter = ofconn->monitor_counter;
 
+struct ofpbuf *msg;
 LIST_FOR_EACH_POP (msg, list_node, >updates) {
-unsigned int n_bytes;
-
-ofconn_send(ofconn, msg, ofconn->monitor_counter);
-n_bytes = rconn_packet_counter_n_bytes(ofconn->monitor_counter);
-if (!ofconn->monitor_paused && n_bytes > 128 * 1024) {
-struct ofpbuf *pause;
-
-COVERAGE_INC(ofmonitor_pause);
-ofconn->monitor_paused = monitor_seqno++;
-pause = ofpraw_alloc_xid(OFPRAW_NXT_FLOW_MONITOR_PAUSED,
- OFP10_VERSION, htonl(0), 0);
-ofconn_send(ofconn, pause, ofconn->monitor_counter);
-}
+ofconn_send(ofconn, msg, counter);
+}
+
+if (!ofconn->monitor_paused
+&& rconn_packet_counter_n_bytes(counter) > 128 * 1024) {
+struct ofpbuf *pause;
+
+COVERAGE_INC(ofmonitor_pause);
+ofconn->monitor_paused = monitor_seqno++;
+pause = ofpraw_alloc_xid(OFPRAW_NXT_FLOW_MONITOR_PAUSED,
+ OFP10_VERSION, htonl(0), 0);
+ofconn_send(ofconn, pause, counter);
 }
 }
 }
-- 
2.10.2

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

[ovs-dev] Fwd: [dpdk-dev] DPDK Community Survey 2017

2017-09-28 Thread Kevin Traynor 
Hi,

DPDK is doing a community survey. It's a good opportunity for developers
and users of OVS with the DPDK datapath to give feedback on how to
improve DPDK. Note it's only open until Sunday.

Kevin.


 Forwarded Message 
Subject: [dpdk-dev] DPDK Community Survey 2017
Date: Fri, 22 Sep 2017 10:47:24 +
From: Jain, Deepak K 
To: d...@dpdk.org , us...@dpdk.org 
CC: Thomas Monjalon 

Hi All,

As part of our ongoing efforts to improve DPDK, we'd like to hear your
feedback!

We have created a number of DPDK-related questions here.

https://www.surveymonkey.com/r/DPDK_Community_Survey_2017

and want to hear your views!!

The survey will close at midnight GMT on Sunday October 1st, 2017.

Thanks in advance for your feedback - the more responses we get the more
data we have to drive further features, improvements, etc.

So please respond!!!

Regards
Deepak



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

Re: [ovs-dev] [RFC PATCH v1] docs: Add release feature roadmap.

2017-09-28 Thread Stokes, Ian 
Thanks for the review Stephen,

This document was raised at the OVS DPDK community sync and it was decided not 
to proceed further with it (mainly due to the overhead entailed in maintaining 
it and frequency of modifications to the doc that may occur at).

Instead roadmaps are going to be flagged via email at the beginning of a 
release cycle and collateral stored in a public google doc.

I appreciate the time you spent reviewing this however.

Thanks
Ian


> On Wed, 2017-09-13 at 22:04 +0100, Ian Stokes wrote:
> > Add a document to outline the roadmap of features contributors are
> > targeting for upcoming OVS releases.
> >
> > Signed-off-by: Ian Stokes 
> > ---
> >  Documentation/automake.mk |1 +
> >  Documentation/faq/index.rst   |1 +
> >  Documentation/faq/release_feature_roadmap.rst |  350
> > +
> >  3 files changed, 352 insertions(+), 0 deletions(-)  create mode
> > 100644 Documentation/faq/release_feature_roadmap.rst
> >
> > diff --git a/Documentation/automake.mk b/Documentation/automake.mk
> > index 24fe63d..3e16873 100644
> > --- a/Documentation/automake.mk
> > +++ b/Documentation/automake.mk
> > @@ -75,6 +75,7 @@ DOC_SOURCE = \
> > Documentation/faq/terminology.rst \
> > Documentation/faq/vlan.rst \
> > Documentation/faq/vxlan.rst \
> > +Documentation/faq/release_feature_roadmap.rst \
> 
> Looks like you've some extra whitespace here than shouldn't be here.
> 
> > Documentation/internals/index.rst \
> > Documentation/internals/authors.rst \
> > Documentation/internals/bugs.rst \
> > diff --git a/Documentation/faq/index.rst b/Documentation/faq/index.rst
> > index 334b828..e865f57 100644
> > --- a/Documentation/faq/index.rst
> > +++ b/Documentation/faq/index.rst
> > @@ -41,3 +41,4 @@ Open vSwitch FAQ
> > terminology
> > vlan
> > vxlan
> > +   release_feature_roadmap
> > diff --git a/Documentation/faq/release_feature_roadmap.rst
> > b/Documentation/faq/release_feature_roadmap.rst
> > new file mode 100644
> > index 000..40388f6
> > --- /dev/null
> > +++ b/Documentation/faq/release_feature_roadmap.rst
> > @@ -0,0 +1,350 @@
> > +..
> > +Licensed under the Apache License, Version 2.0 (the
> > +"License"); you
> > may
> 
> Ditto (before "Licensed")
> 
> > +  not use this file except in compliance with the License. You
> > + may
> > obtain
> > +  a copy of the License at
> > +
> > +  http://www.apache.org/licenses/LICENSE-2.0
> > +
> > +  Unless required by applicable law or agreed to in writing,
> software
> > +  distributed under the License is distributed on an "AS IS"
> > + BASIS,
> > WITHOUT
> > +  WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > + implied. See
> > the
> > +  License for the specific language governing permissions and
> > limitations
> > +  under the License.
> > +
> > +  Convention for heading levels in Open vSwitch documentation:
> > +
> > +  ===  Heading 0 (reserved for the title in a document)
> > +  ---  Heading 1
> > +  ~~~  Heading 2
> > +  +++  Heading 3
> > +  '''  Heading 4
> > +
> > +  Avoid deeper levels because they do not render well.
> > +
> > +===
> > +Release Feature Roadmap
> > +===
> > +
> > +This document provides a feature roadmap for upcoming OVS releases.
> > +
> > +A few issues to note:
> > +
> > +* The aim of the roadmap is to provide visibility across the
> > +community
> > +  regarding which features contributors are targeting in the upcoming
> > release.
> > +* A feature listed on the roadmap is not guaranteed to be upstreamed
> > +in the
> > +  targeted release and a release will not be delayed in order to
> > +accommodate
> > +  features listed in the roadmap.
> > +* It is not mandatory to include planned features in the roadmap
> > +although it
> > +  is encouraged. Features not listed but that are submitted will
> > +still be
> > +  reviewed as per usual for a release.
> > +
> > +--
> > +Adding Features to the Roadmap
> > +--
> 
> nit: overlines aren't necessary, and we don't use them for anything deeper
> than the top-level header. Could you drop it here?
> 
> > +
> > +When adding a feature to the roadmap a user should be aware of the
> > +required fields and expected values as detailed below:
> > +
> > +* **Contributor**: The name of the person/company contributing the
> feature.
> > +* **Feature Name**: The name of the feature being contributed.
> > +* **Description**: A brief description of the feature being
> contributed.
> > +
> > +---
> > +OVS 2.9 feature Roadmap
> > +---
> > +
> > ++--
> +
> > +| **OVS 2.9 Feature Roadmap**
> +
> >

Re: [ovs-dev] [RFC PATCH v1] docs: Add release feature roadmap.

2017-09-28 Thread Stephen Finucane 
On Wed, 2017-09-13 at 22:04 +0100, Ian Stokes wrote:
> Add a document to outline the roadmap of features contributors are targeting
> for upcoming OVS releases.
> 
> Signed-off-by: Ian Stokes 
> ---
>  Documentation/automake.mk |1 +
>  Documentation/faq/index.rst   |1 +
>  Documentation/faq/release_feature_roadmap.rst |  350
> +
>  3 files changed, 352 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/faq/release_feature_roadmap.rst
> 
> diff --git a/Documentation/automake.mk b/Documentation/automake.mk
> index 24fe63d..3e16873 100644
> --- a/Documentation/automake.mk
> +++ b/Documentation/automake.mk
> @@ -75,6 +75,7 @@ DOC_SOURCE = \
>   Documentation/faq/terminology.rst \
>   Documentation/faq/vlan.rst \
>   Documentation/faq/vxlan.rst \
> +Documentation/faq/release_feature_roadmap.rst \

Looks like you've some extra whitespace here than shouldn't be here.

>   Documentation/internals/index.rst \
>   Documentation/internals/authors.rst \
>   Documentation/internals/bugs.rst \
> diff --git a/Documentation/faq/index.rst b/Documentation/faq/index.rst
> index 334b828..e865f57 100644
> --- a/Documentation/faq/index.rst
> +++ b/Documentation/faq/index.rst
> @@ -41,3 +41,4 @@ Open vSwitch FAQ
> terminology
> vlan
> vxlan
> +   release_feature_roadmap
> diff --git a/Documentation/faq/release_feature_roadmap.rst
> b/Documentation/faq/release_feature_roadmap.rst
> new file mode 100644
> index 000..40388f6
> --- /dev/null
> +++ b/Documentation/faq/release_feature_roadmap.rst
> @@ -0,0 +1,350 @@
> +..
> +Licensed under the Apache License, Version 2.0 (the "License"); you
> may

Ditto (before "Licensed")

> +  not use this file except in compliance with the License. You may
> obtain
> +  a copy of the License at
> +
> +  http://www.apache.org/licenses/LICENSE-2.0
> +
> +  Unless required by applicable law or agreed to in writing, software
> +  distributed under the License is distributed on an "AS IS" BASIS,
> WITHOUT
> +  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See
> the
> +  License for the specific language governing permissions and
> limitations
> +  under the License.
> +
> +  Convention for heading levels in Open vSwitch documentation:
> +
> +  ===  Heading 0 (reserved for the title in a document)
> +  ---  Heading 1
> +  ~~~  Heading 2
> +  +++  Heading 3
> +  '''  Heading 4
> +
> +  Avoid deeper levels because they do not render well.
> +
> +===
> +Release Feature Roadmap
> +===
> +
> +This document provides a feature roadmap for upcoming OVS releases.
> +
> +A few issues to note:
> +
> +* The aim of the roadmap is to provide visibility across the community
> +  regarding which features contributors are targeting in the upcoming
> release.
> +* A feature listed on the roadmap is not guaranteed to be upstreamed in the
> +  targeted release and a release will not be delayed in order to accommodate
> +  features listed in the roadmap.
> +* It is not mandatory to include planned features in the roadmap although it
> +  is encouraged. Features not listed but that are submitted will still be
> +  reviewed as per usual for a release.
> +
> +--
> +Adding Features to the Roadmap
> +--

nit: overlines aren't necessary, and we don't use them for anything deeper than
the top-level header. Could you drop it here?

> +
> +When adding a feature to the roadmap a user should be aware of the required
> +fields and expected values as detailed below:
> +
> +* **Contributor**: The name of the person/company contributing the feature.
> +* **Feature Name**: The name of the feature being contributed.
> +* **Description**: A brief description of the feature being contributed.
> +
> +---
> +OVS 2.9 feature Roadmap
> +---
> +
> ++--+
> +| **OVS 2.9 Feature Roadmap**  +
> ++--+
> +|  |
> ++--+
> +| **Contributor**: *Intel* |
> ++--+
> +| **Feature Name**: Keepalive  |
> ++--+
> +| **Description**: Keepalive feature is aimed at achieving Fastpath Service|
> +| Assurance  in OVS-DPDK deployments. It adds support for monitoring the   |
> +| packet processing threads by dispatching

Re: [ovs-dev] [PATCH v2] docs: Add references to git-pw

2017-09-28 Thread Stephen Finucane 
On Thu, 2017-09-28 at 08:44 -0700, Ben Pfaff wrote:
> On Thu, Sep 28, 2017 at 04:36:04PM +0100, Stephen Finucane wrote:
> > On Mon, 2017-09-04 at 14:09 +0100, Stephen Finucane wrote:
> > > Now that Patchwork 2.0 is out, folks can start to take advantage of some
> > > of the new features that it offers. Chief among these is series support,
> > > which is only exposed via the web UI and new REST API and which, in
> > > turn, necessitates using git-pw rather than pwclient. As such, this tool
> > > is slightly documented.
> > > 
> > > Signed-off-by: Stephen Finucane 
> > 
> > Any chance of getting this merged? Seems trivial enough, IMO.
> 
> I've been off writing code lately.

That makes one of us :'(

> Applied, thanks!

Thanks, Ben!

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

Re: [ovs-dev] [PATCH v2] docs: Add references to git-pw

2017-09-28 Thread Ben Pfaff 
On Thu, Sep 28, 2017 at 04:36:04PM +0100, Stephen Finucane wrote:
> On Mon, 2017-09-04 at 14:09 +0100, Stephen Finucane wrote:
> > Now that Patchwork 2.0 is out, folks can start to take advantage of some
> > of the new features that it offers. Chief among these is series support,
> > which is only exposed via the web UI and new REST API and which, in
> > turn, necessitates using git-pw rather than pwclient. As such, this tool
> > is slightly documented.
> > 
> > Signed-off-by: Stephen Finucane 
> 
> Any chance of getting this merged? Seems trivial enough, IMO.

I've been off writing code lately.

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

Re: [ovs-dev] [PATCH v2] docs: Add references to git-pw

2017-09-28 Thread Stephen Finucane 
On Mon, 2017-09-04 at 14:09 +0100, Stephen Finucane wrote:
> Now that Patchwork 2.0 is out, folks can start to take advantage of some
> of the new features that it offers. Chief among these is series support,
> which is only exposed via the web UI and new REST API and which, in
> turn, necessitates using git-pw rather than pwclient. As such, this tool
> is slightly documented.
> 
> Signed-off-by: Stephen Finucane 

Any chance of getting this merged? Seems trivial enough, IMO.

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

Re: [ovs-dev] Proposal for enabling dp_hash irrespective of OF version

2017-09-28 Thread Ben Pfaff 
Hmm, OK.

Dropping back to a previous suggestion, why do you think it is a big
deal for a controller to use OF1.5 style group_mods in OF1.1 to OF1.4?
It is generally a simple matter of sending a different header indicating
a Nicira Extension.  The controller will need modification in any case
to support this new feature.  It's better, in my opinion, to support all
the features of OF1.5 rather than to add them piecemeal in scattered
places over time.

On Tue, Sep 26, 2017 at 03:27:24PM +, Jan Scheurich wrote:
> Hi Ben,
> 
> As usual there is a trade-off scalability vs. max performance: The dp_hash 
> selection method avoids the upcalls and micro-megaflows for the price of an 
> additional recirculation.
> 
> I guess that is why Jarno didn't want to make it the default selection method 
> in the first place. It might have broken characteristics assumed by previous 
> users of select groups.
> 
> Personally I have no strong objection against hard-coding the dp_hash scheme 
> as new default, but there might be users whose use cases do not require 
> scalability and determinism.
> 
> BR, Jan
> 
> > -Original Message-
> > From: Ben Pfaff [mailto:b...@ovn.org]
> > Sent: Monday, 25 September, 2017 18:48
> > To: Jan Scheurich 
> > Cc: Nitin Katiyar ; ovs-dev@openvswitch.org
> > Subject: Re: [ovs-dev] Proposal for enabling dp_hash irrespective of OF 
> > version
> > 
> > If the new selection method is superior to the default one, is there a
> > reason to require the controller to select it at all?
> > 
> > On Mon, Sep 25, 2017 at 04:28:26PM +, Jan Scheurich wrote:
> > > Hi Ben,
> > >
> > > The current hard-coded default select group implementation requires every 
> > > single L4 flow to be load-balanced in an upcall and creates
> > a dedicated megaflow for every 5-tuple. This is clearly not scalable in 
> > deployments where the number of parallel L4 flows and the L4 flow
> > setup rate is unknown and cannot be controlled (e.g. in Telco cloud 
> > deployments where the VNFs carry end-user traffic).
> > >
> > > We need a scalable select group implementation to implement distributed 
> > > ECMP L3 forwarding in OVS. The dp_hash based
> > implementation is mostly already in place, thanks to Jarno, but its use is 
> > unfortunately tied to an OF 1.5 Group Mod extension that our
> > controllers do not support.
> > >
> > > Our aim with this proposal is to provide a scalable select group 
> > > implementation in OVS for any OpenFlow controller. As there is no
> > functional difference between the original selection method and the dp_hash 
> > based one, I don't see a reason why the controller should
> > have to be involved for choosing one or the other. This is different in 
> > nature from the extension to specify the hash fields for the bucket
> > selection.
> > >
> > > As Cloud provider we would like to be able to configure OVS to by default 
> > > use apply the scalable dp_hash selection method, unless the
> > controller specifies something else. A natural place seems to be to add 
> > this as a bridge property.
> > >
> > > Regards, Jan
> > >
> > > N.B.  The pre-OF 1.5 Group Mod message simply has no extension mechanism 
> > > to carry addition group properties. We would have to add
> > a proprietary new NX Group Mod message, which would not make life much 
> > simpler for controllers.
> > >
> > > > -Original Message-
> > > > From: ovs-dev-boun...@openvswitch.org 
> > > > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Ben Pfaff
> > > > Sent: Monday, 25 September, 2017 17:31
> > > > To: Nitin Katiyar 
> > > >
> > > > This proposes adding a default selection method that could be set via
> > > > OVSDB.  This would probably work (I have not thought through the
> > > > implications), but the usual way that we would solve this kind of thing
> > > > in OVS is by making the features of the OF1.5 group_mod available in
> > > > earlier versions.
> > >
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2 4/4] netdev-dpdk: Reword mp_size as n_mbufs.

2017-09-28 Thread antonio . fischetti 
From: Antonio Fischetti 

Rename mp_size as n_mbufs in dpdk_mp structure.
This parameter is passed to rte mempool creation functions
and is meant to contain the number of elements inside
the requested mempool.

CC: Ciara Loftus 
CC: Kevin Traynor 
CC: Aaron Conole 
Signed-off-by: Antonio Fischetti 
---
 lib/netdev-dpdk.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index dded37f..a3fc3bd 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -308,7 +308,7 @@ struct dpdk_mp {
 int mtu;
 int socket_id;
 char if_name[IFNAMSIZ];
-unsigned mp_size;
+unsigned n_mbufs;   /* Number of mbufs inside the mempool. */
 struct ovs_list list_node OVS_GUARDED_BY(dpdk_mp_mutex);
 };
 
@@ -500,7 +500,7 @@ dpdk_mp_name(struct dpdk_mp *dmp)
 uint32_t h = hash_string(dmp->if_name, 0);
 char *mp_name = xcalloc(RTE_MEMPOOL_NAMESIZE, sizeof *mp_name);
 int ret = snprintf(mp_name, RTE_MEMPOOL_NAMESIZE, "ovs_%x_%d_%u",
-   h, dmp->mtu, dmp->mp_size);
+   h, dmp->mtu, dmp->n_mbufs);
 ovs_assert(ret >= 0 && ret < RTE_MEMPOOL_NAMESIZE);
 return mp_name;
 }
@@ -517,13 +517,13 @@ dpdk_mp_create(struct netdev_dpdk *dev, int mtu)
 ovs_strzcpy(dmp->if_name, dev->up.name, IFNAMSIZ);
 
 /*
- * XXX: rough estimation of memory required for port:
+ * XXX: rough estimation of number of mbufs required for this port:
  * 
  * + 
  * + 
  * + 
  */
-dmp->mp_size = dev->requested_n_rxq * dev->requested_rxq_size
+dmp->n_mbufs = dev->requested_n_rxq * dev->requested_rxq_size
 + dev->requested_n_txq * dev->requested_txq_size
 + MIN(RTE_MAX_LCORE, dev->requested_n_rxq) * NETDEV_MAX_BURST
 + MIN_NB_MBUF;
@@ -535,10 +535,10 @@ dpdk_mp_create(struct netdev_dpdk *dev, int mtu)
 
 VLOG_DBG("Requesting a mempool of %u mbufs for netdev %s "
  "with %d Rx and %d Tx queues.",
- dmp->mp_size, dev->up.name,
+ dmp->n_mbufs, dev->up.name,
  dev->requested_n_rxq, dev->requested_n_txq);
 
-dmp->mp = rte_pktmbuf_pool_create(mp_name, dmp->mp_size,
+dmp->mp = rte_pktmbuf_pool_create(mp_name, dmp->n_mbufs,
   MP_CACHE_SZ,
   sizeof (struct dp_packet)
  - sizeof (struct rte_mbuf),
@@ -547,7 +547,7 @@ dpdk_mp_create(struct netdev_dpdk *dev, int mtu)
   dmp->socket_id);
 if (dmp->mp) {
 VLOG_DBG("Allocated \"%s\" mempool with %u mbufs", mp_name,
- dmp->mp_size);
+ dmp->n_mbufs);
 /* rte_pktmbuf_pool_create has done some initialization of the
  * rte_mbuf part of each dp_packet. Some OvS specific fields
  * of the packet still need to be initialized by
@@ -565,14 +565,14 @@ dpdk_mp_create(struct netdev_dpdk *dev, int mtu)
 mp_exists = true;
 } else {
 VLOG_ERR("Failed mempool \"%s\" create request of %u mbufs",
- mp_name, dmp->mp_size);
+ mp_name, dmp->n_mbufs);
 }
 free(mp_name);
 if (dmp->mp) {
 return dmp;
 }
 } while (!mp_exists &&
-(rte_errno == ENOMEM && (dmp->mp_size /= 2) >= MIN_NB_MBUF));
+(rte_errno == ENOMEM && (dmp->n_mbufs /= 2) >= MIN_NB_MBUF));
 
 rte_free(dmp);
 return NULL;
-- 
2.4.11

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

[ovs-dev] [PATCH v2 3/4] netdev-dpdk: assert mempool names.

2017-09-28 Thread antonio . fischetti 
From: Antonio Fischetti 

CC: Ciara Loftus 
CC: Kevin Traynor 
CC: Aaron Conole 
Signed-off-by: Antonio Fischetti 
---
 lib/netdev-dpdk.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 25fb9a8..dded37f 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -501,9 +501,7 @@ dpdk_mp_name(struct dpdk_mp *dmp)
 char *mp_name = xcalloc(RTE_MEMPOOL_NAMESIZE, sizeof *mp_name);
 int ret = snprintf(mp_name, RTE_MEMPOOL_NAMESIZE, "ovs_%x_%d_%u",
h, dmp->mtu, dmp->mp_size);
-if (ret < 0 || ret >= RTE_MEMPOOL_NAMESIZE) {
-return NULL;
-}
+ovs_assert(ret >= 0 && ret < RTE_MEMPOOL_NAMESIZE);
 return mp_name;
 }
 
-- 
2.4.11

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

[ovs-dev] [PATCH v2 2/4] netdev-dpdk: if mempool already exists don't reinit packet areas.

2017-09-28 Thread antonio . fischetti 
From: Antonio Fischetti 

Skip initialization of mempool objects if this was already
done in a previous call to dpdk_mp_create.

CC: Ciara Loftus 
CC: Kevin Traynor 
CC: Aaron Conole 
Signed-off-by: Antonio Fischetti 
---
 lib/netdev-dpdk.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index dda3771..25fb9a8 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -550,6 +550,11 @@ dpdk_mp_create(struct netdev_dpdk *dev, int mtu)
 if (dmp->mp) {
 VLOG_DBG("Allocated \"%s\" mempool with %u mbufs", mp_name,
  dmp->mp_size);
+/* rte_pktmbuf_pool_create has done some initialization of the
+ * rte_mbuf part of each dp_packet. Some OvS specific fields
+ * of the packet still need to be initialized by
+ * ovs_rte_pktmbuf_init. */
+rte_mempool_obj_iter(dmp->mp, ovs_rte_pktmbuf_init, NULL);
 } else if (rte_errno == EEXIST) {
 /* A mempool with the same name already exists.  We just
  * retrieve its pointer to be returned to the caller. */
@@ -566,11 +571,6 @@ dpdk_mp_create(struct netdev_dpdk *dev, int mtu)
 }
 free(mp_name);
 if (dmp->mp) {
-/* rte_pktmbuf_pool_create has done some initialization of the
- * rte_mbuf part of each dp_packet, while ovs_rte_pktmbuf_init
- * initializes some OVS specific fields of dp_packet.
- */
-rte_mempool_obj_iter(dmp->mp, ovs_rte_pktmbuf_init, NULL);
 return dmp;
 }
 } while (!mp_exists &&
-- 
2.4.11

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

Re: [ovs-dev] [PATCH 3/4] netdev-dpdk: log an err message when a mempool name is empty.

2017-09-28 Thread Fischetti, Antonio 

> -Original Message-
> From: Darrell Ball [mailto:db...@vmware.com]
> Sent: Tuesday, September 26, 2017 9:22 PM
> To: Fischetti, Antonio ; d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH 3/4] netdev-dpdk: log an err message when a
> mempool name is empty.
> 
> 
> 
> On 9/26/17, 8:06 AM, "ovs-dev-boun...@openvswitch.org on behalf of
> antonio.fische...@intel.com"  antonio.fische...@intel.com> wrote:
> 
> Log an error message when the creation of a name for a
> new mempool fails.
> 
> CC: Ciara Loftus 
> CC: Kevin Traynor 
> CC: Aaron Conole 
> Signed-off-by: Antonio Fischetti 
> ---
>  lib/netdev-dpdk.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index f3f42ee..7c673ec 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -502,6 +502,9 @@ dpdk_mp_name(struct dpdk_mp *dmp)
>  int ret = snprintf(mp_name, RTE_MEMPOOL_NAMESIZE, "ovs_%x_%d_%u",
> h, dmp->mtu, dmp->mp_size);
>  if (ret < 0 || ret >= RTE_MEMPOOL_NAMESIZE) {
> +VLOG_ERR("Failed to generate a mempool name for \"%s\". "
> +"Hash:0x%x, mtu:%d, mbufs:%u",
> +dmp->if_name, h, dmp->mtu, dmp->mp_size);
> 
> [Darrell] “Unlikely” to fail but this could be an ovs_assert(…)

[Antonio] ok will replace with
 ovs_assert(ret >= 0 && ret < RTE_MEMPOOL_NAMESIZE);

> 
> 
>  return NULL;
>  }
>  return mp_name;
> --
> 2.4.11
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__mail.openvswitch.org_mailman_listinfo_ovs-
> 2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-
> uZnsw=VXc6b9RFgB9FaMDL4JevWOtvj0gTpvDJYBS30fvVj8Y=Eeo-
> qAFITbCVhSWvMvxHDN4IzLsDEIYI1MmIsoUtDOE=
> 

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

Re: [ovs-dev] [PATCH 2/4] netdev-dpdk: if mempool already exists don't reinit packet areas.

2017-09-28 Thread Fischetti, Antonio 

> -Original Message-
> From: Darrell Ball [mailto:db...@vmware.com]
> Sent: Tuesday, September 26, 2017 9:02 PM
> To: Fischetti, Antonio ; d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH 2/4] netdev-dpdk: if mempool already exists 
> don't
> reinit packet areas.
> 
> 
> 
> On 9/26/17, 8:05 AM, "ovs-dev-boun...@openvswitch.org on behalf of
> antonio.fische...@intel.com"  antonio.fische...@intel.com> wrote:
> 
> Skip initialization of mempool objects if this was already
> done in a previous call to dpdk_mp_create.
> 
> CC: Ciara Loftus 
> CC: Kevin Traynor 
> CC: Aaron Conole 
> Signed-off-by: Antonio Fischetti 
> ---
>  lib/netdev-dpdk.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index 2f5ec71..f3f42ee 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -566,12 +566,15 @@ dpdk_mp_create(struct netdev_dpdk *dev, int mtu)
>  }
>  free(mp_name);
>  if (dmp->mp) {
> -/* rte_pktmbuf_pool_create has done some initialization of 
> the
> - * rte_mbuf part of each dp_packet, while 
> ovs_rte_pktmbuf_init
> - * initializes some OVS specific fields of dp_packet.
> - */
> -rte_mempool_obj_iter(dmp->mp, ovs_rte_pktmbuf_init, NULL);
> -
> +/* If the current mp was already created by a previous call
> + * we don't need to init again all its elements. */
> +if (!mp_exists) {
> +/* rte_pktmbuf_pool_create has done some initialization 
> of
> the
> + * rte_mbuf part of each dp_packet, while
> ovs_rte_pktmbuf_init
> + * initializes some OVS specific fields of dp_packet.
> + */
> +rte_mempool_obj_iter(dmp->mp, ovs_rte_pktmbuf_init, 
> NULL);
> 
> 
> [Darrell] Can this be moved inside
> if (dmp->mp) {
> VLOG_DBG("Allocated \"%s\" mempool with %u mbufs", mp_name,
>  dmp->mp_size);
> }…..
> 
> for clarity?

[Antonio] Thanks, that makes the code more readable too.


> 
> 
> +}
>  return dmp;
>  }
>  } while (!mp_exists &&
> --
> 2.4.11
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__mail.openvswitch.org_mailman_listinfo_ovs-
> 2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-
> uZnsw=Bf45eQULq41ut2PpTtt6Dah9xN86c0suku7rL1WVaTs=2HhdsumV1sIAkn7BT6u3jzjIP
> ghy-48d2IgkqXemk8c=
> 

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

Re: [ovs-dev] [PATCH 1/4] netdev-dpdk: fix mempool management with vhu client.

2017-09-28 Thread Fischetti, Antonio 
Thanks Darrell, replies inline.

-Antonio

> -Original Message-
> From: Darrell Ball [mailto:db...@vmware.com]
> Sent: Tuesday, September 26, 2017 9:04 PM
> To: Fischetti, Antonio ; d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH 1/4] netdev-dpdk: fix mempool management with 
> vhu
> client.
> 
> 
> 
> On 9/26/17, 12:58 PM, "Darrell Ball"  wrote:
> 
> 
> 
> On 9/26/17, 8:04 AM, "ovs-dev-boun...@openvswitch.org on behalf of
> antonio.fische...@intel.com"  antonio.fische...@intel.com> wrote:
> 
> In a PVP test where vhostuser ports are configured as
> clients, OvS crashes when QEMU is launched.
> This patch avoids the repeated calls to netdev_change_seq_changed
> after the requested mempool is already acquired.
> 
> CC: Ciara Loftus 
> CC: Kevin Traynor 
> CC: Aaron Conole 
> Fixes: d555d9bded5f ("netdev-dpdk: Create separate memory pool for 
> each
> port.")
> Signed-off-by: Antonio Fischetti 
> ---
> To replicate the bug scenario:
> 
> [Darrell] Just curious, but reproducibility with below steps ?; what about
> using libvirt ?
>Do we have the stacktrace ?

[Antonio] 
Actually I didn't try with libvirt. I also saw that it didn't crash when the
vhostuser ports were set with type=dpdkvhostuser.
 
Below is the stacktrace on a crash, ie when setting type=dpdkvhostuserclient:

Thread 26 "pmd124" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f73ca7fc700 (LWP 20176)]
0x00410fa9 in stack_dequeue ()
(gdb) bt
#0  0x00410fa9 in stack_dequeue ()
#1  0x005cdc17 in rte_mempool_ops_dequeue_bulk (mp=0x7f72fb83c940, 
obj_table=0x7f73ca7fb258, n=1) at
 /home/user/dpdk/x86_64-native-linuxapp-gcc/include/rte_mempool.h:474
#2  0x005cdff9 in __mempool_generic_get (cache=0x0, n=1, 
obj_table=0x7f73ca7fb258, mp=0x7f72fb83c940
) at /home/user/dpdk/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1218
#3  rte_mempool_generic_get (flags=0, cache=0x0, n=1, obj_table=0x7f73ca7fb258, 
mp=0x7f72fb83c940) at /home/
user/dpdk/x86_64-native-linuxapp-gcc/include/rte_mempool.h:1256
#4  rte_mempool_get_bulk (n=1, obj_table=0x7f73ca7fb258, mp=0x7f72fb83c940) at 
/home/user/dpdk/x86_64-nat
ive-linuxapp-gcc/include/rte_mempool.h:1289
#5  rte_mempool_get (obj_p=0x7f73ca7fb258, mp=0x7f72fb83c940) at 
/home/user/dpdk/x86_64-native-linuxapp-g
cc/include/rte_mempool.h:1315
#6  rte_mbuf_raw_alloc (mp=0x7f72fb83c940) at 
/home/user/dpdk/x86_64-native-linuxapp-gcc/include/rte_mbuf
.h:822
#7  0x005ce14b in rte_pktmbuf_alloc (mp=0x7f72fb83c940) at 
/home/user/dpdk/x86_64-native-linuxapp
-gcc/include/rte_mbuf.h:1122
#8  0x005d283a in rte_vhost_dequeue_burst (vid=0, queue_id=1, 
mbuf_pool=0x7f72fb83c940, pkts=0x7f73c
a7fb830, count=1) at /home/user/dpdk/lib/librte_vhost/virtio_net.c:1116
#9  0x007b4025 in netdev_dpdk_vhost_rxq_recv (rxq=0x7f72ffdab080, 
batch=0x7f73ca7fb820) at lib/netde
v-dpdk.c:1650
#10 0x0070d331 in netdev_rxq_recv ()
#11 0x006ea8ce in dp_netdev_process_rxq_port ()
#12 0x006eaba0 in pmd_thread_main ()
#13 0x0075cb34 in ovsthread_wrapper ()
#14 0x7f742a0e65ca in start_thread () from /lib64/libpthread.so.0
#15 0x7f742990f0cd in clone () from /lib64/libc.so.6

> 
> 
> 
>  PVP test setup
>  --
> CLIENT_SOCK_DIR=/tmp
> SOCK0=dpdkvhostuser0
> SOCK1=dpdkvhostuser1
> 
> 1 PMD
> Add 2 dpdk ports, n_rxq=1
> Add 2 vhu ports both of type dpdkvhostuserclient and specify vhost-
> server-path
>  ovs-vsctl set Interface dpdkvhostuser0 options:vhost-server-
> path="$CLIENT_SOCK_DIR/$SOCK0"
>  ovs-vsctl set Interface dpdkvhostuser1 options:vhost-server-
> path="$CLIENT_SOCK_DIR/$SOCK1"
> 
> Set port-based rules: dpdk0 <--> vhu0 and dpdk1 <--> vhu1
>  add-flow br0 in_port=1,action=output:3
>  add-flow br0 in_port=3,action=output:1
>  add-flow br0 in_port=4,action=output:2
>  add-flow br0 in_port=2,action=output:4
> 
>  Launch QEMU
>  ---
> As OvS vhu ports are acting as clients, we must specify 'server' in 
> the
> next command.
> VM_IMAGE=
> 
>  sudo -E taskset 0x3F00 $QEMU_DIR/x86_64-softmmu/qemu-system-x86_64 -
> name us-vhost-vm1 -cpu host -enable-kvm -m 4096M -object memory-backend-
> file,id=mem,size=4096M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem 
> -
> mem-prealloc -smp 4 -drive file=$VM_IMAGE -chardev
> socket,id=char0,path=$CLIENT_SOCK_DIR/$SOCK0,server -netdev type=vhost-
> user,id=mynet1,chardev=char0,vhostforce -device virtio-net-
> pci,mac=00:00:00:00:00:01,netdev=mynet1,mrg_rxbuf=off -chardev
>

[ovs-dev] Greetings with Confidence

2017-09-28 Thread Kelvin Sotire 
Greetings

my name is Kelvin Sotire, i am writing to seek your assistance in the
trasnfer of fund. i am treasurere to mikhail khodorkovsky, the russian
billionaire, the russian oil tycoon. i need a reliable hand for a
transfer 25,000,000 USD and automatic investment of the fund
immediately after transfer.i am very much ready to share with you
accordingly on any agreed percentage...  sotp...@gmail.com

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

Re: [ovs-dev] [PATCH v8 4/4] ovn: Generate Neighbor Solicitation packet for unknown MAC IPv6 packets

2017-09-28 Thread Numan Siddique 
On Thu, Sep 28, 2017 at 2:12 AM, Mark Michelson  wrote:

>
>
> On Thu, Sep 21, 2017 at 11:12 AM  wrote:
>
>> From: Numan Siddique 
>>
>> In the router ingress pipeline, if the destination mac is unresolved
>> by the time the packet reaches the ARP_REQUEST stage, OVN should generate
>> an
>> IPv6 Neighbor Solicitation packet to learn the MAC address. This feature
>> is
>> presently missing. This patch adds this feature.  A new action "nd_ns" is
>> added  which replaces an IPv6 packet being processed with an IPv6 Neighbor
>> Solicitation packet. ovn-northd adds a flow in the ARP_REQUEST router
>> ingress
>> pipeline stage if the eth.dst is zero which applies this action. This
>> action is
>> similar to the IPv4 counterpart "arp" action.
>>
>> OVN already has the support to learn the MAC from the IPv6 Neighbor
>> Advertisement
>> packets and storing in the south bound MAC_Binding table.
>>
>> Signed-off-by: Numan Siddique 
>> ---
>>  include/ovn/actions.h   |   9 +++-
>>  ovn/controller/pinctrl.c| 122 +++---
>> --
>>  ovn/lib/actions.c   |  22 
>>  ovn/northd/ovn-northd.8.xml |  24 ++---
>>  ovn/northd/ovn-northd.c |   8 ++-
>>  ovn/ovn-sb.xml  |  37 ++
>>  ovn/utilities/ovn-trace.c   |  30 +++
>>  tests/ovn.at| 116 ++
>> +++
>>  8 files changed, 302 insertions(+), 66 deletions(-)
>>
>> diff --git a/include/ovn/actions.h b/include/ovn/actions.h
>> index 15cee478d..8c7208ffc 100644
>> --- a/include/ovn/actions.h
>> +++ b/include/ovn/actions.h
>> @@ -73,7 +73,8 @@ struct simap;
>>  OVNACT(SET_QUEUE, ovnact_set_queue)   \
>>  OVNACT(DNS_LOOKUP,ovnact_dns_lookup)  \
>>  OVNACT(LOG,   ovnact_log) \
>> -OVNACT(PUT_ND_RA_OPTS,ovnact_put_opts)
>> +OVNACT(PUT_ND_RA_OPTS,ovnact_put_opts)\
>> +OVNACT(ND_NS, ovnact_nest)
>>
>>  /* enum ovnact_type, with a member OVNACT_ for each action. */
>>  enum OVS_PACKED_ENUM ovnact_type {
>> @@ -427,6 +428,12 @@ enum action_opcode {
>>   *   - Any number of ICMPv6 options.
>>   */
>>  ACTION_OPCODE_PUT_ND_RA_OPTS,
>> +
>> +/* "nd_ns { ...actions... }".
>> + *
>> + * The actions, in OpenFlow 1.3 format, follow the action_header.
>> + */
>> +ACTION_OPCODE_ND_NS,
>>  };
>>
>>  /* Header. */
>> diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
>> index 6dbea4efa..cad0f67ba 100644
>> --- a/ovn/controller/pinctrl.c
>> +++ b/ovn/controller/pinctrl.c
>> @@ -85,6 +85,9 @@ static void pinctrl_handle_put_nd_ra_opts(
>>  const struct flow *ip_flow, struct dp_packet *pkt_in,
>>  struct ofputil_packet_in *pin, struct ofpbuf *userdata,
>>  struct ofpbuf *continuation OVS_UNUSED);
>> +static void pinctrl_handle_nd_ns(const struct flow *ip_flow,
>> + const struct match *md,
>> + struct ofpbuf *userdata);
>>
>>  COVERAGE_DEFINE(pinctrl_drop_put_mac_binding);
>>
>> @@ -132,6 +135,43 @@ set_switch_config(struct rconn *swconn,
>>  }
>>
>>  static void
>> +set_actions_and_enqueu_msg(const struct dp_packet *packet,
>>
>
> Nit: The word is spelled "enqueue", not "enqueu". This could potentially
> lead to some confusion if left this way.
>


Thanks Mark for the comments. I will take care of this in the next patch
set. I will wait for a while so that I can incorporate review comments (if
any) from the other patches in this series.



>
>> +   const struct match *md,
>> +   struct ofpbuf *userdata)
>> +{
>> +/* Copy metadata from 'md' into the packet-out via "set_field"
>> + * actions, then add actions from 'userdata'.
>> + */
>> +uint64_t ofpacts_stub[4096 / 8];
>> +struct ofpbuf ofpacts = OFPBUF_STUB_INITIALIZER(ofpacts_stub);
>> +enum ofp_version version = rconn_get_version(swconn);
>> +
>> +reload_metadata(, md);
>> +enum ofperr error = ofpacts_pull_openflow_actions(userdata,
>> userdata->size,
>> +  version, NULL,
>> NULL,
>> +  );
>> +if (error) {
>> +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
>> +VLOG_WARN_RL(, "failed to parse actions from userdata (%s)",
>> + ofperr_to_string(error));
>> +ofpbuf_uninit();
>> +return;
>> +}
>> +
>> +struct ofputil_packet_out po = {
>> +.packet = dp_packet_data(packet),
>> +.packet_len = dp_packet_size(packet),
>> +.buffer_id = UINT32_MAX,
>> +.ofpacts = ofpacts.data,
>> +.ofpacts_len = ofpacts.size,
>> +};
>> +match_set_in_port(_metadata, OFPP_CONTROLLER);
>> +enum ofputil_protocol proto =