[ovs-dev] [PATCH] odp: Add datapath clone action parser.

[Andy Zhou]

When adding userspace datapath clone action, the corresponding odp
actions parser and unit tests were missing. This patch adds them.

Reported-by: Ben Pfaff 
Signed-off-by: Andy Zhou 

---
Note: back port to branch-2.7
---
 lib/odp-util.c | 56 +++-
 tests/odp.at   |  2 ++
 2 files changed, 45 insertions(+), 13 deletions(-)

diff --git a/lib/odp-util.c b/lib/odp-util.c
index 430793b..e12acf7 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -89,6 +89,9 @@ static void format_u128(struct ds *ds, const ovs_u128 *value,
 const ovs_u128 *mask, bool verbose);
 static int scan_u128(const char *s, ovs_u128 *value, ovs_u128 *mask);
 
+static int parse_odp_action(const char *s, const struct simap *port_names,
+struct ofpbuf *actions);
+
 /* Returns one the following for the action with the given OVS_ACTION_ATTR_*
  * 'type':
  *
@@ -1561,6 +1564,26 @@ find_end:
 }
 
 static int
+parse_action_list(const char *s, const struct simap *port_names,
+  struct ofpbuf *actions)
+{
+int n = 0;
+
+while (s[n] != ')') {
+int retval = 0;
+
+n += strspn(s + n, delimiters);
+retval = parse_odp_action(s + n, port_names, actions);
+if (retval < 0) {
+return retval;
+}
+n += retval;
+}
+
+return n;
+}
+
+static int
 parse_odp_action(const char *s, const struct simap *port_names,
  struct ofpbuf *actions)
 {
@@ -1700,20 +1723,11 @@ parse_odp_action(const char *s, const struct simap 
*port_names,
 
 actions_ofs = nl_msg_start_nested(actions,
   OVS_SAMPLE_ATTR_ACTIONS);
-for (;;) {
-int retval;
-
-n += strspn(s + n, delimiters);
-if (s[n] == ')') {
-break;
-}
+int retval = parse_action_list(s + n, port_names, actions);
+if (retval < 0)
+return retval;
 
-retval = parse_odp_action(s + n, port_names, actions);
-if (retval < 0) {
-return retval;
-}
-n += retval;
-}
+n += retval;
 nl_msg_end_nested(actions, actions_ofs);
 nl_msg_end_nested(actions, sample_ofs);
 
@@ -1722,6 +1736,22 @@ parse_odp_action(const char *s, const struct simap 
*port_names,
 }
 
 {
+if (!strncmp(s, "clone(", 6)) {
+size_t actions_ofs;
+int n = 6;
+
+actions_ofs = nl_msg_start_nested(actions, OVS_ACTION_ATTR_CLONE);
+int retval = parse_action_list(s + n, port_names, actions);
+if (retval < 0) {
+return retval;
+}
+n += retval;
+nl_msg_end_nested(actions, actions_ofs);
+return n + 1;
+}
+}
+
+{
 uint32_t port;
 int n;
 
diff --git a/tests/odp.at b/tests/odp.at
index 019897c..db1e827 100644
--- a/tests/odp.at
+++ b/tests/odp.at
@@ -333,6 +333,8 @@ 
ct(commit,nat(src=fe80::20c:29ff:fe88:1-fe80::20c:29ff:fe88:a18b,random))
 
ct(commit,nat(src=[[fe80::20c:29ff:fe88:1]]-[[fe80::20c:29ff:fe88:a18b]]:255-4096,random))
 ct(commit,helper=ftp,nat(src=10.1.1.240-10.1.1.255))
 trunc(100)
+clone(1)
+clone(clone(push_vlan(vid=12,pcp=0),2),1)
 ])
 AT_CHECK_UNQUOTED([ovstest test-odp parse-actions < actions.txt], [0],
   [`cat actions.txt`
-- 
1.8.3.1

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

Re: [ovs-dev] [PATCH V2] netdev-dpdk: fix ifindex assignment for DPDK ports

[Daniele Di Proietto]

On 31/01/2017 13:52, "Ben Pfaff"  wrote:

>On Thu, Dec 08, 2016 at 01:16:22PM +0100, Przemyslaw Lal wrote:
>> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
>> index de78ddd..ef99eb3 100644
>> --- a/lib/netdev-dpdk.c
>> +++ b/lib/netdev-dpdk.c
>> @@ -2075,7 +2075,13 @@ netdev_dpdk_get_ifindex(const struct netdev *netdev)
>>  int ifindex;
>>  
>>  ovs_mutex_lock(>mutex);
>> -ifindex = dev->port_id;
>> +/* Calculate hash from the netdev name using hash_bytes() function.
>> + * Because ifindex is declared as signed int in the kernel sources and
>> + * OVS follows this implementation right shift is needed to set sign bit
>> + * to 0 and then XOR to slightly improve collision rate.
>> + */
>> +uint32_t h = hash_bytes(netdev->name, strlen(netdev->name), 0);
>> +ifindex = (int)((h >> 1) ^ (h & 0x0FFF));
>
>To hash a string, please use hash_string().
>
>Daniele, are you planning to review this?

Sorry for the delay.

At some point, with vhost-pmd we will have port_ids also for vhost interfaces.  
Maybe we can revisit this approach when that becomes available.

I wish there was a better way to avoid collisions with the linux kernel, but I 
can't think of anything generic.

Unless someone else has an objection I'm fine with the approach.  Two minor 
comments:

Could you please use hash_string(), as suggested by Ben?

I guess the result after hashing and XOR could still be zero.  Could you maybe 
add a check for that case and set it to something else?

Thanks,

Daniele

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

Re: [ovs-dev] branching commits

[Justin Pettit]

> On Jan 31, 2017, at 3:03 PM, Ben Pfaff  wrote:
> 
> Hi Justin.  We branched a couple of weeks ago but at the time we forgot
> to update NEWS, etc. either on master or the branch.  Usually you submit
> those patches; do you want to do the honors this time too?

Okay, I sent out patches.  Normally, I do the following patches to master: 
Prepare for the pending release and prepare for the following release.  I then 
cherry-pick the pending release commit to the new branch.  Since we already had 
the branch and some commits went in, I just made a single patch directly for 
each of branch-2.7 and master.  This means master won't have the "Prepare for 
2.7.0" commit.  I don't think it matters in practice, but the history will be a 
bit different than usual.

--Justin


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

[ovs-dev] [branch-2.7] Prepare for 2.7.0.

[Justin Pettit]

Signed-off-by: Justin Pettit 
---
 NEWS |  2 +-
 configure.ac |  2 +-
 debian/changelog | 79 +---
 3 files changed, 77 insertions(+), 6 deletions(-)

diff --git a/NEWS b/NEWS
index 0a9551c..1a3787d 100644
--- a/NEWS
+++ b/NEWS
@@ -1,4 +1,4 @@
-Post-v2.6.0
+v2.7.0 - xx xxx 
 -
- Utilities and daemons that support SSL now allow protocols and
  ciphers to be configured with --ssl-protocols and --ssl-ciphers.
diff --git a/configure.ac b/configure.ac
index 7c729ef..c4aa356 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@
 # limitations under the License.
 
 AC_PREREQ(2.63)
-AC_INIT(openvswitch, 2.6.90, b...@openvswitch.org)
+AC_INIT(openvswitch, 2.7.0, b...@openvswitch.org)
 AC_CONFIG_SRCDIR([datapath/datapath.c])
 AC_CONFIG_MACRO_DIR([m4])
 AC_CONFIG_AUX_DIR([build-aux])
diff --git a/debian/changelog b/debian/changelog
index 28d00ba..1184038 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,80 @@
-openvswitch (2.6.90-1) unstable; urgency=low
+openvswitch (2.7.0-1) unstable; urgency=low
[ Open vSwitch team ]
* New upstream version
-   - Nothing yet!  Try NEWS...
-
- -- Open vSwitch team   Mon, 15 Aug 2016 19:55:47 -0700
+   - Utilities and daemons that support SSL now allow protocols and
+ ciphers to be configured with --ssl-protocols and --ssl-ciphers.
+   - OVN:
+ * QoS is now implemented via egress shaping rather than ingress policing.
+ * DSCP marking is now supported, via the new northbound QoS table.
+ * IPAM now supports fixed MAC addresses.
+ * Support for source IP address based routing.
+ * ovn-trace:
+   - New --ovs option to also print OpenFlow flows.
+   - put_dhcp_opts and put_dhcp_optsv6 actions may now be traced.
+ * Support for managing SSL and remote connection configuration in
+   northbound and southbound databases.
+ * TCP connections to northbound and southbound databases are no
+   longer enabled by default and must be explicitly configured.
+   See documentation for ovn-sbctl/ovn-nbctl "set-connection"
+   command or the ovn-ctl "--db-sb-create-insecure-remote" and
+   "--db-nb-create-insecure-remote" command-line options for
+   information regarding remote connection configuration.
+ * New appctl "inject-pkt" command in ovn-controller that allows
+   packets to be injected into the connected OVS instance.
+   - Fixed regression in table stats maintenance introduced in OVS
+ 2.3.0, wherein the number of OpenFlow table hits and misses was
+ not accurate.
+   - OpenFlow:
+ * OFPT_PACKET_OUT messages are now supported in bundles.
+ * A new "selection_method=dp_hash" type for OpenFlow select group
+   bucket selection that uses the datapath computed 5-tuple hash
+   without making datapath flows match the 5-tuple fields, which
+   is useful for more efficient load balancing, for example.  This
+   uses the Netronome extension to OpenFlow 1.5+ that allows
+   control over the OpenFlow select groups selection method.  See
+   "selection_method" and related options in ovs-ofctl(8) for
+   details.
+ * The "sample" action now supports "ingress" and "egress" options.
+ * The "ct" action now supports the TFTP ALG where support is available.
+ * New actions "clone" and "ct_clear".
+   - ovs-ofctl:
+ * 'bundle' command now supports packet-out messages.
+ * New syntax for 'ovs-ofctl packet-out' command, which uses the
+   same string parser as the 'bundle' command.  The old 'packet-out'
+   syntax is deprecated and will be removed in a later OVS
+   release.
+ * New unixctl "ofctl/packet-out" command, which can be used to
+   instruct a flow monitor to issue OpenFlow packet-out messages.
+   - ovsdb-server:
+ * Remote connections can now be made read-only (see ovsdb-server(1)).
+   - Tunnels:
+ * TLV mappings for protocols such as Geneve are now segregated on
+   a per-OpenFlow bridge basis rather than globally. (The interface
+   has not changed.)
+ * Removed support for IPsec tunnels.
+   - DPDK:
+ * 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.
+ * Support for rx checksum offload. Refer DPDK HOWTO for details.
+ * 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. Compatibility
+   with the old dpdk naming scheme is broken, and as such a
+   device will not be available for use until a valid dpdk-devargs is
+   specified.
+ * Virtual DPDK Poll Mode Driver (vdev PMD) support.
+   - Fedora packaging:
+ * A package upgrade does not automatically restart OVS service.
+   

Re: [ovs-dev] [PATCH] Windows: Implement Hyper-V VIF discovery agent.

[Alin Serdean]

Hi Yin,

Please see my answers inlined.

Thanks,
Alin.

From: Yin Lin [mailto:li...@vmware.com]
Sent: Wednesday, February 1, 2017 12:31 AM
To: Alin Serdean ; d...@openvswitch.org
Subject: RE: [ovs-dev] [PATCH] Windows: Implement Hyper-V VIF discovery agent.

Hi Alin,

The issues compiler complained are all related to WMI. Have you checked if WMI 
is supported at all in Nano? We need WMI to monitor virtual switch and 
interface changes no matter what. Even powershell commands are based on WMI 
queries. If WMI is not available, I highly doubt if there is a way at all to 
implement the discovery agent.
[Alin Serdean] Powershell commandlets work. I.e.: get-vmswitch; new-vmswitch 
etc. Even our module for renaming works if we change to `Load` on this line: 
https://github.com/openvswitch/ovs/blob/master/datapath-windows/misc/OVS.psm1#L21
WMI works but not all 
API's(https://docs.microsoft.com/en-us/dotnet/core/api/index)  are fully 
available in .NET core. We could use other languages or probably implement it 
ourselves in .NET core.
Otherwise, can we install .NET framework on Nano?
[Alin Serdean] No, we can use only .NET core (https://github.com/dotnet/core) 
https://social.technet.microsoft.com/Forums/en-US/45d0055e-f062-4b67-8587-de2e53e56232/nano-server-and-net-framework?forum=NanoServer
 .
Best regards,
Yin Lin

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

Re: [ovs-dev] [PATCH] ovn: Support ARP proxy in logical switches.

[Han Zhou]

On Tue, Jan 31, 2017 at 2:49 PM, Ben Pfaff  wrote:
>
> On Thu, Jan 05, 2017 at 12:33:51AM -0800, Han Zhou wrote:
> > On Wed, Jan 4, 2017 at 3:29 PM, Ben Pfaff  wrote:
> > > However, I'm concerned about the general utility here.  I usually
think
> > > of proxy ARP as being used for the kinds of applications you see in
the
> > > wikipedia on proxy ARP: https://en.wikipedia.org/wiki/Proxy_ARP.  This
> > > seems to aimed at a different application that is more like a weak
form
> > > of service function chaining than for the traditional applications of
> > > proxy ARP.
> > >
> > > Is this an appropriate application for proxy ARP?  Is it a common
enough
> > > use case to support in OVN?  Should it instead be handled through a
more
> > > general service function chaining interface?
> > >
> >
> > I have similar concerns about how useful it is. I agree it is kind of
> > lightweight SFC, but in my opinion it is not contradict with the fact
that
> > it is also Proxy ARP. At least the firewall example (the 3rd use case)
> > described in https://en.wikipedia.org/wiki/Proxy_ARP seems to be very
> > close. SFC may be a more general approach to redirect packets to a
> > firewall, but it is heavier, and may be difficult in a non-overlay
> > environment, while Proxy ARP is sufficient and simple for such specific
use
> > cases when the nodes are L2 adjacent. So I think it may be good to have
> > such feature in OVN, if the change is not intrusive.
>
> Do the general SFC patches that John McDowall is currently working on
> serve this use case too?

The scenario looks match, but with the SFC approach, if I understanding
correctly, it requires the VNF to be able to handle packets that is not
with dst mac equal to the mac of the VNF port. While with ARP proxy, MAC is
replaced with the MAC of the VNF (in my case it is just the MAC of the veth
interface in the host namespace where kubeproxy is running, which is not a
real so-called VNF), and no change is required in the VNF host/vm/container.

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

Re: [ovs-dev] [PATCH v2] windows: wmi add include

[Alin Serdean]

> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Tuesday, January 31, 2017 11:35 PM
> To: Alin Serdean 
> Cc: d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH v2] windows: wmi add include
> 
> On Mon, Jan 30, 2017 at 07:42:31AM +, Alin Serdean wrote:
> > Add 'util.h' to includes otherwise the result of the function
> > 'ovs_format_message' will be unknown and be converted to int,
> > triggering an abort of vswitchd.
> 
> Is there a way to make MSVC fail the compile if a function is called without a
> visible prototype?  That would prevent this problem.
> 
> Alternatively, if it's possible to get a warning but not an error, it might be
> possible to add something to the appveyor build script to fail that build if 
> any
> such warning is reported.
[Alin Serdean] Thanks for the idea Ben(made me facepalm for not thinking of it).
There is something like -Wimplicit-function-declaration(-Wall) and I could 
issue an error while compiling.

I tried on Linux to add a bogus function, but make stopped during linking (from 
what I remember -Werror is needed to stop compiling).

Since this has deep implication is it ok if I stop compiling for this type of 
issue?

I enabled it locally and fixing current issues that we have in the code(most of 
them are ok since the type are int, but we need to fix them).

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

Re: [ovs-dev] [PATCH v2] ofp-actions: Fix variable length meta-flow field usage in flow actions.

[Joe Stringer]

On 20 January 2017 at 15:12, Yi-Hung Wei  wrote:
> Previously, if a flow action that involves a tunnel metadata meta-flow
> field is dumped from vswitchd, the replied field length in the OXM header
> is filled with the maximum possible field length, instead of the length
> configured in the tunnel TLV mapping table. To solve this issue, this patch
> introduces the following changes.
>
> In order to maintain the correct length of variable length mf_fields (i.e.
> tun_metadata), this patch creates a per-switch based map (struct vl_mff_map)
> that hosts the variable length mf_fields. This map is updated when a
> controller adds/deletes tlv-mapping entries to/from a switch. Although the
> per-swtch based vl_mff_map only hosts tun_metadata for now, it is able to
> support new variable length mf_fields in the future.
>
> With this commit, when a switch decodes a flow action with mf_field, the 
> switch
> firstly looks up the global mf_fields map to identify the mf_field type. For
> the variable length mf_fields, the switch uses the vl_mff_map to get the
> configured mf_field entries. By lookig up vl_mff_map, the switch can check
> if the added flow action access beyond the configured size of a variable
> length mf_field, and the switch reports an ofperr if the controller adds a 
> flow
> with unmapped variable length mf_field. Later on, when a controller request
> flows from the switch, with the per-switch based mf_fields, the switch will
> encode the OXM header with correct length for variable length mf_fields.
>
> To use the vl_mff_map for decoding flow actions, extract-ofp-actions is
> updated to pass the vl_mff_map to the required action decoding functions.
> Also, a new error code is introduced to identify a flow with an invalid
> variable length mf_field. Moreover, a testcase is added to prevent future
> regressions.
>
> VMWare-BZ: #1768370
> Reported-by: Harold Lim 
> Suggested-by: Joe Stringer 
> Suggested-by: Jarno Rajahalme 
> Signed-off-by: Yi-Hung Wei 

Thanks for the patch!

I wonder about renaming OFPERR_NXFMFC_INVALID_VL_MFF to something like
OFPERR_NXFMFC_INVALID_TLV_FIELD, this is slightly less cryptic than
VL_MFF to the unknowing eye. Thoughts?



> +/* Updates the tun_metadata mf_field in 'vl_mff_map' according to 'ttm'.
> + * This function is supposed to be invoked after tun_metadata_table_mod(). */
> +enum ofperr
> +mf_vl_mff_map_mod_from_tun_metadata(struct vl_mff_map *vl_mff_map,
> +const struct ofputil_tlv_table_mod *ttm)
> +OVS_REQUIRES(vl_mff_map->mutex)
> +{
> +struct ofputil_tlv_map *tlv_map;
> +struct mf_field *mf;
> +unsigned int idx;
> +
> +switch (ttm->command) {
> +case NXTTMC_ADD:
> +LIST_FOR_EACH (tlv_map, list_node, >mappings) {
> +idx = MFF_TUN_METADATA0 + tlv_map->index;
> +if (idx >= MFF_TUN_METADATA0 + TUN_METADATA_NUM_OPTS) {
> +return OFPERR_NXTTMFC_BAD_FIELD_IDX;
> +}
> +
> +mf = xmalloc(sizeof *mf);
> +*mf = mf_fields[idx];
> +mf->n_bytes = tlv_map->option_len;
> +mf->n_bits = tlv_map->option_len * 8;
> +mf->mapped = true;
> +
> +cmap_insert(_mff_map->cmap, >cmap_node, 
> mf_field_hash(idx));
> +}
> +break;
> +
> +case NXTTMC_DELETE:
> +LIST_FOR_EACH (tlv_map, list_node, >mappings) {
> +idx = MFF_TUN_METADATA0 + tlv_map->index;
> +if (idx >= MFF_TUN_METADATA0 + TUN_METADATA_NUM_OPTS) {
> +return OFPERR_NXTTMFC_BAD_FIELD_IDX;
> +}
> +
> +CMAP_FOR_EACH_WITH_HASH (mf, cmap_node, mf_field_hash(idx),
> + _mff_map->cmap) {
> +if (mf->id == idx) {
> +cmap_remove(_mff_map->cmap, >cmap_node,
> +mf_field_hash(idx));
> +ovsrcu_postpone(free, mf);
> +break;
> +}
> +}
> +}
> +break;
> +
> +case NXTTMC_CLEAR:
> +mf_vl_mff_map_clear(vl_mff_map);
> +break;
> +
> +default:
> +OVS_NOT_REACHED();
> +}

I think that this could be a bit restructured to share the list
iteration/error checking between ADD and DELETE.

> +
> +return 0;
> +}
> +
> +/* If 'mff' is a variable length field, looks up 'vl_mff_map', returns a
> + * pointer to the variable length meta-flow field corresponding to 'mff'.
> + * Returns NULL if no mapping is existed for 'mff'. */
> +const struct mf_field *
> +mf_get_vl_mff(const struct mf_field *mff,
> +const struct vl_mff_map *vl_mff_map)
> +{
> +const struct mf_field *field;
> +
> +if (mff && mff->variable_len && vl_mff_map) {
> +const uint32_t id = mff->id;
> +
> +CMAP_FOR_EACH_WITH_HASH (field, cmap_node, mf_field_hash(id),
> +   

Re: [ovs-dev] [PATCH v3 1/2] tunneling: Avoid recirculation on datapath by computing the recirculate actions at translate time.

[Ben Pfaff]

On Thu, Jan 26, 2017 at 03:22:24PM +, Zoltán Balogh wrote:
> From: Sugesh Chandran 
> 
> Openvswitch datapath recirculates packets for tunneling, i.e.
> the incoming packets are encapsulated at first pass. Further actions are
> applied on encapsulated packets on the second pass after recirculating.
> The proposed patch compute and append the post tunnel actions at the time of
> translation itself instead of recirculating at datapath. These actions are 
> solely
> depends on tunnel attributes so there is no need of datapath recirculation.
> By avoiding the recirculation at datapath, the patch offers upto 30%
> performance improvement for VxLAN tunneling in our testing.
> The action execution logic is also extended with new CLONE action to define
> the packet cloning when the actions are combined. The lenght in the CLONE
> action specifies the size of nested action set.
> 
> Rebased onto commit: 535e3acfa70b1c1a44daf91de3a63b80d673dc33
>  dpif-netdev: Add clone action
> 
> Signed-off-by: Sugesh Chandran 
> Signed-off-by: Zoltán Balogh 
> Co-authored-by: Zoltán Balogh 

Thanks for working on this!  This seems like a really nice idea, and the
implementation is pretty simple

Even with patch 2 applied, I still get a failure in test 767:

../../tests/tunnel-push-pop.at:137: tail -1 stdout
--- -   2017-01-31 16:37:07.328760120 -0800
+++ /home/blp/nicira/ovs/_build/tests/testsuite.dir/at-groups/767/stdout
2017-01-31 16:37:07.326337064 -0800
@@ -1,2 +1,2 @@
-Datapath actions: 
set(skb_mark(0x4d2)),tnl_push(tnl_port(6081),header(size=50,type=5,eth(dst=f8:bc:12:44:34:b7,src=aa:55:aa:55:00:00,dl_type=0x0800),ipv4(src=1.1.2.88,dst=1.1.2.93,proto=17,tos=0,ttl=64,frag=0x4000),udp(src=0,dst=6081,csum=0x0),geneve(vni=0xea)),out_port(100))
+Datapath actions: 
set(skb_mark(0x4d2)),clone{tnl_push(tnl_port(6081),header(size=50,type=5,eth(dst=f8:bc:12:44:34:b7,src=aa:55:aa:55:00:00,dl_type=0x0800),ipv4(src=1.1.2.88,dst=1.1.2.93,proto=17,tos=0,ttl=64,frag=0x4000),udp(src=0,dst=6081,csum=0x0),geneve(vni=0xea)),out_port(100)),1}

I'm not sure why this changes the formatting for the ODP clone action
from clone(...) to clone{...}.  The latter syntax isn't used anywhere
else in ODP.

This includes a whitespace only change to format_odp_tnl_push_header().

It's really not clear to me why this replaces a simple loop in
format_odp_actions() by a new recursive function print_odp_actions().

There's funny indentation in the print_odp_actions() prototype, here's a
fix:

@@ -890,8 +890,7 @@ format_odp_action(struct ds *ds, const struct nlattr *a)
 
 static void
 print_odp_actions(struct ds *ds, bool is_first_action,
-const struct nlattr **action_,
-size_t *action_len)
+  const struct nlattr **action_, size_t *action_len)
 
 {
 const struct nlattr *action = *action_;

Why is group_actions() named group_actions()?  OpenFlow has a concept
named a "group", but this doesn't seem to have anything to do with it.
Instead, it seems to be about outputting to a patch port, or maybe just
a port on a different bridge.

group_actions() should have a comment explaining its purpose.

I think that build_tunnel_send() should probably just use the nl_msg
functions for nested attributes, something like this:

size_t clone_ofs = nl_msg_start_nested(ctx->odp_actions,
   OVS_ACTION_ATTR_CLONE);
odp_put_tnl_push_action(ctx->odp_actions, _push_data);
group_actions(ctx, xport, out_dev);
nl_msg_end_nested(ctx->odp_actions, clone_ofs);

If there's a real possibility that group_actions() won't actually add
anything, then probably the whole set of actions should just get
dropped, with "ctx->odp_actions->size = clone_ofs;", since there's no
value in cloning and pushing tunnel data just to drop the packet.

Thanks,

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

Re: [ovs-dev] [PATCH] ovn: fix slave node can not connect to the master node using SSL, for pacemaker

[Andy Zhou]

On Tue, Jan 31, 2017 at 3:51 PM, Ben Pfaff  wrote:
> On Tue, Jan 31, 2017 at 03:44:38PM -0800, Andy Zhou wrote:
>> On Wed, Jan 11, 2017 at 4:11 AM, Guoshuai Li  wrote:
>> > The default slave node connect to the master node using TCP, and the 
>> > pacemaker
>> > can not modify the protocol and port of the connection.
>> > Add pacemaker parameters to support the connection of the slave node to the
>> > master node using a different protocol and port.
>> >
>> > Signed-off-by: Guoshuai Li 
>> > ---
>>
>> LGTM,
>>
>> Acked-by: Andy Zhou 
>
> You acked this instead of applying it, so should someone else also
> review it?
>
> Thanks,
>
> Ben.

Applied to master and branch-2.7.  Sorry for the confusion.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovn: fix slave node can not connect to the master node using SSL, for pacemaker

[Ben Pfaff]

On Tue, Jan 31, 2017 at 03:44:38PM -0800, Andy Zhou wrote:
> On Wed, Jan 11, 2017 at 4:11 AM, Guoshuai Li  wrote:
> > The default slave node connect to the master node using TCP, and the 
> > pacemaker
> > can not modify the protocol and port of the connection.
> > Add pacemaker parameters to support the connection of the slave node to the
> > master node using a different protocol and port.
> >
> > Signed-off-by: Guoshuai Li 
> > ---
> 
> LGTM,
> 
> Acked-by: Andy Zhou 

You acked this instead of applying it, so should someone else also
review it?

Thanks,

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

Re: [ovs-dev] [PATCH] ovn: fix slave node can not connect to the master node using SSL, for pacemaker

[Andy Zhou]

On Wed, Jan 11, 2017 at 4:11 AM, Guoshuai Li  wrote:
> The default slave node connect to the master node using TCP, and the pacemaker
> can not modify the protocol and port of the connection.
> Add pacemaker parameters to support the connection of the slave node to the
> master node using a different protocol and port.
>
> Signed-off-by: Guoshuai Li 
> ---

LGTM,

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

Re: [ovs-dev] [PATCH] ovsdb: fix data loss when OVSDB replication from itself

[Andy Zhou]

On Mon, Jan 2, 2017 at 7:09 PM, Guoshuai Li  wrote:
> Delete the local database after receiving the master data,
> this is safer for data.
> This patch is used by HA cluster that have no way to
> control the order of resources, such as kubernetes.
>
> Signed-off-by: Guoshuai Li 

Sorry for the delay in review.

Replication of OVSDB onto itself seems to be an configuration issue. I don't see
why such configuration is ever useful in practice, and probably should
be blocked
at a higher level.

Is there something special about K8 where OVSDB is expected to
replicating itself?
If so, please explain.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ofproto-dpif: Reduce the time of creating large mount of bridges

[Ben Pfaff]

On Tue, Jan 17, 2017 at 12:45:00PM +, zhangsha (A) wrote:
> From e7623970cd71f8af7c3849a5beff87fd31fbdf68 Mon Sep 17 00:00:00 2001
> From: Sha Zhang 
> Date: Tue, 17 Jan 2017 11:34:24 +0800
> Subject: [PATCH] ofproto-dpif: Reduce the time of creating large mount of
> bridges
> 
> This patch moves function xlate_txn_start and xlate_txn_commit out of the loop
> traversing all the ofproto-dpifs to reduce the time of creating a large mount
> of bridges in separate database transactions.
> As a global variable, new_xcfg should only be allocated at the beginning and
> commited at the end once time, other than doing it repeatly in the loop body.
> 
> Signed-off-by: Sha Zhang 

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

[ovs-dev] branching commits

[Ben Pfaff]

Hi Justin.  We branched a couple of weeks ago but at the time we forgot
to update NEWS, etc. either on master or the branch.  Usually you submit
those patches; do you want to do the honors this time too?

Thanks,

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

Re: [ovs-dev] [RFC PATCH 2/5] OVN: SFC Implementation: New stage for SFC and modified ACL stage

[John McDowall]

Ah, my bad do you want me to create a single patch file?

Regards

John

On 1/31/17, 2:44 PM, "Ben Pfaff"  wrote:

Now that I glance at the patch titles, I guess that the problem might be
that this patch depends on some of the later patches.  In general, each
patch should apply, build, and test properly whether or not later
patches have been applied.

On Tue, Jan 31, 2017 at 10:03:21PM +, John McDowall wrote:
> Ben,
> 
> Let me create a new patch set against the top of tree.
> 
> Regards
> 
> John
> 
> On 1/31/17, 1:46 PM, "Ben Pfaff"  wrote:
> 
> On Tue, Dec 27, 2016 at 02:11:43PM -0800, John McDowall wrote:
> > This is the major body of code that implements SFC. There is a new 
L2 stage added to
> > perform the chaining operations and modifications to the ACL stage 
to direct flows
> > to the service chain.
> > 
> > Co-authored-by: Flavio Fernandes 
> > Reported at: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddiscuss_2016-2DMarch_040381.html=DwIBAg=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=0-H45ymu2qKdNfehkwCF8baQWBqDNhngIVaX4MlOpCQ=VbhqfPkju3uYqy7303Bfbz0fgnSeIi6aYsQoRwIH1PU=
 
> > Reported at: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddiscuss_2016-2DMay_041359.html=DwIBAg=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=0-H45ymu2qKdNfehkwCF8baQWBqDNhngIVaX4MlOpCQ=vNieFlb8T7dsSygACJyaJiHvnrQDGCyox17covGw4Ns=
 
> > 
> > Signed-off-by: John McDowall 
> 
> I think that this has bit-rotted because I get tons of compiler errors
> trying to build it.  I tried rewinding my repo to a point from 
December
> but I still the same ones:
> 
> ../ovn/northd/ovn-northd.c:2669:13: error: incomplete definition 
of type 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 
'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2669:37: error: incomplete definition 
of type 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 
'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2673:30: error: incomplete definition 
of type 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 
'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2674:30: error: incomplete definition 
of type 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 
'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2701:49: error: no member named 
'options' in 'struct nbrec_acl'
> ../ovn/northd/ovn-northd.c:2713:37: error: no member named 
'n_port_chains' in 'struct nbrec_logical_switch'
> ../ovn/northd/ovn-northd.c:2714:30: error: no member named 
'port_chains' in 'struct nbrec_logical_switch'
> ../ovn/northd/ovn-northd.c:2716:39: error: incomplete definition 
of type 'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition 
of type 'struct nbrec_logical_port_chain'
> /usr/include/i386-linux-gnu/bits/string2.h:110:58: note: expanded 
from macro 'strcmp'
> ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition 
of type 'struct nbrec_logical_port_chain'
> /usr/include/i386-linux-gnu/bits/string2.h:111:74: note: expanded 
from macro 'strcmp'
> ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition 
of type 'struct nbrec_logical_port_chain'
> /usr/include/i386-linux-gnu/bits/string2.h:113:28: note: expanded 
from macro 'strcmp'
> /usr/include/i386-linux-gnu/bits/string2.h:53:28: note: expanded 
from macro '__string2_1bptr_p'
> ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition 
of type 'struct nbrec_logical_port_chain'
> /usr/include/i386-linux-gnu/bits/string2.h:113:28: note: expanded 
from macro 'strcmp'
> /usr/include/i386-linux-gnu/bits/string2.h:53:63: note: expanded 
from macro 

Re: [ovs-dev] [PATCH v2] ovn-controller: Provide the option to set Encap.options:csum

[Ben Pfaff]

On Sun, Jan 15, 2017 at 12:36:09PM +0530, Numan Siddique wrote:
> ovn-controller by default enables tunnel encapsulation checksums
> for geneve tunnels. With this patch user can set the desired value
> in Open_vSwitch.external_ids:ovn_encap_csum.
> 
> This option will be useful in cases where enabling tunnel
> encapsulation checksums incur significant performance loss due to
> limitations in checksum offloading capabilities of the nics.
> 
> Signed-off-by: Numan Siddique 

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

Re: [ovs-dev] [PATCH] ovn: Support ARP proxy in logical switches.

[Ben Pfaff]

On Thu, Jan 05, 2017 at 12:33:51AM -0800, Han Zhou wrote:
> On Wed, Jan 4, 2017 at 3:29 PM, Ben Pfaff  wrote:
> > However, I'm concerned about the general utility here.  I usually think
> > of proxy ARP as being used for the kinds of applications you see in the
> > wikipedia on proxy ARP: https://en.wikipedia.org/wiki/Proxy_ARP.  This
> > seems to aimed at a different application that is more like a weak form
> > of service function chaining than for the traditional applications of
> > proxy ARP.
> >
> > Is this an appropriate application for proxy ARP?  Is it a common enough
> > use case to support in OVN?  Should it instead be handled through a more
> > general service function chaining interface?
> >
> 
> I have similar concerns about how useful it is. I agree it is kind of
> lightweight SFC, but in my opinion it is not contradict with the fact that
> it is also Proxy ARP. At least the firewall example (the 3rd use case)
> described in https://en.wikipedia.org/wiki/Proxy_ARP seems to be very
> close. SFC may be a more general approach to redirect packets to a
> firewall, but it is heavier, and may be difficult in a non-overlay
> environment, while Proxy ARP is sufficient and simple for such specific use
> cases when the nodes are L2 adjacent. So I think it may be good to have
> such feature in OVN, if the change is not intrusive.

Do the general SFC patches that John McDowall is currently working on
serve this use case too?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC PATCH 2/5] OVN: SFC Implementation: New stage for SFC and modified ACL stage

[Ben Pfaff]

Now that I glance at the patch titles, I guess that the problem might be
that this patch depends on some of the later patches.  In general, each
patch should apply, build, and test properly whether or not later
patches have been applied.

On Tue, Jan 31, 2017 at 10:03:21PM +, John McDowall wrote:
> Ben,
> 
> Let me create a new patch set against the top of tree.
> 
> Regards
> 
> John
> 
> On 1/31/17, 1:46 PM, "Ben Pfaff"  wrote:
> 
> On Tue, Dec 27, 2016 at 02:11:43PM -0800, John McDowall wrote:
> > This is the major body of code that implements SFC. There is a new L2 
> stage added to
> > perform the chaining operations and modifications to the ACL stage to 
> direct flows
> > to the service chain.
> > 
> > Co-authored-by: Flavio Fernandes 
> > Reported at: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddiscuss_2016-2DMarch_040381.html=DwIBAg=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=0-H45ymu2qKdNfehkwCF8baQWBqDNhngIVaX4MlOpCQ=VbhqfPkju3uYqy7303Bfbz0fgnSeIi6aYsQoRwIH1PU=
>  
> > Reported at: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddiscuss_2016-2DMay_041359.html=DwIBAg=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=0-H45ymu2qKdNfehkwCF8baQWBqDNhngIVaX4MlOpCQ=vNieFlb8T7dsSygACJyaJiHvnrQDGCyox17covGw4Ns=
>  
> > 
> > Signed-off-by: John McDowall 
> 
> I think that this has bit-rotted because I get tons of compiler errors
> trying to build it.  I tried rewinding my repo to a point from December
> but I still the same ones:
> 
> ../ovn/northd/ovn-northd.c:2669:13: error: incomplete definition of 
> type 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 
> 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2669:37: error: incomplete definition of 
> type 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 
> 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2673:30: error: incomplete definition of 
> type 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 
> 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2674:30: error: incomplete definition of 
> type 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 
> 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2701:49: error: no member named 'options' 
> in 'struct nbrec_acl'
> ../ovn/northd/ovn-northd.c:2713:37: error: no member named 
> 'n_port_chains' in 'struct nbrec_logical_switch'
> ../ovn/northd/ovn-northd.c:2714:30: error: no member named 
> 'port_chains' in 'struct nbrec_logical_switch'
> ../ovn/northd/ovn-northd.c:2716:39: error: incomplete definition of 
> type 'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
> 'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of 
> type 'struct nbrec_logical_port_chain'
> /usr/include/i386-linux-gnu/bits/string2.h:110:58: note: expanded 
> from macro 'strcmp'
> ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
> 'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of 
> type 'struct nbrec_logical_port_chain'
> /usr/include/i386-linux-gnu/bits/string2.h:111:74: note: expanded 
> from macro 'strcmp'
> ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
> 'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of 
> type 'struct nbrec_logical_port_chain'
> /usr/include/i386-linux-gnu/bits/string2.h:113:28: note: expanded 
> from macro 'strcmp'
> /usr/include/i386-linux-gnu/bits/string2.h:53:28: note: expanded from 
> macro '__string2_1bptr_p'
> ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
> 'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of 
> type 'struct nbrec_logical_port_chain'
> /usr/include/i386-linux-gnu/bits/string2.h:113:28: note: expanded 
> from macro 'strcmp'
> /usr/include/i386-linux-gnu/bits/string2.h:53:63: note: expanded from 
> macro '__string2_1bptr_p'
> ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
> 'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of 
> type 'struct nbrec_logical_port_chain'
> 

Re: [ovs-dev] [PATCH v12 6/6] ovn: specify options:nat-addresses as "router"

[Ben Pfaff]

On Fri, Jan 27, 2017 at 11:49:25AM -0800, Mickey Spiegel wrote:
> On Fri, Jan 27, 2017 at 11:16 AM, Guru Shetty  wrote:
> 
> >
> >>
> >> I should clarify that statement. It is a good thing if the chassis
> >> changes, for example if doing simple high availability. The GARP
> >> packet will fix L2 learning.
> >>
> >> As I think about it, if anyone uses logical routers without NAT
> >> or load balancers, and the chassis changes, then GARP of the
> >> router IP would still be useful. I guess a user could always
> >> specify the router IP and MAC in "nat-addresses" to make that
> >> happen. I am not sure if anyone is deploying OVN that way.
> >>
> >> Mickey
> >>
> >
> > I applied the first 5 patches of the series to master. I couldn't apply it
> > to 2.7 because of some conflicts. Would you mind reposting it just for 2.7
> > with "branch-2.7" in the subject . For e.g: [PATCH branch-2.7]
> >
> 
> Some previous patches made it into master but not yet
> branch-2.7:
> 
> https://github.com/openvswitch/ovs/commit/ba8d3816e88f7a702635c09111f58352ecad6506
> https://github.com/openvswitch/ovs/commit/41a15b71ed1ef35aa612a1128082219fbfc3f327
> 
> Next are a bunch of blp's patches that need to go in
> before these 5 patches:
> 
> https://github.com/openvswitch/ovs/commit/80b6743d0ab3a39884fe873dd616cb49b6f55fab
> https://github.com/openvswitch/ovs/commit/b3bd2c33e83e2039d75e830368a64d596f820aaa
> https://github.com/openvswitch/ovs/commit/ebb467ff1c255813d6ba27d91ef6180e9a20fe0a
> https://github.com/openvswitch/ovs/commit/8f5de08322673f4e60f44d599fa7ee4de65bc078
> https://github.com/openvswitch/ovs/commit/c571f48c36223de360ba0fa4d89104a7da14dbca
> https://github.com/openvswitch/ovs/commit/4c99cb181b6937efb3819cffc9765999fd7b7796
> https://github.com/openvswitch/ovs/commit/db0e819be065c1474ceef232dcc1260c9a2e7c0e
> 
> blp said that he could help with the backport:
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327884.html

I've now cherry-picked all the patches you mention to master.

Guru, does the series now apply to branch-2.7?  Or let me know if you'd
rather have me work on it.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] appveyor: Bump OpenSSL version

[Ben Pfaff]

On Tue, Jan 31, 2017 at 10:00:51PM +, Alin Serdean wrote:
> The URL https://slproweb.com/download/Win32OpenSSL-1_0_2j.exe is
> no longer valid.
> 
> Bump to the variables to the latest version of OpenSSL version.
> 
> Signed-off-by: Alin Gabriel Serdean 

Thanks, applied to master and branch-2.7.

Should we put a copy of OpenSSL at a stable URL?  There is not much
value in using up-to-the-minute OpenSSL for CI builds.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC PATCH 2/5] OVN: SFC Implementation: New stage for SFC and modified ACL stage

[John McDowall]

Ben,

Let me create a new patch set against the top of tree.

Regards

John

On 1/31/17, 1:46 PM, "Ben Pfaff"  wrote:

On Tue, Dec 27, 2016 at 02:11:43PM -0800, John McDowall wrote:
> This is the major body of code that implements SFC. There is a new L2 
stage added to
> perform the chaining operations and modifications to the ACL stage to 
direct flows
> to the service chain.
> 
> Co-authored-by: Flavio Fernandes 
> Reported at: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddiscuss_2016-2DMarch_040381.html=DwIBAg=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=0-H45ymu2qKdNfehkwCF8baQWBqDNhngIVaX4MlOpCQ=VbhqfPkju3uYqy7303Bfbz0fgnSeIi6aYsQoRwIH1PU=
 
> Reported at: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddiscuss_2016-2DMay_041359.html=DwIBAg=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=0-H45ymu2qKdNfehkwCF8baQWBqDNhngIVaX4MlOpCQ=vNieFlb8T7dsSygACJyaJiHvnrQDGCyox17covGw4Ns=
 
> 
> Signed-off-by: John McDowall 

I think that this has bit-rotted because I get tons of compiler errors
trying to build it.  I tried rewinding my repo to a point from December
but I still the same ones:

../ovn/northd/ovn-northd.c:2669:13: error: incomplete definition of 
type 'struct nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 
'struct nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2669:37: error: incomplete definition of 
type 'struct nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 
'struct nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2673:30: error: incomplete definition of 
type 'struct nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 
'struct nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2674:30: error: incomplete definition of 
type 'struct nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 
'struct nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2701:49: error: no member named 'options' in 
'struct nbrec_acl'
../ovn/northd/ovn-northd.c:2713:37: error: no member named 
'n_port_chains' in 'struct nbrec_logical_switch'
../ovn/northd/ovn-northd.c:2714:30: error: no member named 
'port_chains' in 'struct nbrec_logical_switch'
../ovn/northd/ovn-northd.c:2716:39: error: incomplete definition of 
type 'struct nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
'struct nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of 
type 'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:110:58: note: expanded from 
macro 'strcmp'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
'struct nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of 
type 'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:111:74: note: expanded from 
macro 'strcmp'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
'struct nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of 
type 'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:113:28: note: expanded from 
macro 'strcmp'
/usr/include/i386-linux-gnu/bits/string2.h:53:28: note: expanded from 
macro '__string2_1bptr_p'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
'struct nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of 
type 'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:113:28: note: expanded from 
macro 'strcmp'
/usr/include/i386-linux-gnu/bits/string2.h:53:63: note: expanded from 
macro '__string2_1bptr_p'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
'struct nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of 
type 'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:114:31: note: expanded from 
macro 'strcmp'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
'struct nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of 
type 'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:117:28: note: expanded from 
macro 'strcmp'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 
'struct nbrec_logical_port_chain'
   

[ovs-dev] [PATCH] appveyor: Bump OpenSSL version

[Alin Serdean]

The URL https://slproweb.com/download/Win32OpenSSL-1_0_2j.exe is
no longer valid.

Bump to the variables to the latest version of OpenSSL version.

Signed-off-by: Alin Gabriel Serdean 
---
 appveyor.yml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/appveyor.yml b/appveyor.yml
index 3364594..edcead6 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -15,9 +15,9 @@ init:
 
 Invoke-WebRequest $source -OutFile $destination
 
-$source = "https://slproweb.com/download/Win32OpenSSL-1_0_2j.exe;
+$source = "https://slproweb.com/download/Win32OpenSSL-1_0_2k.exe;
 
-$destination = "C:\ovs-build-downloads\Win32OpenSSL-1_0_2j.exe"
+$destination = "C:\ovs-build-downloads\Win32OpenSSL-1_0_2k.exe"
 
 Invoke-WebRequest $source -OutFile $destination
 
@@ -27,7 +27,7 @@ init:
 
 cd C:\ovs-build-downloads
 
-.\Win32OpenSSL-1_0_2j.exe /silent /verysilent /sp- /suppressmsgboxes
+.\Win32OpenSSL-1_0_2k.exe /silent /verysilent /sp- /suppressmsgboxes
 
 Start-Sleep -s 30
 
-- 
2.10.2.windows.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH V2] netdev-dpdk: fix ifindex assignment for DPDK ports

[Ben Pfaff]

On Thu, Dec 08, 2016 at 01:16:22PM +0100, Przemyslaw Lal wrote:
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index de78ddd..ef99eb3 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -2075,7 +2075,13 @@ netdev_dpdk_get_ifindex(const struct netdev *netdev)
>  int ifindex;
>  
>  ovs_mutex_lock(>mutex);
> -ifindex = dev->port_id;
> +/* Calculate hash from the netdev name using hash_bytes() function.
> + * Because ifindex is declared as signed int in the kernel sources and
> + * OVS follows this implementation right shift is needed to set sign bit
> + * to 0 and then XOR to slightly improve collision rate.
> + */
> +uint32_t h = hash_bytes(netdev->name, strlen(netdev->name), 0);
> +ifindex = (int)((h >> 1) ^ (h & 0x0FFF));

To hash a string, please use hash_string().

Daniele, are you planning to review this?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC PATCH] Pipeline packet processing in OVS using FVL flow director.

[Ben Pfaff]

We thawed master a couple of weeks ago, so it's a good time to rebase
and repost.

On Mon, Jan 16, 2017 at 09:08:53AM +, Chandran, Sugesh wrote:
>  Hi Ben,
> Many thanks for the reply..
> Will send out another version after the end of freeze
> 
> Regards
> _Sugesh
> 
> 
> > -Original Message-
> > From: Ben Pfaff [mailto:b...@ovn.org]
> > Sent: Friday, January 13, 2017 5:06 PM
> > To: Chandran, Sugesh 
> > Cc: 'd...@openvswitch.org' ; 'ro...@mellanox.com'
> > ; 'ktray...@redhat.com' ;
> > 'fla...@flaviof.com' 
> > Subject: Re: [ovs-dev] [RFC PATCH] Pipeline packet processing in OVS using
> > FVL flow director.
> > 
> > No, I haven't looked at this further.  Probably, you should post a new 
> > version
> > after the end of the freeze, to get more attention.
> > 
> > On Fri, Jan 13, 2017 at 09:16:44AM +, Chandran, Sugesh wrote:
> > > Hi Ben,
> > > Did you get chance to look at this patch? Any comments or suggestion on
> > this?
> > >
> > >
> > > Regards
> > > _Sugesh
> > >
> > > > -Original Message-
> > > > From: Chandran, Sugesh
> > > > Sent: Tuesday, December 6, 2016 9:51 AM
> > > > To: Ben Pfaff 
> > > > Cc: d...@openvswitch.org; ro...@mellanox.com; ktray...@redhat.com;
> > > > fla...@flaviof.com
> > > > Subject: RE: [ovs-dev] [RFC PATCH] Pipeline packet processing in OVS
> > > > using FVL flow director.
> > > >
> > > >
> > > >
> > > > Regards
> > > > _Sugesh
> > > >
> > > > > -Original Message-
> > > > > From: Ben Pfaff [mailto:b...@ovn.org]
> > > > > Sent: Monday, December 5, 2016 7:44 PM
> > > > > To: Chandran, Sugesh 
> > > > > Cc: d...@openvswitch.org; ro...@mellanox.com;
> > ktray...@redhat.com;
> > > > > fla...@flaviof.com
> > > > > Subject: Re: [ovs-dev] [RFC PATCH] Pipeline packet processing in
> > > > > OVS using FVL flow director.
> > > > >
> > > > > On Thu, Dec 01, 2016 at 06:23:55PM +, Sugesh Chandran wrote:
> > > > > > The RFC patch that uses the metadata information from the NIC to
> > > > > avoid/reduce the
> > > > > > packet processing overhead in OVS.
> > > > > > It uses the flow director feature in XL710 NICs to identify and
> > > > > > report the VxLAN tunneled packets. OVS-DPDK uses the reported
> > > > > > information to
> > > > > bypass the
> > > > > > VxLAN tunnel processing in software.
> > > > >
> > > > > This is interesting and I'd like to apply it locally to look at it
> > > > > more closely.  What commit is it based on?  It doesn't seem to
> > > > > apply cleanly
> > > > to current master.
> > > > [Sugesh] Ben, Thank you for looking at the patch. I haven't merged
> > > > the patch on the latest master yet.
> > > > Can you please try on following commit on the master?
> > > >
> > > > commit 01961bbdd34a9d0be03315401319ef0851a21364
> > > > Author: Daniele Di Proietto 
> > > > Date:   Tue Oct 4 17:58:05 2016 -0700
> > > >
> > > > dpdk: New module with some code from netdev-dpdk.
> > >
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Zong Kai Li's patches

[Ben Pfaff]

Hi Justin, I believe that you were planning to review Zong Kai Li's OVN
patches that have been languishing since October:
https://patchwork.ozlabs.org/project/openvswitch/list/?submitter=69084

Are you still planning to review them?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC PATCH 2/5] OVN: SFC Implementation: New stage for SFC and modified ACL stage

[Ben Pfaff]

On Tue, Dec 27, 2016 at 02:11:43PM -0800, John McDowall wrote:
> This is the major body of code that implements SFC. There is a new L2 stage 
> added to
> perform the chaining operations and modifications to the ACL stage to direct 
> flows
> to the service chain.
> 
> Co-authored-by: Flavio Fernandes 
> Reported at: 
> https://mail.openvswitch.org/pipermail/ovs-discuss/2016-March/040381.html
> Reported at: 
> https://mail.openvswitch.org/pipermail/ovs-discuss/2016-May/041359.html
> 
> Signed-off-by: John McDowall 

I think that this has bit-rotted because I get tons of compiler errors
trying to build it.  I tried rewinding my repo to a point from December
but I still the same ones:

../ovn/northd/ovn-northd.c:2669:13: error: incomplete definition of type 
'struct nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 'struct 
nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2669:37: error: incomplete definition of type 
'struct nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 'struct 
nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2673:30: error: incomplete definition of type 
'struct nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 'struct 
nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2674:30: error: incomplete definition of type 
'struct nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 'struct 
nbrec_logical_port_pair_group'
../ovn/northd/ovn-northd.c:2701:49: error: no member named 'options' in 
'struct nbrec_acl'
../ovn/northd/ovn-northd.c:2713:37: error: no member named 'n_port_chains' 
in 'struct nbrec_logical_switch'
../ovn/northd/ovn-northd.c:2714:30: error: no member named 'port_chains' in 
'struct nbrec_logical_switch'
../ovn/northd/ovn-northd.c:2716:39: error: incomplete definition of type 
'struct nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct 
nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 
'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:110:58: note: expanded from 
macro 'strcmp'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct 
nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 
'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:111:74: note: expanded from 
macro 'strcmp'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct 
nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 
'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:113:28: note: expanded from 
macro 'strcmp'
/usr/include/i386-linux-gnu/bits/string2.h:53:28: note: expanded from macro 
'__string2_1bptr_p'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct 
nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 
'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:113:28: note: expanded from 
macro 'strcmp'
/usr/include/i386-linux-gnu/bits/string2.h:53:63: note: expanded from macro 
'__string2_1bptr_p'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct 
nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 
'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:114:31: note: expanded from 
macro 'strcmp'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct 
nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 
'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:117:28: note: expanded from 
macro 'strcmp'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct 
nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 
'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:117:54: note: expanded from 
macro 'strcmp'
/usr/include/i386-linux-gnu/bits/string2.h:53:28: note: expanded from macro 
'__string2_1bptr_p'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct 
nbrec_logical_port_chain'
../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 
'struct nbrec_logical_port_chain'
/usr/include/i386-linux-gnu/bits/string2.h:117:54: note: expanded from 
macro 'strcmp'
/usr/include/i386-linux-gnu/bits/string2.h:53:63: note: expanded from macro 
'__string2_1bptr_p'
../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct 

Re: [ovs-dev] [RFC PATCH 1/5] OVN: SFC Implemnentation - documentation for SFC ACL Action

[Ben Pfaff]

On Tue, Dec 27, 2016 at 02:11:42PM -0800, John McDowall wrote:
> This is minor changes to documentation to support additional ACL action.
> 
> Co-authored-by: Flavio Fernandes 
> Reported at: 
> https://mail.openvswitch.org/pipermail/ovs-discuss/2016-March/040381.html
> Reported at: 
> https://mail.openvswitch.org/pipermail/ovs-discuss/2016-May/041359.html
> 
> Signed-off-by: John McDowall 

This is documentation for something coming later in the series, right?
Usually we document a feature in the same patch that implements it.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] documentation: Windows support multiple VTEP/NICs

[Ben Pfaff]

Applied, thanks Sairam and Alin!

On Fri, Jan 27, 2017 at 07:58:09AM +, Sairam Venugopal wrote:
> Acked-by: Sairam Venugopal 
> 
> 
> 
> 
> 
> On 1/26/17, 6:30 PM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
> Serdean"  aserd...@cloudbasesolutions.com> wrote:
> 
> >Multiple VTEP and multiple physical NICs are supported on Hyper-V now.
> >Update the documentation
> >
> >Signed-off-by: Alin Gabriel Serdean 
> >---
> >Intended for master and branch-2.7
> >---
> > Documentation/faq/releases.rst | 8 ++--
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> >diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst
> >index f9cb2e9..fcff5c3 100644
> >--- a/Documentation/faq/releases.rst
> >+++ b/Documentation/faq/releases.rst
> >@@ -118,18 +118,14 @@ Q: Are all features available with all datapaths?
> > sFlow YESYESYES   NO
> > IPFIX 3.10   YESYES   NO
> > Set actionYESYESYES   PARTIAL
> >-NIC Bonding   YESYESYES   NO
> >-Multiple VTEPsYESYESYES   NO
> >+NIC Bonding   YESYESYES   YES
> >+Multiple VTEPsYESYESYES   YES
> > = == == = ===
> > 
> > Do note, however:
> > 
> > * Only a limited set of flow fields is modifiable via the set action by 
> > the
> >   Hyper-V datapath.
> >-* The Hyper-V datapath only supports one physical NIC per datapath. 
> >This is
> >-  why bonding is not supported.
> >-* The Hyper-V datapath can have at most one IP address configured as a
> >-  tunnel endpoint.
> > 
> > The following table lists features that do not *directly* impact an Open
> > vSwitch user, e.g. because their absence can be hidden by the ofproto 
> > layer
> >-- 
> >2.10.2.windows.1
> >___
> >dev mailing list
> >d...@openvswitch.org
> >https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo=T_rrUyNsK92gO-mgKelX89Gl9X7BN9l6R492H7PrFUg=cSew8mJ8O124153-iYqpdbkMzTjPsaPrD1UJS9_Kx2k=
> > 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] windows: wmi add include

[Ben Pfaff]

On Mon, Jan 30, 2017 at 07:42:31AM +, Alin Serdean wrote:
> Add 'util.h' to includes otherwise the result of the function
> 'ovs_format_message' will be unknown and be converted to int,
> triggering an abort of vswitchd.

Is there a way to make MSVC fail the compile if a function is called
without a visible prototype?  That would prevent this problem.

Alternatively, if it's possible to get a warning but not an error, it
might be possible to add something to the appveyor build script to fail
that build if any such warning is reported.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/1] OVN: Firewall service files for OVN

[Russell Bryant]

On Tue, Jan 31, 2017 at 1:11 PM, Ben Pfaff  wrote:

> On Tue, Jan 31, 2017 at 05:25:26PM +0100, Marcin Mirecki wrote:
> > Firewall service files allowing to open firewalld
> > ports required for running OVN.
> >
> >
> > Current OVN installation does not configure firewalld.
> > Running firewalld prevents OVN from working properly.
> >
> > Signed-off-by: Marcin Mirecki
>
> This email is written like a commit message, but no patch is included.
>

I got it as an attachment, perhaps because it was also sent directly to
me.  Marcin, can you try submitting this using the "git-send-email" utility?

Thanks,

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

Re: [ovs-dev] [PATCH v2] packet: proper return type for vlan_tci_to_pcp()

[Ben Pfaff]

By my count, vlan_tci_to_pcp() is used in printf-like format specifiers
in 7 places in the tree.  Before this patch, it is used with the
following format specifiers:

%d  3 times
%x  1 time
PRIu8   1 time
PRIx8   1 time

Both %d and %x are obviously correct, portable format specifiers for
int, which is the return type of vlan_tci_to_pcp().  I contend that
PRIu8 and PRIx8 should be acceptable too because the integer promotions
convert uint8_t to int anyway.

After this patch, vlan_tci_to_pcp() returns uint8_t and it is used in
the following format specifiers:

%d  2 times
PRIu8   2 times
PRIx8   2 times

I still don't see the point.  You're saying, effectively, that %x is not
acceptable but all the others are.  How is that possible?

On Sat, Jan 14, 2017 at 09:59:33AM -0800, Shu Shen wrote:
> The main change of this patch is in lib/packets.h, where the return type of
> vlan_tci_to_pcp() and vlan_tci_to_cfi() are changed from int to uint8_t.
> 
> Changes to the format specifiers are for portability to mac OS and
> consistency use of PRIu* specifiers.
> 
> On Sat, Jan 14, 2017 at 8:47 AM, Ben Pfaff  wrote:
> > On Fri, Jan 13, 2017 at 02:04:38PM -0800, Shu Shen wrote:
> >> The return type of vlan_tci_to_pcp() was int where it's expected to be
> >> uint8_t and causing implicit truncation when the function is used. On
> >> some platforms such as macOS, where PRIu8 is defined as "hhx" and no
> >> promotion of short to int is done, the compiler might throw out Wformat
> >> message for ds_put_format() calls on the returns value of
> >> vlan_tci_to_pcp().
> >>
> >> vlan_tci_to_cfi() is also fixed with uint8_t as return type although the
> >> function is not currently being used anywhere.
> >>
> >> Format strings in ds_put_format() for printing out returned values from
> >> vlan_tci_to_pcp() were updated to ensure PRIu8 or PRIx8 are used for
> >> portability.
> >>
> >> Signed-off-by: Shu Shen 
> >> ---
> >>
> >> v2: Fixed typoes for uint8_t in commit message
> >
> > This one doesn't really make sense to me.  This patch only changes two
> > format specifiers away from %d or %x, which are both correct format
> > specifiers for "int".  Can you explain?
> >
> > Thanks,
> >
> > Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 6/6] datapath-windows: GENEVE Check for flow destination port

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 1/10/17, 8:48 AM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Serdean"  wrote:

>Change the UDP destination port(GENEVE header) to check if it was set by
>the userspace, use it if it was set.
>If the userspace did not specify a destination port, use the configured
>vport destination port.
>
>Signed-off-by: Alin Gabriel Serdean 
>---
> datapath-windows/ovsext/Geneve.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/datapath-windows/ovsext/Geneve.c 
>b/datapath-windows/ovsext/Geneve.c
>index d38a656..1938aaa 100644
>--- a/datapath-windows/ovsext/Geneve.c
>+++ b/datapath-windows/ovsext/Geneve.c
>@@ -201,7 +201,8 @@ NDIS_STATUS OvsEncapGeneve(POVS_VPORT_ENTRY vport,
> /* UDP header */
> udpHdr = (UDPHdr *)((PCHAR)ipHdr + sizeof *ipHdr);
> udpHdr->source = htons(tunKey->flow_hash | MAXINT16);
>-udpHdr->dest = htons(vportGeneve->dstPort);
>+udpHdr->dest = tunKey->dst_port ? tunKey->dst_port :
>+  htons(vportGeneve->dstPort);
> udpHdr->len = htons(NET_BUFFER_DATA_LENGTH(curNb) - headRoom +
> sizeof *udpHdr + sizeof *geneveHdr +
> tunKey->tunOptLen);
>-- 
>2.10.2.windows.1
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo=27Dx7O-5y_jyUN7Wbspxmpvpmjl03_tnujYJ8a5JWgk=GxVh-4CexmeK4NNAYLfyuzdTn25QmVzYHPk0agAE7VQ=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 5/6] datapath-windows: STT Check for flow destination port

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 1/10/17, 8:48 AM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Serdean"  wrote:

>Change the TCP destination port(STT header) to check if it was set by
>the userspace, use it if it was set.
>If the userspace did not specify a destination port, use the configured
>vport destination port.
>
>Signed-off-by: Alin Gabriel Serdean 
>---
> datapath-windows/ovsext/Stt.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/datapath-windows/ovsext/Stt.c b/datapath-windows/ovsext/Stt.c
>index 9da81dc..5aa8652 100644
>--- a/datapath-windows/ovsext/Stt.c
>+++ b/datapath-windows/ovsext/Stt.c
>@@ -308,7 +308,8 @@ OvsDoEncapStt(POVS_VPORT_ENTRY vport,
> /* L4 header */
> RtlZeroMemory(outerTcpHdr, sizeof *outerTcpHdr);
> outerTcpHdr->source = htons(tunKey->flow_hash | 32768);
>-outerTcpHdr->dest = htons(vportStt->dstPort);
>+outerTcpHdr->dest = tunKey->dst_port ? tunKey->dst_port:
>+   htons(vportStt->dstPort);
> outerTcpHdr->seq = htonl((STT_HDR_LEN + innerFrameLen) <<
>  STT_SEQ_LEN_SHIFT);
> outerTcpHdr->ack_seq = htonl(atomic_inc64(>ackNo));
>-- 
>2.10.2.windows.1
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo=hBUOR4xEDx1_kXNf_w0UfXPyCRqbASz4TKv3Gcu8SjY=L1_elR78u6pHX6FjX3RUoYW1BH_aPfjfuZInfwRpdnA=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 4/6] datapath-windows: VXLAN Check for flow destination port

[Sairam Venugopal]

Acked-by: Sairam Venugopal 





On 1/10/17, 8:48 AM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Serdean"  wrote:

>Change the UDP destination port(VXLAN header) to check if it was set by
>the userspace, use it if it was set.
>If the userspace did not specify a destination port, use the configured
>vport destination port.
>
>Signed-off-by: Alin Gabriel Serdean 
>---
> datapath-windows/ovsext/Vxlan.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/datapath-windows/ovsext/Vxlan.c b/datapath-windows/ovsext/Vxlan.c
>index 949e069..84c2f2f 100644
>--- a/datapath-windows/ovsext/Vxlan.c
>+++ b/datapath-windows/ovsext/Vxlan.c
>@@ -289,7 +289,8 @@ OvsDoEncapVxlan(POVS_VPORT_ENTRY vport,
> /* UDP header */
> udpHdr = (UDPHdr *)((PCHAR)ipHdr + sizeof *ipHdr);
> udpHdr->source = htons(tunKey->flow_hash | MAXINT16);
>-udpHdr->dest = htons(vportVxlan->dstPort);
>+udpHdr->dest = tunKey->dst_port ? tunKey->dst_port :
>+  htons(vportVxlan->dstPort);
> udpHdr->len = htons(NET_BUFFER_DATA_LENGTH(curNb) - headRoom +
> sizeof *udpHdr + sizeof *vxlanHdr);
> 
>-- 
>2.10.2.windows.1
>___
>dev mailing list
>d...@openvswitch.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo=5_pKhBH-PUBhzkQB9iiJQHwEXF4_z3jQTCICjBvpj1M=LmmZoSZ1s-GGDQBO7ydyZsKXCOqTZ_QAp99ZVHO633M=
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v3] dpif-netdev: Conditional EMC insert

[Ciara Loftus]

Unconditional insertion of EMC entries results in EMC thrashing at high
numbers of parallel flows. When this occurs, the performance of the EMC
often falls below that of the dpcls classifier, rendering the EMC
practically useless.

Instead of unconditionally inserting entries into the EMC when a miss
occurs, use a 1% probability of insertion. This ensures that the most
frequent flows have the highest chance of creating an entry in the EMC,
and the probability of thrashing the EMC is also greatly reduced.

The probability of insertion is configurable, via the
other_config:emc-insert-prob option. For example the following command
increases the insertion probability to 1/10 ie. 10%.

ovs-vsctl set Open_vSwitch . other_config:emc-insert-prob=10

Signed-off-by: Ciara Loftus 
Signed-off-by: Georg Schmuecking 
Co-authored-by: Georg Schmuecking 
---
v3:
- Use new dpif other_config infrastructure to tidy up how the
  emc-insert-prob value is passed to dpif-netdev.
v2:
- Enable probability configurability via other_config:emc-insert-prob
  option.

 Documentation/howto/dpdk.rst | 20 +
 NEWS |  2 ++
 lib/dpif-netdev.c| 53 ++--
 vswitchd/vswitch.xml | 16 +
 4 files changed, 89 insertions(+), 2 deletions(-)

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index d1e6e89..f2e888b 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -354,6 +354,26 @@ the `DPDK documentation
 
 Note: Not all DPDK virtual PMD drivers have been tested and verified to work.
 
+EMC Insertion Probability
+-
+By default 1 in every 100 flows are inserted into the Exact Match Cache (EMC).
+It is possible to change this insertion probability by setting the
+``emc-insert-prob`` option::
+
+$ ovs-vsctl --no-wait set Open_vSwitch . other_config:emc-insert-prob=N
+
+where:
+
+``N``
+  is a positive integer between 0 and 4294967295 (maximum unsigned 32bit int).
+
+If ``N`` is set to 1, an insertion will be performed for every flow. The lower
+the value of ``emc-insert-prob`` the higher the probability of insertion,
+except for the value 0 which will result in no insertions being performed and
+thus essentially disabling the EMC.
+
+For more information on the EMC refer to :doc:`/intro/install/dpdk` .
+
 .. _dpdk-ovs-in-guest:
 
 OVS with DPDK Inside VMs
diff --git a/NEWS b/NEWS
index 6838649..5a21580 100644
--- a/NEWS
+++ b/NEWS
@@ -65,6 +65,8 @@ Post-v2.6.0
device will not be available for use until a valid dpdk-devargs is
specified.
  * Virtual DPDK Poll Mode Driver (vdev PMD) support.
+ * EMC insertion probability is reduced to 1/100 and is configurable via
+   the new 'other_config:emc-insert-prob' option.
- Fedora packaging:
  * A package upgrade does not automatically restart OVS service.
- ovs-vswitchd/ovs-vsctl:
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 0be5db5..e514ddb 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -144,6 +144,10 @@ struct netdev_flow_key {
 #define EM_FLOW_HASH_MASK (EM_FLOW_HASH_ENTRIES - 1)
 #define EM_FLOW_HASH_SEGS 2
 
+/* Default EMC insert probability is 1 / DEFAULT_EM_FLOW_INSERT_PROB */
+#define DEFAULT_EM_FLOW_INSERT_PROB 100
+#define DEFAULT_EM_FLOW_INSERT_MIN (UINT32_MAX / DEFAULT_EM_FLOW_INSERT_PROB)
+
 struct emc_entry {
 struct dp_netdev_flow *flow;
 struct netdev_flow_key key;   /* key.hash used for emc hash value. */
@@ -254,6 +258,9 @@ struct dp_netdev {
 uint64_t last_tnl_conf_seq;
 
 struct conntrack conntrack;
+
+/* Probability of EMC insertions is a factor of 'emc_insert_min'.*/
+atomic_uint32_t emc_insert_min;
 };
 
 static struct dp_netdev_port *dp_netdev_lookup_port(const struct dp_netdev *dp,
@@ -1066,6 +1073,8 @@ create_dp_netdev(const char *name, const struct 
dpif_class *class,
 
 conntrack_init(>conntrack);
 
+atomic_init(>emc_insert_min, DEFAULT_EM_FLOW_INSERT_MIN);
+
 cmap_init(>poll_threads);
 ovs_mutex_init_recursive(>non_pmd_mutex);
 ovsthread_key_create(>per_pmd_key, NULL);
@@ -1943,6 +1952,22 @@ emc_insert(struct emc_cache *cache, const struct 
netdev_flow_key *key,
 emc_change_entry(to_be_replaced, flow, key);
 }
 
+static inline void
+emc_probabilistic_insert(struct emc_cache *cache,
+ const struct netdev_flow_key *key,
+ struct dp_netdev_flow *flow,
+ uint32_t random_val, uint32_t min)
+{
+/* Insert an entry into the EMC based on probability value 'min'. By
+ * default the value is UINT32_MAX / 100 which yields an insertion
+ * probability of 1/100. This value may be different for the DPDK datapath
+ * depending on whether or not the user has configured the
+ * 'emc-insert-prob' other_config option. */
+if 

[ovs-dev] [PATCH 1/1] OVN: Firewall service files for OVN

[Marcin Mirecki]

Firewall service files allowing to open firewalld
ports required for running OVN.


Current OVN installation does not configure firewalld.
Running firewalld prevents OVN from working properly.

Signed-off-by: Marcin Mirecki
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] netlink-socket: Fix possiblity of nl_transact dereferncing null pointer

[Ben Pfaff]

On Tue, Jan 31, 2017 at 08:40:08AM +0200, Roi Dayan wrote:
> Many nl_transact callers and its wrapper tc_transact pass NULL for replyp
> which is being accessed in error flow without being checked if null or not.
> 
> Signed-off-by: Roi Dayan 
> Reviewed-by: Paul Blakey 

Thanks, applied to master, branch-2.7, branch-2.6.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev