[ovs-dev] [PATCH v2] ovn-controller: Fix duplicated flows in table 32.

[Han Zhou]

In commit 475f0a2c it introduced a priority 150 flow for filtering
the sending of traffic received from vxlan tunnels back out tunnels.
However, it added the flow for every remote port processing, which
results in continuous logs about duplicated flows. We only need to
install this flow once per physical_run() loop iteration.

Signed-off-by: Han Zhou 
Acked-by: Darrell Ball 
---

Notes:
v1 -> v2: update commit message according to Darrell's comments.

 ovn/controller/physical.c | 47 ---
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index 48adb78..3b653dd 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -465,33 +465,16 @@ consider_port_binding(enum mf_field_id mff_ovn_geneve,
 } else {
 /* Remote port connected by tunnel */
 
-/* Table 32, priority 150 and 100.
+/* Table 32, priority 100.
  * ===
  *
- * Priority 150 is for packets received from a VXLAN tunnel
- * which get resubmitted to OFTABLE_LOG_INGRESS_PIPELINE due to
- * lack of needed metadata in VXLAN, explicitly skip sending
- * back out any tunnels and resubmit to table 33 for local
- * delivery.
- *
- * Priority 100 is for all other traffic which need to be sent
- * to a remote hypervisor.  Each flow matches an output port
- * that includes a logical port on a remote hypervisor, and
- * tunnels the packet to that hypervisor.
+ * Priority 100 is for traffic that needs to be sent to a remote
+ * hypervisor.  Each flow matches an output port that includes a
+ * logical port on a remote hypervisor, and tunnels the packet to
+ * that hypervisor.
  */
 match_init_catchall();
 ofpbuf_clear(ofpacts_p);
-match_set_reg_masked(, MFF_LOG_FLAGS - MFF_REG0,
- MLF_RCV_FROM_VXLAN, MLF_RCV_FROM_VXLAN);
-
-/* Resubmit to table 33. */
-put_resubmit(OFTABLE_LOCAL_OUTPUT, ofpacts_p);
-ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 150, ,
-ofpacts_p);
-
-
-match_init_catchall();
-ofpbuf_clear(ofpacts_p);
 
 /* Match MFF_LOG_DATAPATH, MFF_LOG_OUTPORT. */
 match_set_metadata(, htonll(dp_key));
@@ -870,12 +853,30 @@ physical_run(struct controller_ctx *ctx, enum mf_field_id 
mff_ovn_geneve,
 }
 }
 
+/* Table 32, priority 150.
+ * ===
+ *
+ * Priority 150 is for packets received from a VXLAN tunnel
+ * which get resubmitted to OFTABLE_LOG_INGRESS_PIPELINE due to
+ * lack of needed metadata in VXLAN, explicitly skip sending
+ * back out any tunnels and resubmit to table 33 for local
+ * delivery.
+ */
+struct match match;
+match_init_catchall();
+ofpbuf_clear();
+match_set_reg_masked(, MFF_LOG_FLAGS - MFF_REG0,
+ MLF_RCV_FROM_VXLAN, MLF_RCV_FROM_VXLAN);
+
+/* Resubmit to table 33. */
+put_resubmit(OFTABLE_LOCAL_OUTPUT, );
+ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 150, , );
+
 /* Table 32, Priority 0.
  * ===
  *
  * Resubmit packets that are not directed at tunnels or part of a
  * multicast group to the local output table. */
-struct match match;
 match_init_catchall();
 ofpbuf_clear();
 put_resubmit(OFTABLE_LOCAL_OUTPUT, );
-- 
2.1.0

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

Re: [ovs-dev] [PATCH] ovn-controller: Fix duplicated flows in table 32.

[Darrell Ball]

From: Han Zhou 
Date: Tuesday, December 13, 2016 at 10:28 PM
To: Darrell Ball 
Cc: "d...@openvswitch.org" 
Subject: Re: [ovs-dev] [PATCH] ovn-controller: Fix duplicated flows in table 32.

Hi Darrell,
The duplicated flows are detected and filtered by the logic you mentioned, and 
continuous INFO logs printed (with ratelimiting). I think I should update the 
commit message a little bit. It is not "failures", but just the unexpected INFO 
logs. Sorry for the confusion.
Could you also comment if this change make sense?

Thanks,
Han

Hi Han

There are two levels of filtering duplicates flows in the ovn specific code.

Another part of the commit message seems to need updating as well.

“In commit 475f0a2c it introduced a priority 150 flow for skipping
VXLAN traffic.”

should be changed to

“In commit 475f0a2c it introduced a priority 150 flow for filtering the sending 
of
traffic received from vxlan tunnels back out tunnels.”


We only need to attempt to install this flow once per physical_run() loop
iteration, which is what it looks like your patch is doing.
I’ll test it in the morning to be sure.


On Tue, Dec 13, 2016 at 9:24 PM, Darrell Ball 
> wrote:


On 12/13/16, 8:18 PM, 
"ovs-dev-boun...@openvswitch.org on 
behalf of Han Zhou" 
 on 
behalf of zhou...@gmail.com> wrote:

In commit 475f0a2c it introduced a priority 150 flow for skipping
VXLAN traffic. However, it added the flow for every remote port
processing, which results in duplicated flows and failures seen
in ovn-controller logs.

Thanks for working on this.
I see the following logs in ovn-controller:

2016-12-14T05:10:31.004Z|01685|ofctrl|INFO|dropping duplicate flow: 
table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)

which implies that the redundant attempts to add the same flow is being 
filtered by the below
duplicate check in ofctrl_add_flow(..)
Is the duplicate flow check working in all cases ?
or
Is the check for duplicates failing in some instances and duplicate flows
are really created or leaked somehow ?

void
ofctrl_add_flow(struct hmap *desired_flows,
uint8_t table_id, uint16_t priority,
const struct match *match, const struct ofpbuf *actions)
{
struct ovn_flow *f = xmalloc(sizeof *f);
f->table_id = table_id;
f->priority = priority;
f->match = *match;
f->ofpacts = xmemdup(actions->data, actions->size);
f->ofpacts_len = actions->size;
f->hmap_node.hash = ovn_flow_hash(f);

if (ovn_flow_lookup(desired_flows, f)) {
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 5);
if (!VLOG_DROP_INFO()) {
char *s = ovn_flow_to_string(f);
VLOG_INFO("dropping duplicate flow: %s", s);
free(s);
}

ovn_flow_destroy(f);
return;
}


 This fix moves the logic to global so that
the flow is added only once.

Signed-off-by: Han Zhou >
---
 ovn/controller/physical.c | 47 
---
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index 48adb78..3b653dd 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -465,33 +465,16 @@ consider_port_binding(enum mf_field_id mff_ovn_geneve,
 } else {
 /* Remote port connected by tunnel */

-/* Table 32, priority 150 and 100.
+/* Table 32, priority 100.
  * ===
  *
- * Priority 150 is for packets received from a VXLAN tunnel
- * which get resubmitted to OFTABLE_LOG_INGRESS_PIPELINE due to
- * lack of needed metadata in VXLAN, explicitly skip sending
- * back out any tunnels and resubmit to table 33 for local
- * delivery.
- *
- * Priority 100 is for all other traffic which need to be sent
- * to a remote hypervisor.  Each flow matches an output port
- * that includes a logical port on a remote hypervisor, and
- * tunnels the packet to that hypervisor.
+ * Priority 100 is for traffic that needs to be sent to a remote
+ * hypervisor.  Each flow matches an output port that includes a
+ * logical port on a remote hypervisor, and tunnels the packet to
+ * that hypervisor.
  */
 match_init_catchall();
 ofpbuf_clear(ofpacts_p);
-match_set_reg_masked(, MFF_LOG_FLAGS - MFF_REG0,
- MLF_RCV_FROM_VXLAN, MLF_RCV_FROM_VXLAN);
-
-/* Resubmit to table 33. */

Re: [ovs-dev] [PATCH] ovn-controller: Fix duplicated flows in table 32.

[Darrell Ball]

On 12/13/16, 8:18 PM, "ovs-dev-boun...@openvswitch.org on behalf of Han Zhou" 
 wrote:

In commit 475f0a2c it introduced a priority 150 flow for skipping
VXLAN traffic. However, it added the flow for every remote port
processing, which results in duplicated flows and failures seen
in ovn-controller logs.

Thanks for working on this.
I see the following logs in ovn-controller:

2016-12-14T05:10:31.004Z|01685|ofctrl|INFO|dropping duplicate flow: 
table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)

which implies that the redundant attempts to add the same flow is being 
filtered by the below
duplicate check in ofctrl_add_flow(..)
Is the duplicate flow check working in all cases ?
or
Is the check for duplicates failing in some instances and duplicate flows
are really created or leaked somehow ? 

void
ofctrl_add_flow(struct hmap *desired_flows,
uint8_t table_id, uint16_t priority,
const struct match *match, const struct ofpbuf *actions)
{
struct ovn_flow *f = xmalloc(sizeof *f);
f->table_id = table_id;
f->priority = priority;
f->match = *match;
f->ofpacts = xmemdup(actions->data, actions->size);
f->ofpacts_len = actions->size;
f->hmap_node.hash = ovn_flow_hash(f);

if (ovn_flow_lookup(desired_flows, f)) {
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 5);
if (!VLOG_DROP_INFO()) {
char *s = ovn_flow_to_string(f);
VLOG_INFO("dropping duplicate flow: %s", s);
free(s);
}

ovn_flow_destroy(f);
return;
}


 This fix moves the logic to global so that
the flow is added only once.

Signed-off-by: Han Zhou 
---
 ovn/controller/physical.c | 47 
---
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index 48adb78..3b653dd 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -465,33 +465,16 @@ consider_port_binding(enum mf_field_id mff_ovn_geneve,
 } else {
 /* Remote port connected by tunnel */
 
-/* Table 32, priority 150 and 100.
+/* Table 32, priority 100.
  * ===
  *
- * Priority 150 is for packets received from a VXLAN tunnel
- * which get resubmitted to OFTABLE_LOG_INGRESS_PIPELINE due to
- * lack of needed metadata in VXLAN, explicitly skip sending
- * back out any tunnels and resubmit to table 33 for local
- * delivery.
- *
- * Priority 100 is for all other traffic which need to be sent
- * to a remote hypervisor.  Each flow matches an output port
- * that includes a logical port on a remote hypervisor, and
- * tunnels the packet to that hypervisor.
+ * Priority 100 is for traffic that needs to be sent to a remote
+ * hypervisor.  Each flow matches an output port that includes a
+ * logical port on a remote hypervisor, and tunnels the packet to
+ * that hypervisor.
  */
 match_init_catchall();
 ofpbuf_clear(ofpacts_p);
-match_set_reg_masked(, MFF_LOG_FLAGS - MFF_REG0,
- MLF_RCV_FROM_VXLAN, MLF_RCV_FROM_VXLAN);
-
-/* Resubmit to table 33. */
-put_resubmit(OFTABLE_LOCAL_OUTPUT, ofpacts_p);
-ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 150, ,
-ofpacts_p);
-
-
-match_init_catchall();
-ofpbuf_clear(ofpacts_p);
 
 /* Match MFF_LOG_DATAPATH, MFF_LOG_OUTPORT. */
 match_set_metadata(, htonll(dp_key));
@@ -870,12 +853,30 @@ physical_run(struct controller_ctx *ctx, enum 
mf_field_id mff_ovn_geneve,
 }
 }
 
+/* Table 32, priority 150.
+ * ===
+ *
+ * Priority 150 is for packets received from a VXLAN tunnel
+ * which get resubmitted to OFTABLE_LOG_INGRESS_PIPELINE due to
+ * lack of needed metadata in VXLAN, explicitly skip sending
+ * back out any tunnels and resubmit to table 33 for local
+ * delivery.
+ */
+struct match match;
+match_init_catchall();
+ofpbuf_clear();
+match_set_reg_masked(, MFF_LOG_FLAGS - MFF_REG0,
+ MLF_RCV_FROM_VXLAN, MLF_RCV_FROM_VXLAN);
+
+/* Resubmit to table 33. */
+put_resubmit(OFTABLE_LOCAL_OUTPUT, );
+ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 150, , 
);
+
 /* Table 32, Priority 0.
  * ===
  *
  * Resubmit 

Re: [ovs-dev] [PATCH 3/3] netdev-dpdk: Add support for virtual DPDK PMDs (vdevs)

[Daniele Di Proietto]

Not super important, but can we support detaching vdevs?

I'd like to see an example of usage with af_packet devices on the
documentation, but I can add that later.

Thanks,

Daniele

2016-12-13 11:22 GMT-08:00 Ciara Loftus :
> Prior to this commit, the 'dpdk' port type could only be used for
> physical DPDK devices. Now, virtual devices (or 'vdevs') are supported.
> 'vdev' devices are those which use virtual DPDK Poll Mode Drivers eg.
> null, pcap. To add a DPDK vdev, a valid 'dpdk-devargs' must be set for
> the given dpdk port. The format expected is 'eth_' where
> 'x' is a number between 0 and RTE_MAX_ETHPORTS -1.
>
> For example to add a port that uses the 'null' DPDK PMD driver:
>
> ovs-vsctl set Interface null0 options:dpdk-devargs=eth_null0
>
> Not all DPDK vdevs have been verified to work at this point in time.
>
> Signed-off-by: Ciara Loftus 
> ---
>  Documentation/intro/install/dpdk-advanced.rst | 22 ++
>  NEWS  |  1 +
>  lib/netdev-dpdk.c | 21 +
>  vswitchd/vswitch.xml  |  9 +++--
>  4 files changed, 51 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/intro/install/dpdk-advanced.rst 
> b/Documentation/intro/install/dpdk-advanced.rst
> index 858ff98..0384330 100644
> --- a/Documentation/intro/install/dpdk-advanced.rst
> +++ b/Documentation/intro/install/dpdk-advanced.rst
> @@ -956,6 +956,28 @@ This feature is not supported with VFIO and could not 
> work with some NICs.
>  For more information please refer to the `DPDK Port Hotplug Framework
>  
> `__.
>
> +Vdev Support
> +
> +
> +DPDK provides drivers for both physical and virtual devices. Physical DPDK
> +devices are added to OVS by specifying a valid PCI address in 'dpdk-devargs'.
> +Virtual DPDK devices which do not have PCI addresses can be added using a
> +different format for 'dpdk-devargs'.
> +
> +Typically, the format expected is 'eth_' where 'x' is a
> +number between 0 and RTE_MAX_ETHPORTS -1 (31).
> +
> +For example to add a dpdk port that uses the 'null' DPDK PMD driver:
> +
> +   $ ovs-vsctl add-port br0 null0 -- set Interface null0 type=dpdk \
> +   options:dpdk-devargs=eth_null0
> +
> +More information on the different types of virtual DPDK PMDs can be found in
> +the `DPDK documentation
> +`__.
> +
> +Note: Not all DPDK virtual PMD drivers have been tested and verified to work.
> +
>  Bug Reporting
>  -
>
> diff --git a/NEWS b/NEWS
> index a62a7a4..2215066 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -44,6 +44,7 @@ Post-v2.6.0
>   * Port Hotplug is now supported.
>   * DPDK physical ports can now have arbitrary names. The PCI address of
> the device must be set using the 'dpdk-devargs' option.
> + * Virtual DPDK Poll Mode Driver (vdev PMD) support.
> - Fedora packaging:
>   * A package upgrade does not automatically restart OVS service.
> - ovs-vswitchd/ovs-vsctl:
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index 07a99c7..872ce63 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -1124,6 +1124,24 @@ netdev_dpdk_process_pdevargs(struct netdev_dpdk *dev, 
> const char *devargs,
>  return 0;
>  }
>
> +static int
> +netdev_dpdk_process_vdevargs(struct netdev_dpdk *dev, const char *devargs)
> +{
> +uint8_t port_id;
> +
> +if (!rte_eth_dev_attach(devargs, _id)) {
> +/* Attach successful */
> +VLOG_INFO("Port '%s' attached to DPDK as virtual device",
> +  dev->up.name);
> +dev->port_id = port_id;
> +} else {
> +/* Attach unsuccessful */
> +return -1;
> +}
> +
> +return 0;
> +}
> +
>  static void
>  netdev_dpdk_process_devargs(struct netdev_dpdk *dev)
>  OVS_REQUIRES(dev->mutex)
> @@ -1134,6 +1152,9 @@ netdev_dpdk_process_devargs(struct netdev_dpdk *dev)
>  if (!eal_parse_pci_DomBDF(dev->requested_devargs, )) {
>  /* Valid PCI address format detected - configure physical device */
>  err = netdev_dpdk_process_pdevargs(dev, dev->requested_devargs, 
> );
> +} else {
> +/* Not a PCI device format - configure virtual device (vdev) */
> +err = netdev_dpdk_process_vdevargs(dev, dev->requested_devargs);
>  }
>
>  if (!err) {
> diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
> index 23ab469..7c6f229 100644
> --- a/vswitchd/vswitch.xml
> +++ b/vswitchd/vswitch.xml
> @@ -2306,8 +2306,13 @@
>type='{"type": "string"}'>
>  
> -  Specifies the PCI address of a physical dpdk device.
> -  Only supported by 'dpdk' devices.
> +  Specifies the PCI address associated with the port for physical
> +  devices, or the virtual driver to be used for the port when a 

Re: [ovs-dev] [PATCH 2/3] netdev-dpdk: Arbitrary 'dpdk' port naming

[Daniele Di Proietto]

I've been playing with this a little and I've come up with an
incremental with these changes:

* Detaching fails if port_id is in use by netdev
* I suggested before to process the arguments in reconfigure().  I
realize now that it's probably better to populate 'port_id' in
set_config() and start the device on reconfigure().  See points below.
* set_config now only allows setting devargs for a new device.  If a
netdev already has devargs it returns failure.  The upper layer will
destroy that netdev and recreate it.  This is useful to handle
duplicates (see point below)
* When we move the port identification from the name column to the
options column, there's nothing that prevents the user from adding two
ports with the same pci address.  This currently causes breakage.  We
should detect duplicates and print a warning.

Other than the diff below I have a couple of more comments:

We're totally breaking backwards compatibility.  I think we should be
more explicit about that in NEWS.

We should update the second unixctl_command_register() argument for
netdev-dpdk/detach to reflect that a pci address is required, not a
port name.

What do you think?

Other than this it looks good to me.  I'd like to test it a little more though

Thanks,

Daniele

---8<---
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index d089491..2d92227 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -355,7 +355,7 @@ struct netdev_dpdk {
 char vhost_id[PATH_MAX];

 /* Device arguments for dpdk ports */
-char dpdk_devargs[DEVARGS_MAX];
+char *devargs;

 /* In dpdk_list. */
 struct ovs_list list_node OVS_GUARDED_BY(dpdk_mutex);
@@ -371,7 +371,6 @@ struct netdev_dpdk {
 int requested_n_rxq;
 int requested_rxq_size;
 int requested_txq_size;
-char requested_devargs[DEVARGS_MAX];

 /* Number of rx/tx descriptors for physical devices */
 int rxq_size;
@@ -975,6 +974,7 @@ netdev_dpdk_destruct(struct netdev *netdev)
 ovs_mutex_lock(>mutex);

 rte_eth_dev_stop(dev->port_id);
+free(dev->devargs);
 free(ovsrcu_get_protected(struct ingress_policer *,
   >ingress_policer));

@@ -1079,6 +1079,21 @@ netdev_dpdk_get_config(const struct netdev
*netdev, struct smap *args)
 return 0;
 }

+static struct netdev_dpdk *
+netdev_dpdk_lookup_by_port_id(int port_id)
+OVS_REQUIRES(dpdk_mutex)
+{
+struct netdev_dpdk *dev;
+
+LIST_FOR_EACH (dev, list_node, _list) {
+if (dev->port_id == port_id) {
+return dev;
+}
+}
+
+return NULL;
+}
+
 static uint8_t
 dpdk_get_port_id_from_pci(struct rte_pci_addr *addr)
 {
@@ -1100,45 +1115,41 @@ dpdk_get_port_id_from_pci(struct rte_pci_addr *addr)
 }

 static int
-netdev_dpdk_process_pdevargs(struct netdev_dpdk *dev, const char *devargs,
- struct rte_pci_addr *addr)
+netdev_dpdk_process_pdevargs(const char *devargs, struct rte_pci_addr *addr)
 {
+uint8_t new_port_id;
+
 /* Search for PCI device in DPDK */
-dev->port_id = dpdk_get_port_id_from_pci(addr);
+new_port_id = dpdk_get_port_id_from_pci(addr);

-if (!rte_eth_dev_is_valid_port(dev->port_id)) {
+if (!rte_eth_dev_is_valid_port(new_port_id)) {
 /* PCI device not found in DPDK, attempt to attach it */
-uint8_t new_port_id;

 if (!rte_eth_dev_attach(devargs, _port_id)) {
 /* Attach successful */
 VLOG_INFO("Device "PCI_PRI_FMT" has been attached to DPDK",
 addr->domain, addr->bus, addr->devid, addr->function);
-dev->port_id = new_port_id;
 } else {
 /* Attach unsuccessful */
 return -1;
 }
 }

-return 0;
+return new_port_id;
 }

-static void
-netdev_dpdk_process_devargs(struct netdev_dpdk *dev)
-OVS_REQUIRES(dev->mutex)
+static int
+netdev_dpdk_process_devargs(const char *devargs)
 {
 struct rte_pci_addr addr;
-int err = -1;
+int new_port_id = -1;

-if (!eal_parse_pci_DomBDF(dev->requested_devargs, )) {
+if (!eal_parse_pci_DomBDF(devargs, )) {
 /* Valid PCI address format detected - configure physical device */
-err = netdev_dpdk_process_pdevargs(dev, dev->requested_devargs, );
+new_port_id = netdev_dpdk_process_pdevargs(devargs, );
 }

-if (!err) {
-strcpy(dev->dpdk_devargs, dev->requested_devargs);
-}
+return new_port_id;
 }

 static void
@@ -1184,6 +1195,7 @@ netdev_dpdk_set_config(struct netdev *netdev,
const struct smap *args)
 const char *new_devargs;
 int err = 0;

+ovs_mutex_lock(_mutex);
 ovs_mutex_lock(>mutex);

 dpdk_set_rxq_config(dev, args);
@@ -1195,6 +1207,42 @@ netdev_dpdk_set_config(struct netdev *netdev,
const struct smap *args)
 NIC_PORT_DEFAULT_TXQ_SIZE,
 >requested_txq_size);

+new_devargs = smap_get(args, "dpdk-devargs");
+
+if (dev->devargs && strcmp(new_devargs, 

Re: [ovs-dev] [PATCH] datapath: enable vxlangpe creation in compat mode

[Yang, Yi]

On Tue, Dec 13, 2016 at 08:41:18PM -0800, Pravin Shelar wrote:
> On Thu, Dec 8, 2016 at 9:41 PM, Yi Yang  wrote:
> >
> > if (vport->dev->flags & IFF_LOOPBACK ||
> > -   vport->dev->type != ARPHRD_ETHER ||
> > +   (vport->dev->type != ARPHRD_ETHER &&
> > +vport->dev->type != ARPHRD_NONE) ||
> 
> OVS out of tree module is not ready for ARPHRD_NONE type of devices
> yet. we have to backport L3 patches from upstream OVS first.

Yeah, I'm working on this, it is almost done, I'll post them once they
are verified.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/3] netdev-dpdk: add hotplug support

[Daniele Di Proietto]

2016-12-13 11:22 GMT-08:00 Ciara Loftus :
> In order to use dpdk ports in ovs they have to be bound to a DPDK
> compatible driver before ovs is started.
>
> This patch adds the possibility to hotplug (or hot-unplug) a device
> after ovs has been started. The implementation adds two appctl commands:
> netdev-dpdk/port-attach and netdev-dpdk/port-detach
>
> After the user attaches a new device, it has to be added to a bridge
> using the add-port command, similarly, before detaching a device,
> it has to be removed using the del-port command.
>
> Signed-off-by: Mauricio Vasquez B 

'response' should be freed in multiple places.

How about calling the commands netdev-dpdk/attach and
netdev-dpdk/detach without the 'port'? I think the 'port' part is
implicit in netdev-dpdk.

Minor: can you add your signoff with your coauthored-by?

> ---
> Changelog:
> * Use xasprintf instead of snprintf when reporting attach/detach errors.
> * Updated format of link in docs to comply with new format.
>
>  Documentation/intro/install/dpdk-advanced.rst | 25 
>  NEWS  |  1 +
>  lib/netdev-dpdk.c | 91 
> +--
>  3 files changed, 111 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/intro/install/dpdk-advanced.rst 
> b/Documentation/intro/install/dpdk-advanced.rst
> index 44d1cd7..42a4af6 100644
> --- a/Documentation/intro/install/dpdk-advanced.rst
> +++ b/Documentation/intro/install/dpdk-advanced.rst
> @@ -932,6 +932,31 @@ validate the suitability of different vSwitch 
> implementations in a telco
>  deployment environment. More information can be found on the `OPNFV wiki
>  `__.
>
> +Port Hotplug
> +
> +
> +OvS supports port hotplugging, it allows to use ports that were not bound
> +to DPDK when vswitchd was started.
> +In order to attach a port, it has to be bound to DPDK using the
> +dpdk_nic_bind.py script:
> +
> +   $ $DPDK_DIR/tools/dpdk_nic_bind.py --bind=igb_uio :01:00.0
> +
> +Then it can be attached to OVS:
> +
> +   $ ovs-appctl netdev-dpdk/port-attach :01:00.0
> +
> +At this point, the user can create a ovs port using the add-port command.
> +
> +It is also possible to detach a port from ovs, the user has to remove the
> +port using the del-port command, then it can be detached using:
> +
> +   $ ovs-appctl netdev-dpdk/port-detach dpdk0
> +
> +This feature is not supported with VFIO and could not work with some NICs.
> +For more information please refer to the `DPDK Port Hotplug Framework
> +`__.
> +
>  Bug Reporting
>  -
>
> diff --git a/NEWS b/NEWS
> index 3a08dbc..b596cf3 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -41,6 +41,7 @@ Post-v2.6.0
>   * New option 'n_rxq_desc' and 'n_txq_desc' fields for DPDK interfaces
> which set the number of rx and tx descriptors to use for the given 
> port.
>   * Support for DPDK v16.11.
> + * Port Hotplug is now supported.
> - Fedora packaging:
>   * A package upgrade does not automatically restart OVS service.
> - ovs-vswitchd/ovs-vsctl:
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index 625f425..677a10c 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -2307,6 +2307,78 @@ netdev_dpdk_set_admin_state(struct unixctl_conn *conn, 
> int argc,
>  unixctl_command_reply(conn, "OK");
>  }
>
> +static void
> +netdev_dpdk_port_attach(struct unixctl_conn *conn, int argc OVS_UNUSED,
> +const char *argv[], void *aux OVS_UNUSED)
> +{
> +int ret;
> +char *response;
> +uint8_t port_id;
> +
> +ovs_mutex_lock(_mutex);
> +
> +ret = rte_eth_dev_attach(argv[1], _id);
> +if (ret < 0) {
> +response = xasprintf("Error attaching device '%s'", argv[1]);
> +ovs_mutex_unlock(_mutex);
> +unixctl_command_reply_error(conn, response);
> +return;
> +}
> +
> +response = xasprintf("Device '%s' has been attached as 'dpdk%d'",
> + argv[1], port_id);
> +
> +ovs_mutex_unlock(_mutex);
> +unixctl_command_reply(conn, response);
> +}
> +
> +static void
> +netdev_dpdk_port_detach(struct unixctl_conn *conn, int argc OVS_UNUSED,
> +const char *argv[], void *aux OVS_UNUSED)
> +{
> +int ret;
> +char *response;
> +unsigned int parsed_port;
> +uint8_t port_id;
> +char devname[RTE_ETH_NAME_MAX_LEN];
> +
> +ovs_mutex_lock(_mutex);
> +
> +ret = dpdk_dev_parse_name(argv[1], "dpdk", _port);
> +if (ret) {
> +response = xasprintf("'%s' is not a valid port", argv[1]);
> +goto error;
> +}
> +
> +port_id = parsed_port;
> +
> +struct netdev *netdev = netdev_from_name(argv[1]);
> +if (netdev) {
> +netdev_close(netdev);
> +

Re: [ovs-dev] assertion failing in commit_set_ipv4_action(), flow->nw_proto != base_flow->nw_proto

[Takashi YAMAMOTO]

On Wed, Dec 14, 2016 at 9:02 AM, Jarno Rajahalme  wrote:

>
> On Dec 13, 2016, at 3:32 PM, Takashi YAMAMOTO  wrote:
>
>
>
> On Tue, Dec 13, 2016 at 6:49 PM, Thomas Morin 
> wrote:
>
>> Hi Jarno,
>>
>> 2016-12-10, Jarno Rajahalme:
>>
>> On Dec 9, 2016, at 7:04 AM, Thomas Morin  wrote:
>>
>>
>> 2016-12-09, Thomas Morin:
>>
>> In the same setup as the one on which the bug was observed, [...]
>>
>>
>> I was confused, I in fact tested the patch (branch-2.5) on a /different/
>> setup as the one on which we hit the bug, using MPLS over a GRE tunnel
>> port, rather than plain MPLS over an eth port.
>> Sorry if any confusion arised... I can test on the first setup if
>> relevant.
>>
>>
>> Maybe the kernel datapath does not support MPLS over a GRE tunnel port.
>> Having ‘dmesg’ output for the test run might reveal why the actions
>> validation fails.
>>
>>
>> The dmesg output was the following:
>>
>> [171295.258939] openvswitch: netlink: Flow actions may not be safe on all
>> matching packets.
>>
>> I've tested the patch on the platform on which the bug was initially hit
>> (*not* using MPLS/GRE), and I have the following a few times in the logs
>> right after I do an "ovs-appctl fdb/flush":
>>
>> 2016-12-13T09:44:08.449Z|1|dpif(handler68)|WARN|Dropped 3 log
>> messages in last 1 seconds (most recently, 1 seconds ago) due to excessive
>> rate
>> 2016-12-13T09:44:08.449Z|2|dpif(handler68)|WARN|system@ovs-system:
>> failed to put[create] (Invalid argument) 
>> ufid:f046c4c4-b97f-436d-bd7c-91ed307275ac
>> recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(9),skb_m
>> ark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/
>> 0),eth(src=fa:16:3e:61:c0:b5,dst=00:00:5e:00:43:64),eth_
>> type(0x0800),ipv4(src=10.0.1.29,dst=10.0.0.3,proto=6,tos=0/
>> 0xfc,ttl=64,frag=no),tcp(src=54253,dst=8080),tcp_flags(0/0),
>> actions:set(ipv4(src=10.0.1.29,dst=10.0.0.3,ttl=63)),set(eth
>> (src=b8:2a:72:de:1b:e3,dst=00:17:cb:79:2c:01)),push_mpls(lab
>> el=433680,tc=0,ttl=63,bos=1,eth_type=0x8847),7,set(eth(src
>> =fa:16:3e:61:c0:b5,dst=00:00:5e:00:43:64)),pop_mpls(eth_typ
>> e=0x800),set(ipv4(src=10.0.1.29,dst=10.0.0.3,tos=0/0xfc,ttl
>> =64)),push_vlan(vid=1,pcp=0),3,8,pop_vlan,13
>>
>> And dmesg:
>> [926833.612372] openvswitch: netlink: Flow actions may not be safe on all
>> matching packets.
>>
>
> it's complaining about set ipv4 after pop_mpls because it doesn't know
> about the "restored" l3.
> while we can improve the kernel, i guess we need to stick with recirc for
> now.
>
>
>
> This should do it? Does not break any existing tests on branch-2.5, but I
> did not create a test for this yet.
>
> diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> index fb25f63..6ee2a72 100644
> --- a/ofproto/ofproto-dpif-xlate.c
> +++ b/ofproto/ofproto-dpif-xlate.c
> @@ -2899,6 +2899,15 @@ xlate_commit_actions(struct xlate_ctx *ctx)
>  {
>  bool use_masked = ctx->xbridge->support.masked_set_action;
>
> +/* An MPLS packet can be implicitly popped back to a non-MPLS packet,
> if a
> + * patch port peer or a group bucket pushed MPLS.  Set the 'was_mpls'
> flag
> + * also in that case. */
> +if (eth_type_mpls(ctx->base_flow.dl_type)
> +&& !eth_type_mpls(ctx->xin->flow.dl_type)
> +&& ctx->xbridge->support.odp.recirc) {
> +ctx->was_mpls = true;
> +}
> +
>

i guess this check needs to be somewhere around "ctx->was_mpls =
old_was_mpls" in
affected functions.

 ctx->xout->slow |= commit_odp_actions(>xin->flow, >base_flow,
>ctx->odp_actions, ctx->wc,
>use_masked);
>
>   Jarno
>
>
>
>>
>> -Thomas
>>
>>
>>
>>
>>
>> On Dec 1, 2016, at 5:57 PM, Jarno Rajahalme  wrote:
>>
>>
>> On Nov 30, 2016, at 8:50 PM, Ben Pfaff  wrote:
>>
>> On Wed, Nov 30, 2016 at 06:58:57PM -0800, Jarno Rajahalme wrote:
>>
>>
>> On Nov 30, 2016, at 8:41 AM, Ben Pfaff  wrote:
>>
>> On Wed, Nov 30, 2016 at 12:05:46PM +0100, Thomas Morin wrote:
>>
>> Hi Ben,
>>
>> 2016-11-30, Ben Pfaff:
>>
>> Do you have any idea what in your OpenFlow pipeline might do that,
>> i.e. is there anything especially tricky in the OpenFlow flows?
>>
>> Are you willing to show us your OpenFlow flow table?
>>
>>
>> The setup involves three OVS bridges connected with patch-ports: br-int --
>> br-tun -- br-mpls, with the traffic that triggers the assert being
>> processed
>> by br-int with a NORMAL action (ie. MAC learning).
>>
>> The flows in this setup aren't particularly tricky, I think, although I'm
>> not sure what qualifies as tricky or non-tricky :)
>>
>> Anyway, since yesterday I managed to identify the event that trigger the
>> assert, by adding more logging before the assert and displaying the
>> actions
>> taken:
>>
>> 2016-11-29T14:44:40.126Z|1|odp_util(revalidator45)|WARN|
>> commit_set_ipv4_action
>> 

Re: [ovs-dev] [PATCH] datapath: enable vxlangpe creation in compat mode

[Pravin Shelar]

On Thu, Dec 8, 2016 at 9:41 PM, Yi Yang  wrote:
> Current out-of-tree ovs vxlan module has included vxlangpe code, but
> it can't create vxlangpe port, this patch enables out-of-tree ovs vxlan
> module to create vxlangpe port without Linux kernel v4.7 or above needed,
> this can ensure we can create vxlangpe port on any Linux system as long
> as Linux kernel isn't older than 3.10.
>
> When you run the cmd
>
> sudo ovs-vsctl add-port br-int vxlan_gpe1 -- set interface vxlan_gpe1 
> type=vxlan options:remote_ip=flow options:key=flow options:dst_port=4790 
> options:exts=gpe
>
> in current ovs, you will see the below warning
>
> netdev_vport|WARN|vxlan_gpe1: unknown extension 'gpe'
>
> , and you will see a vxlan port but not vxlangpe port
>
> vxlan_sys_4790 Link encap:Ethernet  HWaddr 6a:f6:6e:cb:75:fc
>   inet6 addr: fe80::68f6:6eff:fecb:75fc/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:65485  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:8 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> But after you apply this patch, you won't see any warning, and
> a vxlangpe port will be created successfully.
>
> vxlan_sys_4790 Link encap:UNSPEC  HWaddr 
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>   UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:65485  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> $ sudo ovs-vsctl show
> fc8eaac4-e16e-47e0-a5bb-9fc8475ada0a
> Bridge br-int
> Port br-int
> Interface br-int
> type: internal
> Port "vxlan_gpe1"
> Interface "vxlan_gpe1"
> type: vxlan
> options: {dst_port="4790", exts=gpe, key=flow, remote_ip=flow}
>
> Signed-off-by: Yi Yang 
> ---
>  datapath/linux/compat/include/linux/openvswitch.h |  1 +
>  datapath/vport-netdev.c   |  3 ++-
>  datapath/vport-vxlan.c| 15 +++
>  lib/netdev-vport.c|  2 ++
>  4 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
> b/datapath/linux/compat/include/linux/openvswitch.h
> index 12260d8..17e21cb 100644
> --- a/datapath/linux/compat/include/linux/openvswitch.h
> +++ b/datapath/linux/compat/include/linux/openvswitch.h
> @@ -291,6 +291,7 @@ enum ovs_vport_attr {
>  enum {
> OVS_VXLAN_EXT_UNSPEC,
> OVS_VXLAN_EXT_GBP,  /* Flag or __u32 */
> +   OVS_VXLAN_EXT_GPE,  /* Flag or __u32 */
> __OVS_VXLAN_EXT_MAX,
>  };
>
> diff --git a/datapath/vport-netdev.c b/datapath/vport-netdev.c
> index 970f7d3..73d6053 100644
> --- a/datapath/vport-netdev.c
> +++ b/datapath/vport-netdev.c
> @@ -102,7 +102,8 @@ struct vport *ovs_netdev_link(struct vport *vport, const 
> char *name)
> }
>
> if (vport->dev->flags & IFF_LOOPBACK ||
> -   vport->dev->type != ARPHRD_ETHER ||
> +   (vport->dev->type != ARPHRD_ETHER &&
> +vport->dev->type != ARPHRD_NONE) ||

OVS out of tree module is not ready for ARPHRD_NONE type of devices
yet. we have to backport L3 patches from upstream OVS first.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] travis: Update build matrix for latest kernels.

[Pravin Shelar]

On Tue, Dec 13, 2016 at 4:00 PM, Joe Stringer  wrote:
> Signed-off-by: Joe Stringer 

LGTM.

Acked-by: Pravin B Shelar 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] ovn-controller: Fix duplicated flows in table 32.

[Han Zhou]

In commit 475f0a2c it introduced a priority 150 flow for skipping
VXLAN traffic. However, it added the flow for every remote port
processing, which results in duplicated flows and failures seen
in ovn-controller logs. This fix moves the logic to global so that
the flow is added only once.

Signed-off-by: Han Zhou 
---
 ovn/controller/physical.c | 47 ---
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index 48adb78..3b653dd 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -465,33 +465,16 @@ consider_port_binding(enum mf_field_id mff_ovn_geneve,
 } else {
 /* Remote port connected by tunnel */
 
-/* Table 32, priority 150 and 100.
+/* Table 32, priority 100.
  * ===
  *
- * Priority 150 is for packets received from a VXLAN tunnel
- * which get resubmitted to OFTABLE_LOG_INGRESS_PIPELINE due to
- * lack of needed metadata in VXLAN, explicitly skip sending
- * back out any tunnels and resubmit to table 33 for local
- * delivery.
- *
- * Priority 100 is for all other traffic which need to be sent
- * to a remote hypervisor.  Each flow matches an output port
- * that includes a logical port on a remote hypervisor, and
- * tunnels the packet to that hypervisor.
+ * Priority 100 is for traffic that needs to be sent to a remote
+ * hypervisor.  Each flow matches an output port that includes a
+ * logical port on a remote hypervisor, and tunnels the packet to
+ * that hypervisor.
  */
 match_init_catchall();
 ofpbuf_clear(ofpacts_p);
-match_set_reg_masked(, MFF_LOG_FLAGS - MFF_REG0,
- MLF_RCV_FROM_VXLAN, MLF_RCV_FROM_VXLAN);
-
-/* Resubmit to table 33. */
-put_resubmit(OFTABLE_LOCAL_OUTPUT, ofpacts_p);
-ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 150, ,
-ofpacts_p);
-
-
-match_init_catchall();
-ofpbuf_clear(ofpacts_p);
 
 /* Match MFF_LOG_DATAPATH, MFF_LOG_OUTPORT. */
 match_set_metadata(, htonll(dp_key));
@@ -870,12 +853,30 @@ physical_run(struct controller_ctx *ctx, enum mf_field_id 
mff_ovn_geneve,
 }
 }
 
+/* Table 32, priority 150.
+ * ===
+ *
+ * Priority 150 is for packets received from a VXLAN tunnel
+ * which get resubmitted to OFTABLE_LOG_INGRESS_PIPELINE due to
+ * lack of needed metadata in VXLAN, explicitly skip sending
+ * back out any tunnels and resubmit to table 33 for local
+ * delivery.
+ */
+struct match match;
+match_init_catchall();
+ofpbuf_clear();
+match_set_reg_masked(, MFF_LOG_FLAGS - MFF_REG0,
+ MLF_RCV_FROM_VXLAN, MLF_RCV_FROM_VXLAN);
+
+/* Resubmit to table 33. */
+put_resubmit(OFTABLE_LOCAL_OUTPUT, );
+ofctrl_add_flow(flow_table, OFTABLE_REMOTE_OUTPUT, 150, , );
+
 /* Table 32, Priority 0.
  * ===
  *
  * Resubmit packets that are not directed at tunnels or part of a
  * multicast group to the local output table. */
-struct match match;
 match_init_catchall();
 ofpbuf_clear();
 put_resubmit(OFTABLE_LOCAL_OUTPUT, );
-- 
2.1.0

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

[ovs-dev] [PATCH] route-table: Stop netlink log message when routes withdrawn

[Tony van der Peet]

When a route is withdrawn (blackholed) the netlink message doesn't include
an RTA_OIF element. This results in an "unexpected netlink message
contents" log message because this element is not optional.

Given that the netlink message will be ignored anyway, and subsequent
error checking will cope with missing RTA_OIF, the element should be
optional in order to suppress unnecessary log messages.

Signed-off-by: Tony van der Peet 
---
 lib/route-table.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/route-table.c b/lib/route-table.c
index 6a3eeb504..d1c71def2 100644
--- a/lib/route-table.c
+++ b/lib/route-table.c
@@ -188,7 +188,7 @@ route_table_parse(struct ofpbuf *buf, struct 
route_table_msg *change)
 
 static const struct nl_policy policy[] = {
 [RTA_DST] = { .type = NL_A_U32, .optional = true  },
-[RTA_OIF] = { .type = NL_A_U32, .optional = false },
+[RTA_OIF] = { .type = NL_A_U32, .optional = true },
 [RTA_GATEWAY] = { .type = NL_A_U32, .optional = true },
 };
 
-- 
2.11.0

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

Re: [ovs-dev] [PATCH net-next] net: remove abuse of VLAN DEI/CFI bit

[Alexei Starovoitov]

On Tue, Dec 13, 2016 at 6:03 PM, Michał Mirosław
 wrote:
> On Tue, Dec 13, 2016 at 05:21:18PM -0800, Stephen Hemminger wrote:
>> On Sat,  3 Dec 2016 10:22:28 +0100 (CET)
>> Michał Mirosław  wrote:
>> > This All-in-one patch removes abuse of VLAN CFI bit, so it can be passed
>> > intact through linux networking stack.
>> >
>> > Signed-off-by: Michał Mirosław 
>> > ---
>> >
>> > Dear NetDevs
>> >
>> > I guess this needs to be split to the prep..convert[]..finish sequence,
>> > but if you like it as is, then it's ready.
>> >
>> > The biggest question is if the modified interface and vlan_present
>> > is the way to go. This can be changed to use vlan_proto != 0 instead
>> > of an extra flag bit.
>> >
>> > As I can't test most of the driver changes, please look at them carefully.
>> > OVS and bridge eyes are especially welcome.
>> >
>> > Best Regards,
>> > Michał Mirosław
>> Is the motivation to support 802.1ad Drop Eligability Indicator (DEI)?
>>
>> If so then you need to be more verbose in the commit log, and lots more
>> work is needed. You need to rename fields and validate every place a
>> driver is using DEI bit to make sure it really does the right thing
>> on that hardware. It is not just a mechanical change.
>
> My main motivation is to be able to see the bit intact in tcpdump and be
> able to pass it untouched through at least a veth pair. It would be great
> if all devices didn't do something stupid with the bit, but it's not
> something I am able to make happen.

imo "be able to pass untouched through veth" is not good enough
justification for such invasive patches.
I'm still not sure that all of these changes don't affect user space.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next] net: remove abuse of VLAN DEI/CFI bit

[Michał Mirosław]

On Tue, Dec 13, 2016 at 05:21:18PM -0800, Stephen Hemminger wrote:
> On Sat,  3 Dec 2016 10:22:28 +0100 (CET)
> Michał Mirosław  wrote:
> > This All-in-one patch removes abuse of VLAN CFI bit, so it can be passed
> > intact through linux networking stack.
> > 
> > Signed-off-by: Michał Mirosław 
> > ---
> > 
> > Dear NetDevs
> > 
> > I guess this needs to be split to the prep..convert[]..finish sequence,
> > but if you like it as is, then it's ready.
> > 
> > The biggest question is if the modified interface and vlan_present
> > is the way to go. This can be changed to use vlan_proto != 0 instead
> > of an extra flag bit.
> > 
> > As I can't test most of the driver changes, please look at them carefully.
> > OVS and bridge eyes are especially welcome.
> > 
> > Best Regards,
> > Michał Mirosław
> Is the motivation to support 802.1ad Drop Eligability Indicator (DEI)?
> 
> If so then you need to be more verbose in the commit log, and lots more
> work is needed. You need to rename fields and validate every place a
> driver is using DEI bit to make sure it really does the right thing
> on that hardware. It is not just a mechanical change.

My main motivation is to be able to see the bit intact in tcpdump and be
able to pass it untouched through at least a veth pair. It would be great
if all devices didn't do something stupid with the bit, but it's not
something I am able to make happen.

Best Regards,
Michał Mirosław
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [ovs]Specify the range of the tag for "ovn-nbctl lsp-add" command

[zhou . huijing]

commit 6e3a951654756f4dbd2b853980b710df66763a56
Author: zhaojingjing 
Date:   Wed Dec 14 09:19:20 2016 +0800

Specify the range of the tag for "ovn-nbctl lsp-add" command

diff --git a/ovn/utilities/ovn-nbctl.8.xml b/ovn/utilities/ovn-nbctl.8.xml
index 3904685..3683876 100644
--- a/ovn/utilities/ovn-nbctl.8.xml
+++ b/ovn/utilities/ovn-nbctl.8.xml
@@ -125,7 +125,9 @@
 
   Creates on switch a logical switch port named
   port that is a child of parent that is
-  identified with VLAN ID tag_request.  If
+  identified with VLAN ID tag_request.
+ Tag_request must be between 0 
and
+ 4095, inclusive. If
   tag_request is 0, 
ovn-northd
   generates a tag that is unique in the scope of 
parent.
   This is useful in cases such as virtualized container 
environments
diff --git a/ovn/utilities/ovn-nbctl.c b/ovn/utilities/ovn-nbctl.c
index 0cc0c1f..a90f94a 100644
--- a/ovn/utilities/ovn-nbctl.c
+++ b/ovn/utilities/ovn-nbctl.c
@@ -798,7 +798,7 @@ nbctl_lsp_add(struct ctl_context *ctx)
 parent_name = ctx->argv[3];
 if (!ovs_scan(ctx->argv[4], "%"SCNd64, )
 || tag < 0 || tag > 4095) {
-ctl_fatal("%s: invalid tag", ctx->argv[4]);
 }
 } else {
 ctl_fatal("lsp-add with parent must also specify a tag");



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

Re: [ovs-dev] [PATCH net-next] net: remove abuse of VLAN DEI/CFI bit

[Stephen Hemminger]

On Sat,  3 Dec 2016 10:22:28 +0100 (CET)
Michał Mirosław  wrote:

> This All-in-one patch removes abuse of VLAN CFI bit, so it can be passed
> intact through linux networking stack.
> 
> Signed-off-by: Michał Mirosław 
> ---
> 
> Dear NetDevs
> 
> I guess this needs to be split to the prep..convert[]..finish sequence,
> but if you like it as is, then it's ready.
> 
> The biggest question is if the modified interface and vlan_present
> is the way to go. This can be changed to use vlan_proto != 0 instead
> of an extra flag bit.
> 
> As I can't test most of the driver changes, please look at them carefully.
> OVS and bridge eyes are especially welcome.
> 
> Best Regards,
> Michał Mirosław

Is the motivation to support 802.1ad Drop Eligability Indicator (DEI)?

If so then you need to be more verbose in the commit log, and lots more
work is needed. You need to rename fields and validate every place a
driver is using DEI bit to make sure it really does the right thing
on that hardware. It is not just a mechanical change.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] eFax message from +611300309949 - 4 page(s), Caller-ID: +611300309949

[eFax]

You have a new fax from eFax! Click attachment to view.
Fax Details

Caller ID:
Date Received:
Type:
Number of pages:
Reference #:


+611300309949
2016-12-13 08:49:19 GMT
Attached in doc
4
chd_did1-+611300309949-+611300309949-57
Enjoy all the benefits of eFax:

- Send faxes from your Android or iOS device
- Sign and edit faxes with no printing required
- Send large files by email (up to 3GB)
- Learn more >>

Thank you for choosing eFax!

Sincerely,
The eFax Team

P.S. Too busy to answer all your business calls? Let eVoice answer, manage and 
route your phone calls 24/7. Try a Free 30-Day Trial Today!
j2

© 2016 j2 Global, Inc and affiliates. All rights reserved.
eFax is a registered trademark of j2 Global, Inc. and affiliates.
6922 Hollywood Blvd., Los Angeles, CA 90028

This account is subject to the terms listed in the eFax Customer Agreement.

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

[ovs-dev] [PATCH] travis: Update build matrix for latest kernels.

[Joe Stringer]

Signed-off-by: Joe Stringer 
---
 .travis.yml | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 9f967ad080c4..90fc6995b229 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -24,18 +24,18 @@ sudo: false
 
 env:
   - OPTS="--disable-ssl"
-  - TESTSUITE=1 KERNEL=3.18.1
+  - TESTSUITE=1 KERNEL=3.16.39
   - TESTSUITE=1 OPTS="--enable-shared"
   - BUILD_ENV="-m32" OPTS="--disable-ssl"
-  - KERNEL=3.17.7 DPDK=1
-  - KERNEL=3.17.7 DPDK=1 OPTS="--enable-shared"
-  - KERNEL=4.7.2
-  - KERNEL=4.4.15
-  - KERNEL=4.1.28
-  - KERNEL=3.18.37
-  - KERNEL=3.14.73
-  - KERNEL=3.12.61
-  - KERNEL=3.10.102
+  - KERNEL=3.16.39 DPDK=1
+  - KERNEL=3.16.39 DPDK=1 OPTS="--enable-shared"
+  - KERNEL=4.9
+  - KERNEL=4.8.14
+  - KERNEL=4.4.38
+  - KERNEL=4.1.36
+  - KERNEL=3.18.45
+  - KERNEL=3.12.68
+  - KERNEL=3.10.104
   - TESTSUITE=1 LIBS=-ljemalloc
 
 matrix:
-- 
2.10.2

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

[ovs-dev] facultades de las autoridades fiscales

[Reformas Fiscales 2017 - En Línea]

 

En línea y en Vivo / Para todo su Equipo con una sola Conexión 

Puntos destacados de las Reformas Fiscales 2017
Revisiones electrónicas, NUEVAS infracciones y multas, cancelación de CFDI 
y facultades de las autoridades fiscales
28 de diciembre - Online en Vivo - 10:00 a 13:00 Hrs   
 
La Reforma Fiscal para 2017, incluye diversas disposiciones que pretenden 
simplificar el pago de impuestos, incentivar diversos sectores y áreas 
productivas del país a través de estímulos fiscales; cuidar el medio ambiente, 
evitar prácticas fiscales indebidas o eludir obligaciones por parte de los 
contribuyentes y aclarar diversas disposiciones con el fin de otorgar mayor 
certeza jurídica a los contribuyentes. 
"Pregunte por nuestra Promoción Navideña"


Temario: 

1. Ley de Ingresos de la Federación.

2. Ley del Impuesto sobre la Renta.

3. Sector primario: Facilidades para llevar la contabilidad.

4. Ley del Impuesto al Valor
Agregado.

5. Código Fiscal de la Federación.



...¡Y mucho más!


 
¿Requiere la información a la Brevedad?
responda este email con la palabra: 
Info - Reformas.
centro telefónico: 018002129393
 

Lic. Melvin Puerto
Coordinador de Evento


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

 

 

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

Re: [ovs-dev] assertion failing in commit_set_ipv4_action(), flow->nw_proto != base_flow->nw_proto

[Takashi YAMAMOTO]

On Tue, Dec 13, 2016 at 6:49 PM, Thomas Morin 
wrote:

> Hi Jarno,
>
> 2016-12-10, Jarno Rajahalme:
>
> On Dec 9, 2016, at 7:04 AM, Thomas Morin  wrote:
>
>
> 2016-12-09, Thomas Morin:
>
> In the same setup as the one on which the bug was observed, [...]
>
>
> I was confused, I in fact tested the patch (branch-2.5) on a /different/
> setup as the one on which we hit the bug, using MPLS over a GRE tunnel
> port, rather than plain MPLS over an eth port.
> Sorry if any confusion arised... I can test on the first setup if relevant.
>
>
> Maybe the kernel datapath does not support MPLS over a GRE tunnel port.
> Having ‘dmesg’ output for the test run might reveal why the actions
> validation fails.
>
>
> The dmesg output was the following:
>
> [171295.258939] openvswitch: netlink: Flow actions may not be safe on all
> matching packets.
>
> I've tested the patch on the platform on which the bug was initially hit
> (*not* using MPLS/GRE), and I have the following a few times in the logs
> right after I do an "ovs-appctl fdb/flush":
>
> 2016-12-13T09:44:08.449Z|1|dpif(handler68)|WARN|Dropped 3 log
> messages in last 1 seconds (most recently, 1 seconds ago) due to excessive
> rate
> 2016-12-13T09:44:08.449Z|2|dpif(handler68)|WARN|system@ovs-system:
> failed to put[create] (Invalid argument) 
> ufid:f046c4c4-b97f-436d-bd7c-91ed307275ac
> recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(9),skb_
> mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_
> label(0/0),eth(src=fa:16:3e:61:c0:b5,dst=00:00:5e:00:43:
> 64),eth_type(0x0800),ipv4(src=10.0.1.29,dst=10.0.0.3,proto=
> 6,tos=0/0xfc,ttl=64,frag=no),tcp(src=54253,dst=8080),tcp_flags(0/0),
> actions:set(ipv4(src=10.0.1.29,dst=10.0.0.3,ttl=63)),set(
> eth(src=b8:2a:72:de:1b:e3,dst=00:17:cb:79:2c:01)),push_mpls(
> label=433680,tc=0,ttl=63,bos=1,eth_type=0x8847),7,set(eth(
> src=fa:16:3e:61:c0:b5,dst=00:00:5e:00:43:64)),pop_mpls(eth_
> type=0x800),set(ipv4(src=10.0.1.29,dst=10.0.0.3,tos=0/0xfc,
> ttl=64)),push_vlan(vid=1,pcp=0),3,8,pop_vlan,13
>
> And dmesg:
> [926833.612372] openvswitch: netlink: Flow actions may not be safe on all
> matching packets.
>

it's complaining about set ipv4 after pop_mpls because it doesn't know
about the "restored" l3.
while we can improve the kernel, i guess we need to stick with recirc for
now.


>
>
> -Thomas
>
>
>
>
>
> On Dec 1, 2016, at 5:57 PM, Jarno Rajahalme  wrote:
>
>
> On Nov 30, 2016, at 8:50 PM, Ben Pfaff  wrote:
>
> On Wed, Nov 30, 2016 at 06:58:57PM -0800, Jarno Rajahalme wrote:
>
>
> On Nov 30, 2016, at 8:41 AM, Ben Pfaff  wrote:
>
> On Wed, Nov 30, 2016 at 12:05:46PM +0100, Thomas Morin wrote:
>
> Hi Ben,
>
> 2016-11-30, Ben Pfaff:
>
> Do you have any idea what in your OpenFlow pipeline might do that,
> i.e. is there anything especially tricky in the OpenFlow flows?
>
> Are you willing to show us your OpenFlow flow table?
>
>
> The setup involves three OVS bridges connected with patch-ports: br-int --
> br-tun -- br-mpls, with the traffic that triggers the assert being
> processed
> by br-int with a NORMAL action (ie. MAC learning).
>
> The flows in this setup aren't particularly tricky, I think, although I'm
> not sure what qualifies as tricky or non-tricky :)
>
> Anyway, since yesterday I managed to identify the event that trigger the
> assert, by adding more logging before the assert and displaying the actions
> taken:
>
> 2016-11-29T14:44:40.126Z|1|odp_util(revalidator45)|
> WARN|commit_set_ipv4_action
> assert would fail
> 2016-11-29T14:44:40.126Z|2|odp_util(revalidator45)|WARN|  base_flow:
> ip,in_port=5,dl_vlan=3,dl_vlan_pcp=0,dl_src=fa:16:3e:33:
> f7:fe,dl_dst=00:00:5e:00:43:64,nw_src=0.0.0.0,nw_dst=0.0.
> 0.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> 2016-11-29T14:44:40.126Z|3|odp_util(revalidator45)|WARN|  flow:
> tcp,in_port=5,dl_vlan=3,dl_vlan_pcp=0,dl_src=fa:16:3e:33:
> f7:fe,dl_dst=00:00:5e:00:43:64,nw_src=10.0.1.22,nw_dst=10.
> 0.0.3,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=53295,tp_dst=
> 8080,tcp_flags=psh|ack
> 2016-11-29T14:44:40.126Z|4|odp_util(revalidator45)|WARN|  masks:
> recirc_id=0x,reg0=0x,in_port=4294967295,
> dl_vlan=4095,dl_vlan_pcp=7,dl_src=ff:ff:ff:ff:ff:ff,dl_dst=
> ff:ff:ff:ff:ff:ff,dl_type=0x
> 2016-11-29T14:44:40.126Z|5|odp_util(revalidator45)|WARN|  actions:
> set(ipv4(src=10.0.1.22,dst=10.0.0.3,ttl=63)),set(eth(src=b8:
> 2a:72:de:1b:e3,dst=00:17:cb:79:2c:01)),push_mpls(label=
> 410384,tc=0,ttl=63,bos=1,eth_type=0x8847),9,set(eth(src=fa:
> 16:3e:33:f7:fe,dst=00:00:5e:00:43:64)),pop_mpls(eth_type=
> 0x800),push_vlan(vid=3,pcp=0),1
>
>
> push_mpls clears L3/L4, while pop_mpls re-populates them, and then
> processing the output to port 1 hits the assert?
>
>
> That's what I'm thinking too.
>
> Jarno, is this something you have time to look into?  It'd be great, if
> you do.  I'm way behind.
>
>
> I’m looking at this.
>
> Based on the trace given it seems 

Re: [ovs-dev] [RFC v2] lib/table: add new flexible formatting

[Aaron Conole]

Ben Pfaff  writes:

> On Mon, Dec 12, 2016 at 08:11:16PM -0500, Aaron Conole wrote:
>> Ben Pfaff  writes:
>> 
>> > On Wed, Dec 07, 2016 at 02:15:12PM -0500, Aaron Conole wrote:
>> >> Ben Pfaff  writes:
>> >> > On Wed, Dec 07, 2016 at 01:08:43PM -0500, Aaron Conole wrote:
>> >> >> Ben Pfaff  writes:
>> >> >> To accomplish this, I'm going down the following route:
>> >> >> 
>> >> >> 1. Add formatting option to the lib/table.{c,h}, such that we can
>> >> >>still express the existing output.
>> >> >> 
>> >> >> 2. Change ofp-print to use a table for flow dumping, with a default
>> >> >>format that preserves the current format, and the option of changing
>> >> >>the format.
>> >> >
>> >> > #2 is interesting.
>> >> 
>> >> I don't currently see how to implement #2, while preserving the existing
>> >> output, unless I implement #1.  Is there a way to accomplish this that
>> >> I'm missing?  If not, is #2 compelling enough to accept #1?
>> >
>> > I don't understand how you are going to preserve the default format even
>> > with #1.  I assumed you were going to need to write a separate code path
>> > to do that.
>> 
>> No - that's my last resort.
>> 
>> > Can you explain your plan?
>> 
>> I was thinking of creating a table which had column headings that were,
>> example:
>> 
>>   actions, in_port, priority, table number, etc.
>> 
>> Then a format string such as:
>> 
>>   [priority={priority},][table={tableno},]...
>> 
>> where things in the [] would only be printed if all elements in the row
>> were filled in, could preserve the original output (without the full
>> working code set it might be difficult to see what I mean), while also
>> offering the existing --table=XXX output.
>
> This may be challenging because of the number of columns.  in_port is
> easy enough, but OVS has dozens (at least) of possible fields.  It also
> has a nonuniform way to display fields.  For example, it shows the
> Ethernet type in a general form as "dl_type=0x1234", but if it's an IP
> packet then it just says "ip" instead, and if it's TCP then it just says
> "tcp" instead of "dl_type=0x0800,nw_proto=6", and so on.

I enjoy a challenge from time to time ;-)

Moreover, I'm willing to do the work.  Agreed, there's lots of it
(dozens is right), but I think it's an elegant solution.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH V16] Function tracer to trace all function calls

[Ben Pfaff]

On Mon, Dec 12, 2016 at 04:20:52PM -0800, Ben Pfaff wrote:
> On Mon, Dec 12, 2016 at 03:42:19PM -0600, Ryan Moats wrote:
> > Ben Pfaff  wrote on 12/12/2016 03:32:55 PM:
> > > Ryan, at one point you were shepherding this patch through review.  Are
> > > you still doing that?  Is it ready for me to review?
> >
> > While I was shepherding this patch set through review, I've not
> > looked at this version, nor do I expect to have time to review it in
> > the near future.
> 
> OK.
> 
> Nirapada, is this still something that you'd like to get into OVS?  Is
> it ready for review?

If so, it will need to be rebased and reposted because of changes that
have been committed to OVS in the meantime.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC v2] lib/table: add new flexible formatting

[Ben Pfaff]

On Mon, Dec 12, 2016 at 08:11:16PM -0500, Aaron Conole wrote:
> Ben Pfaff  writes:
> 
> > On Wed, Dec 07, 2016 at 02:15:12PM -0500, Aaron Conole wrote:
> >> Ben Pfaff  writes:
> >> > On Wed, Dec 07, 2016 at 01:08:43PM -0500, Aaron Conole wrote:
> >> >> Ben Pfaff  writes:
> >> >> To accomplish this, I'm going down the following route:
> >> >> 
> >> >> 1. Add formatting option to the lib/table.{c,h}, such that we can
> >> >>still express the existing output.
> >> >> 
> >> >> 2. Change ofp-print to use a table for flow dumping, with a default
> >> >>format that preserves the current format, and the option of changing
> >> >>the format.
> >> >
> >> > #2 is interesting.
> >> 
> >> I don't currently see how to implement #2, while preserving the existing
> >> output, unless I implement #1.  Is there a way to accomplish this that
> >> I'm missing?  If not, is #2 compelling enough to accept #1?
> >
> > I don't understand how you are going to preserve the default format even
> > with #1.  I assumed you were going to need to write a separate code path
> > to do that.
> 
> No - that's my last resort.
> 
> > Can you explain your plan?
> 
> I was thinking of creating a table which had column headings that were,
> example:
> 
>   actions, in_port, priority, table number, etc.
> 
> Then a format string such as:
> 
>   [priority={priority},][table={tableno},]...
> 
> where things in the [] would only be printed if all elements in the row
> were filled in, could preserve the original output (without the full
> working code set it might be difficult to see what I mean), while also
> offering the existing --table=XXX output.

This may be challenging because of the number of columns.  in_port is
easy enough, but OVS has dozens (at least) of possible fields.  It also
has a nonuniform way to display fields.  For example, it shows the
Ethernet type in a general form as "dl_type=0x1234", but if it's an IP
packet then it just says "ip" instead, and if it's TCP then it just says
"tcp" instead of "dl_type=0x0800,nw_proto=6", and so on.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] dist-docs: Make "make dist-docs" work again.

[Lance Richardson]

> From: "Ben Pfaff" 
> To: d...@openvswitch.org
> Cc: "Ben Pfaff" , "Stephen Finucane" , 
> "Lance Richardson" 
> Sent: Tuesday, December 13, 2016 3:50:32 PM
> Subject: [PATCH] dist-docs: Make "make dist-docs" work again.
> 
> CC: Stephen Finucane 
> Fixes: c431227e3350 ("doc: Remove documentation from distdoc target")
> Reported-by: Lance Richardson 
> Signed-off-by: Ben Pfaff 
> ---
>  build-aux/dist-docs | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/build-aux/dist-docs b/build-aux/dist-docs
> index d2d11d7..9f6ca7b 100755
> --- a/build-aux/dist-docs
> +++ b/build-aux/dist-docs
> @@ -3,10 +3,10 @@
>  set -e
>  
>  # Check command line.
> -if test ! -d "$1" || test $# -lt 2; then
> +if test ! -d "$1" || test $# != 1; then
>  cat <  $0: HTML documentation generator for Open vSwitch
> -usage: $0 srcdir docfile...
> +usage: $0 srcdir
>  
>  The VERSION environment variable should be set to the Open vSwitch version.
>  Must be invoked from an Open vSwitch build directory.
> --
> 2.10.2
> 
> 

LGTM, works for me.

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

[ovs-dev] [PATCH] dist-docs: Make "make dist-docs" work again.

[Ben Pfaff]

CC: Stephen Finucane 
Fixes: c431227e3350 ("doc: Remove documentation from distdoc target")
Reported-by: Lance Richardson 
Signed-off-by: Ben Pfaff 
---
 build-aux/dist-docs | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/build-aux/dist-docs b/build-aux/dist-docs
index d2d11d7..9f6ca7b 100755
--- a/build-aux/dist-docs
+++ b/build-aux/dist-docs
@@ -3,10 +3,10 @@
 set -e
 
 # Check command line.
-if test ! -d "$1" || test $# -lt 2; then
+if test ! -d "$1" || test $# != 1; then
 cat 

Re: [ovs-dev] [PATCH v2 11/11] doc: Remove documentation from distdoc target

[Ben Pfaff]

On Tue, Dec 13, 2016 at 03:07:00PM -0500, Russell Bryant wrote:
> On Tue, Dec 13, 2016 at 3:01 PM, Lance Richardson 
> wrote:
> 
> > > From: "Stephen Finucane" 
> > > To: d...@openvswitch.org
> > > Sent: Thursday, December 8, 2016 7:55:30 AM
> > > Subject: [ovs-dev] [PATCH v2 11/11] doc: Remove documentation from
> > distdoctarget
> > >
> > > Basic Sphinx integration is now complete. Remove the documentation
> > > aspects of the 'dist-docs' target in favor of the htmldocs target.
> > >
> > > Signed-off-by: Stephen Finucane 
> > > ---
> > >  Documentation/automake.mk |  4 +---
> > >  Makefile.am   |  7 +--
> > >  build-aux/dist-docs   | 50
> > >  +--
> > >  debian/rules.modules  |  2 +-
> > >  third-party/automake.mk   |  5 +++--
> > >  5 files changed, 7 insertions(+), 61 deletions(-)
> > >
> > > diff --git a/Documentation/automake.mk b/Documentation/automake.mk
> > > index 58cd650..6657b70 100644
> > > --- a/Documentation/automake.mk
> > > +++ b/Documentation/automake.mk
> > > @@ -1,7 +1,5 @@
> > > -docs += \
> > > - Documentation/group-selection-method-property.txt
> > > -
> >
> > With the initialization of "docs" gone, "make dist-docs" now fails. Is
> > this intentional?
> >
> > $ make dist-docs
> > VERSION=2.6.90 MAKE='make' ./build-aux/dist-docs .
> > ./build-aux/dist-docs: HTML documentation generator for Open vSwitch
> > usage: ./build-aux/dist-docs srcdir docfile...
> >
> > The VERSION environment variable should be set to the Open vSwitch version.
> > Must be invoked from an Open vSwitch build directory.
> > Most conveniently invoked via "make dist-docs".
> > Makefile:6103: recipe for target 'dist-docs' failed
> > make: *** [dist-docs] Error 1
> 
> 
> We still need the dist-docs target for rendering all of the man pages,
> right?

Yes.

I sent out a fix:
https://mail.openvswitch.org/pipermail/ovs-dev/2016-December/326198.html
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/5] doc: Use higher resolution logo

[Ben Pfaff]

On Tue, Dec 13, 2016 at 11:29:56AM -0800, Ben Pfaff wrote:
> On Tue, Dec 13, 2016 at 05:40:38PM +, Stephen Finucane wrote:
> > Rework the logo to remove much of the white background and increase
> > resolution.
> > 
> > Signed-off-by: Stephen Finucane 
> 
> I didn't even know that Git could email binary patches.

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

Re: [ovs-dev] [PATCH 2/2] doc: Add link to manpages guide

[Ben Pfaff]

On Tue, Dec 13, 2016 at 06:38:42PM +, Stephen Finucane wrote:
> This was included only in the contents page.
> 
> Signed-off-by: Stephen Finucane 
> Reported-by: Russell Bryant 

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

[ovs-dev] [PATCH 3/3] netdev-dpdk: Add support for virtual DPDK PMDs (vdevs)

[Ciara Loftus]

Prior to this commit, the 'dpdk' port type could only be used for
physical DPDK devices. Now, virtual devices (or 'vdevs') are supported.
'vdev' devices are those which use virtual DPDK Poll Mode Drivers eg.
null, pcap. To add a DPDK vdev, a valid 'dpdk-devargs' must be set for
the given dpdk port. The format expected is 'eth_' where
'x' is a number between 0 and RTE_MAX_ETHPORTS -1.

For example to add a port that uses the 'null' DPDK PMD driver:

ovs-vsctl set Interface null0 options:dpdk-devargs=eth_null0

Not all DPDK vdevs have been verified to work at this point in time.

Signed-off-by: Ciara Loftus 
---
 Documentation/intro/install/dpdk-advanced.rst | 22 ++
 NEWS  |  1 +
 lib/netdev-dpdk.c | 21 +
 vswitchd/vswitch.xml  |  9 +++--
 4 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/Documentation/intro/install/dpdk-advanced.rst 
b/Documentation/intro/install/dpdk-advanced.rst
index 858ff98..0384330 100644
--- a/Documentation/intro/install/dpdk-advanced.rst
+++ b/Documentation/intro/install/dpdk-advanced.rst
@@ -956,6 +956,28 @@ This feature is not supported with VFIO and could not work 
with some NICs.
 For more information please refer to the `DPDK Port Hotplug Framework
 `__.
 
+Vdev Support
+
+
+DPDK provides drivers for both physical and virtual devices. Physical DPDK
+devices are added to OVS by specifying a valid PCI address in 'dpdk-devargs'.
+Virtual DPDK devices which do not have PCI addresses can be added using a
+different format for 'dpdk-devargs'.
+
+Typically, the format expected is 'eth_' where 'x' is a
+number between 0 and RTE_MAX_ETHPORTS -1 (31).
+
+For example to add a dpdk port that uses the 'null' DPDK PMD driver:
+
+   $ ovs-vsctl add-port br0 null0 -- set Interface null0 type=dpdk \
+   options:dpdk-devargs=eth_null0
+
+More information on the different types of virtual DPDK PMDs can be found in
+the `DPDK documentation
+`__.
+
+Note: Not all DPDK virtual PMD drivers have been tested and verified to work.
+
 Bug Reporting
 -
 
diff --git a/NEWS b/NEWS
index a62a7a4..2215066 100644
--- a/NEWS
+++ b/NEWS
@@ -44,6 +44,7 @@ Post-v2.6.0
  * Port Hotplug is now supported.
  * DPDK physical ports can now have arbitrary names. The PCI address of
the device must be set using the 'dpdk-devargs' option.
+ * Virtual DPDK Poll Mode Driver (vdev PMD) support.
- Fedora packaging:
  * A package upgrade does not automatically restart OVS service.
- ovs-vswitchd/ovs-vsctl:
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 07a99c7..872ce63 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -1124,6 +1124,24 @@ netdev_dpdk_process_pdevargs(struct netdev_dpdk *dev, 
const char *devargs,
 return 0;
 }
 
+static int
+netdev_dpdk_process_vdevargs(struct netdev_dpdk *dev, const char *devargs)
+{
+uint8_t port_id;
+
+if (!rte_eth_dev_attach(devargs, _id)) {
+/* Attach successful */
+VLOG_INFO("Port '%s' attached to DPDK as virtual device",
+  dev->up.name);
+dev->port_id = port_id;
+} else {
+/* Attach unsuccessful */
+return -1;
+}
+
+return 0;
+}
+
 static void
 netdev_dpdk_process_devargs(struct netdev_dpdk *dev)
 OVS_REQUIRES(dev->mutex)
@@ -1134,6 +1152,9 @@ netdev_dpdk_process_devargs(struct netdev_dpdk *dev)
 if (!eal_parse_pci_DomBDF(dev->requested_devargs, )) {
 /* Valid PCI address format detected - configure physical device */
 err = netdev_dpdk_process_pdevargs(dev, dev->requested_devargs, );
+} else {
+/* Not a PCI device format - configure virtual device (vdev) */
+err = netdev_dpdk_process_vdevargs(dev, dev->requested_devargs);
 }
 
 if (!err) {
diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index 23ab469..7c6f229 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -2306,8 +2306,13 @@
   
 
-  Specifies the PCI address of a physical dpdk device.
-  Only supported by 'dpdk' devices.
+  Specifies the PCI address associated with the port for physical
+  devices, or the virtual driver to be used for the port when a virtual
+  PMD is intended to be used. For the latter, the argument string
+  typically takes the form of eth_driver_namex where
+  'driver_name' is a valid virtual DPDK PMD driver name and where 'x'
+  lies in the range of 0 to RTE_MAX_ETHPORTS-1.
+  Only supported by the dpdk port type.
 
   
 
-- 
2.4.3

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

[ovs-dev] [PATCH 2/3] netdev-dpdk: Arbitrary 'dpdk' port naming

[Ciara Loftus]

'dpdk' ports no longer have naming restrictions. Now, instead of
specifying the dpdk port ID as part of the name, the PCI address of the
device must be specified via the 'dpdk-devargs' option. eg.

ovs-vsctl add-port br0 my-port
ovs-vsctl set Interface my-port type=dpdk
ovs-vsctl set Interface my-port options:dpdk-devargs=:06:00.3

The user must no longer hotplug attach DPDK ports by issuing the
specific ovs-appctl netdev-dpdk/port-attach command. The hotplug is now
automatically invoked when a valid PCI address is set in the
dpdk-devargs. The format for ovs-appctl netdev-dpdk/port-detach command
has changed in that the user now must specify the relevant PCI address
as input instead of the port name.

Signed-off-by: Ciara Loftus 
---
Changelog:
* Keep port-detach appctl function - use PCI as input arg
* Add requires_mutex to devargs processing functions
* use reconfigure infrastructure for devargs changes
* process devargs even if valid portid ie. device already configured
* report err if dpdk-devargs is not specified

 Documentation/intro/install/dpdk-advanced.rst |   7 +-
 Documentation/intro/install/dpdk.rst  |  14 ++-
 NEWS  |   2 +
 lib/netdev-dpdk.c | 157 +-
 vswitchd/vswitch.xml  |   8 ++
 5 files changed, 123 insertions(+), 65 deletions(-)

diff --git a/Documentation/intro/install/dpdk-advanced.rst 
b/Documentation/intro/install/dpdk-advanced.rst
index 42a4af6..858ff98 100644
--- a/Documentation/intro/install/dpdk-advanced.rst
+++ b/Documentation/intro/install/dpdk-advanced.rst
@@ -944,14 +944,13 @@ dpdk_nic_bind.py script:
 
 Then it can be attached to OVS:
 
-   $ ovs-appctl netdev-dpdk/port-attach :01:00.0
-
-At this point, the user can create a ovs port using the add-port command.
+   $ ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk \
+   options:dpdk-devargs=:01:00.0
 
 It is also possible to detach a port from ovs, the user has to remove the
 port using the del-port command, then it can be detached using:
 
-   $ ovs-appctl netdev-dpdk/port-detach dpdk0
+   $ ovs-appctl netdev-dpdk/port-detach :01:00.0
 
 This feature is not supported with VFIO and could not work with some NICs.
 For more information please refer to the `DPDK Port Hotplug Framework
diff --git a/Documentation/intro/install/dpdk.rst 
b/Documentation/intro/install/dpdk.rst
index 7724c8a..40b5b67 100644
--- a/Documentation/intro/install/dpdk.rst
+++ b/Documentation/intro/install/dpdk.rst
@@ -245,12 +245,14 @@ Bridges should be created with a 
``datapath_type=netdev``::
 
 $ ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
 
-Now you can add DPDK devices. OVS expects DPDK device names to start with
-``dpdk`` and end with a portid. ovs-vswitchd should print the number of dpdk
-devices found in the log file::
-
-$ ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk
-$ ovs-vsctl add-port br0 dpdk1 -- set Interface dpdk1 type=dpdk
+Now you can add dpdk devices. The PCI address of the device needs to be
+set using the 'dpdk-devargs' option. DPDK will print the PCI addresses of
+eligible devices found during initialisation.
+
+$ ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk \
+options:dpdk-devargs=:06:00.0
+$ ovs-vsctl add-port br0 dpdk1 -- set Interface dpdk1 type=dpdk \
+options:dpdk-devargs=:06:00.1
 
 After the DPDK ports get added to switch, a polling thread continuously polls
 DPDK devices and consumes 100% of the core, as can be checked from 'top' and
diff --git a/NEWS b/NEWS
index b596cf3..a62a7a4 100644
--- a/NEWS
+++ b/NEWS
@@ -42,6 +42,8 @@ Post-v2.6.0
which set the number of rx and tx descriptors to use for the given port.
  * Support for DPDK v16.11.
  * Port Hotplug is now supported.
+ * DPDK physical ports can now have arbitrary names. The PCI address of
+   the device must be set using the 'dpdk-devargs' option.
- Fedora packaging:
  * A package upgrade does not automatically restart OVS service.
- ovs-vswitchd/ovs-vsctl:
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 677a10c..07a99c7 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -143,6 +143,8 @@ BUILD_ASSERT_DECL((MAX_NB_MBUF / 
ROUND_DOWN_POW2(MAX_NB_MBUF/MIN_NB_MBUF))
 #define VHOST_ENQ_RETRY_NUM 8
 #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
 
+#define DEVARGS_MAX PCI_PRI_STR_SIZE
+
 static const struct rte_eth_conf port_conf = {
 .rxmode = {
 .mq_mode = ETH_MQ_RX_RSS,
@@ -352,6 +354,9 @@ struct netdev_dpdk {
 /* Identifier used to distinguish vhost devices from each other. */
 char vhost_id[PATH_MAX];
 
+/* Device arguments for dpdk ports */
+char dpdk_devargs[DEVARGS_MAX];
+
 /* In dpdk_list. */
 struct ovs_list list_node OVS_GUARDED_BY(dpdk_mutex);
 
@@ -366,6 +371,7 @@ 

[ovs-dev] [PATCH 1/3] netdev-dpdk: add hotplug support

[Ciara Loftus]

In order to use dpdk ports in ovs they have to be bound to a DPDK
compatible driver before ovs is started.

This patch adds the possibility to hotplug (or hot-unplug) a device
after ovs has been started. The implementation adds two appctl commands:
netdev-dpdk/port-attach and netdev-dpdk/port-detach

After the user attaches a new device, it has to be added to a bridge
using the add-port command, similarly, before detaching a device,
it has to be removed using the del-port command.

Signed-off-by: Mauricio Vasquez B 
---
Changelog:
* Use xasprintf instead of snprintf when reporting attach/detach errors.
* Updated format of link in docs to comply with new format.

 Documentation/intro/install/dpdk-advanced.rst | 25 
 NEWS  |  1 +
 lib/netdev-dpdk.c | 91 +--
 3 files changed, 111 insertions(+), 6 deletions(-)

diff --git a/Documentation/intro/install/dpdk-advanced.rst 
b/Documentation/intro/install/dpdk-advanced.rst
index 44d1cd7..42a4af6 100644
--- a/Documentation/intro/install/dpdk-advanced.rst
+++ b/Documentation/intro/install/dpdk-advanced.rst
@@ -932,6 +932,31 @@ validate the suitability of different vSwitch 
implementations in a telco
 deployment environment. More information can be found on the `OPNFV wiki
 `__.
 
+Port Hotplug
+
+
+OvS supports port hotplugging, it allows to use ports that were not bound
+to DPDK when vswitchd was started.
+In order to attach a port, it has to be bound to DPDK using the
+dpdk_nic_bind.py script:
+
+   $ $DPDK_DIR/tools/dpdk_nic_bind.py --bind=igb_uio :01:00.0
+
+Then it can be attached to OVS:
+
+   $ ovs-appctl netdev-dpdk/port-attach :01:00.0
+
+At this point, the user can create a ovs port using the add-port command.
+
+It is also possible to detach a port from ovs, the user has to remove the
+port using the del-port command, then it can be detached using:
+
+   $ ovs-appctl netdev-dpdk/port-detach dpdk0
+
+This feature is not supported with VFIO and could not work with some NICs.
+For more information please refer to the `DPDK Port Hotplug Framework
+`__.
+
 Bug Reporting
 -
 
diff --git a/NEWS b/NEWS
index 3a08dbc..b596cf3 100644
--- a/NEWS
+++ b/NEWS
@@ -41,6 +41,7 @@ Post-v2.6.0
  * New option 'n_rxq_desc' and 'n_txq_desc' fields for DPDK interfaces
which set the number of rx and tx descriptors to use for the given port.
  * Support for DPDK v16.11.
+ * Port Hotplug is now supported.
- Fedora packaging:
  * A package upgrade does not automatically restart OVS service.
- ovs-vswitchd/ovs-vsctl:
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 625f425..677a10c 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -2307,6 +2307,78 @@ netdev_dpdk_set_admin_state(struct unixctl_conn *conn, 
int argc,
 unixctl_command_reply(conn, "OK");
 }
 
+static void
+netdev_dpdk_port_attach(struct unixctl_conn *conn, int argc OVS_UNUSED,
+const char *argv[], void *aux OVS_UNUSED)
+{
+int ret;
+char *response;
+uint8_t port_id;
+
+ovs_mutex_lock(_mutex);
+
+ret = rte_eth_dev_attach(argv[1], _id);
+if (ret < 0) {
+response = xasprintf("Error attaching device '%s'", argv[1]);
+ovs_mutex_unlock(_mutex);
+unixctl_command_reply_error(conn, response);
+return;
+}
+
+response = xasprintf("Device '%s' has been attached as 'dpdk%d'",
+ argv[1], port_id);
+
+ovs_mutex_unlock(_mutex);
+unixctl_command_reply(conn, response);
+}
+
+static void
+netdev_dpdk_port_detach(struct unixctl_conn *conn, int argc OVS_UNUSED,
+const char *argv[], void *aux OVS_UNUSED)
+{
+int ret;
+char *response;
+unsigned int parsed_port;
+uint8_t port_id;
+char devname[RTE_ETH_NAME_MAX_LEN];
+
+ovs_mutex_lock(_mutex);
+
+ret = dpdk_dev_parse_name(argv[1], "dpdk", _port);
+if (ret) {
+response = xasprintf("'%s' is not a valid port", argv[1]);
+goto error;
+}
+
+port_id = parsed_port;
+
+struct netdev *netdev = netdev_from_name(argv[1]);
+if (netdev) {
+netdev_close(netdev);
+response = xasprintf("Port '%s' is being used. Remove it before"
+ "detaching", argv[1]);
+goto error;
+}
+
+rte_eth_dev_close(port_id);
+
+ret = rte_eth_dev_detach(port_id, devname);
+if (ret < 0) {
+response = xasprintf("Port '%s' can not be detached", argv[1]);
+goto error;
+}
+
+response = xasprintf("Port '%s' has been detached", argv[1]);
+
+ovs_mutex_unlock(_mutex);
+unixctl_command_reply(conn, response);
+return;
+
+error:
+ovs_mutex_unlock(_mutex);
+

Re: [ovs-dev] [PATCH] rhel: Support building python ovs package with native json impl

[Aaron Conole]

Although I'm not Flavio, I do have some quick thoughts on this.

Russell Bryant  writes:

> My main concern with this was that it implements a new python-ovs package
> and leaves the existing one alone.  I'd like to figure out how to change
> the existing package so that we always use this approach.

+1.  I don't think this should be split out the way it is here.

Additionally, I'm concerned about a possible future issue with conflicting
files (the openvswitch library file, itself), and ABI versioning.

Rather than build and ship the openvswitch library, would it be possible
to just try and detect it in the python code, and fallback if it doesn't
exist/load?  That would give us a way to handle mismatched ABIs in the
.so, AND prevent possible conflicts with a package that contains the
libopenvswitch.so (which I would assume would just be the openvswitch
package).

Also, FYI (and this is sortof a side-note) the libtool ABI versioning
information hasn't changed since 2014;  bumping / managing that may
become an additional release burden if we start building on top of it,
and expect to ship it around.  Imagine an install of this python package
from ovs 2.7.0 and a future openvswitch package 3.0.0; they currently
both see libtool version tag of 1:0:0

Thanks,
-Aaron

> Added Flavio to CC.
>
> On Mon, Dec 12, 2016 at 5:19 PM, Ben Pfaff  wrote:
>
>> Russell and Terry, I think that probably one of you should review this.
>>
>> Thanks,
>>
>> Ben.
>>
>> On Mon, Nov 28, 2016 at 03:07:05PM +0530, Numan Siddique wrote:
>> > Since building python-openvswitch _json.so requires libopenvswitch.so
>> > a separate spec file is added which configures Open vSwitch with
>> > --enable-shared flag. The resulting RPM also includes the Open vSwitch
>> > shared library.
>> >
>> > $ rpm -qlp python-openvswitch-2.6.90-1.fc25.x86_64.rpm
>> > /usr/lib64/libopenvswitch.so
>> > /usr/lib64/libopenvswitch.so.1
>> > /usr/lib64/libopenvswitch.so.1.0.0
>> > /usr/lib64/python2.7/site-packages/ovs
>> > /usr/lib64/python2.7/site-packages/ovs-2.6.90-py2.7.egg-info
>> > ...
>> > /usr/lib64/python2.7/site-packages/ovs/_json.so
>> > ...
>> >
>> > CC:
>> > Signed-off-by: Numan Siddique 
>> > ---
>> >  INSTALL.Fedora.rst |  13 +
>> >  python/setup.py|   9 ++-
>> >  rhel/automake.mk   |   9 +++
>> >  rhel/python-openvswitch-fedora.spec.in | 103
>> +
>> >  4 files changed, 133 insertions(+), 1 deletion(-)
>> >  create mode 100644 rhel/python-openvswitch-fedora.spec.in
>> >
>> > diff --git a/INSTALL.Fedora.rst b/INSTALL.Fedora.rst
>> > index b9be0ed..40eacfc 100644
>> > --- a/INSTALL.Fedora.rst
>> > +++ b/INSTALL.Fedora.rst
>> > @@ -83,6 +83,8 @@ This will create the RPMs `openvswitch`,
>> `python-openvswitch`,
>> >  `openvswitch-ovn-central`, `openvswitch-ovn-host`,
>> `openvswitch-ovn-vtep`,
>> >  `openvswitch-ovn-docker`, and `openvswitch-debuginfo`.
>> >
>> > +`python-openvswitch` RPM doesn't include the native json library.
>> > +
>> >  To enable DPDK support in the openvswitch package, the ``--with dpdk``
>> option
>> >  can be added:
>> >
>> > @@ -98,6 +100,17 @@ these tests, the ``--without check`` option can be
>> added:
>> >
>> >  $ make rpm-fedora RPMBUILD_OPT="--without check"
>> >
>> > +Open vSwitch python binding RPM with native json library
>> > +
>> > +
>> > +To build the `python-openvswitch` RPM with native json library, run:
>> > +
>> > +
>> > +::
>> > +$ make rpm-fedora-python-ovs
>> > +
>> > +This also builds the Open vSwitch shared library and includes it in the
>> RPM.
>> > +
>> >  Kernel OVS Tree Datapath RPM
>> >  
>> >
>> > diff --git a/python/setup.py b/python/setup.py
>> > index 19c1f18..5070c9b 100644
>> > --- a/python/setup.py
>> > +++ b/python/setup.py
>> > @@ -12,6 +12,7 @@
>> >
>> >  from __future__ import print_function
>> >  import sys
>> > +import os
>> >
>> >  from distutils.command.build_ext import build_ext
>> >  from distutils.errors import CCompilerError, DistutilsExecError, \
>> > @@ -33,6 +34,10 @@ ext_errors = (CCompilerError, DistutilsExecError,
>> DistutilsPlatformError)
>> >  if sys.platform == 'win32':
>> >  ext_errors += (IOError, ValueError)
>> >
>> > +# Get the include path if defined
>> > +include_dirs = os.environ.get('OVS_INCLUDE_DIR', '.')
>> > +library_dirs = os.environ.get('OVS_LIB_DIR', '.')
>> > +
>> >
>> >  class BuildFailed(Exception):
>> >  pass
>> > @@ -77,7 +82,9 @@ setup_args = dict(
>> >  'Programming Language :: Python :: 3.4',
>> >  ],
>> >  ext_modules=[setuptools.Extension("ovs._json",
>> sources=["ovs/_json.c"],
>> > -  libraries=['openvswitch'])],
>> > +  libraries=['openvswitch'],
>> > +  

[ovs-dev] [PATCH 2/2] doc: Add link to manpages guide

[Stephen Finucane]

This was included only in the contents page.

Signed-off-by: Stephen Finucane 
Reported-by: Russell Bryant 
---
 Documentation/index.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/index.rst b/Documentation/index.rst
index f15993f..8484dbd 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -61,7 +61,7 @@ vSwitch? Start here.
 Deeper Dive
 ---
 
-**TODO**
+- **Reference Guides:** :doc:`ref/index`
 
 The Open vSwitch Project
 
-- 
2.9.3

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

Re: [ovs-dev] [PATCH] docs: Add link to man pages.

[Stephen Finucane]

On Tue, 2016-12-13 at 10:57 -0500, Russell Bryant wrote:
> Our new docs site does not yet include all of the man pages.  Add a
> link
> to where they are currently hosted on openvswitch.org.

Working on it :)

> Signed-off-by: Russell Bryant 
> ---
>  Documentation/index.rst | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/index.rst b/Documentation/index.rst
> index f15993f..b2b1be9 100644
> --- a/Documentation/index.rst
> +++ b/Documentation/index.rst
> @@ -61,7 +61,8 @@ vSwitch? Start here.
>  Deeper Dive
>  ---
>  
> -**TODO**
> +Detailed man pages can be found on openvswitch.org
> +(http://openvswitch.org/support/dist-docs/).

Perhaps:

  `openvswitch.org `__

might be a little cleaner? That's a nit though, so...

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

[ovs-dev] [PATCH 4/4] Merge docs into README

[Stephen Finucane]

More readable. Less weird filenames. Winning.

Signed-off-by: Stephen Finucane 
---
 README.md | 156 +++---
 _BUILD|  28 ---
 _DOC  |  78 ---
 _TODO |  40 
 4 files changed, 149 insertions(+), 153 deletions(-)
 delete mode 100644 _BUILD
 delete mode 100644 _DOC
 delete mode 100644 _TODO

diff --git a/README.md b/README.md
index 27a4b31..3f9952f 100644
--- a/README.md
+++ b/README.md
@@ -1,10 +1,152 @@
-openvswitch.github.io
-=
+# openvswitch.github.io
 
-Website for Open vSwitch.
+Website for Open vSwitch. This is written in Jekyll. We use:
 
-Documentation:
+- the templating engine, to format yaml data into html (for the navbar), to use
+  jekyll variables (`page.url`, `site.url`, `page.title`)
 
-* **\_BUILD**: How to generate the website HTML from Jekyll sources.
-* **\_DOC**: Architecture of the website (layouts, directories, ...).
-* **\_TODO**: Unfinished features and improvements.
+- the layout mechanism. Each page includes only its specific content and
+  declare its layout (which is a html file that contains the logo, the navbar,
+  the footer...)
+
+We do not use:
+
+- blog specific mechanisms: we do not have blogs, we do not have posts.  We do
+  not have a `_post/` directory.
+
+## Development
+
+You can develop using `docker-compose`:
+
+$ docker-compose up
+
+You should see your site at http://localhost:4000/
+
+Alternatively, install the Jekyll dependencies (2.x only, for now), then run:
+
+$ jekyll server -w
+
+in the main site directory. This will be available at the
+http://localhost:4000/
+
+## Deployment
+
+GitHub pages supports Jekyll without any further changes. To deploy locally,
+run:
+
+$ jekyll build
+
+in the main site directory. This will output to `_site/`, the contents of which
+can be exported with any static HTTP server.
+
+## Design
+
+### Layouts
+
+The skel (`_layouts/skel.html`) layout contains the header (logo+navbar) and
+the footer. Only the home page uses this.
+
+The page (`_layouts/page.html`) layout "inherits" from the skel layout and adds
+a series of widgets (updates, recent releases, ...) and the title inside the
+mainpage div. Almost every page uses this.
+
+The pagenosidewidget (`_layouts/pagenosidewidget.html`) layout "inherits" from
+the skel layout and adds only the title inside the mainpage div.
+
+The CSS that we use is inspired by the wordpress output (but it's supposed to
+be directly maintainable). It uses heavily fixed sized elements (i.e. we
+explicitly specify the size in px).
+
+Layouts rely on includes
+
+### Includes
+
+We use includes to split html in multiple files. For example the side widgets
+are on `_include/side_widgets.html`.
+
+### Navigation bar
+
+- Style
+
+  The navbar is only a nested series of `` elements (this is in line
+  with current best practices).  The navbar display behavior (display/hide
+  submenus) is implemented only in CSS, in a style tag inside header.html. It
+  should support an unlimited number of nested submenus
+
+- Content:
+
+  Jekyll (at least the safe version used by github pages) does not support a
+  way to generate a page list. Therefore we manually list the pages that we
+  want to appear in the navbar (in order) in `_data/nav.yml`. The url attribute
+  is relative to the parent page.  A bit of templating magic (recursively
+  including `menulist.html`, with different `include.*` variables) allows us to
+  generate the `` elements
+
+The skel layout includes `_includes/header.html` which includes
+`_includes/menulist.html`.
+
+### Pages
+
+Jekyll allows us to write page content in html or markdown. Most of the pages
+are HTML now, since that is the output of the wordpress importer. Pages that
+require advanced styling (e.g. the homepage) should be in html too.
+
+Currently all the pages use a directory URL (e.g.
+http://openvswitch.org/support/) The page is stored in a file called index.html
+(or index.markdown)
+
+Each page has a yaml preamble that contains the title, the layout that we want,
+and some other information extracted by wordpress that it might be worth
+keeping.
+
+## TODO
+
+- Refine style:
+
+  Test with many browsers
+
+- Navigation summary (under the navbar)
+
+  A > B > C
+
+- There are some TODO in the files. grep for them
+
+- Remove useless info from the preamble? (author, ...)
+
+## Open issues
+
+1) Releases
+
+   This repository currently does not host ovs releases as the oldwebsite did.
+
+   Proposals:
+
+   a) do not host them. Let github generate the files through tags
+
+  + simple
+
+  - Is github reliable? does the file change? Some user might expect it to
+have a consistent hash
+
+   b) upload them to the website git repository
+
+2) /cgi-bin/man
+
+   There was a script on the old website that generated updated (from master)
+   man pages (in PDF and HTML). There are some links to 

[ovs-dev] Invitation: OVS-DPDK bi-weekly meeting @ Every 2 weeks from 5pm to 6pm on Thursday from Thu Dec 15 to Thu Jun 29, 2017 (GMT) (d...@openvswitch.org)

[ktraynor]

You have been invited to the following event.

Title: OVS-DPDK bi-weekly meeting
Hi All,

At the OVS-DPDK Meetup after the OVS conference, it was suggested to have a  
regular sync up call between people working on OVS-DPDK. Let's keep it to  
status/plans and keep the technical discussion for the mailing list.


I'd suggest for a first meeting, we collect status for the items identified  
at the meetup  
https://mail.openvswitch.org/pipermail/ovs-dev/2016-November/325217.html

and discuss any new plans or opens anyone wants to talk about.

You can connect to Bluejeans on a computer or through phone dial in, all  
welcome.

https://bluejeans.com/393834449

US: +1.408.740.7256
UK: +44.203.608.5256
Germany: +49.32.221.091256
Ireland: +353.1.697.1256
Other numbers at https://www.bluejeans.com/numbers
Meeting ID: 393834449

thanks
Kevin.
When: Every 2 weeks from 5pm to 6pm on Thursday from Thu Dec 15 to Thu Jun  
29, 2017 Dublin

Where: https://bluejeans.com/393834449
Calendar: d...@openvswitch.org
Who:
* ktray...@redhat.com - organizer
* d...@openvswitch.org

Event details:  
https://www.google.com/calendar/event?action=VIEW=cmRzbXJxdnZqNmF0cDg5MThyc2NncW5vcWcgZGV2QG9wZW52c3dpdGNoLm9yZw=MTkja3RyYXlub3JAcmVkaGF0LmNvbTVjNzQ5OGViNzY1MGEyM2JlMDE2ZDI4ZDkwNWVjM2E3OWE3N2VjZjU=Europe/Dublin=en


Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account d...@openvswitch.org  
because you are an attendee of this event.


To stop receiving future updates for this event, decline this event.  
Alternatively you can sign up for a Google account at  
https://www.google.com/calendar/ and control your notification settings for  
your entire calendar.


Forwarding this invitation could allow any recipient to modify your RSVP  
response. Learn more at  
https://support.google.com/calendar/answer/37135#forwarding
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 1/2] hash: Add P4 based miniflow hash calculation

[Cian Ferriter]

The 'miniflow_hash_ntuple' function which replaces
'miniflow_hash_5tuple' uses the dynamically generated macro,
OVS_HASH_FIELDS, to calculate the hash of a packet. By default, all
standard header fields defined in the P4 input file are hashed. A
subset of the standard header fields can be hashed by declaring a P4
'field list' in the P4 input file with the name 'ovs_hash_list' and
listing the fields which should be hashed.

The 'hash_add_bytes_mask' function is also added to deal with fields
that have an awkward bit size.

This change will make the hash of a packet more relevant in cases
where nonstandard or custom headers are defined in the P4 input file.

Signed-off-by: Cian Ferriter 
---
 include/p4/automake.mk |1 +
 include/p4/plugin/ovs/lib/hash.c.h |   55 
 lib/dpif-netdev.c  |2 +-
 lib/flow.c |   44 
 lib/flow.h |8 -
 lib/hash.c |   16 ++
 lib/hash.h |1 +
 7 files changed, 87 insertions(+), 40 deletions(-)
 create mode 100644 include/p4/plugin/ovs/lib/hash.c.h

diff --git a/include/p4/automake.mk b/include/p4/automake.mk
index 66b8a5e..810568d 100644
--- a/include/p4/automake.mk
+++ b/include/p4/automake.mk
@@ -8,6 +8,7 @@ EXTRA_DIST += \
include/p4/plugin/ovs/include/openvswitch/types.h.h \
include/p4/plugin/ovs/lib/dp-packet.h.h \
include/p4/plugin/ovs/lib/flow.c.h \
+   include/p4/plugin/ovs/lib/hash.c.h \
include/p4/plugin/ovs/lib/match.c.h \
include/p4/plugin/ovs/lib/meta-flow.c.h \
include/p4/plugin/ovs/lib/nx-match.c.h \
diff --git a/include/p4/plugin/ovs/lib/hash.c.h 
b/include/p4/plugin/ovs/lib/hash.c.h
new file mode 100644
index 000..d4ace47
--- /dev/null
+++ b/include/p4/plugin/ovs/lib/hash.c.h
@@ -0,0 +1,55 @@
+/*
+ * Copyright (c) 2016 Nicira, Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may 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.
+ */
+//::
+//:: import helpers
+//:: aligned_field_info = helpers.get_align_field_info(field_info, 
header_info, ordered_header_instances_all)
+//:: ordered_header_instances_non_virtual = 
helpers.get_ordered_header_instances_non_virtual(ordered_header_instances_non_virtual)
+//:: (_, ordered_header_instances_non_virtual_aligned_field__name_width) = 
helpers.get_ordered_header_and_aligned_field_instances_non_virtual__name_width(
+//::   
 ordered_header_instances_non_virtual,
+//::   
 header_info, aligned_field_info)
+
+#ifndef OVS_LIB_HASH_C_H
+#define OVS_LIB_HASH_C_H 1
+
+/* -- Used in lib/flow.c -- */
+#define OVS_HASH_FIELDS \
+\
+if (flow) { \
+//::  for header_name in ordered_header_instances_regular:
+//::for field_name, bit_width in 
ordered_header_instances_non_virtual_field__name_width[header_name]:
+//::  if "ovs_hash_list" in field_lists:
+//::if field_name not in [hash_field[1] for hash_field in 
field_lists["ovs_hash_list"]]:
+//::  continue
+//::#endif
+//::  #endif
+//::  if bit_width == 8:
+hash = hash_add(hash, MINIFLOW_GET_U8(flow, 
${header_name}.hdr.${field_name})); \
+//::  elif bit_width in [16, 32]:
+hash = hash_add(hash, MINIFLOW_GET_BE${bit_width}(flow, 
${header_name}.hdr.${field_name})); \
+//::  elif bit_width == 64:
+hash = hash_add64(hash, MINIFLOW_GET_BE64(flow, 
${header_name}.hdr.${field_name})); \
+//::  else:
+//::# NOTE: we assume that all fields are, at least, byte aligned.
+hash = hash_add_bytes_mask(hash, (uint32_t 
*)MINIFLOW_GET_ADDRESS(flow, \
+struct ${field_name}_t, ${header_name}.hdr.${field_name}), 
sizeof(struct ${field_name}_t)); \
+//::  #endif
+//::#endfor
+\
+//::  #endfor
+} \
+\
+
+#endif  /* OVS_LIB_HASH_C_H */
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 5049b40..232bddf 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -3837,7 +3837,7 @@ dpif_netdev_packet_get_rss_hash(struct dp_packet *packet,
 if (OVS_LIKELY(dp_packet_rss_valid(packet))) {
 hash = dp_packet_get_rss_hash(packet);
 } else {
-hash = miniflow_hash_5tuple(mf, 0);
+hash = miniflow_hash_ntuple(mf, 0);
 dp_packet_set_rss_hash(packet, 

[ovs-dev] [PATCH 4/5] doc: Document Patchwork instance

[Stephen Finucane]

I know more than a little bit about this :)

Signed-off-by: Stephen Finucane 
---
 Documentation/automake.mk |  1 +
 Documentation/index.rst   |  1 +
 Documentation/internals/index.rst |  1 +
 Documentation/internals/patchwork.rst | 61 +++
 4 files changed, 64 insertions(+)
 create mode 100644 Documentation/internals/patchwork.rst

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index ffb8ae3..8bf1e07 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -64,6 +64,7 @@ EXTRA_DIST += \
Documentation/internals/committer-responsibilities.rst \
Documentation/internals/mailing-lists.rst \
Documentation/internals/maintainers.rst \
+   Documentation/internals/patchwork.rst \
Documentation/internals/release-process.rst \
Documentation/internals/security.rst \
Documentation/internals/contributing/index.rst \
diff --git a/Documentation/index.rst b/Documentation/index.rst
index ca367f1..d682651 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -82,6 +82,7 @@ Learn more about the Open vSwitch project and about how you 
can contribute:
 - **Community:** :doc:`internals/release-process` |
   :doc:`internals/authors` |
   :doc:`internals/mailing-lists` |
+  :doc:`internals/patchwork` |
   :doc:`internals/bugs` |
   :doc:`internals/security`
 
diff --git a/Documentation/internals/index.rst 
b/Documentation/internals/index.rst
index 9588861..b0ae9b4 100644
--- a/Documentation/internals/index.rst
+++ b/Documentation/internals/index.rst
@@ -35,6 +35,7 @@ itself and how they might involved.
 
contributing/index
mailing-lists
+   patchwork
release-process
bugs
security
diff --git a/Documentation/internals/patchwork.rst 
b/Documentation/internals/patchwork.rst
new file mode 100644
index 000..3ae0d95
--- /dev/null
+++ b/Documentation/internals/patchwork.rst
@@ -0,0 +1,61 @@
+..
+  Copyright (C) 2016, Stephen Finucane 
+
+  Licensed under the Apache License, Version 2.0 (the "License"); you may
+  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.
+
+=
+Patchwork
+=
+
+Open vSwitch uses `Patchwork`__ to track the status of patches sent to the
+:doc:`ovs-dev mailing list `. The Open vSwitch Patchwork
+instance can be found on `ozlabs.org`__. The ``pwclientrc`` file, required for
+*pwclient*, can be found on the `project page`__
+
+Patchwork provides a number of useful features for developers working on Open
+vSwitch:
+
+- Tracking the lifecycle of patches (accepted, rejected, under-review, ...)
+- Assigning reviewers (delegates) to patches
+- Downloading/applying patches via the web UI or the XML-RPC API (see
+  :ref:`pwclient`)
+- A usable UI for viewing patch discussions
+
+__ https://github.com/getpatchwork/patchwork
+__ https://patchwork.ozlabs.org/project/openvswitch/list/
+__ https://patchwork.ozlabs.org/project/openvswitch/
+
+.. _pwclient:
+
+pwclient
+
+
+The *pwclient* tool provides an way to download and apply patches, change the
+state of patches in Patchwork, and more. You can download *pwclient* from
+`here`__. Once downloaded, run::
+
+$ pwclient help
+
+to get more information about the functionality pwclient provides.
+
+__ https://patchwork.ozlabs.org/pwclient/
-- 
2.9.3

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

[ovs-dev] [PATCH 3/5] doc: Move testing to testing section

[Stephen Finucane]

This makes more sense here, seeing as it's not exactly installation
related.

Signed-off-by: Stephen Finucane 
---
 Documentation/intro/install/general.rst | 348 +--
 Documentation/topics/testing.rst| 359 +++-
 2 files changed, 359 insertions(+), 348 deletions(-)

diff --git a/Documentation/intro/install/general.rst 
b/Documentation/intro/install/general.rst
index 89b4e74..371643a 100644
--- a/Documentation/intro/install/general.rst
+++ b/Documentation/intro/install/general.rst
@@ -436,7 +436,8 @@ and ``vif1.0`` to it::
 $ ovs-vsctl add-port br0 eth0
 $ ovs-vsctl add-port br0 vif1.0
 
-Refer to ovs-vsctl(8) for more details.
+Refer to ovs-vsctl(8) for more details. You may also wish to refer to
+:doc:`/topics/testing` for information on more generic testing of OVS.
 
 Upgrading
 -
@@ -511,351 +512,6 @@ above, but also replaces the old kernel module with the 
new one. Open vSwitch
 startup scripts for Debian, XenServer and RHEL use ovs-ctl's functions and it
 is recommended that these functions be used for other software platforms too.
 
-.. _general-testing:
-
-Testing

-
-This section describe Open vSwitch's built-in support for various test
-suites. You must bootstrap, configure and build Open vSwitch (steps are
-in "Building and Installing Open vSwitch for Linux, FreeBSD or NetBSD"
-above) before you run the tests described here. You do not need to
-install Open vSwitch or to build or load the kernel module to run these
-test suites. You do not need supervisor privilege to run these test
-suites.
-
-Unit Tests
-~~
-
-Open vSwitch includes a suite of self-tests. Before you submit patches
-upstream, we advise that you run the tests and ensure that they pass. If you
-add new features to Open vSwitch, then adding tests for those features will
-ensure your features don't break as developers modify other areas of Open
-vSwitch.
-
-To run all the unit tests in Open vSwitch, one at a time, run::
-
-$ make check
-
-This takes under 5 minutes on a modern desktop system.
-
-To run all the unit tests in Open vSwitch in parallel, run::
-
-$ make check TESTSUITEFLAGS=-j8
-
-You can run up to eight threads. This takes under a minute on a modern 4-core
-desktop system.
-
-To see a list of all the available tests, run:
-
-$ make check TESTSUITEFLAGS=--list
-
-To run only a subset of tests, e.g. test 123 and tests 477 through 484, run::
-
-$ make check TESTSUITEFLAGS='123 477-484'
-
-Tests do not have inter-dependencies, so you may run any subset.
-
-To run tests matching a keyword, e.g. ``ovsdb``, run::
-
-$ make check TESTSUITEFLAGS='-k ovsdb'
-
-To see a complete list of test options, run::
-
-$ make check TESTSUITEFLAGS=--help
-
-The results of a testing run are reported in ``tests/testsuite.log``. Report
-report test failures as bugs and include the ``testsuite.log`` in your report.
-
-.. note::
-  Sometimes a few tests may fail on some runs but not others. This is usually a
-  bug in the testsuite, not a bug in Open vSwitch itself. If you find that a
-  test fails intermittently, please report it, since the developers may not
-  have noticed. You can make the testsuite automatically rerun tests that fail,
-  by adding ``RECHECK=yes`` to the ``make`` command line, e.g.::
-
-  $ make check TESTSUITEFLAGS=-j8 RECHECK=yes
-
-Coverage
-
-
-If the build was configured with ``--enable-coverage`` and the ``lcov`` utility
-is installed, you can run the testsuite and generate a code coverage report by
-using the ``check-lcoc`` target::
-
-$ make check-lcov
-
-All the same options are avaiable via TESTSUITEFLAGS. For example::
-
-$ make check-lcov TESTSUITEFLAGS=-j8 -k ovn
-
-Valgrind
-
-
-If you have ``valgrind`` installed, you can run the testsuite under
-valgrind by using the ``check-valgrind`` target::
-
-$ make check-valgrind
-
-When you do this, the "valgrind" results for test  are reported in files
-named ``tests/testsuite.dir//valgrind.*``.
-
-All the same options are available via TESTSUITEFLAGS.
-
-.. hint::
-  You may find that the valgrind results are easier to interpret if you put
-  ``-q`` in ``~/.valgrindrc``, since that reduces the amount of output.
-
-.. _general-oftest:
-
-OFTest
-~~
-
-OFTest is an OpenFlow protocol testing suite. Open vSwitch includes a Makefile
-target to run OFTest with Open vSwitch in "dummy mode". In this mode of
-testing, no packets travel across physical or virtual networks.  Instead, Unix
-domain sockets stand in as simulated networks. This simulation is imperfect,
-but it is much easier to set up, does not require extra physical or virtual
-hardware, and does not require supervisor privileges.
-
-To run OFTest with Open vSwitch, first read and follow the instructions under
-**Testing** above. Second, obtain a copy of OFTest and install its
-prerequisites. You need a copy of OFTest that includes commit 

[ovs-dev] [PATCH 1/5] doc: Use higher resolution logo

[Stephen Finucane]

Rework the logo to remove much of the white background and increase
resolution.

Signed-off-by: Stephen Finucane 
---
 Documentation/_static/logo.png | Bin 13341 -> 672215 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/Documentation/_static/logo.png b/Documentation/_static/logo.png
index 
11d7fdc561f47d404792f2529c53521567139c16..c2c021bf752ea8d5d1e8d1eabc89b9762d351557
 100644
GIT binary patch
literal 672215
zcmeHw3$$Lvb>6{`#Eu&-X;^t2q-iZdAz5vWWUwe%wj}dtLJbmNoR>kCaUDA#
z=|b8h=1K^fI5i*)dD%t??8FH#iKcD9fJCxZS{#s^)jD`#OL;q8LBuPGn+N^BU)uN1
zJ^z_Gv*~x;p1SXJ*fyZ)WzMJ+o)du8S^s+c$p0>%O6?s&8EP_Vd2Ks!sZ=
z(ccBH`nu7RAOGMvdq$U6T($Q6wN>@NM_%)HKlsYg@2~rz4R1TIdI|qN{+svSI(qWz
z54?TjhpKAk2l02(edpY}dGzq>e|+8f-}m)jdd=)>-uOM|zw6yAs%k~G?!2`ZZ#${l
zys&%zq?cZLX%tI?U<6WD&`E;JsjMjiihv?O2&9mEQ!DRYK`83A7X(r?UJm0v`AuzS
z-~g#{6#+#c8UY`96qAXI{-EWYD)yLWFBx|f*OvK4ERq~U~fGTV9
zjXp_*0AVbyL!>I8(oqBkf^ffOf8F$g0u@=O)`Qaw}UEIko)ckI})>hPgMY>rm1
zS;J1#VFJQjOo!;O?3$G#AQ=Jbo4xZ0xd-{@6MB|+gjw(MOci@II;>YfIC$W|xbdP9
zA3bt(@&3gZUrff`$tRy^`iW@cu__j7Y|<7=`^!U$0v^xh%D*w<8wz@QMI
z{@7We_V3#_He8^ywjPSw0=<;oK>Zl+qlVM7-(t`}K0jY__g
z#!HP2*7(6uBZhK+>fk|oT*MXDK1RH-_yBqDo2@A1kxgqO)i>>911;^QIn$h
zFlg3oSf5+TcP_`KNwH^ZxMl+*MSlExph`KdZsya+y{YKY88D^aQRuv5bW|?QMiJ;6
zfh=+n%KW~)d#gwG?H8rUU0`>hxp$<{KXvbYMMDMIcGc$1)uo#@rY=V(GHl3-
zJ$a)wYq-P_smXupdm8OtI#TjYmi)i}H$StG!WW={?@l^OL%#Y*5f}mj$>rpId+)7a
z?3A|j*jAaDlzo2rwRvIp{7^N0^45!10C!Gm#a()Uw6#EK@8PNnPn8VAU$dzBdx)8v
z-YWvbKp?4Xy!ob^ikg29t-=giKCAp1nqp7dXsHokIEs1qNA~ZhM|$-{;F67(j+K1I
zeJEKwh-Wc1nj%mF0!ic}rZ4ZjXk3SEir?}qx$GK(
zVo%awP2g3bn`orHPdwtSGso>9Ke+8RznsYzpw629Rs=*K5G^lZvEQ(LesGKGF|~s&
zL{Ritf=m#?F`!$x1%Dv6{$WEghCR6#TT0Oif@+)0Mpd$pL<)m8d
z?wVS+etmW8?%Umw{N5&$U8O4a=*CJot3oFv`nf{E!_EGx%~z*pAXz6#&6v_t1Uf<>
zN=~Yk?q5rZtoLLxt3<^f)mY7{(vhf%M!)yy7}ssvmU=xtSx4y?9nD=4U?UJECsj7G
z@g66Dc1m4b?;%C(Yb^)2>RlubHUGxQBzvb=$V4JPjvFN9h5b
zjW2uf57if-2jB;mWw6{-i#@(2NKo{pDEZ)qYE~1b;ISXG^y8DvG7a_qJy%~fw
zuT*895CSDN1qcMoN*piuuFEc0f1?DA1jfoI@7WVWDN0_IpxA>Os)?#jGnr_VagVk5
zYe$xRA`es)I;yjjftqqT1HOI7OWTMf4UKJf5EF@%HVm2|}()JRPv(O@wJKeTfY
z%`y)CUix0rq2sURD+Yled8tZ0U;RS4!+XBzJZ{figOs~u#U9j1O|UTSe%HtDG#}}G
z!3bQtb!#e5`k>BIFm$O|KjrP8ezW=lq((I@J+}N*1)sJ8nyA5H7*q84W_Cabl3P-h
zJiCFKfWaB$n)hx|r#Tapf!rrp$08(xIt(S_0k+IkrQTf)Vu|swC!Yw-kS(iT
z7MfG0bZDIH25Rzxv)?az$N8$%O;84OkL8s!Pdk15ZQaOXMYXfYyfwKZkP-oQTUMo>
z68?5tIJ*48kzNW6?E00Y*xAh2LBcfr`?tJLJv{5c4D2^f47~F4E5^GWB8!GL7v1h6
zdC=sFK?(QtuS*#munn`ugqL7k}rxkunt@C0uptJ!cbvtAuK4PQrOx_;|4{dCp0mUbBeY}tvA
zy{J-OhGFMF;OLF-mIMU<`rf>-d%kb&?$2!l6gn5*0Lm0TqPhCO9%CXF)gDbkdanpb
zLje6l_XNwR73eOkk>m<}@p8GEMY(h(ob^~Pddhi02(aZRyinC-ms7(L
zuJf()@_k$EY?N_kEcUjkQfEUq6$#KTB0W~v0&^;W)j~!h@PGgC{?WeX71g@))?OS*
zDl$3brz-eJ5ECbd8$GP}9HB4kJxGv3!Q;?l{o+fGrZ6m;2|ldcIzk>6Vp^Jl5Maqq
zI3{5$kp`Ivd}7bt)#^2CxXd}_Qy+?*)hMa7>K0E(=+zg2J`Z*F)F2aq!0CCXV()rdp4A|!8sKoCC(;ladi6yBGdnmj0)xW95Y%1+^U`FBfDZz!
zHi@ZTRq8_7^8`O5WKHy0qAxjM!k+lNM~q=yP8LA`fy#HqOzpFCQ9D5lDc5w;Vlq
z;K2Blr}jKQdh4TqA;TA-o!9Az5imV(l~G+;@7@j5tU^`rCK`GliU1sl;HMF>?IfuE
zhVrZF6afnYtagYE?HbBK0N*2L25WohLa|#jcNIdFx(gkB$3+0j9bUo_A*dZkBXAQ$K+biHBxcmcPGm;Vdqp4<0^V&8j-!w4-=B$%
zuF3xAm;dRjrqdT7(7|q^f^s_5c{fVpiWI!=UnfM4U$ISMc5ZI;H(Slj%v38^tr}mK
z$6ESz^vKbXhxnJr118*Ki9=^Xmhiz{ignvtcCoF%WQ?XJ
zgs(%bT(xpcc5d#}u^gm4NY)*{9vQ^hCvXCO`q^iwh(6Z|d6Y}BdpAOpYdAYi>v_kh
zOekzL;F+0IPF#;GaTBAMdnkAeo@mPM@S(#~t@I<0sGaCcF?FM96@eB6yk#nuo=P^3
zNRi_(mw*FZ#@k*W*|`W!Gn6*nP^awvB1252_qX*?eumiW32>~Zqyd}w
z#oWVr1IqrX0|$%k2%+VVQ0^0*DU=6IrwFtl;4M=zC4cVO=d_TM_Zo)HrJFX6{x(%}
zquI$+0dfsag{3W1Fb}htkVPUCI}TUCH}9q);FPr0YgSk5H*6SN=+epzs~(CTBi?E8
zu)TKc*6OOwSBF%^M289?qG=R?76iN%dug&13hb)Qo5xDM1%s&981TS?hmudXEV<
zJ3gJy7k~yk*KOOzDf@&>O0DF*8zXUz(bbigUqL?ydBxf;rrcqvryQB)25an`Gg9_Y
z`Xx{E`QUW_Ll1@yx+Xf6PktIl5nv$TEmuoAVwO4e%z(=t6*3LmVI|5l=!t8$Z4J>8
z6EY~JV)t%*1Uo>+akA+~Q$)G{D=G<7?U-sBO2Eh$1F_PkxP0(uPJ@{wCpwk+QtuUk
zNCdp)YAHq%W-u3a?g$-7N5XkLxuj)a$etTVctkACPRgLo3%log)$XNxeKa*Qc!Hp&
zN;1!z%HetjDFRpAp?N+=xXw@ZE*F6MP7&}+1aZ(pa|QML4NVG+0hKiS!GF{pH>2>~x950BW3`E)o?yfz>5;3FhI6ZCtG~C
zUJZ}9!9x2GzG8qW6?lU@_T&?TT3Dxg;#}cwj?)%^#}Go`;q$D1Fa(^m3~~^_;T2K?
zEY*dbJEgKWUi`Do`at%%&@9=?<7@*K@-F>@6)|T-E<0O~d!ocSKhaXCX!ru8!aAA`Mxapa

Re: [ovs-dev] [PATCH v6] netdev-dpdk: Enable Rx checksum offloading feature on DPDK physical ports.

[Ben Pfaff]

On Tue, Dec 13, 2016 at 10:19:53AM +, Chandran, Sugesh wrote:
> Hi Ben,
> 
> Regards
> _Sugesh
> 
> > -Original Message-
> > From: Ben Pfaff [mailto:b...@ovn.org]
> > Sent: Monday, December 12, 2016 10:24 PM
> > To: Chandran, Sugesh 
> > Cc: d...@openvswitch.org; je...@kernel.org
> > Subject: Re: [ovs-dev] [PATCH v6] netdev-dpdk: Enable Rx checksum
> > offloading feature on DPDK physical ports.
> > 
> > On Mon, Nov 28, 2016 at 03:24:24PM +, Sugesh Chandran wrote:
> > > Add Rx checksum offloading feature support on DPDK physical ports. By
> > > default, the Rx checksum offloading is enabled if NIC supports.
> > > However, the checksum offloading can be turned OFF either while adding
> > > a new DPDK physical port to OVS or at runtime.
> > >
> > > The rx checksum offloading can be turned off by setting the parameter
> > > to 'false'. For eg: To disable the rx checksum offloading when adding
> > > a port,
> > >
> > >  'ovs-vsctl add-port br0 dpdk0 -- \
> > >   set Interface dpdk0 type=dpdk options:rx-checksum-offload=false'
> > >
> > > OR (to disable at run time after port is being added to OVS)
> > >
> > > 'ovs-vsctl set Interface dpdk0 options:rx-checksum-offload=false'
> > >
> > > Similarly to turn ON rx checksum offloading at run time,
> > >
> > > 'ovs-vsctl set Interface dpdk0 options:rx-checksum-offload=true'
> > >
> > > The Tx checksum offloading support is not implemented due to the
> > > following reasons.
> > >
> > > 1) Checksum offloading and vectorization are mutually exclusive in
> > > DPDK poll mode driver. Vector packet processing is turned OFF when
> > > checksum offloading is enabled which causes significant performance drop
> > at Tx side.
> > >
> > > 2) Normally, OVS generates checksum for tunnel packets in software at
> > > the 'tunnel push' operation, where the tunnel headers are created.
> > > However enabling Tx checksum offloading involves,
> > >
> > >   *) Mark every packets for tx checksum offloading at 'tunnel_push' and
> > >   recirculate.
> > >   *) At the time of xmit, validate the same flag and instruct the NIC to 
> > > do
> > the
> > >   checksum calculation.  In case NIC doesnt support Tx checksum 
> > > offloading,
> > >   the checksum calculation has to be done in software before sending out
> > the
> > >   packets.
> > >
> > > No significant performance improvement noticed with Tx checksum
> > > offloading due to the e overhead of additional validations + non vector
> > packet processing.
> > > In some test scenarios, it introduces performance drop too.
> > >
> > > Rx checksum offloading still offers 8-9% of improvement on VxLAN
> > > tunneling decapsulation even though the SSE vector Rx function is
> > > disabled in DPDK poll mode driver.
> > >
> > > Signed-off-by: Sugesh Chandran 
> > > Acked-by: Jesse Gross 
> > 
> > Why would a user want to turn off checksum offloading?  The patch and the
> > documentation does not explain why, and it seems strange to offer an
> > optimization that a user would not want to use.
> [Sugesh] In DPDK, The vectorization get turned off when checksum offloading 
> is enabled, which impacts the
> performance of smaller(64 bytes) packet traffic. The performance gain offered 
> by checksum offload alleviates the vectorization impact in
> tunneling decapsulation. However it is not the case for non tunnel traffic. 
> We also noticed the impact of vectorization is not very significant for 
> larger packets >256 bytes for any type of traffic. 
> Considering all these aspects and according to the previous communications on 
> this patch, we decided to give flexibility to user to turn ON/OFF checksum. 
> So that a user who have only non tunnel traffic(with smaller packets) can 
> turn off the checksum offload to get the same old good performance. By 
> default the checksum offload is in ON state.
> 
> Do you think this information must be mentioned in the documentation? There 
> are lot of parameters involved in there for a normal user to decide upon the 
> checksum offload ON/OFF. Considering the style of documentation which talks 
> only about the available configuration options and its syntax, do we have to 
> put all these information which may cause confusion? 
> As you mentioned, I can provide these details in the commit message. Do you 
> think it is suffice?

I think that the documentation should try to explain.  Users will not
read commit messages.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next 17/27] OVS: remove assumptions about VLAN_TAG_PRESENT bit

[Jiri Benc]

On Tue, 13 Dec 2016 01:12:38 +0100 (CET), Michał Mirosław wrote:
> @@ -850,20 +848,11 @@ static int validate_vlan_from_nlattrs(const struct 
> sw_flow_match *match,
>   return -EINVAL;
>   }
>  
> - if (a[OVS_KEY_ATTR_VLAN])
> - tci = nla_get_be16(a[OVS_KEY_ATTR_VLAN]);
> -
> - if (!(tci & htons(VLAN_TAG_PRESENT))) {
> - if (tci) {
> - OVS_NLERR(log, "%s TCI does not have VLAN_TAG_PRESENT 
> bit set.",
> -   (inner) ? "C-VLAN" : "VLAN");
> - return -EINVAL;
> - } else if (nla_len(a[OVS_KEY_ATTR_ENCAP])) {
> - /* Corner case for truncated VLAN header. */
> - OVS_NLERR(log, "Truncated %s header has non-zero encap 
> attribute.",
> -   (inner) ? "C-VLAN" : "VLAN");
> - return -EINVAL;
> - }
> + if (!a[OVS_KEY_ATTR_VLAN] && nla_len(a[OVS_KEY_ATTR_ENCAP])) {
> + /* Corner case for truncated VLAN header. */
> + OVS_NLERR(log, "Truncated %s header has non-zero encap 
> attribute.",
> + (inner) ? "C-VLAN" : "VLAN");
> + return -EINVAL;

This looks wrong. The zero value of nla_get_be16(a[OVS_KEY_ATTR_VLAN])
together with empty a[OVS_KEY_ATTR_ENCAP] means truncated VLAN header
and this needs to be preserved.

In other words, you need to check also !nla_get_be16(a[OVS_KEY_ATTR_VLAN])
here.


Overall, this whole patch looks very suspicious from the very
beginning. The xors used are strong indication that something is not
right.

And indeed, you're breaking uAPI compatibility. Previously, the
VLAG_TAG_PRESENT bit set in OVS_KEY_ATTR_VLAN caused the flow to match
on packets with VLAN tag present. After this patch, it causes the flow
to match only on those packets that have a certain value of
VLAN_CFI_MASK in their VLAN tag (I haven't bother deciphering what
value is checked after all these xors, it's as well possible that it
will also match on packets _without_ any VLAN header).

You have to preserve the old meaning of VLAN_TAG_PRESENT in
OVS_KEY_ATTR_VLAN. When doing flow lookups, VLAN_TAG_PRESENT must match
on and only on packets that have VLAN tag present, irrespective of their
VLAN_CFI_MASK.

If you want to introduce support for lookups on VLAN_CFI_MASK, you'll
have to do that by introducing a new netlink attribute.

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

Re: [ovs-dev] [PATCH v6] netdev-dpdk: Enable Rx checksum offloading feature on DPDK physical ports.

[Chandran, Sugesh]

Hi Ben,

Regards
_Sugesh

> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Monday, December 12, 2016 10:24 PM
> To: Chandran, Sugesh 
> Cc: d...@openvswitch.org; je...@kernel.org
> Subject: Re: [ovs-dev] [PATCH v6] netdev-dpdk: Enable Rx checksum
> offloading feature on DPDK physical ports.
> 
> On Mon, Nov 28, 2016 at 03:24:24PM +, Sugesh Chandran wrote:
> > Add Rx checksum offloading feature support on DPDK physical ports. By
> > default, the Rx checksum offloading is enabled if NIC supports.
> > However, the checksum offloading can be turned OFF either while adding
> > a new DPDK physical port to OVS or at runtime.
> >
> > The rx checksum offloading can be turned off by setting the parameter
> > to 'false'. For eg: To disable the rx checksum offloading when adding
> > a port,
> >
> >  'ovs-vsctl add-port br0 dpdk0 -- \
> >   set Interface dpdk0 type=dpdk options:rx-checksum-offload=false'
> >
> > OR (to disable at run time after port is being added to OVS)
> >
> > 'ovs-vsctl set Interface dpdk0 options:rx-checksum-offload=false'
> >
> > Similarly to turn ON rx checksum offloading at run time,
> >
> > 'ovs-vsctl set Interface dpdk0 options:rx-checksum-offload=true'
> >
> > The Tx checksum offloading support is not implemented due to the
> > following reasons.
> >
> > 1) Checksum offloading and vectorization are mutually exclusive in
> > DPDK poll mode driver. Vector packet processing is turned OFF when
> > checksum offloading is enabled which causes significant performance drop
> at Tx side.
> >
> > 2) Normally, OVS generates checksum for tunnel packets in software at
> > the 'tunnel push' operation, where the tunnel headers are created.
> > However enabling Tx checksum offloading involves,
> >
> >   *) Mark every packets for tx checksum offloading at 'tunnel_push' and
> >   recirculate.
> >   *) At the time of xmit, validate the same flag and instruct the NIC to do
> the
> >   checksum calculation.  In case NIC doesnt support Tx checksum offloading,
> >   the checksum calculation has to be done in software before sending out
> the
> >   packets.
> >
> > No significant performance improvement noticed with Tx checksum
> > offloading due to the e overhead of additional validations + non vector
> packet processing.
> > In some test scenarios, it introduces performance drop too.
> >
> > Rx checksum offloading still offers 8-9% of improvement on VxLAN
> > tunneling decapsulation even though the SSE vector Rx function is
> > disabled in DPDK poll mode driver.
> >
> > Signed-off-by: Sugesh Chandran 
> > Acked-by: Jesse Gross 
> 
> Why would a user want to turn off checksum offloading?  The patch and the
> documentation does not explain why, and it seems strange to offer an
> optimization that a user would not want to use.
[Sugesh] In DPDK, The vectorization get turned off when checksum offloading is 
enabled, which impacts the
performance of smaller(64 bytes) packet traffic. The performance gain offered 
by checksum offload alleviates the vectorization impact in
tunneling decapsulation. However it is not the case for non tunnel traffic. We 
also noticed the impact of vectorization is not very significant for larger 
packets >256 bytes for any type of traffic. 
Considering all these aspects and according to the previous communications on 
this patch, we decided to give flexibility to user to turn ON/OFF checksum. So 
that a user who have only non tunnel traffic(with smaller packets) can turn off 
the checksum offload to get the same old good performance. By default the 
checksum offload is in ON state.

Do you think this information must be mentioned in the documentation? There are 
lot of parameters involved in there for a normal user to decide upon the 
checksum offload ON/OFF. Considering the style of documentation which talks 
only about the available configuration options and its syntax, do we have to 
put all these information which may cause confusion? 
As you mentioned, I can provide these details in the commit message. Do you 
think it is suffice?


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

Re: [ovs-dev] assertion failing in commit_set_ipv4_action(), flow->nw_proto != base_flow->nw_proto

[Thomas Morin]

Hi Jarno,

2016-12-10, Jarno Rajahalme:
On Dec 9, 2016, at 7:04 AM, Thomas Morin > wrote:


2016-12-09, Thomas Morin:

In the same setup as the one on which the bug was observed, [...]


I was confused, I in fact tested the patch (branch-2.5) on a 
/different/ setup as the one on which we hit the bug, using MPLS over 
a GRE tunnel port, rather than plain MPLS over an eth port.
Sorry if any confusion arised... I can test on the first setup if 
relevant.




Maybe the kernel datapath does not support MPLS over a GRE tunnel 
port. Having ‘dmesg’ output for the test run might reveal why the 
actions validation fails.


The dmesg output was the following:

[171295.258939] openvswitch: netlink: Flow actions may not be safe on 
all matching packets.


I've tested the patch on the platform on which the bug was initially hit 
(*not* using MPLS/GRE), and I have the following a few times in the logs 
right after I do an "ovs-appctl fdb/flush":


2016-12-13T09:44:08.449Z|1|dpif(handler68)|WARN|Dropped 3 log 
messages in last 1 seconds (most recently, 1 seconds ago) due to 
excessive rate
2016-12-13T09:44:08.449Z|2|dpif(handler68)|WARN|system@ovs-system: 
failed to put[create] (Invalid argument) 
ufid:f046c4c4-b97f-436d-bd7c-91ed307275ac 
recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(9),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=fa:16:3e:61:c0:b5,dst=00:00:5e:00:43:64),eth_type(0x0800),ipv4(src=10.0.1.29,dst=10.0.0.3,proto=6,tos=0/0xfc,ttl=64,frag=no),tcp(src=54253,dst=8080),tcp_flags(0/0), 
actions:set(ipv4(src=10.0.1.29,dst=10.0.0.3,ttl=63)),set(eth(src=b8:2a:72:de:1b:e3,dst=00:17:cb:79:2c:01)),push_mpls(label=433680,tc=0,ttl=63,bos=1,eth_type=0x8847),7,set(eth(src=fa:16:3e:61:c0:b5,dst=00:00:5e:00:43:64)),pop_mpls(eth_type=0x800),set(ipv4(src=10.0.1.29,dst=10.0.0.3,tos=0/0xfc,ttl=64)),push_vlan(vid=1,pcp=0),3,8,pop_vlan,13


And dmesg:
[926833.612372] openvswitch: netlink: Flow actions may not be safe on 
all matching packets.


-Thomas






On Dec 1, 2016, at 5:57 PM, Jarno Rajahalme > wrote:



On Nov 30, 2016, at 8:50 PM, Ben Pfaff > wrote:


On Wed, Nov 30, 2016 at 06:58:57PM -0800, Jarno Rajahalme wrote:


On Nov 30, 2016, at 8:41 AM, Ben Pfaff > wrote:


On Wed, Nov 30, 2016 at 12:05:46PM +0100, Thomas Morin wrote:

Hi Ben,

2016-11-30, Ben Pfaff:
Do you have any idea what in your OpenFlow pipeline might do 
that,

i.e. is there anything especially tricky in the OpenFlow flows?

Are you willing to show us your OpenFlow flow table?


The setup involves three OVS bridges connected with 
patch-ports: br-int --
br-tun -- br-mpls, with the traffic that triggers the assert 
being processed

by br-int with a NORMAL action (ie. MAC learning).

The flows in this setup aren't particularly tricky, I think, 
although I'm

not sure what qualifies as tricky or non-tricky :)

Anyway, since yesterday I managed to identify the event that 
trigger the
assert, by adding more logging before the assert and 
displaying the actions

taken:

2016-11-29T14:44:40.126Z|1|odp_util(revalidator45)|WARN|commit_set_ipv4_action
assert would fail
2016-11-29T14:44:40.126Z|2|odp_util(revalidator45)|WARN| 
 base_flow: 
ip,in_port=5,dl_vlan=3,dl_vlan_pcp=0,dl_src=fa:16:3e:33:f7:fe,dl_dst=00:00:5e:00:43:64,nw_src=0.0.0.0,nw_dst=0.0.0.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
2016-11-29T14:44:40.126Z|3|odp_util(revalidator45)|WARN| 
 flow: 
tcp,in_port=5,dl_vlan=3,dl_vlan_pcp=0,dl_src=fa:16:3e:33:f7:fe,dl_dst=00:00:5e:00:43:64,nw_src=10.0.1.22,nw_dst=10.0.0.3,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=53295,tp_dst=8080,tcp_flags=psh|ack
2016-11-29T14:44:40.126Z|4|odp_util(revalidator45)|WARN| 
 masks: 
recirc_id=0x,reg0=0x,in_port=4294967295,dl_vlan=4095,dl_vlan_pcp=7,dl_src=ff:ff:ff:ff:ff:ff,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x
2016-11-29T14:44:40.126Z|5|odp_util(revalidator45)|WARN| 
 actions: 
set(ipv4(src=10.0.1.22,dst=10.0.0.3,ttl=63)),set(eth(src=b8:2a:72:de:1b:e3,dst=00:17:cb:79:2c:01)),push_mpls(label=410384,tc=0,ttl=63,bos=1,eth_type=0x8847),9,set(eth(src=fa:16:3e:33:f7:fe,dst=00:00:5e:00:43:64)),pop_mpls(eth_type=0x800),push_vlan(vid=3,pcp=0),1


push_mpls clears L3/L4, while pop_mpls re-populates them, and 
then processing the output to port 1 hits the assert?


That's what I'm thinking too.

Jarno, is this something you have time to look into?  It'd be 
great, if

you do.  I'm way behind.


I’m looking at this.

Based on the trace given it seems that:
1. Packet is received on br-int port 32, which outputs it via 
NORMAL action over a patch port to another bridge. The only 
patch-port on br-int is 2 (patch-tun). The NORMAL action adds 
dl_vlan=1.
2. br-tun receives the packet on in_port 1 (patch-int), and 
outputs it on it’s port 2 (patch-to-mpls)
3. br-mpls receives the packet on it’s 

Re: [ovs-dev] [PATCH] netdev-dpdk: Create separate memory pool for each port

[Robert Wojciechowicz]

On Wed, Nov 09, 2016 at 08:02:49AM -0500, Robert Wojciechowicz wrote:
> 
> Hi,
> 
> I started working on this patch after this discussion:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2016-September/042643.html
> 
> It turned out that it is not possible in OVS to allocate 64 rx queues
> for two ports, so I started wondering if we can allocate this memory
> dynamically instead of statically.
> 
> Br,
> Robert
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Hi,

did anyone get a chance to look at this patch?

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

Re: [ovs-dev] [PATCH v2 00/11] Sphinx-ification of documentation

[Stephen Finucane]

On Mon, 2016-12-12 at 09:12 -0800, Ben Pfaff wrote:
> Thanks a lot!  I applied this series to master.  I only made a few
> changes.  First, there were lots of missing \s at the end of lines in
> makefiles, which caused "make" to complain about files that were not
> distributed.  I fixed those.  Second, I changed the default
> SPHINXBUILDDIR from $(srcdir) to $(builddir).

Thank you. docs.openvswitch.org looks good :)

Stephen

> On Thu, Dec 08, 2016 at 12:55:19PM +, Stephen Finucane wrote:
> > This series is the first in a number of planned series that rework
> > and
> > expand the OVS documentation. This particular series aims to
> > achieve
> > the following:
> > 
> > * Configure the basics required for Sphinx documentation generation
> > 
> > * Create a number of document sections and move all documents, with
> >   the exception of some top-level files, into at least one of these
> >   sections
> > 
> > * Update or remove references to any doc files which have been
> > moved
> > 
> > Any significant refactoring of documentation has been left for
> > future
> > series, though TODOs are included to remind people to do this. I
> > plan
> > to follow-up this series with the following:
> > 
> > * A refactor of existing documents, moving content from one section
> > to
> >   another if it makes more sense. The (generally excellent, but
> >   somewhat convoluted) DPDK-advanced guide is first on my radar.
> > 
> > * Adding further documentation to the '/topics' section, based on a
> >   variety of blog posts and mailing list posts I've collected. A
> >   change to the patch acceptance criteria could help in the long
> > term
> >   (think: don't add a new feature until how it works is explained
> > in
> >   the docs)?
> > 
> > * Other random oddities
> > 
> > All other comments from the original series cover letter still
> > apply.
> > 
> > https://mail.openvswitch.org/pipermail/ovs-dev/2016-November/325292
> > .html
> > 
> > Changes since v1:
> > - Rebase onto master
> > 
> > Stephen Finucane (11):
> >   Add initial sphinx configuration
> >   doc: Create directory structure
> >   doc: Populate 'ref' section
> >   doc: Populate 'internals' section
> >   doc: Populate 'install', 'howto' sections
> >   doc: Further populate the 'howto' section
> >   doc: Populate 'topics' section
> >   doc: Populate 'tutorials' section
> >   doc: Move WHY-OVS
> >   doc: Populate 'faq' section
> >   doc: Remove documentation from distdoc target
> > 
> >  .gitignore |1 +
> >  CONTRIBUTING.rst   |  430 +---
> >  Documentation/_static/logo.png |  Bin 0 ->
> > 13341 bytes
> >  Documentation/automake.mk  |   93 +-
> >  Documentation/conf.py  |  338 
> >  Documentation/contents.rst |   42 +
> >  Documentation/faq/configuration.rst|  240 +++
> >  Documentation/faq/contributing.rst |   75 +
> >  Documentation/faq/design.rst   |  110 +
> >  Documentation/faq/general.rst  |  132 ++
> >  Documentation/faq/index.rst|   43 +
> >  Documentation/faq/issues.rst   |  416 
> >  Documentation/faq/openflow.rst |  537 +
> >  Documentation/faq/qos.rst  |  169 ++
> >  Documentation/faq/releases.rst |  270 +++
> >  Documentation/faq/terminology.rst  |   37 +
> >  Documentation/faq/vlan.rst |  282 +++
> >  Documentation/faq/vxlan.rst|   53 +
> >  .../howto/docker.rst   |   13 +-
> >  Documentation/howto/index.rst  |   48 +
> >  INSTALL.KVM.rst => Documentation/howto/kvm.rst |   15 +-
> >  .../howto/libvirt.rst  |   11 +-
> >  README-lisp.rst => Documentation/howto/lisp.rst|0
> >  .../howto/native-tunneling.rst |0
> >  .../howto/openstack-containers.rst |   10 +-
> >  .../howto/selinux.rst  |8 +-
> >  INSTALL.SSL.rst => Documentation/howto/ssl.rst |4 +-
> >  .../howto/vtep.rst |   17 +-
> >  Documentation/index.rst|   93 +
> >  Documentation/internals/authors.rst|   24 +
> >  .../internals/bugs.rst |2 +-
> >  .../{ => internals}/committer-grant-revocation.rst |2 +-
> >  .../{ => internals}/committer-responsibilities.rst |8 +-
> >  .../contributing/coding-style-windows.rst  |8 +-
> >  .../internals/contributing/coding-style.rst|2 +-
> >  .../internals/contributing/documentation-style.rst |8 +-
> >  Documentation/internals/contributing/index.rst |   36 +
> >  .../internals/contributing/submitting-patches.rst  |  452 +
>