[ovs-dev] dpdk was compiled with CONFIG_RTE_LIBRTE_VHOST_NUMA=n , but on ovs-2.8 compilation, "configure: error: unable to find libnuma, install the dependency package "

2017-09-27 Thread Joo Kim 
Hello,


My dpdk was compiled with   CONFIG_RTE_LIBRTE_VHOST_NUMA=n  (which is a
default in config/common_base).

But, I see following error when I  compile ovs-2.8 with dpdk enabled. Is
this expected?   Also ignorable error?

"
. . .
checking for library containing get_mempolicy... no
configure: error: unable to find libnuma, install the dependency package
"
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v4 3/3] ovn-controller: Use separate thread for packet-in processing.

2017-09-27 Thread Han Zhou 
Hi Guoshuai,

Thanks for the feedback. I am glad it is useful for you. And you have a
very valid point that the current patch breaks the connection status
feature. I didn't think about the detailed fix yet but in general I think
it might be reasonable to add a "proxy" layer of HV-local SB DB, which will
be solve the problem you mentioned and also save the bandwidth, without
doubling the burden of the central SB DB. What do you think?

Thanks,
Han

On Tue, Sep 26, 2017 at 5:08 PM, Guoshuai Li  wrote:
>
> This is very useful to me.
>
> I found a problem in my use:
> In the ovn-controller and the south of the database connection，when the
ovn-controller as a passive service, the SB as a client, such as configured
to
>
> ovs-vsctl set Open_vSwitch . external-ids:ovn-remote=ptcp:6644:0.0.0.0
> ovn-sbctl set-connection  tcp:10.157.145.211:6644 tcp:10.157.145.212:6644
tcp:10.157.145.213:6644 tcp:10.157.145.214:6644
>
> This configuration is to determine the status of the chassis through the
state of the connection in the OVNSB。
>
>
> But here the two threads listening conflict：
> 2017-09-27T00:00:59.387Z|26144|socket_util|ERR|6644:0.0.0.0: bind:
Address already in use
> 2017-09-27T00:00:59.387Z|26145|reconnect|INFO|ptcp:6644:0.0.0.0:
listening...
> 2017-09-27T00:00:59.387Z|26146|reconnect|INFO|ptcp:6644:0.0.0.0: listen
attempt failed (Address already in use)
>
> Do you have a good way to fix it?
>
> And this patch also conflict with master...
>
>
>  2017/8/28 12:14, Han Zhou :
>
>> This patch introduces multi-threading for ovn-controller and use
>> dedicated thread for packet-in processing as a start. It decouples
>> packet-in processing and ovs flow computing, so that packet-in inputs
>> won't trigger flow recomputing, and flow computing won't block
>> packet-in processing. In large scale environment this largely reduces
>> CPU cost and improves performance.
>>
>> Related effort and discussion:
>> https://mail.openvswitch.org/pipermail/ovs-dev/2017-May/331813.html
>>
>> Signed-off-by: Han Zhou 
>> ---
>> v3->v4: rebased on master.
>>
>>   ovn/controller/ovn-controller.c |  71 ++-
>>   ovn/controller/ovn-controller.h |  38 +++
>>   ovn/controller/pinctrl.c| 105

>>   ovn/controller/pinctrl.h|   1 +
>>   4 files changed, 193 insertions(+), 22 deletions(-)
>>
>> diff --git a/ovn/controller/ovn-controller.c
b/ovn/controller/ovn-controller.c
>> index 414443f..cb04244 100644
>> --- a/ovn/controller/ovn-controller.c
>> +++ b/ovn/controller/ovn-controller.c
>> @@ -56,6 +56,8 @@
>>   #include "stream.h"
>>   #include "unixctl.h"
>>   #include "util.h"
>> +#include "latch.h"
>> +#include "ovs-thread.h"
>> VLOG_DEFINE_THIS_MODULE(main);
>>   @@ -66,8 +68,6 @@ static unixctl_cb_func inject_pkt;
>>   #define DEFAULT_BRIDGE_NAME "br-int"
>>   #define DEFAULT_PROBE_INTERVAL_MSEC 5000
>>   -static void update_probe_interval(struct controller_ctx *,
>> -  const char *ovnsb_remote);
>>   static void parse_options(int argc, char *argv[]);
>>   OVS_NO_RETURN static void usage(void);
>>   @@ -78,7 +78,7 @@ struct pending_pkt {
>>   char *flow_s;
>>   };
>>   -static char *ovs_remote;
>> +char *ovs_remote;
>> struct local_datapath *
>>   get_local_datapath(const struct hmap *local_datapaths, uint32_t
tunnel_key)
>> @@ -129,7 +129,7 @@ get_bridge(struct ovsdb_idl *ovs_idl, const char
*br_name)
>>   return NULL;
>>   }
>>   -static void
>> +void
>>   update_sb_monitors(struct ovsdb_idl *ovnsb_idl,
>>  const struct sbrec_chassis *chassis,
>>  const struct sset *local_ifaces,
>> @@ -257,7 +257,7 @@ create_br_int(struct controller_ctx *ctx)
>>   return bridge;
>>   }
>>   -static const struct ovsrec_bridge *
>> +const struct ovsrec_bridge *
>>   get_br_int(struct controller_ctx *ctx)
>>   {
>>   const struct ovsrec_open_vswitch *cfg;
>> @@ -269,7 +269,7 @@ get_br_int(struct controller_ctx *ctx)
>>   return get_bridge(ctx->ovs_idl, br_int_name(cfg));
>>   }
>>   -static const char *
>> +const char *
>>   get_chassis_id(const struct ovsdb_idl *ovs_idl)
>>   {
>>   const struct ovsrec_open_vswitch *cfg =
ovsrec_open_vswitch_first(ovs_idl);
>> @@ -309,7 +309,7 @@ update_ssl_config(const struct ovsdb_idl *ovs_idl)
>> /* Retrieves the OVN Southbound remote location from the
>>* "external-ids:ovn-remote" key in 'ovs_idl' and returns a copy of
it. */
>> -static char *
>> +char *
>>   get_ovnsb_remote(struct ovsdb_idl *ovs_idl)
>>   {
>>   while (1) {
>> @@ -498,6 +498,22 @@ get_nb_cfg(struct ovsdb_idl *idl)
>>   }
>> static void
>> +ctrl_thread_create(struct ctrl_thread *thread, const char *name,
>> +void *(*start)(void *))
>> +{
>> +latch_init(>exit_latch);
>> +thread->thread = ovs_thread_create(name, start, thread);
>> +}
>> +
>> +static void
>> +ctrl_thread_exit(struct ctrl_thread

Re: [ovs-dev] [PATCH] ovs-lib: dont't purge corrupted DB

2017-09-27 Thread Mark Michelson 
LGTM

On Wed, Sep 27, 2017 at 8:46 AM Matteo Croce  wrote:

> In ovs-lib there is a function named upgrade_db which tries to convert a
> database after OVS {up,down}grades. This function uses ovsdb-tool to
> check if the DB needs to be upgraded. If the upgrade fails,
> it purges the DB and create an empty one.
> ovsdb-tool returns "yes" or "no" to indicate if the DB needs upgrading,
> but if the DB is corrupted it returns a list of errors.
> Change a condition from "!= no" to "= yes" because in case of DB
> corruption upgrade_db would purge the existing DB without writing
> anything in the logs.
>
> Signed-off-by: Matteo Croce 
>
Acked-by: Mark Michelson 

> ---
>  utilities/ovs-lib.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/utilities/ovs-lib.in b/utilities/ovs-lib.in
> index 8665698bb..ea5a12375 100644
> --- a/utilities/ovs-lib.in
> +++ b/utilities/ovs-lib.in
> @@ -400,7 +400,7 @@ upgrade_db () {
>  log_warning_msg "$DB_FILE does not exist"
>  install_dir `dirname $DB_FILE`
>  create_db "$DB_FILE" "$DB_SCHEMA"
> -elif test X"`ovsdb_tool needs-conversion "$DB_FILE" "$DB_SCHEMA"`" !=
> Xno; then
> +elif test X"`ovsdb_tool needs-conversion "$DB_FILE" "$DB_SCHEMA"`" =
> Xyes; then
>  # Back up the old version.
>  version=`ovsdb_tool db-version "$DB_FILE"`
>  cksum=`ovsdb_tool db-cksum "$DB_FILE" | awk '{print $1}'`
> --
> 2.13.5
>
> ___
> 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 v8 4/4] ovn: Generate Neighbor Solicitation packet for unknown MAC IPv6 packets

2017-09-27 Thread Mark Michelson 
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.


> +   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 =
> ofputil_protocol_from_ofp_version(version);
> +queue_msg(ofputil_encode_packet_out(, proto));
> +ofpbuf_uninit();
> +}
> +
> +static void
>  pinctrl_handle_arp(const struct flow *ip_flow, const struct match *md,
> struct ofpbuf *userdata)
>  {
> @@ -166,40 +206,8 @@ pinctrl_handle_arp(const struct flow *ip_flow, const
> struct match *md,
>ip_flow->vlans[0].tci);
>

Re: [ovs-dev] [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow

2017-09-27 Thread Darrell Ball 


On 9/27/17, 3:41 AM, "Finn Christensen"  wrote:

-Original Message-
From: Yuanhan Liu [mailto:y...@fridaylinux.org]
Sent: 27. september 2017 11:47
To: Finn Christensen 
Cc: Darrell Ball ; d...@openvswitch.org; Chandran
Sugesh ; Simon Horman

Subject: Re: [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow

On Wed, Sep 27, 2017 at 09:12:49AM +, Finn Christensen wrote:
>
> [Darrell] It looks fine; of course, if we could drop dependencies 
on cap
> probe, it would be ideal (.
>
>
> [Finn]
> From a Napatech point of view, we would definitely want to use the
> RTE_FLOW_ACTION_TYPE_RSS if it were implement. It definitely makes
> good sense to me. I have 2 reasons for this:
> 1. It would fit nicely into the way Napatech does flow programming in
> nic 2. We would be fully RSS controlled through OVS Furthermore,
> Future RSS splitting on a per megaflow basis will be possible.
> IMO the "pure_mark_cap_probed" function is a temp work-around to
make it work.
> The RSS seems to be a solution to the queue problem.

Finn, that's really good to know! I do agree without this probe, it 
makes the
code simpler and cleaner.

Few questions though. Have Napatech already implemented rss action? If
not, what's the plan?

[Finn]
Our nic handles rss on a per flow basis, but we have not yet used rte rss 
action
for OVS. In OVS we simply handles RSS config outside it.
The full control of rss through OVS is better though.

And are you okay with following code?

add_mark_action();
add_rss_action_unconditionally();

flow = rte_create_flow(...);
if (!flow)
return -1;

That is, no probes, no feedbacks. If it failed, it just failed (flow 
offload then
is just skipped).

[Finn]
Yes, we can easily make this work. Good suggestion!


But I do think some feedbacks are necessary. If we know the rte_flow cap
in the begnning, we could simply disable the flow offload for a 
specific port
if we know it doesn't have offload ability. This would avoid the repeat
effort of trying to do hw offload completely.

[Finn]
This seems to be a good idea.

[Darrell] Regarding the general question of capability checking, it is fine to 
have this support
   in general and we already identified some cases where it would 
be best to use this
   if we can (the question mostly comes down to support by RTE and 
drivers).

  Probing is different and we usually use the term for some try and 
error checking to configure
  something during initialization and see if works and then mark 
the associated capability as enabled
 or disabled.  We could also use a different kind of probing here 
in a dynamic fashion, where we try to do
 HWOL and if it fails X times we don’t try again unless we detect 
the port has been reconfigured,
 for example, in case the capability check is not possible or not 
implemented yet.




--yliu
Disclaimer: This email and any files transmitted with it may contain 
confidential information intended for the addressee(s) only. The information is 
not to be surrendered or copied to unauthorized persons. If you have received 
this communication in error, please notify the sender immediately and delete 
this e-mail from your system.


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

Re: [ovs-dev] [PATCH] dpif-netdev: Fix a zero-rate bug for meter

2017-09-27 Thread Andy Zhou 
On Wed, Sep 27, 2017 at 9:23 AM, Ali Volkan Atli
 wrote:
> From 23bc166eecd6e4db7b55720cdd780012df62a0cc Mon Sep 17 00:00:00 2001
> From: Ali Volkan ATLI 
> Date: Wed, 27 Sep 2017 18:33:57 +0300
> Subject: [PATCH] dpif-netdev: Fix a zero-rate bug for meter
>
> Open vSwitch daemon crashes (by receiving signal SIGFPE,
> Arithmetic exception) when a controller tries to send
> a meter-mod message with zero rate.
>
> Signed-off-by: Ali Volkan ATLI 

Thanks for the fix! Pushed to master with some minor style
adjustments.  Also back ported to branch 2.8.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [merge native tunneling and patch port 1/7] ofproto-dpif: Unfreeze within clone

2017-09-27 Thread Andy Zhou 
On Thu, Sep 21, 2017 at 9:44 AM, Greg Rose  wrote:
> On 09/12/2017 12:49 PM, Andy Zhou wrote:
>>
>> When translating actions within open flow clone, actions generated
>> by finish_freezeing() should also be enclosed within the datapath
>> clone netlink encoding.
>>
>> Signed-off-by: Andy Zhou 
>> ---
>>   ofproto/ofproto-dpif-xlate.c | 9 +
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
>> index 9e1f837cb23e..e5ad832d7c47 100644
>> --- a/ofproto/ofproto-dpif-xlate.c
>> +++ b/ofproto/ofproto-dpif-xlate.c
>> @@ -5353,6 +5353,9 @@ compose_clone(struct xlate_ctx *ctx, const struct
>> ofpact_nest *oc)
>>   if (reversible_actions(oc->actions, oc_actions_len)) {
>>   old_flow = ctx->xin->flow;
>>   do_xlate_actions(oc->actions, oc_actions_len, ctx);
>> +if (ctx->freezing) {
>> +finish_freezing(ctx);
>> +}
>>   goto xlate_done;
>>   }
>>   @@ -5372,6 +5375,9 @@ compose_clone(struct xlate_ctx *ctx, const struct
>> ofpact_nest *oc)
>>   offset = nl_msg_start_nested(ctx->odp_actions,
>> OVS_ACTION_ATTR_CLONE);
>>   ac_offset = ctx->odp_actions->size;
>>   do_xlate_actions(oc->actions, oc_actions_len, ctx);
>> +if (ctx->freezing) {
>> +finish_freezing(ctx);
>> +}
>>   nl_msg_end_non_empty_nested(ctx->odp_actions, offset);
>>   goto dp_clone_done;
>>   }
>> @@ -5382,6 +5388,9 @@ compose_clone(struct xlate_ctx *ctx, const struct
>> ofpact_nest *oc)
>>   ac_offset = nl_msg_start_nested(ctx->odp_actions,
>>   OVS_SAMPLE_ATTR_ACTIONS);
>>   do_xlate_actions(oc->actions, oc_actions_len, ctx);
>> +if (ctx->freezing) {
>> +finish_freezing(ctx);
>> +}
>>   if (nl_msg_end_non_empty_nested(ctx->odp_actions, ac_offset)) {
>>   nl_msg_cancel_nested(ctx->odp_actions, offset);
>>   } else {
>>
>
> Tested-by: Greg Rose 
> Reviewed-by: Greg Rose 

Thanks for the review Greg!  I applied your suggestion on patch 6 and pushed
the series to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] dpif-netdev: Fix a zero-rate bug for meter

2017-09-27 Thread Ali Volkan Atli 
>From 23bc166eecd6e4db7b55720cdd780012df62a0cc Mon Sep 17 00:00:00 2001
From: Ali Volkan ATLI 
Date: Wed, 27 Sep 2017 18:33:57 +0300
Subject: [PATCH] dpif-netdev: Fix a zero-rate bug for meter

Open vSwitch daemon crashes (by receiving signal SIGFPE,
Arithmetic exception) when a controller tries to send
a meter-mod message with zero rate.

Signed-off-by: Ali Volkan ATLI 
---
 lib/dpif-netdev.c  | 8 
 ofproto/ofproto-dpif.c | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index cb6cf06..ab52809 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -4276,10 +4276,18 @@ dpif_netdev_meter_set(struct dpif *dpif, 
ofproto_meter_id *meter_id,
 !(config->flags & (OFPMF13_KBPS | OFPMF13_PKTPS))) {
 return EBADF; /* Unsupported flags set */
 }
+
 /* Validate bands */
 if (config->n_bands == 0 || config->n_bands > MAX_BANDS) {
 return EINVAL; /* Too many bands */
 }
+
+/* Validate rates */
+for (i = 0; i < config->n_bands; ++i) {
+if (config->bands[i].rate == 0)
+return EBADRQC; /* rate must be non-zero */
+}
+
 for (i = 0; i < config->n_bands; ++i) {
 switch (config->bands[i].type) {
 case OFPMBT13_DROP:
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 1a8e829..d99dc9d 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -5695,6 +5695,8 @@ 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 */
+return OFPERR_OFPMMFC_BAD_RATE;
 default:
 return OFPERR_OFPMMFC_UNKNOWN;
 }
-- 
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

2017-09-27 Thread nusiddiq 
From: Numan Siddique 

ovn-northd is adding the below logical flow for a disabled logical port (with 
mac M
and IP 'A')

table=6 (lr_in_arp_resolve  ), match=(outport == "lrp-port" && reg0 == 'A'),
action=(eth.dst = 'M'; next;)

In the case of openstack load balancer 'octavia' service, it creates logical
ports 'P1' (M1 IP1) and 'P2' (M2 IP2). It then disables logical port P2 and
adds IP2 to P1 - (M1 IP1 IP2).

When another port tries to reach IP2, it doesn't get delivered to port P1 
because
of the above flow.

Signed-off-by: Numan Siddique 
---
 ovn/northd/ovn-northd.c |  4 
 tests/ovn.at| 21 +
 2 files changed, 25 insertions(+)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 2db238073..c1a76480a 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -5368,6 +5368,10 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
  * resolves the IP address in reg0 into an output port in outport and an
  * Ethernet address in eth.dst. */
 HMAP_FOR_EACH (op, key_node, ports) {
+if (op->nbsp && !lsp_is_enabled(op->nbsp)) {
+continue;
+}
+
 if (op->nbrp) {
 /* This is a logical router port. If next-hop IP address in
  * '[xx]reg0' matches IP address of this router port, then
diff --git a/tests/ovn.at b/tests/ovn.at
index 6c38b973f..490841c63 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -3050,6 +3050,27 @@ echo $packet | ovstest test-ovn expr-to-packets > 
expected
 
 OVN_CHECK_PACKETS([hv2/vif1-tx.pcap], [expected])
 
+AT_CHECK([ovn-sbctl dump-flows | grep lr_in_arp_resolve | \
+grep "reg0 == 172.16.1.2" | wc -l], [0], [1
+])
+
+# Disable the ls2-lp1 port.
+ovn-nbctl --wait=hv set logical_switch_port ls2-lp1 enabled=false
+
+AT_CHECK([ovn-sbctl dump-flows | grep lr_in_arp_resolve | \
+grep "reg0 == 172.16.1.2" | wc -l], [0], [0
+])
+
+# Generate the packet destined for ls2-lp1 and it should not be delivered.
+# Packet to send.
+packet="inport==\"ls1-lp1\" && eth.src==$ls1_lp1_mac && eth.dst==$rp_ls1_mac &&
+ip4 && ip.ttl==64 && ip4.src==$ls1_lp1_ip && ip4.dst==$ls2_lp1_ip &&
+udp && udp.src==53 && udp.dst==4369"
+
+as hv1 ovs-appctl -t ovn-controller inject-pkt "$packet"
+# The 2nd packet sent shound not be received.
+OVN_CHECK_PACKETS([hv2/vif1-tx.pcap], [expected])
+
 OVN_CLEANUP([hv1],[hv2])
 
 AT_CLEANUP
-- 
2.13.5

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

[ovs-dev] [PATCH] ovs-lib: dont't purge corrupted DB

2017-09-27 Thread Matteo Croce 
In ovs-lib there is a function named upgrade_db which tries to convert a
database after OVS {up,down}grades. This function uses ovsdb-tool to
check if the DB needs to be upgraded. If the upgrade fails,
it purges the DB and create an empty one.
ovsdb-tool returns "yes" or "no" to indicate if the DB needs upgrading,
but if the DB is corrupted it returns a list of errors.
Change a condition from "!= no" to "= yes" because in case of DB
corruption upgrade_db would purge the existing DB without writing
anything in the logs.

Signed-off-by: Matteo Croce 
---
 utilities/ovs-lib.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utilities/ovs-lib.in b/utilities/ovs-lib.in
index 8665698bb..ea5a12375 100644
--- a/utilities/ovs-lib.in
+++ b/utilities/ovs-lib.in
@@ -400,7 +400,7 @@ upgrade_db () {
 log_warning_msg "$DB_FILE does not exist"
 install_dir `dirname $DB_FILE`
 create_db "$DB_FILE" "$DB_SCHEMA"
-elif test X"`ovsdb_tool needs-conversion "$DB_FILE" "$DB_SCHEMA"`" != Xno; 
then
+elif test X"`ovsdb_tool needs-conversion "$DB_FILE" "$DB_SCHEMA"`" = Xyes; 
then
 # Back up the old version.
 version=`ovsdb_tool db-version "$DB_FILE"`
 cksum=`ovsdb_tool db-cksum "$DB_FILE" | awk '{print $1}'`
-- 
2.13.5

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

Re: [ovs-dev] [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow

2017-09-27 Thread Finn Christensen 
-Original Message-
From: Yuanhan Liu [mailto:y...@fridaylinux.org]
Sent: 27. september 2017 11:47
To: Finn Christensen 
Cc: Darrell Ball ; d...@openvswitch.org; Chandran
Sugesh ; Simon Horman

Subject: Re: [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow

On Wed, Sep 27, 2017 at 09:12:49AM +, Finn Christensen wrote:
>
> [Darrell] It looks fine; of course, if we could drop dependencies on 
cap
> probe, it would be ideal (.
>
>
> [Finn]
> From a Napatech point of view, we would definitely want to use the
> RTE_FLOW_ACTION_TYPE_RSS if it were implement. It definitely makes
> good sense to me. I have 2 reasons for this:
> 1. It would fit nicely into the way Napatech does flow programming in
> nic 2. We would be fully RSS controlled through OVS Furthermore,
> Future RSS splitting on a per megaflow basis will be possible.
> IMO the "pure_mark_cap_probed" function is a temp work-around to
make it work.
> The RSS seems to be a solution to the queue problem.

Finn, that's really good to know! I do agree without this probe, it makes 
the
code simpler and cleaner.

Few questions though. Have Napatech already implemented rss action? If
not, what's the plan? 

[Finn]
Our nic handles rss on a per flow basis, but we have not yet used rte rss 
action 
for OVS. In OVS we simply handles RSS config outside it.
The full control of rss through OVS is better though.

And are you okay with following code?

add_mark_action();
add_rss_action_unconditionally();

flow = rte_create_flow(...);
if (!flow)
return -1;

That is, no probes, no feedbacks. If it failed, it just failed (flow 
offload then
is just skipped).

[Finn]
Yes, we can easily make this work. Good suggestion!


But I do think some feedbacks are necessary. If we know the rte_flow cap
in the begnning, we could simply disable the flow offload for a specific 
port
if we know it doesn't have offload ability. This would avoid the repeat
effort of trying to do hw offload completely.

[Finn]
This seems to be a good idea.


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

Re: [ovs-dev] [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow

2017-09-27 Thread Yuanhan Liu 
On Wed, Sep 27, 2017 at 09:12:49AM +, Finn Christensen wrote:
> 
> [Darrell] It looks fine; of course, if we could drop dependencies on cap
> probe, it would be ideal (.
> 
> 
> [Finn]
> From a Napatech point of view, we would definitely want to use the
> RTE_FLOW_ACTION_TYPE_RSS if it were implement. It definitely makes good
> sense to me. I have 2 reasons for this:
> 1. It would fit nicely into the way Napatech does flow programming in nic
> 2. We would be fully RSS controlled through OVS
> Furthermore, Future RSS splitting on a per megaflow basis will be possible.
> IMO the "pure_mark_cap_probed" function is a temp work-around to make it work.
> The RSS seems to be a solution to the queue problem.

Finn, that's really good to know! I do agree without this probe, it
makes the code simpler and cleaner.

Few questions though. Have Napatech already implemented rss action? If not,
what's the plan? And are you okay with following code?

add_mark_action();
add_rss_action_unconditionally();

flow = rte_create_flow(...);
if (!flow)
return -1;

That is, no probes, no feedbacks. If it failed, it just failed (flow
offload then is just skipped).

But I do think some feedbacks are necessary. If we know the rte_flow
cap in the begnning, we could simply disable the flow offload for a
specific port if we know it doesn't have offload ability. This would
avoid the repeat effort of trying to do hw offload completely.

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

Re: [ovs-dev] [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow

2017-09-27 Thread Finn Christensen 
-Original Message-
From: Darrell Ball [mailto:db...@vmware.com]
Sent: 27. september 2017 05:54
To: Yuanhan Liu 
Cc: d...@openvswitch.org; Finn Christensen ;
Chandran Sugesh ; Simon Horman

Subject: Re: [PATCH v3 0/9] OVS-DPDK flow offload with rte_flow



On 9/26/17, 8:27 PM, "Yuanhan Liu"  wrote:

On Wed, Sep 27, 2017 at 03:13:33AM +, Darrell Ball wrote:
>
>
> On 9/26/17, 6:25 PM, "Yuanhan Liu"  wrote:
>
> On Tue, Sep 26, 2017 at 09:58:16PM +, Darrell Ball wrote:
> > The second major change is there is a thread introduced to 
do
the real
> > flow offload. This is for diminishing the overhead by hw 
flow
offload
> > installation/deletion at data path. See patch 9 for more 
detailed
info.
> >
> > [Darrell] There might be other options to handle this such as
dividing time
> > to HWOL in a given PMD.
> > Another option to have PMD isolation.
>
> Good to know, though I'm not sure I understand it so far. But it 
can
be
> discussed later. That's also the reason I put it in the last 
patch, so
> that we could easily turn it to another solution, or even simpler 
(just
> remove it).
>
> > In the last discussion, RSS action was suggested to use to 
get rid
of
> > the QUEUE action workaround. Unfortunately, it didn't work. 
The
flow
> > creation failed with MLX5 PMD driver, and that's the only 
driver in
> > DPDK that supports RSS action so far.
> >
> >
> > [Darrell]
> > I wonder if we should take a pause before jumping into the next
version of the code.
>
> I have no objections.
>
> > If workarounds are required in OVS code, then so be it as long 
as
they are not
> > overly disruptive to the existing code and hard to maintain.
> > In the case of RTE_FLOW_ACTION_TYPE_RSS, we might have a
reasonable option
> > to avoid some unpleasant OVS workarounds.
> > This would make a significant difference in the code paths, if 
we
supported it, so
> > we need to be sure as early as possible.
>
> I agree.
>
> > The support needed would be in some drivers and seems
reasonably doable.
> > Moreover, this was discussed in the last dpdk meeting and the
support was
> > indicated as existing?, although I only verified the MLX code,
myself.
>
> From the code point of view, yes, the code was there months ago.
>
> > I had seen the MLX code supporting _RSS action and there are
some checks for
> > supported cases; when you say “it didn't work”, what was the 
issue
?
>
> I actually have met the error months ago, I even debugged it. 
IIRC,
> the error is from libibverbs, when trying to create the hw flow. I
> think I need double-confirm it with our colleague who developed 
this
> feature.
>
> > Let us have a discussion also about the Intel nic side and the
Napatech side.
>
> I think it's not necessary for Napatech, because they can support
> MARK only action.
>
> It is not necessary for Napatech; however to avoid the need to detect
the Napatech
> special (good) case, ‘ideally’ we do the exact same programming even
in Napatech case.

Will following look okay to you (assuming we have the probe ability and
DPDK
has some basic capability feedback)?

if (!pure_mark_cap_probed) {
if (dpdk_rte_flow_has_rss_action_support) {
append_rss_action();
} else {
fail and return;
}
}

/* create flow once, with no retries, if fails, let it fail */
flow = rte_flow_create(...);

I assume that's how the code looks like finally. What do you think?


[Darrell] It looks fine; of course, if we could drop dependencies on cap
probe, it would be ideal (.


[Finn]
From a Napatech point of view, we would definitely want to use the 
RTE_FLOW_ACTION_TYPE_RSS if it were implement. It definitely makes good
sense to me. I have 2 reasons for this: 
1. It would fit nicely into the way Napatech does flow programming in nic
2. We would be fully RSS controlled through OVS
Furthermore,

Re: [ovs-dev] [PATCH V2 3/4] tc: Add header rewrite using tc pedit action

2017-09-27 Thread Simon Horman 
On Mon, Sep 25, 2017 at 04:31:42PM +0300, Paul Blakey wrote:
> 
> 
> On 18/09/2017 18:01, Simon Horman wrote:
> >On Mon, Sep 18, 2017 at 07:16:03AM +0300, Roi Dayan wrote:
> >>From: Paul Blakey 
> >>
> >>To be later used to implement ovs action set offloading.
> >>
> >>Signed-off-by: Paul Blakey 
> >>Reviewed-by: Roi Dayan 
> >>---
> >>  lib/tc.c | 372 
> >> ++-
> >>  lib/tc.h |  16 +++
> >>  2 files changed, 385 insertions(+), 3 deletions(-)
> >>
> >>diff --git a/lib/tc.c b/lib/tc.c
> >>index c9cada2..743b2ee 100644
> >>--- a/lib/tc.c
> >>+++ b/lib/tc.c
> >>@@ -21,8 +21,10 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >>+#include 
> >>  #include 
> >>  #include 
> >>+#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>@@ -33,11 +35,14 @@
> >>  #include "netlink-socket.h"
> >>  #include "netlink.h"
> >>  #include "openvswitch/ofpbuf.h"
> >>+#include "openvswitch/util.h"
> >>  #include "openvswitch/vlog.h"
> >>  #include "packets.h"
> >>  #include "timeval.h"
> >>  #include "unaligned.h"
> >>+#define MAX_PEDIT_OFFSETS 8
> >
> >Why 8?
> We don't expect anything more right now (ipv6 src/dst rewrite requires 8
> pedits iirc). I can't think of a larger use case, maybe ipv6 + macs if
> that's makes sens. do you suggest we increase it? to what?

It seems strange to me to place a somewhat arbitrary small limit
when none exists in the pedit API being used. I would at prefer if
it was at least a bigger, say 16 or 32.

> >>  VLOG_DEFINE_THIS_MODULE(tc);
> >>  static struct vlog_rate_limit error_rl = VLOG_RATE_LIMIT_INIT(60, 5);
> >>@@ -50,6 +55,82 @@ enum tc_offload_policy {
> >>  static enum tc_offload_policy tc_policy = TC_POLICY_NONE;
> >>+struct tc_pedit_key_ex {
> >>+enum pedit_header_type htype;
> >>+enum pedit_cmd cmd;
> >>+};
> >>+
> >>+struct flower_key_to_pedit {
> >>+enum pedit_header_type htype;
> >>+int flower_offset;
> >>+int offset;
> >>+int size;
> >>+};
> >>+
> >>+static struct flower_key_to_pedit flower_pedit_map[] = {
> >>+{
> >>+TCA_PEDIT_KEY_EX_HDR_TYPE_IP4,
> >>+12,
> >>+offsetof(struct tc_flower_key, ipv4.ipv4_src),
> >>+MEMBER_SIZEOF(struct tc_flower_key, ipv4.ipv4_src)
> >>+}, {
> >>+TCA_PEDIT_KEY_EX_HDR_TYPE_IP4,
> >>+16,
> >>+offsetof(struct tc_flower_key, ipv4.ipv4_dst),
> >>+MEMBER_SIZEOF(struct tc_flower_key, ipv4.ipv4_dst)
> >>+}, {
> >>+TCA_PEDIT_KEY_EX_HDR_TYPE_IP4,
> >>+8,
> >>+offsetof(struct tc_flower_key, ipv4.rewrite_ttl),
> >>+MEMBER_SIZEOF(struct tc_flower_key, ipv4.rewrite_ttl)
> >>+}, {
> >>+TCA_PEDIT_KEY_EX_HDR_TYPE_IP6,
> >>+8,
> >>+offsetof(struct tc_flower_key, ipv6.ipv6_src),
> >>+MEMBER_SIZEOF(struct tc_flower_key, ipv6.ipv6_src)
> >>+}, {
> >>+TCA_PEDIT_KEY_EX_HDR_TYPE_IP6,
> >>+24,
> >>+offsetof(struct tc_flower_key, ipv6.ipv6_dst),
> >>+MEMBER_SIZEOF(struct tc_flower_key, ipv6.ipv6_dst)
> >>+}, {
> >>+TCA_PEDIT_KEY_EX_HDR_TYPE_ETH,
> >>+6,
> >>+offsetof(struct tc_flower_key, src_mac),
> >>+MEMBER_SIZEOF(struct tc_flower_key, src_mac)
> >>+}, {
> >>+TCA_PEDIT_KEY_EX_HDR_TYPE_ETH,
> >>+0,
> >>+offsetof(struct tc_flower_key, dst_mac),
> >>+MEMBER_SIZEOF(struct tc_flower_key, dst_mac)
> >>+}, {
> >>+TCA_PEDIT_KEY_EX_HDR_TYPE_ETH,
> >>+12,
> >>+offsetof(struct tc_flower_key, eth_type),
> >>+MEMBER_SIZEOF(struct tc_flower_key, eth_type)
> >>+}, {
> >>+TCA_PEDIT_KEY_EX_HDR_TYPE_TCP,
> >>+0,
> >>+offsetof(struct tc_flower_key, tcp_src),
> >>+MEMBER_SIZEOF(struct tc_flower_key, tcp_src)
> >>+}, {
> >>+TCA_PEDIT_KEY_EX_HDR_TYPE_TCP,
> >>+2,
> >>+offsetof(struct tc_flower_key, tcp_dst),
> >>+MEMBER_SIZEOF(struct tc_flower_key, tcp_dst)
> >>+}, {
> >>+TCA_PEDIT_KEY_EX_HDR_TYPE_UDP,
> >>+0,
> >>+offsetof(struct tc_flower_key, udp_src),
> >>+MEMBER_SIZEOF(struct tc_flower_key, udp_src)
> >>+}, {
> >>+TCA_PEDIT_KEY_EX_HDR_TYPE_UDP,
> >>+2,
> >>+offsetof(struct tc_flower_key, udp_dst),
> >>+MEMBER_SIZEOF(struct tc_flower_key, udp_dst)
> >>+},
> >>+};
> >>+
> >>  struct tcmsg *
> >>  tc_make_request(int ifindex, int type, unsigned int flags,
> >>  struct ofpbuf *request)
> >>@@ -365,6 +446,96 @@ nl_parse_flower_ip(struct nlattr **attrs, struct 
> >>tc_flower *flower) {
> >>  }
> >>  }
> >>+static const struct nl_policy pedit_policy[] = {
> >>+[TCA_PEDIT_PARMS_EX] = { .type = NL_A_UNSPEC,
> >>+ .min_len = sizeof(struct tc_pedit),
> >>+ .optional = false, },
> >>+[TCA_PEDIT_KEYS_EX]   =

Re: [ovs-dev] [PATCH V2 4/4] netdev-tc-offloads: Add support for action set

2017-09-27 Thread Simon Horman 
On Mon, Sep 25, 2017 at 05:48:49PM +0300, Paul Blakey wrote:
> 
> 
> On 18/09/2017 18:05, Simon Horman wrote:
> >On Mon, Sep 18, 2017 at 07:16:04AM +0300, Roi Dayan wrote:
> >>From: Paul Blakey 
> >>
> >>Implement support for offloading ovs action set using
> >>tc header rewrite action.
> >>
> >>Signed-off-by: Paul Blakey 
> >>Reviewed-by: Roi Dayan 
> >>---
> >>  lib/netdev-tc-offloads.c | 201 
> >> +--
> >>  1 file changed, 195 insertions(+), 6 deletions(-)
> >>
> >>diff --git a/lib/netdev-tc-offloads.c b/lib/netdev-tc-offloads.c
> >>index 3c145c2..4044a77 100644
> >>--- a/lib/netdev-tc-offloads.c
> >>+++ b/lib/netdev-tc-offloads.c
> >>@@ -27,11 +27,13 @@
> >>  #include "openvswitch/ofpbuf.h"
> >>  #include "openvswitch/thread.h"
> >>  #include "openvswitch/types.h"
> >>+#include "openvswitch/util.h"
> >>  #include "openvswitch/vlog.h"
> >>  #include "netdev-linux.h"
> >>  #include "netlink.h"
> >>  #include "netlink-socket.h"
> >>  #include "odp-netlink.h"
> >>+#include "odp-util.h"
> >>  #include "tc.h"
> >>  #include "unaligned.h"
> >>  #include "util.h"
> >>@@ -41,6 +43,76 @@ VLOG_DEFINE_THIS_MODULE(netdev_tc_offloads);
> >>  static struct vlog_rate_limit error_rl = VLOG_RATE_LIMIT_INIT(60, 5);
> >>  static struct hmap ufid_tc = HMAP_INITIALIZER(_tc);
> >>+
> >>+struct netlink_field {
> >>+int offset;
> >>+int flower_offset;
> >>+int size;
> >>+};
> >>+
> >>+static struct netlink_field set_flower_map[][3] = {
> >>+[OVS_KEY_ATTR_IPV4] = {
> >>+{ offsetof(struct ovs_key_ipv4, ipv4_src),
> >>+  offsetof(struct tc_flower_key, ipv4.ipv4_src),
> >>+  MEMBER_SIZEOF(struct tc_flower_key, ipv4.ipv4_src)
> >>+},
> >>+{ offsetof(struct ovs_key_ipv4, ipv4_dst),
> >>+  offsetof(struct tc_flower_key, ipv4.ipv4_dst),
> >>+  MEMBER_SIZEOF(struct tc_flower_key, ipv4.ipv4_dst)
> >>+},
> >>+{ offsetof(struct ovs_key_ipv4, ipv4_ttl),
> >>+  offsetof(struct tc_flower_key, ipv4.rewrite_ttl),
> >>+  MEMBER_SIZEOF(struct tc_flower_key, ipv4.rewrite_ttl)
> >>+},
> >>+},
> >>+[OVS_KEY_ATTR_IPV6] = {
> >>+{ offsetof(struct ovs_key_ipv6, ipv6_src),
> >>+  offsetof(struct tc_flower_key, ipv6.ipv6_src),
> >>+  MEMBER_SIZEOF(struct tc_flower_key, ipv6.ipv6_src)
> >>+},
> >>+{ offsetof(struct ovs_key_ipv6, ipv6_dst),
> >>+  offsetof(struct tc_flower_key, ipv6.ipv6_dst),
> >>+  MEMBER_SIZEOF(struct tc_flower_key, ipv6.ipv6_dst)
> >>+},
> >>+},
> >>+[OVS_KEY_ATTR_ETHERNET] = {
> >>+{ offsetof(struct ovs_key_ethernet, eth_src),
> >>+  offsetof(struct tc_flower_key, src_mac),
> >>+  MEMBER_SIZEOF(struct tc_flower_key, src_mac)
> >>+},
> >>+{ offsetof(struct ovs_key_ethernet, eth_dst),
> >>+  offsetof(struct tc_flower_key, dst_mac),
> >>+  MEMBER_SIZEOF(struct tc_flower_key, dst_mac)
> >>+},
> >>+},
> >>+[OVS_KEY_ATTR_ETHERTYPE] = {
> >>+{ 0,
> >>+  offsetof(struct tc_flower_key, eth_type),
> >>+  MEMBER_SIZEOF(struct tc_flower_key, eth_type)
> >>+},
> >>+},
> >>+[OVS_KEY_ATTR_TCP] = {
> >>+{ offsetof(struct ovs_key_tcp, tcp_src),
> >>+  offsetof(struct tc_flower_key, tcp_src),
> >>+  MEMBER_SIZEOF(struct tc_flower_key, tcp_src)
> >>+},
> >>+{ offsetof(struct ovs_key_tcp, tcp_dst),
> >>+  offsetof(struct tc_flower_key, tcp_dst),
> >>+  MEMBER_SIZEOF(struct tc_flower_key, tcp_dst)
> >>+},
> >>+},
> >>+[OVS_KEY_ATTR_UDP] = {
> >>+{ offsetof(struct ovs_key_udp, udp_src),
> >>+  offsetof(struct tc_flower_key, udp_src),
> >>+  MEMBER_SIZEOF(struct tc_flower_key, udp_src)
> >>+},
> >>+{ offsetof(struct ovs_key_udp, udp_dst),
> >>+  offsetof(struct tc_flower_key, udp_dst),
> >>+  MEMBER_SIZEOF(struct tc_flower_key, udp_dst)
> >>+},
> >>+},
> >>+};
> >
> >Do you have any plans to add the following?
> >
> > OVS_KEY_ATTR_ICMP
> > OVS_KEY_ATTR_ICMPV6
> > OVS_KEY_ATTR_ARP
> > OVS_KEY_ATTR_ND
> > OVS_KEY_ATTR_SCTP
> > OVS_KEY_ATTR_TCP_FLAGS
> >
> >...
> >
> 
> 
> Yes, if pedit supports them (which I think it should). do you want it me to
> add it to this patchset, for us it would be faster to add those later after
> this is accepted as we have some inside testsuite for the currently
> supported ones and will need to come up with new ones for these.

Later is fine by me.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] From Mrs.Maryam.

2017-09-27 Thread mrsmaryam tukur 
Dearest One,
It is my pleasure to write you after much consideration since can not be able 
to see you face to face, at first.being the wife of late Dr Ken B.TUKUR, from 
ZULU in republic of SOUTH AFRICA (S.A) Iam Mrs MARYAM KEN TUKUR and my husband 
was a limited liability cocoa and Gold merchant in South-Africa .

Before his death after his business trip to Abidjan-Coted'ivoire west -Africa 
to negotiate on a cocoa business on 6th of February 2004 a week after he came 
back from Abidjan,he was assassinated with my first son by unknown assassins 
which my son dead instantly but my husband dead two week after in the hospital 
, on that faithful afternoon I didn't know that my husband is going to leave me 
after I lost my jovial and intelligent son. But before he gave up the ghost it 
was as if he knew hewas going to die .

He KEN TUKUR my lovely husband ( may his soul rest in perfectpeace ) he 
disclosed to me that he deposited the sum of USD$ 10,000,000.00 million dollars 
with a bank in Abidjan -Cote d'ivoirethat the money was meant for his cocoa 
business he wanted toinvest in Abidjan-Cote d'ivoire.  Though according to my 
husband he told me to take care of the money for the future sake of his other 
children , so he instructed me to seek for a life time investment abroad .

As a result of this assassination we cannot stay in South-Africa now .I have 
succeeded in locating and confirming the existence of the fund in Abidjan -Cote 
d'ivoire and also with mosthonest and confidentiality. I am soliciting your 
assistance to help me on how to transfer this money from the bank in Abidjan 
Cote d'ivoire to your bank account abroad so that we will invest in a lucrative 
business in your country . you should understand that this fund is our only 
hope . I am waiting anxiously to hear from you so that we can discuss the 
modalities of this transaction.

Although I and my remaining Son Kevin Jr. have decided to give you a 10% 
interest from the total sumof $10million . Please kingly contact me on the 
above email address immediately for more discussion .
Thank you and God bless You .
Best regards
Mrs.Maryam.


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