Re: [ovs-dev] [PATCH 4.4-only] openvswitch: clear sender cpu before forwarding packets

[Greg KH]

On Wed, May 17, 2017 at 10:21:09AM +0100, Anoob Soman wrote:
> On 17/05/17 09:19, Greg KH wrote:
> > Why is this a non-upstream patch?  What commit in Linus's tree fixed
> > this?  Why not just backport that?
> > 
> > thanks,
> > 
> > greg k-h
> 
> Agreed, I think it is sensible to backport 52bd2d62ce67 "net: better
> skb->sender_cpu and skb->napi_id cohabitation" to 4.4, rather than having a
> different patch.

So backporting that one patch solves the issue here?  Can you please
verify it, and let me know before I apply it?

thanks,

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

[ovs-dev] [RFC PATCH v1 0/3] RFC for Userspace IPsec Interface

[Ian Stokes]

Hi all,

I'm starting to work on enabling IPsec for userspace in OVS.

IPsec was previously implemented for OVS but was removed in OVS 2.6 due to a
number of issues.

This RFC patchset aims to outline the approach I'm considering for
re-introducing it to userspace and to gather feedback at the early stages of
development.

The RFC patch for the actual implementation will be submitted at a later date.

I'd like to discuss 2 areas in this cover letter which are not directly
covered in the accompanying RFC patches.

(i) Usecase: Securing isolated tenant VM traffic.
(ii) Known Opens


(i) Usecase: Securing isolated tenant VM traffic.

Users can isolate traffic between VMs in a data center by the use of an
appropriate tunneling protocol i.e. VXLAN.

However although the traffic is isolated in terms of its source and
destination, it is not encrypted.

A rogue entity with access to the network could listen and examine the clear
text payload of this traffic between VMs.

The aim of this work is to introduce IPsec in userspace to secure the traffic
payloads.

As such, the malicious entity could still see the traffic as it traverses the
network but the payload of the traffic will be secured via encryption and
authentication provided by IPsec.

The steps involved in securing the vxlan payload would be done with VXLAN over
IPsec (transport Mode). This would look as follows

1.) Original header | Payload ! before VXLAN

2.) Outer header | UDP |VXLAN | Original header | Payload ! after VXLAN

3.) Outer header | ESP | Encrypt ( UDP | VXLAN | Original header | Payload )
! after IPsec transport mode

A more detailed description of the expected packet format is given below.

   Outer Ethernet Header:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Outer Destination MAC Address |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Outer Destination MAC Address | Outer Source MAC Address  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Outer Source MAC Address   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |OptnlEthtype = C-Tag 802.1Q| Outer.VLAN Tag Information|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Ethertype = 0x0800|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Outer IPv4 Header:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|  Total Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Identification|Flags|  Fragment Offset|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live | Protocol = 50 (ESP) |   Header Checksum   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Outer Source IPv4 Address   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Outer Destination IPv4 Address  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   ESP Header:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |SPI (Security Parameter Index) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sequence Number  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Outer UDP Header:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Source Port |   Dest Port = VXLAN Port  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   UDP Length  |UDP Checksum   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   VXLAN Header:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|R|R|R|I|R|R|R|Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |VXLAN Network Identifier (VNI) |   Reserved|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   Inner Ethernet Header:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Inner Destination MAC Address |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Inner Destination MAC Address | Inner Source MAC Address  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Inner Source MAC Address   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |OptnlEthtype = C-Tag 802.1Q| Inner.VLAN Tag Information|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Payload:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[ovs-dev] [RFC PATCH v1 1/3] vswitch.xml: Detail ipsec user interface.

[Ian Stokes]

This commit adds details to the vswitch xml regarding the use of the
ipsec interface type. This patch is not intended for upstreaming and
simply seeks to solicit feedback on the user interface design of the
ipsec port type as described in the vswitch.xml.

This modifies the vswitch.xml with a proposed ipsec interface. It also
provides details for the proposed interface options such as SPD
creation, SA creation and modification, Policy entries for the SPD as
well as traffic selctor options for the policy.

Signed-off-by: Ian Stokes 
---
 vswitchd/vswitch.xml |  222 ++
 1 files changed, 222 insertions(+), 0 deletions(-)

diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index bb66cb5..a537911 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -2191,6 +2191,12 @@
 A pair of virtual devices that act as a patch cable.
   
 
+  ipsec
+  
+An interface type to provide IPsec RFC4301 functionality for
+traffic at the IP layer, initially for IPv4 environments.
+  
+
   null
   An ignored interface. Deprecated and slated for removal in
   February 2013.
@@ -2510,6 +2516,222 @@
   
 
 
+
+  
+Only ipsec interfaces support these options.
+  
+
+  
+  
+Must be an identifier for the SPD that is to be used by this IPsec
+interface. If no SPD exists with this ID then it will be created.
+  
+  
+
+  
+  
+An identifier representing the ID of a Security Association.
+If no SA with this ID exists it will be created.
+  
+  
+
+  
+  
+A 32 bit number representing the security policy index for
+the SA.
+  
+  
+
+  
+  
+The IPsec mode that applies to the SA, one of:
+  
+
+  
+transport: Provide protection primarily for next
+layer protocols.
+  
+  
+tunnel: Provide protection to IP layer also (applied
+to tunneled IP packets).
+  
+
+  
+Initially only support for transport mode will be implemented.
+  
+  
+
+  
+  
+The security protocol used for IPsec, one of the following:
+  
+
+  
+ESP: Encapsulating Security Payload.
+  
+  
+AH: Authentication header
+  
+
+  
+Initially only ESP is supported, users can implement authentication
+communication only by setting the encryption algorithm to NULL for ESP
+but specifying the integrity algorithm. In this way there is no need
+to support AH. If this is acceptable to the OVS community then this
+option could be removed as it will always be ESP.
+  
+  
+
+  
+  
+The encryption algorithm used for IPsec, one of the following:
+  
+
+  
+NULL: No encryption. Note NULL is required for the
+use of ESP with authentication only which is preferred over AH
+due to NAT traversal.
+  
+  
+AES_CBC: AES_CBC is a non-AEAD algorithm. Note users
+MUST specify an authentication algorithm to check integrity.
+  
+  
+AES_GCM_16: An AEAD algorithm. This allows the use of
+ESP with a combined mode cipher that handles encryption/decryption
+and authentication in a single step. Recommended for performance.
+  
+
+  
+
+  
+  
+A crypto key specifies the transformation of plaintext into cipher
+text for the encryption algorithm. Alphanumeric user generated string.
+IPsec sessions may have very long life time, and carry multiple
+packets, where possible 128-bit or 256-bit keys should be used.
+  
+  
+
+  
+  
+Optional. Represents the authentication algorithm to be used for
+IPsec. Depending on the encryption algorithm that is chosen a user
+may have to specify a separate authentication algorithm.  This
+typically occurs when communications are encrypted with non-AEAD
+algorithm which MUST be combined with an authentication algorithm.
+Can be one of the following:
+  
+
+  
+NULL: No authentication algorithm. Must only be used
+when the encryption is done with an AEAD algorithm.
+  
+  
+HMAC_SHA2_256_128: Should be selected when a non AEAD
+algorithm is used for encryption.
+  
+  
+
+  
+  
+Required if an auth_alg has been specificed. An authentication key
+specifies the transformation of plaintext into cipher text for the
+authentication algorithm. An alphanumeric user generated string. IPsec
+sessions may have very long 

[ovs-dev] [RFC PATCH v1 2/3] Docs: Add userspace-ipsec how to guide.

[Ian Stokes]

This commit adds a how to guide for using the proposed IPsec userspace
interface. It is not intended to be upstreamed but simply seeks to
solicit feed back by providing an example of the proposed IPsec interface
design setup and usage.

The how to usecase deals with securing vxlan traffic between 2 VMs as
described in the userspace-vxlan how to guide. It provides an example of
how the proposed ipsec interface is configured with an SPD, creation of
SAs including IPsec protocol, mode, crypto/authentication algorithms/keys,
assigning SPD entires to SAs for inbound/outbound traffic with traffic
selectors and finally updating the SA keys.

Signed-off-by: Ian Stokes 
---
 Documentation/howto/userspace-ipsec.rst |  166 +++
 1 files changed, 166 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/howto/userspace-ipsec.rst

diff --git a/Documentation/howto/userspace-ipsec.rst 
b/Documentation/howto/userspace-ipsec.rst
new file mode 100644
index 000..ae75516
--- /dev/null
+++ b/Documentation/howto/userspace-ipsec.rst
@@ -0,0 +1,166 @@
+..
+  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.
+
+==
+Securing VXLAN traffic between VMs Using IPsec (Userspace)
+==
+
+This document describes how to use IPsec in Open vSwitch to secure traffic
+between VMs on two different hosts communicating over VXLAN tunnels. This
+solution works entirely in userspace.
+
+.. note::
+
+   This guide covers the steps required to configure an IPsec interface to
+   secure VXLAN tunneling traffic. It does not cover the steps to configure
+   the vxlan tunnels in userspace. For these configuration steps please refer
+   to :doc:`userspace-tunneling`.
+
+.. TODO(stephenfin): Convert this to a (prettier) PNG with same styling as the
+   rest of the document
+
+::
+
++--+  +--+
+| vm0  | 192.168.1.1/24192.168.1.2/24 | vm1  |
++--+  +--+
+   (vm_port0)(vm_port1)
+   | |
+   | |
+   | |
++--+  +--+
+|br-int|  |br-int|
++--+  +--+
+|vxlan0| 172.168.1.1/24172.168.1.2/24 |vxlan0|
++--+  +--+
+|ipsec0|  |ipsec0|
++--+  +--+
+   | |
+   | |
+   | |
++--+  +--+
+|br-phy|  |br-phy|
++--+  +--+
+|  dpdk0/eth1  |--|  dpdk0/eth1  |
++--+  +--+
+Host 1 with OVS.  Host 2 with OVS.
+
+Setup
+-
+
+This guide assumes the environment is configured as described below.
+
+Two Physical Hosts
+~~
+
+The environment assumes the use of two hosts, named `host1` and `host2`. We
+only detail the configuration of `host1` but a similar configuration can be
+used for `host2`. Both hosts should be configured with Open vSwitch with DPDK
+datapath, QEMU/KVM and suitable VM images. Open vSwitch should be running
+before proceeding.
+
+Configuration Steps
+---
+
+Follow the configuration steps outlined in :doc:`userspace-tunneling` to setup
+VXLAN tunneling between vm0 and vm1 using the DPDK data

[ovs-dev] [RFC PATCH v1 3/3] Docs: Update releases with IPsec feature support info.

[Ian Stokes]

This commit adds details to the releases doc regarding the support
provided for IPsec functionality. It is not intended to be upstreamed,
simply to solicit feedback regarding the basic IPsec functionality
required to secure vxlan traffic as described in the cover letter
usecase for the patch series.

The modifications include the addition of IPsec to the OVS feature
support table, supported algorithms for encryption/authentication,
supported protocols and modes for ESP as well as support for SW/HW
encryption.

Signed-off-by: Ian Stokes 
---
 Documentation/faq/releases.rst |   51 
 1 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst
index c85eff8..1bad2b0 100644
--- a/Documentation/faq/releases.rst
+++ b/Documentation/faq/releases.rst
@@ -121,6 +121,7 @@ Q: Are all features available with all datapaths?
 Set actionYESYESYES   PARTIAL
 NIC Bonding   YESYESYES   YES
 Multiple VTEPsYESYESYES   YES
+IPsec NO NO PARTIAL   No
 = == == = ===
 
 Do note, however:
@@ -163,6 +164,56 @@ Q: What DPDK version does each Open vSwitch release work 
with?
 2.7.x16.11.1
  ===
 
+Q: What IPsec features are available in OVS Userspace?
+
+A: IPsec supports the following IPsec features in userspace.
+
+=== =
+IPsec Protocols Supported
+=== =
+ESP YES
+AH  NO
+=== =
+
+== =
+IPsec Mode Supported
+== =
+Transport  YES
+Tunnel NO
+== =
+
+= =
+ESP Encryption Algorithms Supported
+= =
+NULL  YES
+AES_CBC   YES
+AES_GCM_16YES
+= 
+
+= =
+ESP Authentication Algorithms Supported
+= =
+NULL  YES
+HMAC_SHA2_256_128 YES
+= =
+
+= =
+SA Key generation Supported
+= =
+User generatedYES
+IKEv2 NO
+= =
+
+The following is specific to the use of DPDK crypto devices for IPsec
+encryption/decryption operations.
+
+=== =
+Crypto Dev Type Supported
+=== =
+Virtual YES
+HardwareNO
+=== =
+
 Q: I get an error like this when I configure Open vSwitch:
 
 configure: error: Linux kernel in  is version , but
-- 
1.7.0.7

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

Re: [ovs-dev] [PATCH v2 1/3] netdev-dpdk: Fix double attaching of virtual devices.

[Ilya Maximets]

On 17.05.2017 18:01, Darrell Ball wrote:
> 
> 
> On 5/17/17, 4:16 AM, "Ilya Maximets"  wrote:
> 
> On 17.05.2017 08:53, Ilya Maximets wrote:
> > Hi Darrell,
> > 
> > Good catch. Thanks. One comment inline.
> > 
> > Best regards, Ilya Maximets.
> > 
> > On 16.05.2017 20:14, Darrell Ball wrote:
> >> I applied the following incremental to fix a missing free on error, 
> but otherwise is fine 
> >> Can you fold in the incremental.
> >>
> >>
> >> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> >> index 56b9d25..25d9c9b 100644
> >> --- a/lib/netdev-dpdk.c
> >> +++ b/lib/netdev-dpdk.c
> >> @@ -1128,7 +1128,7 @@ netdev_dpdk_process_devargs(const char *devargs, 
> char **errp)
> >>  } else {
> >>  /* Attach unsuccessful */
> >>  VLOG_WARN_BUF(errp, "Error attaching device '%s' to 
> DPDK", devargs);
> >> -return -1;
> >> +new_port_id = UINT8_MAX;
> > 
> > 'rte_eth_dev_get_port_by_name' and 'rte_eth_dev_attach' set a valid
> > 'new_port_id' only on success. So, we don't need to reinitialize it
> > here. Just removing of return should be enough.
> 
> I just found that this change also was mistakenly moved to the third 
> patch.
> Oh.. Kind of bad luck with splitting of this patches.
> Also, I think, I'll keep this reinitialization just to make code more 
> clear.
> 
> In your previous response, you were arguing that removing the return was good
> enough. Now, you are saying the re-initialization is ok since you had 
> something 
> similar in your 3rd patch – hmm, fine.

There is one more reason. 'rte_eth_dev_get_port_by_name' actually changes
the new_port_id even on failure. It sets new_port_id to RTE_MAX_ETHPORTS.
It's harmless, but looks logically wrong. This is actually undocumented
behaviour and I decided to re-initialize just to avoid any possible issue
in the future.

In general, I think, that 'rte_eth_dev_get_port_by_name' shouldn't touch
the new_port_id in case of failure. I'll send corresponding patch to DPDK.

> >>  }
> >>  }
> >>
> >>
> >> On 5/12/17, 8:10 AM, "Ilya Maximets"  wrote:
> >>
> >> 'devargs' for virtual devices contains not only name but
> >> also a list of arguments like this:
> >> 
> >>'net_pcap0,rx_pcap=file_rx.pcap,tx_pcap=file_tx.pcap'
> >>or
> >>'eth_af_packet0,iface=eth0'
> >> 
> >> We must cut off the arguments from this string before calling
> >> 'rte_eth_dev_get_port_by_name()' to avoid double attaching of
> >> the same device.
> >> 
> >> CC: Ciara Loftus 
> >> Fixes: 69876ed78611 ("netdev-dpdk: Add support for virtual DPDK 
> PMDs (vdevs)")
> >> Signed-off-by: Ilya Maximets 
> >> ---
> >> 
> >>  lib/netdev-dpdk.c | 5 -
> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> >> index 609b8da..56b9d25 100644
> >> --- a/lib/netdev-dpdk.c
> >> +++ b/lib/netdev-dpdk.c
> >> @@ -1114,10 +1114,12 @@ netdev_dpdk_lookup_by_port_id(int port_id)
> >>  static int
> >>  netdev_dpdk_process_devargs(const char *devargs, char **errp)
> >>  {
> >> +/* Get the name up to the first comma. */
> >> +char *name = xmemdup0(devargs, strcspn(devargs, ","));
> >>  uint8_t new_port_id = UINT8_MAX;
> >>  
> >>  if (!rte_eth_dev_count()
> >> -|| rte_eth_dev_get_port_by_name(devargs, &new_port_id)
> >> +|| rte_eth_dev_get_port_by_name(name, &new_port_id)
> >>  || !rte_eth_dev_is_valid_port(new_port_id)) {
> >>  /* Device not found in DPDK, attempt to attach it */
> >>  if (!rte_eth_dev_attach(devargs, &new_port_id)) {
> >> @@ -1130,6 +1132,7 @@ netdev_dpdk_process_devargs(const char 
> *devargs, char **errp)
> >>  }
> >>  }
> >>  
> >> +free(name);
> >>  return new_port_id;
> >>  }
> >>  
> >> -- 
> >> 2.7.4
> >> 
> >> 
> >>
> 
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] submitting-patches: Update test and documentation recommendations.

[Ben Pfaff]

Rationale:

- "make distcheck" is not as necessary anymore because we have a build-time
  check that fails if files in the repository are not distributed.

- xenserver has not been important for years, so remove the specific
  callout.

- We already have an informal custom of adding tests for new feaures and
  bug fixes, so codify it.

- Add note about updating NEWS.

Signed-off-by: Ben Pfaff 
---
 .../internals/contributing/submitting-patches.rst  | 25 +++---
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/Documentation/internals/contributing/submitting-patches.rst 
b/Documentation/internals/contributing/submitting-patches.rst
index edbc1aa8d9ff..4f7ca0304034 100644
--- a/Documentation/internals/contributing/submitting-patches.rst
+++ b/Documentation/internals/contributing/submitting-patches.rst
@@ -44,29 +44,28 @@ particular:
 - A patch should make one logical change.  Don't make multiple, logically
   unconnected changes to disparate subsystems in a single patch.
 
-- A patch that adds or removes user-visible features should also update the
-  appropriate user documentation or manpages.  Check "Feature Deprecation
-  Guidelines" section in this document if you intend to remove user-visible
-  feature.
+- A patch that adds or removes user-visible features should also
+  update the appropriate user documentation or manpages.  Consider
+  adding an item to NEWS for nontrivial changes.  Check "Feature
+  Deprecation Guidelines" section in this document if you intend to
+  remove user-visible feature.
 
 Testing is also important:
 
-- A patch that modifies existing code should be tested with ``make
-  check`` before submission.  Refer to the `install guide`, under "Self-Tests",
-  for more information.
+- Test a patch that modifies existing code with ``make check`` before
+  submission.  Refer to the `install guide`, under "Self-Tests", for
+  more information.
 
-- A patch that adds or deletes files should also be tested with ``make
+- Consider testing a patch that adds or deletes files with ``make
   distcheck`` before submission.
 
 - A patch that modifies Linux kernel code should be at least build-tested on
   various Linux kernel versions before submission.  I suggest versions 3.10 and
   whatever the current latest release version is at the time.
 
-- A patch that modifies the ofproto or vswitchd code should be tested in at
-  least simple cases before submission.
-
-- A patch that modifies xenserver code should be tested on XenServer before
-  submission.
+- A patch that adds a new feature should add appropriate tests for the
+  feature.  A bug fix patch should preferably add a test that would
+  fail if the bug recurs.
 
 If you are using GitHub, then you may utilize the travis-ci.org CI build system
 by linking your GitHub repository to it. This will run some of the above tests
-- 
2.10.2

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

Re: [ovs-dev] [PATCH] Supporting ovn-northd service HA depend on OVNDB-HA

[Numan Siddique]

On Wed, May 17, 2017 at 9:15 PM, Ben Pfaff  wrote:

> From: Zhengwei Gao 
>
> As ovn-northd servcie  parse network element between ovnnb_db and
> ovnsb_db, it ensures ovn-northd service connecting to ovnnb_db and
> ovnsb_db. OVNDB-HA was supported with pacemaker, ovn-northd service
> will be failover fllowing OVNDB-HA.
> ---
> This was posted as a github pull request:
> https://github.com/openvswitch/ovs/pull/176
>
>  ovn/utilities/ovndb-servers.ocf | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/ovn/utilities/ovndb-servers.ocf
> b/ovn/utilities/ovndb-servers.ocf
> index 908cb3c17d84..40c55411e828 100755
> --- a/ovn/utilities/ovndb-servers.ocf
> +++ b/ovn/utilities/ovndb-servers.ocf
> @@ -122,8 +122,12 @@ ovsdb_server_notify() {
>  # the right thing at startup
>  ocf_log debug "ovndb_server: $host_name is the master"
>  ${CRM_ATTR_REPL_INFO} -v "$host_name"
> +# Startup ovn-northd service
> +${OVN_CTL} start_northd
>
>  else
> +# Stop ovn-northd service
> +${OVN_CTL} stop_northd
>  # Synchronize with the new master
>  ocf_log debug "ovndb_server: Connecting to the new master
> ${OCF_RESKEY_CRM_meta_notify_promote_uname}"
>  ${OVN_CTL} demote_ovnnb --db-nb-sync-from-addr=${MASTER_IP} \
>

I tried this patch and it works.
In the case of OpenStack and Tripleo, puppet is used to create and manage
the pacemaker resources for OVN [1] and it also starts ovn-northd as a
pacemaker service with colocation constraint set to the virtual ip created
for the OVN DB servers.

I think it makes more sense to start ovn-northd based on a flag (like
START_NORTHD) so that the user or the configuration systems can chose.

Thanks
Numan



[1] -
https://review.openstack.org/#/c/372274/10/manifests/profile/pacemaker/ovn_northd.pp


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

Re: [ovs-dev] [PATCH 3/3] netdev-dpdk: Use uint8_t for port_id.

[Ilya Maximets]

On 17.05.2017 18:32, Darrell Ball wrote:
> 
> 
> On 5/17/17, 7:59 AM, "Ilya Maximets"  wrote:
> 
> I guess, we need some more opinions about this.
> 
> My comments inline.
> 
> Best regards, Ilya Maximets.
> 
> On 13.05.2017 07:00, Darrell Ball wrote:
> > 
> > 
> > On 5/12/17, 8:04 AM, "Ilya Maximets"  wrote:
> > 
> > On 05.04.2017 22:34, Darrell Ball wrote:
> > > 
> > > 
> > > On 4/3/17, 8:04 AM, "ovs-dev-boun...@openvswitch.org on behalf of 
> Ilya Maximets"  i.maxim...@samsung.com> wrote:
> > > 
> > > Currently, signed integer is used for 'port_id' variable and
> > > '-1' as identifier of bad or uninitialized 'port_id'.
> > > 
> > > This inconsistent with dpdk library and, also, in few cases,
> > > leads to passing '-1' to dpdk functions where uint8_t 
> expected.
> > > 
> > > Such behaviour doesn't produce any issues, but it's better to
> > > use same type as in dpdk library for consistency.
> > > 
> > > Also, magic number '-1' replaced with DPDK_ETH_PORT_ID_INVALID
> > > macro.
> > > 
> > > Signed-off-by: Ilya Maximets 
> > > ---
> > >  lib/netdev-dpdk.c | 61 
> +++
> > >  1 file changed, 35 insertions(+), 26 deletions(-)
> > > 
> > > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> > > index 658a454..216ced8 100644
> > > --- a/lib/netdev-dpdk.c
> > > +++ b/lib/netdev-dpdk.c
> > > @@ -140,6 +140,8 @@ BUILD_ASSERT_DECL((MAX_NB_MBUF / 
> ROUND_DOWN_POW2(MAX_NB_MBUF/MIN_NB_MBUF))
> > >  #define OVS_VHOST_QUEUE_DISABLED(-2) /* Queue was 
> disabled by guest and not
> > >* yet mapped to 
> another queue. */
> > >  
> > > +#define DPDK_ETH_PORT_ID_INVALIDRTE_MAX_ETHPORTS
> > > +
> > >  #define VHOST_ENQ_RETRY_NUM 8
> > >  #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : 
> IFNAMSIZ)
> > >  
> > > @@ -309,7 +311,7 @@ struct dpdk_ring {
> > >  struct rte_ring *cring_tx;
> > >  struct rte_ring *cring_rx;
> > >  unsigned int user_port_id; /* User given port no, parsed 
> from port name */
> > > -int eth_port_id; /* ethernet device port id */
> > > +uint8_t eth_port_id; /* ethernet device port id */
> > > 
> > > The rte does not have a typedef for port_id.
> > > One optional change is for OVS to have a typedef for this 
> external type.
> > > /* The dpdk rte uses uint8_t for port_id. */
> > > typedef uint8_t rte_port_id;
> > 
> > I don't think that it is a good change to do because we will have to
> > create additional typedef at least for PRIu8. This will look ugly.
> > 
> > No, see my following diff
> > 
> > Also, if DPDK someday will create typedef with different name
> > we will have typedef of the typedef?
> > 
> > I don’t follow this comment; see the diff below.
> > 
> > The reasons for the typedef here are:
> > 1) Easier to maintain if the size of type changes in future
> 
> In case of future type change we will have to change all the "PRIu8"
> format strings to something else. This is the half of all the changes.
> So, maintainability is in question.
> 
> The alternative is to change both PRIu8 and the other code as well…
> This reasoning would imply that your proposed change is more maintainable
> because all code using the datatype would need to be re-written ?

Maybe you're right, but both approaches are more or less poorly maintainable.
 
> The main purpose here is to differentiate b/w ovs and external port_id
> namespaces. 
> The reason why this patch exists is due to confusion in this regard –
> using the wrong datatype of int for port_ids derived from the RTE library.
> 
> Your patch is trying again to manually replicate the RTE port_id datatype in 
> OVS code and
> doing this without documenting that the port_id namespace is RTE and not one 
> of 
> OVS native port ids.
> This is confusing to me and not maintainable.
> 
> 
> > 2) Serves as documentation that the origin of the type is the rte 
> library and
> > and originates externally to ovs
> 
> IMHO, using 'rte_' prefix for something defined not inside DPDK is a
> bad style and may be misleading. We should remember that this type
> defined locally in OVS.
> 
> This patch is trying to replicate the datatype coming from the RTE library 
> inside
> OVS code.
> As mentioned earlier, I would prefer the port_id being defined in RTE code 
> and then used in OVS

Re: [ovs-dev] [PATCH 3/3] netdev-dpdk: Use uint8_t for port_id.

[Aaron Conole]

Hi Ilya,

Ilya Maximets  writes:

> On 17.05.2017 18:32, Darrell Ball wrote:
>> 
>> 
>> On 5/17/17, 7:59 AM, "Ilya Maximets"  wrote:
>> 
>> I guess, we need some more opinions about this.
>> 
>> My comments inline.
>> 
>> Best regards, Ilya Maximets.
>> 
>> On 13.05.2017 07:00, Darrell Ball wrote:
>> > 
>> > 
>> > On 5/12/17, 8:04 AM, "Ilya Maximets"  wrote:
>> > 
>> > On 05.04.2017 22:34, Darrell Ball wrote:
>> > > 
>> > > 
>> > > On 4/3/17, 8:04 AM, "ovs-dev-boun...@openvswitch.org on behalf
> of Ilya Maximets"  i.maxim...@samsung.com> wrote:
>> > > 
>> > > Currently, signed integer is used for 'port_id' variable and
>> > > '-1' as identifier of bad or uninitialized 'port_id'.
>> > > 
>> > > This inconsistent with dpdk library and, also, in few cases,
>> > > leads to passing '-1' to dpdk functions where uint8_t expected.
>> > > 
>> > > Such behaviour doesn't produce any issues, but it's better to
>> > > use same type as in dpdk library for consistency.
>> > > 
>> > > Also, magic number '-1' replaced with 
>> DPDK_ETH_PORT_ID_INVALID
>> > > macro.
>> > > 
>> > > Signed-off-by: Ilya Maximets 
>> > > ---
>> > > lib/netdev-dpdk.c | 61
> +++
>> > >  1 file changed, 35 insertions(+), 26 deletions(-)
>> > > 
>> > > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
>> > > index 658a454..216ced8 100644
>> > > --- a/lib/netdev-dpdk.c
>> > > +++ b/lib/netdev-dpdk.c
>> > > @@ -140,6 +140,8 @@ BUILD_ASSERT_DECL((MAX_NB_MBUF /
> ROUND_DOWN_POW2(MAX_NB_MBUF/MIN_NB_MBUF))
>> > > #define OVS_VHOST_QUEUE_DISABLED (-2) /* Queue was disabled by
> guest and not
>> > > * yet mapped to another queue. */
>> > >  
>> > > +#define DPDK_ETH_PORT_ID_INVALIDRTE_MAX_ETHPORTS
>> > > +
>> > >  #define VHOST_ENQ_RETRY_NUM 8
>> > > #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
>> > >  
>> > > @@ -309,7 +311,7 @@ struct dpdk_ring {
>> > >  struct rte_ring *cring_tx;
>> > >  struct rte_ring *cring_rx;
>> > > unsigned int user_port_id; /* User given port no, parsed from
> port name */
>> > > -int eth_port_id; /* ethernet device port id */
>> > > +uint8_t eth_port_id; /* ethernet device port id */
>> > > 
>> > > The rte does not have a typedef for port_id.
>> > > One optional change is for OVS to have a typedef for this
> external type.
>> > > /* The dpdk rte uses uint8_t for port_id. */
>> > > typedef uint8_t rte_port_id;
>> > 
>> > I don't think that it is a good change to do because we will have 
>> to
>> > create additional typedef at least for PRIu8. This will look ugly.
>> > 
>> > No, see my following diff
>> > 
>> > Also, if DPDK someday will create typedef with different name
>> > we will have typedef of the typedef?
>> > 
>> > I don’t follow this comment; see the diff below.
>> > 
>> > The reasons for the typedef here are:
>> > 1) Easier to maintain if the size of type changes in future
>> 
>> In case of future type change we will have to change all the "PRIu8"
>> format strings to something else. This is the half of all the changes.
>> So, maintainability is in question.
>> 
>> The alternative is to change both PRIu8 and the other code as well…
>> This reasoning would imply that your proposed change is more maintainable
>> because all code using the datatype would need to be re-written ?
>
> Maybe you're right, but both approaches are more or less poorly maintainable.
>  
>> The main purpose here is to differentiate b/w ovs and external port_id
>> namespaces. 
>> The reason why this patch exists is due to confusion in this regard –
>> using the wrong datatype of int for port_ids derived from the RTE library.
>> 
>> Your patch is trying again to manually replicate the RTE port_id
> datatype in OVS code and
>> doing this without documenting that the port_id namespace is RTE and
> not one of
>> OVS native port ids.
>> This is confusing to me and not maintainable.
>> 
>> 
>> > 2) Serves as documentation that the origin of the type is the rte
> library and
>> > and originates externally to ovs
>> 
>> IMHO, using 'rte_' prefix for something defined not inside DPDK is a
>> bad style and may be misleading. We should remember that this type
>> defined locally in OVS.
>> 
>> This patch is trying to replicate the datatype coming from the RTE
> library inside
>> OVS code.
>> As mentioned earlier, I would prefer the port_id being defined in
> RTE code and then used in OVS
>> but I don’t see that dat

[ovs-dev] Fwd: [PATCH] bfd: Fix signs in ovs-appctl bfd/show Detect Time, Next Tx Time, Last TX Time

[Gabor Szucs]

Hi,
This is a fix for ovs-appctl bfd/show printout that looks partly incorrect.

ovs-appctl bfd/show command printout
shows negative time lag from now for upcoming events:
Detect Time: now -2632ms
Next TX Time: now -800ms
and positive time lag from now for past event:
Last TX Time: now +150ms

The fix negates the signs.

Signed-off-by: Gábor Szűcs 
Co-authored-by: Csaba Ihllye 
Signed-off-by: Csaba Ihllye 
---
diff --git a/lib/bfd.c b/lib/bfd.c
index 1fb1cfb..9e79f12 100644
--- a/lib/bfd.c
+++ b/lib/bfd.c
@@ -1239,11 +1239,11 @@ bfd_put_details(struct ds *ds, const struct bfd *bfd) 
OVS_REQUIRES(mutex)
 ds_put_format(ds, "\tTX Interval: Approx %lldms\n", bfd_tx_interval(bfd));
 ds_put_format(ds, "\tRX Interval: Approx %lldms\n", bfd_rx_interval(bfd));
 ds_put_format(ds, "\tDetect Time: now %+lldms\n",
-  time_msec() - bfd->detect_time);
+  bfd->detect_time - time_msec());
 ds_put_format(ds, "\tNext TX Time: now %+lldms\n",
-  time_msec() - bfd->next_tx);
+  bfd->next_tx - time_msec());
 ds_put_format(ds, "\tLast TX Time: now %+lldms\n",
-  time_msec() - bfd->last_tx);
+  bfd->last_tx - time_msec());

 ds_put_cstr(ds, "\n");



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

Re: [ovs-dev] [PATCH branch-2.7 1/2] libopenvswitch: Rename to libfoo-X.Y.

[Aaron Conole]

Hi Joe,

Joe Stringer  writes:

> The current intent for Open vSwitch is to maintain libopenvswitch ABI
> stability for minor versions, for example each release within the 2.7.z
> series. According to the following documentation, no changes to exported
> headers should be made.
>
> http://docs.openvswitch.org/en/latest/internals/contributing/libopenvswitch-abi/
>
> However, it is occasionally necessary to make changes to
> {include/openvswitch,lib}/*.h headers to fix issues within a given
> release series. The current libtool tagging mechanism in the build
> system does not allow for this without creating a conflict between the
> libtool 'current' version and the next minor release of OVS.
>
> This patch modifies libopenvswitch build to include the MAJOR.MINOR
> release version in the libX name, and include the libtool CURRENT and
> OVS MICRO release in the libtool versioning tags to indicate library
> stability. The resulting format is "libfoo-X.Y.so.CURRENT.0.Z" for OVS
> release "X.Y.Z".
>
> Developers should still attempt to avoid introducing ABI-breaking changes
> within a particular OVS-X.Y release series, but if this is not possible
> this patch introduced a mechanism to allow an ABI-breaking fix to be
> introduced. In such a case, developers may update the libtool CURRENT
> version to indicate this breakage to library users.
>
> Signed-off-by: Joe Stringer 
> Acked-by: Ben Pfaff 
> ---

Acked-by: Aaron Conole 

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

Re: [ovs-dev] [PATCH branch-2.7 2/2] NEWS: Describe libopenvswitch-X.Y change.

[Aaron Conole]

Joe Stringer  writes:

> The previous commit renamed libopenvswitch-X to libopenvswitch-X.Y to
> allow ABI breakage to be expressed through libtool numbering. Document
> this change.
>
> Signed-off-by: Joe Stringer 
> ---

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

Re: [ovs-dev] [PATCH] ovn-ctl: Fix help message for option ovn-controller-priority

[Aaron Conole]

Han Zhou  writes:

> Signed-off-by: Han Zhou 
> ---

LGTM.

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

[ovs-dev] Makayabu (Colin) Populaire

[Bonesca Import en Export BV]

    [ View in browser ]( http://r.bonesca.eu/nru6rdjyoatrf.html )   
 
[  ]( http://r.bonesca.eu/click/2n3cr1i7haoatrd.html ) 


 
Makayabu (Colin) populaire
packed in 3,5 kilo boxes
 
 
This fish is graded out from our normal (recent) production, while not splitted 
well or back is open. Further quality of the fish is same.
 
 
Sales only per full palets (221 boxes)
+/- 20 tons available

Prices :
1 palet € 2,80 per kilo = € 9,80 per box
3 palets € 2,60 per kilo = € 9,10 per box
5 palets € 2,50 per kilo = € 8,75 per box    


   [ More offers? Click here ]( 
http://r.bonesca.eu/click/2n3cr1i89qoatrd.html )     
This email was sent to d...@openvswitch.org
You received this email because you are registered with Bonesca Import en 
Export BV
 
[ Unsubscribe here ]( http://r.bonesca.eu/nru6rdjyoatrg.html )  

Sent by
[  ]( http://r.bonesca.eu/click/2n3cr1i926oatrd.html )     
© 2017 Bonesca Import en Export BV  

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

[ovs-dev] Fwd:New Order

[Stephen]

FYI
 Thanks,
 Stephen Elleng
 Smartech Havec (Hong Kong) Limited
  
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Darrell Ball]

On 4/4/17, 5:47 PM, "Darrell Ball"  wrote:



On 4/4/17, 3:09 AM, "Lal, PrzemyslawX"  wrote:

On 04/04/2017 06:14, Darrell Ball wrote:

>
> On 4/3/17, 5:27 AM, "ovs-dev-boun...@openvswitch.org on behalf of 
Przemyslaw Lal"  wrote:
>
>  In current implementation port_id is used as an ifindex for all 
netdev-dpdk
>  interfaces.
>  
>  For physical DPDK interfaces using port_id as ifindex causes 
that '0' is set as
>  ifindex for 'dpdk0' interface, '1' for 'dpdk1' and so on. For 
the DPDK vHost
>  interfaces ifindexes are not even assigned (0 is used by 
default) due to the
>  fact that vHost ports don't use port_id field from the DPDK 
library.
>  
>  This causes multiple negative side-effects. First of all 0 is an 
invalid
>  ifindex value. The other issue is possible overlapping of 
'dpdkX' interfaces
>  ifindex values with the ifindexes of kernel space interfaces 
which may cause
>  problems in any external tools that use those values. Neither 
'dpdk0', nor any
>  DPDK vHost interfaces are visible in sFlow collector tools, as 
all interfaces
>  with ifindexes smaller than 1 are ignored.
>  
>  Proposed solution to these issues is to calculate a hash of 
interface's name
>  and use calculated value as an ifindex. This way interfaces keep 
their
>  ifindexes during OVS-DPDK restarts, ports re-initialization 
events, etc., show
>  up in sFlow collectors and meet RFC 2863 specification regarding 
re-using
>  ifindex values by the same virtual interfaces and maximum 
ifindex value.
>  
>  Signed-off-by: Przemyslaw Lal 
>  ---
>   lib/netdev-dpdk.c | 6 +-
>   1 file changed, 5 insertions(+), 1 deletion(-)
>  
>  diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
>  index ddc651b..687b0a5 100644
>  --- a/lib/netdev-dpdk.c
>  +++ b/lib/netdev-dpdk.c
>  @@ -2215,7 +2215,11 @@ netdev_dpdk_get_ifindex(const struct 
netdev *netdev)
>   int ifindex;
>   
>   ovs_mutex_lock(&dev->mutex);
>  -ifindex = dev->port_id;
>  +/* Calculate hash from the netdev name. Ensure that ifindex 
is a 24-bit
>  + * postive integer to meet RFC 2863 recommendations.
>  + */
>  +uint32_t h = hash_string(netdev->name, 0);
>  +ifindex = (int)(h % 0xfe + 1);
>
>
> If user configuration was supported, enforcing uniqueness would be the
> responsibility of the user.

This was already discussed on this mailing list and outcome was that 
while hash is not perfect, it is the best solution for now.
Also, please keep in mind that names of the physical DPDK devices and 
dpdkvhostuser interfaces are configurable, so user can still enforce
uniqueness.

I know uniqueness could be enforced by trial and error of name selection.
I saw the comment
 “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.”

If others are fine, then so am I.

The uniqueness issue is understood and there is a workaround capability to
address it.

Let us just fold the patch in, since the patch has been out for long enough to
receive feedback.

Acked by: Darrell Ball 




>
> One minor question:
> I know other ifindex implementations do not limit to 24 bits, so I 
checked RFC 2863.
> What section is the 24 bit limit recommendation mentioned in RFC 
2863; I missed it.

Recommendation of RFC 2863 is to use "small integers". Main purpose of 
this patch is to enable dpdkvhostuser interfaces in sFlow metrics collecting 
tools.
After posting previous version I've received feedback from the 
community that not all interfaces are visible in sFlow collectors and maximum 
supported ifindex is 2^24.
Here's the sFlow v5 specification: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__sflow.org_sflow-5Fversion-5F5.txt&d=DwICaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=BU2KdxyVIZVbS8qF48IH8n4FNs8DBkSQf7Bp0zdQvXE&s=ZgBDm95VkGw_R6_ULUFT5mh0OtbGPzcnjpWXze9DIGw&e=
 

2^24 is an sflow recommendation (rather than Interfaces MIB recommendation)
 – that’s fine; I was just curious where it came from.


>
>
>
>   ovs_mutex_unlock(&dev->mutex);
>   
>   return ifindex;
>  --
>  1.9.1
>  
>  ___

Re: [ovs-dev] [PATCH branch-2.7 1/2] libopenvswitch: Rename to libfoo-X.Y.

[Joe Stringer]

On 18 May 2017 at 09:11, Aaron Conole  wrote:
> Hi Joe,
>
> Joe Stringer  writes:
>
>> The current intent for Open vSwitch is to maintain libopenvswitch ABI
>> stability for minor versions, for example each release within the 2.7.z
>> series. According to the following documentation, no changes to exported
>> headers should be made.
>>
>> http://docs.openvswitch.org/en/latest/internals/contributing/libopenvswitch-abi/
>>
>> However, it is occasionally necessary to make changes to
>> {include/openvswitch,lib}/*.h headers to fix issues within a given
>> release series. The current libtool tagging mechanism in the build
>> system does not allow for this without creating a conflict between the
>> libtool 'current' version and the next minor release of OVS.
>>
>> This patch modifies libopenvswitch build to include the MAJOR.MINOR
>> release version in the libX name, and include the libtool CURRENT and
>> OVS MICRO release in the libtool versioning tags to indicate library
>> stability. The resulting format is "libfoo-X.Y.so.CURRENT.0.Z" for OVS
>> release "X.Y.Z".
>>
>> Developers should still attempt to avoid introducing ABI-breaking changes
>> within a particular OVS-X.Y release series, but if this is not possible
>> this patch introduced a mechanism to allow an ABI-breaking fix to be
>> introduced. In such a case, developers may update the libtool CURRENT
>> version to indicate this breakage to library users.
>>
>> Signed-off-by: Joe Stringer 
>> Acked-by: Ben Pfaff 
>> ---
>
> Acked-by: Aaron Conole 

I appreciate the review on this work Aaron, thanks! Applied to branch-2.7.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.7 2/2] NEWS: Describe libopenvswitch-X.Y change.

[Joe Stringer]

On 18 May 2017 at 09:12, Aaron Conole  wrote:
> Joe Stringer  writes:
>
>> The previous commit renamed libopenvswitch-X to libopenvswitch-X.Y to
>> allow ABI breakage to be expressed through libtool numbering. Document
>> this change.
>>
>> Signed-off-by: Joe Stringer 
>> ---
>
> Acked-by: Aaron Conole 

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

[ovs-dev] New Arrivals

[Bonesca - Jona]

    [ View in browser ]( http://r.newsletter.bonescamail.nl/nru6receoatrf.html 
)   
 
 
 
NEW ARRIVAL NATURAL AND SMOKED GOAT MEAT
 
12 X 1 KILO DUTCH PRODUCTION
 
1 BOX € 4,50 PER KILO
10 BOX € 4,25 PER KILO
PALET (98 BOX) € 3,95 PER KILO!!
 
SMOKED AND NATURAL BOTH SAME PRICE    

 
This email was sent to d...@openvswitch.org
You received this email because you are registered with Bonesca Import en 
Export BV
 
[ Unsubscribe here ]( http://r.newsletter.bonescamail.nl/nru6receoatrg.html )  

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

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

[ovs-dev] [PATCH v5 1/7] netdev: get device type from vport prefix if it uses one

[Eric Garver]

From: Thadeu Lima de Souza Cascardo 

If the device name uses a vport prefix, then use that vport type.

Since these names are reserved, we can assume this is the right type.

This is important when we are querying the datapath right after vswitch has
started and using the right type will be even more important when we add support
to creating tunnel ports with rtnetlink.

Signed-off-by: Thadeu Lima de Souza Cascardo 
Acked-by: Joe Stringer 
---
 lib/netdev.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/lib/netdev.c b/lib/netdev.c
index a8d8edad7243..26c413601550 100644
--- a/lib/netdev.c
+++ b/lib/netdev.c
@@ -288,6 +288,21 @@ netdev_enumerate_types(struct sset *types)
 }
 }
 
+static const char *
+netdev_vport_type_from_name(const char *name)
+{
+struct netdev_registered_class *rc;
+const char *type;
+CMAP_FOR_EACH (rc, cmap_node, &netdev_classes) {
+const char *dpif_port = netdev_vport_class_get_dpif_port(rc->class);
+if (dpif_port && !strncmp(name, dpif_port, strlen(dpif_port))) {
+type = rc->class->type;
+return type;
+}
+}
+return NULL;
+}
+
 /* Check that the network device name is not the same as any of the registered
  * vport providers' dpif_port name (dpif_port is NULL if the vport provider
  * does not define it) or the datapath internal port name (e.g. ovs-system).
@@ -1811,9 +1826,14 @@ netdev_get_vports(size_t *size)
 const char *
 netdev_get_type_from_name(const char *name)
 {
-struct netdev *dev = netdev_from_name(name);
-const char *type = dev ? netdev_get_type(dev) : NULL;
-netdev_close(dev);
+struct netdev *dev;
+const char *type;
+type = netdev_vport_type_from_name(name);
+if (type == NULL) {
+dev = netdev_from_name(name);
+type = dev ? netdev_get_type(dev) : NULL;
+netdev_close(dev);
+}
 return type;
 }
 
-- 
2.12.0

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

[ovs-dev] [PATCH v5 2/7] dpif-netlink: Refactor code to create compat ports

[Eric Garver]

This breaks up creating compat ports so we can reuse some of the code to
create ports with rtnetlink.

Co-authored-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Eric Garver 
Acked-by: Joe Stringer 
---
 lib/dpif-netlink.c | 138 ++---
 1 file changed, 79 insertions(+), 59 deletions(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 319808f909f9..4c4106c9b33f 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -785,10 +785,8 @@ get_vport_type(const struct dpif_netlink_vport *vport)
 }
 
 static enum ovs_vport_type
-netdev_to_ovs_vport_type(const struct netdev *netdev)
+netdev_to_ovs_vport_type(const char *type)
 {
-const char *type = netdev_get_type(netdev);
-
 if (!strcmp(type, "tap") || !strcmp(type, "system")) {
 return OVS_VPORT_TYPE_NETDEV;
 } else if (!strcmp(type, "internal")) {
@@ -809,19 +807,14 @@ netdev_to_ovs_vport_type(const struct netdev *netdev)
 }
 
 static int
-dpif_netlink_port_add__(struct dpif_netlink *dpif, struct netdev *netdev,
+dpif_netlink_port_add__(struct dpif_netlink *dpif, const char *name,
+enum ovs_vport_type type,
+struct ofpbuf *options,
 odp_port_t *port_nop)
 OVS_REQ_WRLOCK(dpif->upcall_lock)
 {
-const struct netdev_tunnel_config *tnl_cfg;
-char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
-const char *name = netdev_vport_get_dpif_port(netdev,
-  namebuf, sizeof namebuf);
-const char *type = netdev_get_type(netdev);
 struct dpif_netlink_vport request, reply;
 struct ofpbuf *buf;
-uint64_t options_stub[64 / 8];
-struct ofpbuf options;
 struct nl_sock **socksp = NULL;
 uint32_t *upcall_pids;
 int error = 0;
@@ -836,17 +829,81 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, struct 
netdev *netdev,
 dpif_netlink_vport_init(&request);
 request.cmd = OVS_VPORT_CMD_NEW;
 request.dp_ifindex = dpif->dp_ifindex;
-request.type = netdev_to_ovs_vport_type(netdev);
-if (request.type == OVS_VPORT_TYPE_UNSPEC) {
+request.type = type;
+request.name = name;
+
+request.port_no = *port_nop;
+upcall_pids = vport_socksp_to_pids(socksp, dpif->n_handlers);
+request.n_upcall_pids = socksp ? dpif->n_handlers : 1;
+request.upcall_pids = upcall_pids;
+
+if (options) {
+request.options = options->data;
+request.options_len = options->size;
+}
+
+error = dpif_netlink_vport_transact(&request, &reply, &buf);
+if (!error) {
+*port_nop = reply.port_no;
+} else {
+if (error == EBUSY && *port_nop != ODPP_NONE) {
+VLOG_INFO("%s: requested port %"PRIu32" is in use",
+  dpif_name(&dpif->dpif), *port_nop);
+}
+
+vport_del_socksp(dpif, socksp);
+goto exit;
+}
+
+if (socksp) {
+error = vport_add_channels(dpif, *port_nop, socksp);
+if (error) {
+VLOG_INFO("%s: could not add channel for port %s",
+  dpif_name(&dpif->dpif), name);
+
+/* Delete the port. */
+dpif_netlink_vport_init(&request);
+request.cmd = OVS_VPORT_CMD_DEL;
+request.dp_ifindex = dpif->dp_ifindex;
+request.port_no = *port_nop;
+dpif_netlink_vport_transact(&request, NULL, NULL);
+vport_del_socksp(dpif, socksp);
+goto exit;
+}
+}
+free(socksp);
+
+exit:
+ofpbuf_delete(buf);
+free(upcall_pids);
+
+return error;
+}
+
+static int
+dpif_netlink_port_add_compat(struct dpif_netlink *dpif, struct netdev *netdev,
+ odp_port_t *port_nop)
+OVS_REQ_WRLOCK(dpif->upcall_lock)
+{
+const struct netdev_tunnel_config *tnl_cfg;
+char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
+const char *type = netdev_get_type(netdev);
+uint64_t options_stub[64 / 8];
+enum ovs_vport_type ovs_type;
+struct ofpbuf options;
+const char *name;
+
+name = netdev_vport_get_dpif_port(netdev, namebuf, sizeof namebuf);
+
+ovs_type = netdev_to_ovs_vport_type(netdev_get_type(netdev));
+if (ovs_type == OVS_VPORT_TYPE_UNSPEC) {
 VLOG_WARN_RL(&error_rl, "%s: cannot create port `%s' because it has "
  "unsupported type `%s'",
  dpif_name(&dpif->dpif), name, type);
-vport_del_socksp(dpif, socksp);
 return EINVAL;
 }
-request.name = name;
 
-if (request.type == OVS_VPORT_TYPE_NETDEV) {
+if (ovs_type == OVS_VPORT_TYPE_NETDEV) {
 #ifdef _WIN32
 /* XXX : Map appropiate Windows handle */
 #else
@@ -855,10 +912,9 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, struct 
netdev *netdev,
 }
 
 #ifdef _WIN32
-if (request.type == OVS_VPORT_TYPE_INTERNAL) {
+if (ovs_type == OVS_VPORT_TYPE_INTERNAL) {
 if (!create_wmi_

[ovs-dev] [PATCH v5 3/7] dpif-netlink: Support rtnetlink port creation.

[Eric Garver]

In order to be able to add those tunnels, we need to add code to create
the tunnels and add them as NETDEV vports. And when there is no support
to create them, we need to fallback to compatibility code and add them
as tunnel vports.

When removing those tunnels, we need to remove the interfaces as well,
and detecting the right type might be important, at least to distinguish
the tunnel vports that we should remove and the interfaces that we
shouldn't.

Co-authored-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Eric Garver 
---
 lib/automake.mk |   3 +
 lib/dpif-netlink-rtnl.c | 273 
 lib/dpif-netlink-rtnl.h |  47 +
 lib/dpif-netlink.c  |  29 -
 lib/dpif-netlink.h  |   2 +
 5 files changed, 353 insertions(+), 1 deletion(-)
 create mode 100644 lib/dpif-netlink-rtnl.c
 create mode 100644 lib/dpif-netlink-rtnl.h

diff --git a/lib/automake.mk b/lib/automake.mk
index faace7993e79..f5baba27179f 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -352,6 +352,8 @@ if LINUX
 lib_libopenvswitch_la_SOURCES += \
lib/dpif-netlink.c \
lib/dpif-netlink.h \
+   lib/dpif-netlink-rtnl.c \
+   lib/dpif-netlink-rtnl.h \
lib/if-notifier.c \
lib/if-notifier.h \
lib/netdev-linux.c \
@@ -382,6 +384,7 @@ if WIN32
 lib_libopenvswitch_la_SOURCES += \
lib/dpif-netlink.c \
lib/dpif-netlink.h \
+   lib/dpif-netlink-rtnl.h \
lib/netdev-windows.c \
lib/netlink-conntrack.c \
lib/netlink-conntrack.h \
diff --git a/lib/dpif-netlink-rtnl.c b/lib/dpif-netlink-rtnl.c
new file mode 100644
index ..7dfc945e7444
--- /dev/null
+++ b/lib/dpif-netlink-rtnl.c
@@ -0,0 +1,273 @@
+/*
+ * Copyright (c) 2017 Red Hat, 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.
+ */
+
+#include 
+
+#include "dpif-netlink-rtnl.h"
+
+#include 
+#include 
+#include 
+
+#include "dpif-netlink.h"
+#include "netdev-vport.h"
+#include "netlink-socket.h"
+#include "openvswitch/vlog.h"
+
+VLOG_DEFINE_THIS_MODULE(dpif_netlink_rtnl);
+
+static const struct nl_policy rtlink_policy[] = {
+[IFLA_LINKINFO] = { .type = NL_A_NESTED },
+};
+static const struct nl_policy linkinfo_policy[] = {
+[IFLA_INFO_KIND] = { .type = NL_A_STRING },
+[IFLA_INFO_DATA] = { .type = NL_A_NESTED },
+};
+
+static const char *
+vport_type_to_kind(enum ovs_vport_type type)
+{
+switch (type) {
+case OVS_VPORT_TYPE_VXLAN:
+return "vxlan";
+case OVS_VPORT_TYPE_GRE:
+return "gretap";
+case OVS_VPORT_TYPE_GENEVE:
+return "geneve";
+case OVS_VPORT_TYPE_NETDEV:
+case OVS_VPORT_TYPE_INTERNAL:
+case OVS_VPORT_TYPE_LISP:
+case OVS_VPORT_TYPE_STT:
+case OVS_VPORT_TYPE_UNSPEC:
+case __OVS_VPORT_TYPE_MAX:
+default:
+break;
+}
+
+return NULL;
+}
+
+static int
+rtnl_transact(uint32_t type, uint32_t flags, const char *name,
+  struct ofpbuf **reply)
+{
+struct ofpbuf request;
+int err;
+
+ofpbuf_init(&request, 0);
+nl_msg_put_nlmsghdr(&request, 0, type, flags);
+ofpbuf_put_zeros(&request, sizeof(struct ifinfomsg));
+nl_msg_put_string(&request, IFLA_IFNAME, name);
+
+err = nl_transact(NETLINK_ROUTE, &request, reply);
+ofpbuf_uninit(&request);
+
+return err;
+}
+
+static int
+dpif_netlink_rtnl_destroy(const char *name)
+{
+return rtnl_transact(RTM_DELLINK, NLM_F_REQUEST | NLM_F_ACK, name, NULL);
+}
+
+static int OVS_UNUSED
+dpif_netlink_rtnl_getlink(const char *name, struct ofpbuf **reply)
+{
+return rtnl_transact(RTM_GETLINK, NLM_F_REQUEST, name, reply);
+}
+
+static int OVS_UNUSED
+rtnl_policy_parse(const char *kind, struct ofpbuf *reply,
+  const struct nl_policy *policy,
+  struct nlattr *tnl_info[],
+  size_t policy_size)
+{
+struct nlattr *linkinfo[ARRAY_SIZE(linkinfo_policy)];
+struct nlattr *rtlink[ARRAY_SIZE(rtlink_policy)];
+struct ifinfomsg *ifmsg;
+int error = 0;
+
+ifmsg = ofpbuf_at(reply, NLMSG_HDRLEN, sizeof *ifmsg);
+if (!nl_policy_parse(reply, NLMSG_HDRLEN + sizeof *ifmsg,
+ rtlink_policy, rtlink, ARRAY_SIZE(rtlink_policy))
+|| !nl_parse_nested(rtlink[IFLA_LINKINFO], linkinfo_policy,
+linkinfo, ARRAY_SIZE(linkinfo_policy))
+|| strcmp(nl_attr_get_string(linkinfo[IFLA_INFO_KIND]), k

[ovs-dev] [PATCH v5 4/7] dpif-netlink-rtnl: Support VXLAN creation

[Eric Garver]

Creates VXLAN devices using rtnetlink and tunnel metadata.

Co-Authored-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Eric Garver 
---
 lib/dpif-netlink-rtnl.c | 78 -
 lib/dpif-netlink-rtnl.h |  3 +-
 2 files changed, 72 insertions(+), 9 deletions(-)

diff --git a/lib/dpif-netlink-rtnl.c b/lib/dpif-netlink-rtnl.c
index 7dfc945e7444..e0924c968cc0 100644
--- a/lib/dpif-netlink-rtnl.c
+++ b/lib/dpif-netlink-rtnl.c
@@ -29,6 +29,18 @@
 
 VLOG_DEFINE_THIS_MODULE(dpif_netlink_rtnl);
 
+/* On some older systems, these enums are not defined. */
+#ifndef IFLA_VXLAN_MAX
+#define IFLA_VXLAN_MAX 0
+#endif
+#if IFLA_VXLAN_MAX < 25
+#define IFLA_VXLAN_LEARNING 7
+#define IFLA_VXLAN_PORT 15
+#define IFLA_VXLAN_UDP_ZERO_CSUM6_RX 20
+#define IFLA_VXLAN_GBP 23
+#define IFLA_VXLAN_COLLECT_METADATA 25
+#endif
+
 static const struct nl_policy rtlink_policy[] = {
 [IFLA_LINKINFO] = { .type = NL_A_NESTED },
 };
@@ -36,6 +48,12 @@ static const struct nl_policy linkinfo_policy[] = {
 [IFLA_INFO_KIND] = { .type = NL_A_STRING },
 [IFLA_INFO_DATA] = { .type = NL_A_NESTED },
 };
+static const struct nl_policy vxlan_policy[] = {
+[IFLA_VXLAN_COLLECT_METADATA] = { .type = NL_A_U8 },
+[IFLA_VXLAN_LEARNING] = { .type = NL_A_U8 },
+[IFLA_VXLAN_UDP_ZERO_CSUM6_RX] = { .type = NL_A_U8 },
+[IFLA_VXLAN_PORT] = { .type = NL_A_U16 },
+};
 
 static const char *
 vport_type_to_kind(enum ovs_vport_type type)
@@ -84,13 +102,13 @@ dpif_netlink_rtnl_destroy(const char *name)
 return rtnl_transact(RTM_DELLINK, NLM_F_REQUEST | NLM_F_ACK, name, NULL);
 }
 
-static int OVS_UNUSED
+static int
 dpif_netlink_rtnl_getlink(const char *name, struct ofpbuf **reply)
 {
 return rtnl_transact(RTM_GETLINK, NLM_F_REQUEST, name, reply);
 }
 
-static int OVS_UNUSED
+static int
 rtnl_policy_parse(const char *kind, struct ofpbuf *reply,
   const struct nl_policy *policy,
   struct nlattr *tnl_info[],
@@ -116,8 +134,44 @@ rtnl_policy_parse(const char *kind, struct ofpbuf *reply,
 }
 
 static int
-dpif_netlink_rtnl_verify(const struct netdev_tunnel_config OVS_UNUSED *tnl_cfg,
- enum ovs_vport_type type, const char OVS_UNUSED *name)
+dpif_netlink_rtnl_vxlan_verify(const struct netdev_tunnel_config *tnl_cfg,
+   const char *name, const char *kind)
+{
+struct ofpbuf *reply;
+int err;
+
+err = dpif_netlink_rtnl_getlink(name, &reply);
+
+if (!err) {
+struct nlattr *vxlan[ARRAY_SIZE(vxlan_policy)];
+
+err = rtnl_policy_parse(kind, reply, vxlan_policy, vxlan,
+ARRAY_SIZE(vxlan_policy));
+if (!err) {
+if (0 != nl_attr_get_u8(vxlan[IFLA_VXLAN_LEARNING])
+|| 1 != nl_attr_get_u8(vxlan[IFLA_VXLAN_COLLECT_METADATA])
+|| 1 != nl_attr_get_u8(vxlan[IFLA_VXLAN_UDP_ZERO_CSUM6_RX])
+|| (tnl_cfg->dst_port
+!= nl_attr_get_be16(vxlan[IFLA_VXLAN_PORT]))) {
+err = EINVAL;
+}
+}
+if (!err) {
+if (tnl_cfg->exts & (1 << OVS_VXLAN_EXT_GBP)
+&& !nl_attr_get_flag(vxlan[IFLA_VXLAN_GBP])) {
+err = EINVAL;
+}
+}
+ofpbuf_delete(reply);
+}
+
+return err;
+}
+
+
+static int
+dpif_netlink_rtnl_verify(const struct netdev_tunnel_config *tnl_cfg,
+ enum ovs_vport_type type, const char *name)
 {
 const char *kind;
 
@@ -128,6 +182,7 @@ dpif_netlink_rtnl_verify(const struct netdev_tunnel_config 
OVS_UNUSED *tnl_cfg,
 
 switch (type) {
 case OVS_VPORT_TYPE_VXLAN:
+return dpif_netlink_rtnl_vxlan_verify(tnl_cfg, name, kind);
 case OVS_VPORT_TYPE_GRE:
 case OVS_VPORT_TYPE_GENEVE:
 case OVS_VPORT_TYPE_NETDEV:
@@ -143,8 +198,8 @@ dpif_netlink_rtnl_verify(const struct netdev_tunnel_config 
OVS_UNUSED *tnl_cfg,
 return 0;
 }
 
-static int OVS_UNUSED
-dpif_netlink_rtnl_create(const struct netdev_tunnel_config OVS_UNUSED *tnl_cfg,
+static int
+dpif_netlink_rtnl_create(const struct netdev_tunnel_config *tnl_cfg,
  const char *name, enum ovs_vport_type type,
  const char *kind, uint32_t flags)
 {
@@ -166,6 +221,14 @@ dpif_netlink_rtnl_create(const struct netdev_tunnel_config 
OVS_UNUSED *tnl_cfg,
 /* tunnel unique info */
 switch (type) {
 case OVS_VPORT_TYPE_VXLAN:
+nl_msg_put_u8(&request, IFLA_VXLAN_LEARNING, 0);
+nl_msg_put_u8(&request, IFLA_VXLAN_COLLECT_METADATA, 1);
+nl_msg_put_u8(&request, IFLA_VXLAN_UDP_ZERO_CSUM6_RX, 1);
+if (tnl_cfg->exts & (1 << OVS_VXLAN_EXT_GBP)) {
+nl_msg_put_flag(&request, IFLA_VXLAN_GBP);
+}
+nl_msg_put_be16(&request, IFLA_VXLAN_PORT, tnl_cfg->dst_port);
+break;
 case OVS_VPORT_TYPE_GRE:
 case OVS_VPORT_TYPE_GENEVE:
  

[ovs-dev] [PATCH v5 5/7] dpif-netlink-rtnl: Support GRE creation

[Eric Garver]

Creates GRE devices using rtnetlink and tunnel metadata.

Co-Authored-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Eric Garver 
---
 lib/dpif-netlink-rtnl.c | 39 ++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/lib/dpif-netlink-rtnl.c b/lib/dpif-netlink-rtnl.c
index e0924c968cc0..7594e75088d7 100644
--- a/lib/dpif-netlink-rtnl.c
+++ b/lib/dpif-netlink-rtnl.c
@@ -41,6 +41,13 @@ VLOG_DEFINE_THIS_MODULE(dpif_netlink_rtnl);
 #define IFLA_VXLAN_COLLECT_METADATA 25
 #endif
 
+#ifndef IFLA_GRE_MAX
+#define IFLA_GRE_MAX 0
+#endif
+#if IFLA_GRE_MAX < 18
+#define IFLA_GRE_COLLECT_METADATA 18
+#endif
+
 static const struct nl_policy rtlink_policy[] = {
 [IFLA_LINKINFO] = { .type = NL_A_NESTED },
 };
@@ -54,6 +61,9 @@ static const struct nl_policy vxlan_policy[] = {
 [IFLA_VXLAN_UDP_ZERO_CSUM6_RX] = { .type = NL_A_U8 },
 [IFLA_VXLAN_PORT] = { .type = NL_A_U16 },
 };
+static const struct nl_policy gre_policy[] = {
+[IFLA_GRE_COLLECT_METADATA] = { .type = NL_A_FLAG },
+};
 
 static const char *
 vport_type_to_kind(enum ovs_vport_type type)
@@ -168,6 +178,30 @@ dpif_netlink_rtnl_vxlan_verify(const struct 
netdev_tunnel_config *tnl_cfg,
 return err;
 }
 
+static int
+dpif_netlink_rtnl_gre_verify(const struct netdev_tunnel_config OVS_UNUSED *tnl,
+ const char *name, const char *kind)
+{
+struct ofpbuf *reply;
+int err;
+
+err = dpif_netlink_rtnl_getlink(name, &reply);
+
+if (!err) {
+struct nlattr *gre[ARRAY_SIZE(gre_policy)];
+
+err = rtnl_policy_parse(kind, reply, gre_policy, gre,
+ARRAY_SIZE(gre_policy));
+if (!err) {
+if (!nl_attr_get_flag(gre[IFLA_GRE_COLLECT_METADATA])) {
+err = EINVAL;
+}
+}
+ofpbuf_delete(reply);
+}
+
+return err;
+}
 
 static int
 dpif_netlink_rtnl_verify(const struct netdev_tunnel_config *tnl_cfg,
@@ -184,6 +218,7 @@ dpif_netlink_rtnl_verify(const struct netdev_tunnel_config 
*tnl_cfg,
 case OVS_VPORT_TYPE_VXLAN:
 return dpif_netlink_rtnl_vxlan_verify(tnl_cfg, name, kind);
 case OVS_VPORT_TYPE_GRE:
+return dpif_netlink_rtnl_gre_verify(tnl_cfg, name, kind);
 case OVS_VPORT_TYPE_GENEVE:
 case OVS_VPORT_TYPE_NETDEV:
 case OVS_VPORT_TYPE_INTERNAL:
@@ -230,6 +265,8 @@ dpif_netlink_rtnl_create(const struct netdev_tunnel_config 
*tnl_cfg,
 nl_msg_put_be16(&request, IFLA_VXLAN_PORT, tnl_cfg->dst_port);
 break;
 case OVS_VPORT_TYPE_GRE:
+nl_msg_put_flag(&request, IFLA_GRE_COLLECT_METADATA);
+break;
 case OVS_VPORT_TYPE_GENEVE:
 case OVS_VPORT_TYPE_NETDEV:
 case OVS_VPORT_TYPE_INTERNAL:
@@ -321,8 +358,8 @@ dpif_netlink_rtnl_port_destroy(const char *name, const char 
*type)
 {
 switch (netdev_to_ovs_vport_type(type)) {
 case OVS_VPORT_TYPE_VXLAN:
-return dpif_netlink_rtnl_destroy(name);
 case OVS_VPORT_TYPE_GRE:
+return dpif_netlink_rtnl_destroy(name);
 case OVS_VPORT_TYPE_GENEVE:
 case OVS_VPORT_TYPE_NETDEV:
 case OVS_VPORT_TYPE_INTERNAL:
-- 
2.12.0

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

[ovs-dev] [PATCH v5 6/7] dpif-netlink-rtnl: Support GENEVE creation

[Eric Garver]

Creates GENEVE devices using rtnetlink and tunnel metadata.

Co-Authored-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Thadeu Lima de Souza Cascardo 
Signed-off-by: Eric Garver 
---
 lib/dpif-netlink-rtnl.c | 49 -
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/lib/dpif-netlink-rtnl.c b/lib/dpif-netlink-rtnl.c
index 7594e75088d7..2061564436df 100644
--- a/lib/dpif-netlink-rtnl.c
+++ b/lib/dpif-netlink-rtnl.c
@@ -48,6 +48,15 @@ VLOG_DEFINE_THIS_MODULE(dpif_netlink_rtnl);
 #define IFLA_GRE_COLLECT_METADATA 18
 #endif
 
+#ifndef IFLA_GENEVE_MAX
+#define IFLA_GENEVE_MAX 0
+#endif
+#if IFLA_GENEVE_MAX < 10
+#define IFLA_GENEVE_PORT 5
+#define IFLA_GENEVE_COLLECT_METADATA 6
+#define IFLA_GENEVE_UDP_ZERO_CSUM6_RX 10
+#endif
+
 static const struct nl_policy rtlink_policy[] = {
 [IFLA_LINKINFO] = { .type = NL_A_NESTED },
 };
@@ -64,6 +73,11 @@ static const struct nl_policy vxlan_policy[] = {
 static const struct nl_policy gre_policy[] = {
 [IFLA_GRE_COLLECT_METADATA] = { .type = NL_A_FLAG },
 };
+static const struct nl_policy geneve_policy[] = {
+[IFLA_GENEVE_COLLECT_METADATA] = { .type = NL_A_FLAG },
+[IFLA_GENEVE_UDP_ZERO_CSUM6_RX] = { .type = NL_A_U8 },
+[IFLA_GENEVE_PORT] = { .type = NL_A_U16 },
+};
 
 static const char *
 vport_type_to_kind(enum ovs_vport_type type)
@@ -204,6 +218,34 @@ dpif_netlink_rtnl_gre_verify(const struct 
netdev_tunnel_config OVS_UNUSED *tnl,
 }
 
 static int
+dpif_netlink_rtnl_geneve_verify(const struct netdev_tunnel_config *tnl_cfg,
+const char *name, const char *kind)
+{
+struct ofpbuf *reply;
+int err;
+
+err = dpif_netlink_rtnl_getlink(name, &reply);
+
+if (!err) {
+struct nlattr *geneve[ARRAY_SIZE(geneve_policy)];
+
+err = rtnl_policy_parse(kind, reply, geneve_policy, geneve,
+ARRAY_SIZE(geneve_policy));
+if (!err) {
+if (!nl_attr_get_flag(geneve[IFLA_GENEVE_COLLECT_METADATA])
+|| 1 != nl_attr_get_u8(geneve[IFLA_GENEVE_UDP_ZERO_CSUM6_RX])
+|| (tnl_cfg->dst_port
+!= nl_attr_get_be16(geneve[IFLA_GENEVE_PORT]))) {
+err = EINVAL;
+}
+}
+ofpbuf_delete(reply);
+}
+
+return err;
+}
+
+static int
 dpif_netlink_rtnl_verify(const struct netdev_tunnel_config *tnl_cfg,
  enum ovs_vport_type type, const char *name)
 {
@@ -220,6 +262,7 @@ dpif_netlink_rtnl_verify(const struct netdev_tunnel_config 
*tnl_cfg,
 case OVS_VPORT_TYPE_GRE:
 return dpif_netlink_rtnl_gre_verify(tnl_cfg, name, kind);
 case OVS_VPORT_TYPE_GENEVE:
+return dpif_netlink_rtnl_geneve_verify(tnl_cfg, name, kind);
 case OVS_VPORT_TYPE_NETDEV:
 case OVS_VPORT_TYPE_INTERNAL:
 case OVS_VPORT_TYPE_LISP:
@@ -268,6 +311,10 @@ dpif_netlink_rtnl_create(const struct netdev_tunnel_config 
*tnl_cfg,
 nl_msg_put_flag(&request, IFLA_GRE_COLLECT_METADATA);
 break;
 case OVS_VPORT_TYPE_GENEVE:
+nl_msg_put_flag(&request, IFLA_GENEVE_COLLECT_METADATA);
+nl_msg_put_u8(&request, IFLA_GENEVE_UDP_ZERO_CSUM6_RX, 1);
+nl_msg_put_be16(&request, IFLA_GENEVE_PORT, tnl_cfg->dst_port);
+break;
 case OVS_VPORT_TYPE_NETDEV:
 case OVS_VPORT_TYPE_INTERNAL:
 case OVS_VPORT_TYPE_LISP:
@@ -359,8 +406,8 @@ dpif_netlink_rtnl_port_destroy(const char *name, const char 
*type)
 switch (netdev_to_ovs_vport_type(type)) {
 case OVS_VPORT_TYPE_VXLAN:
 case OVS_VPORT_TYPE_GRE:
-return dpif_netlink_rtnl_destroy(name);
 case OVS_VPORT_TYPE_GENEVE:
+return dpif_netlink_rtnl_destroy(name);
 case OVS_VPORT_TYPE_NETDEV:
 case OVS_VPORT_TYPE_INTERNAL:
 case OVS_VPORT_TYPE_LISP:
-- 
2.12.0

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

[ovs-dev] [PATCH v5 7/7] dpif-netlink: Probe for out-of-tree tunnels, decides used interface

[Eric Garver]

On dpif init, probe for whether tunnels are created using in-tree
(upstream linux) or out-of-tree (OVS). This is done by probing for the
existence of "ovs_geneve" via rtnetlink. This is used to determine how
to create the tunnel devices.

For out-of-tree tunnels, only try genetlink/compat.
For in-tree kernel tunnels, try rtnetlink then fallback to genetlink.

Signed-off-by: Eric Garver 
---
 NEWS|  3 +++
 lib/dpif-netlink-rtnl.c | 46 ++
 lib/dpif-netlink-rtnl.h |  8 
 lib/dpif-netlink.c  | 53 ++---
 4 files changed, 94 insertions(+), 16 deletions(-)

diff --git a/NEWS b/NEWS
index 7a2b185bbd84..da9863966617 100644
--- a/NEWS
+++ b/NEWS
@@ -3,6 +3,9 @@ Post-v2.7.0
- Tunnels:
  * Added support to set packet mark for tunnel endpoint using
`egress_pkt_mark` OVSDB option.
+ * When using Linux kernel datapath tunnels may be created using rtnetlink.
+   This will allow us to take advantage of new tunnel features without
+   having to make changes to the vport modules.
- EMC insertion probability is reduced to 1% and is configurable via
  the new 'other_config:emc-insert-inv-prob' option.
- DPDK:
diff --git a/lib/dpif-netlink-rtnl.c b/lib/dpif-netlink-rtnl.c
index 2061564436df..7faad5248037 100644
--- a/lib/dpif-netlink-rtnl.c
+++ b/lib/dpif-netlink-rtnl.c
@@ -419,3 +419,49 @@ dpif_netlink_rtnl_port_destroy(const char *name, const 
char *type)
 }
 return 0;
 }
+
+/**
+ * Probe for whether the modules are out-of-tree (openvswitch) or in-tree
+ * (upstream kernel).
+ *
+ * We probe for "ovs_geneve" via rtnetlink. As long as this returns something
+ * other than EOPNOTSUPP we know that the module in use is the out-of-tree one.
+ * This will be used to determine which netlink interface to use when creating
+ * ports; rtnetlink or compat/genetlink.
+ *
+ * See ovs_tunnels_out_of_tree
+ */
+bool
+dpif_netlink_rtnl_probe_oot_tunnels(void)
+{
+char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
+struct netdev *netdev = NULL;
+bool out_of_tree = false;
+const char *name;
+int error;
+
+error = netdev_open("ovs-system-probe", "geneve", &netdev);
+if (!error) {
+const struct netdev_tunnel_config *tnl_cfg;
+
+tnl_cfg = netdev_get_tunnel_config(netdev);
+if (!tnl_cfg) {
+return true;
+}
+
+name = netdev_vport_get_dpif_port(netdev, namebuf, sizeof namebuf);
+error = dpif_netlink_rtnl_create(tnl_cfg, name, OVS_VPORT_TYPE_GENEVE,
+ "ovs_geneve",
+ (NLM_F_REQUEST | NLM_F_ACK
+  | NLM_F_CREATE));
+if (error != EOPNOTSUPP) {
+if (!error) {
+dpif_netlink_rtnl_destroy(name);
+}
+out_of_tree = true;
+}
+netdev_close(netdev);
+}
+
+return out_of_tree;
+}
diff --git a/lib/dpif-netlink-rtnl.h b/lib/dpif-netlink-rtnl.h
index 952c0d4187e5..5c790e0bc06f 100644
--- a/lib/dpif-netlink-rtnl.h
+++ b/lib/dpif-netlink-rtnl.h
@@ -25,6 +25,8 @@
 int dpif_netlink_rtnl_port_create(struct netdev *netdev);
 int dpif_netlink_rtnl_port_destroy(const char *name, const char *type);
 
+bool dpif_netlink_rtnl_probe_oot_tunnels(void);
+
 #ifndef __linux__
 /* Dummy implementations for non Linux builds. */
 
@@ -41,6 +43,12 @@ dpif_netlink_rtnl_port_destroy(const char *name OVS_UNUSED,
 return EOPNOTSUPP;
 }
 
+static inline bool
+dpif_netlink_rtnl_probe_oot_tunnels(void)
+{
+return true;
+}
+
 #endif
 
 #endif /* DPIF_NETLINK_RTNL_H */
diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 52d28fb39e7b..503fe33eb161 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -62,9 +62,6 @@ VLOG_DEFINE_THIS_MODULE(dpif_netlink);
 #ifdef _WIN32
 #include "wmi.h"
 enum { WINDOWS = 1 };
-static int dpif_netlink_port_query__(const struct dpif_netlink *dpif,
- odp_port_t port_no, const char *port_name,
- struct dpif_port *dpif_port);
 #else
 enum { WINDOWS = 0 };
 #endif
@@ -215,6 +212,12 @@ static int ovs_packet_family;
  * Initialized by dpif_netlink_init(). */
 static unsigned int ovs_vport_mcgroup;
 
+/* If true, tunnel devices are created using OVS compat/genetlink.
+ * If false, tunnel devices are created with rtnetlink and using light weight
+ * tunnels. If we fail to create the tunnel the rtnetlink+LWT, then we fallback
+ * to using the compat interface. */
+static bool ovs_tunnels_out_of_tree = true;
+
 static int dpif_netlink_init(void);
 static int open_dpif(const struct dpif_netlink_dp *, struct dpif **);
 static uint32_t dpif_netlink_port_get_pid(const struct dpif *,
@@ -226,6 +229,9 @@ static void dpif_netlink_vport_to_ofpbuf(const struct 
dpif_netlink_vport *,
  struct ofpbuf *);
 static int d

[ovs-dev] [PATCH v5 0/7] create tunnel devices using rtnetlink interface

[Eric Garver]

This series adds support for the creation of tunnels using the rtnetlink
interface. This will open the possibility for new features and flags on those
vports without the need to change vport compatibility code.

Support for STT and LISP have not been added because these are not upstream yet,
so we don't know how the interface will be like upstream. And there are no
features in the current drivers right now we could make use of.

Note: This work originally started by Thadeu Lima de Souza Cascardo.

Note: There is a known failure for GENEVE tunnels using rtnetlink on newer
kernels. This is being addressed with a separate kernel fix. The fallback to
compat will work however.

Testing:
  - kernel 4.9.22, in-tree datapath
- rtnetlink successfully creates devices
  - kernel 4.2.8, in-tree datapath
- rtnetlink is tried, but fails due to no COLLECT_METADATA support
- genetlink successfully creates devices
  - kernel 4.2.8, out-of-tree datapath
- rtnetlink is not tried
- genetlink successfully creates devices
  - Create a native VXLAN interface with incorrect config, run VXLAN
check-kernel test. Old device is replaced by OVS created one.

v5:
  - Make dpif_netlink_rtnl_port_create() easier to follow.
  - Reword some patch descriptions

v4:
  - If device exists, verify and potentially delete/re-add. This handles the
case where OVS may be killed.
  - Further commonize rtnetlink code; create, verify, delete
  - Incorporate Joe's style changes from last review

v3:
  - commonzie code to get port data to verify port
  - eliminate dpif_netlink_rtnl_vxlan_destroy() and alike
  - minor changes for coding style guidelines
  - add ACKs from previous reviews

Eric Garver (6):
  dpif-netlink: Refactor code to create compat ports
  dpif-netlink: Support rtnetlink port creation.
  dpif-netlink-rtnl: Support VXLAN creation
  dpif-netlink-rtnl: Support GRE creation
  dpif-netlink-rtnl: Support GENEVE creation
  dpif-netlink: Probe for out-of-tree tunnels, decides used interface

Thadeu Lima de Souza Cascardo (1):
  netdev: get device type from vport prefix if it uses one

 NEWS|   3 +
 lib/automake.mk |   3 +
 lib/dpif-netlink-rtnl.c | 467 
 lib/dpif-netlink-rtnl.h |  54 ++
 lib/dpif-netlink.c  | 210 ++
 lib/dpif-netlink.h  |   2 +
 lib/netdev.c|  26 ++-
 7 files changed, 691 insertions(+), 74 deletions(-)
 create mode 100644 lib/dpif-netlink-rtnl.c
 create mode 100644 lib/dpif-netlink-rtnl.h

-- 
2.12.0

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

[ovs-dev] [PATCH] travis: Update kernel build targets.

[Joe Stringer]

3.18 and 3.12 have been EOLed, 4.11 is new, and there are some minor
revisions to other kernels. Update the list.

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

diff --git a/.travis.yml b/.travis.yml
index 3a7387373ed7..36cd5cf6a7d9 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -25,17 +25,16 @@ sudo: false
 
 env:
   - OPTS="--disable-ssl"
-  - TESTSUITE=1 KERNEL=3.16.39
+  - TESTSUITE=1 KERNEL=3.16.43
   - TESTSUITE=1 OPTS="--enable-shared"
   - BUILD_ENV="-m32" OPTS="--disable-ssl"
-  - KERNEL=3.16.39 DPDK=1
-  - KERNEL=3.16.39 DPDK=1 OPTS="--enable-shared"
-  - KERNEL=4.10.12
-  - KERNEL=4.9.24
-  - KERNEL=4.4.63
+  - KERNEL=3.16.43 DPDK=1
+  - KERNEL=3.16.43 DPDK=1 OPTS="--enable-shared"
+  - KERNEL=4.11.1
+  - KERNEL=4.10.16
+  - KERNEL=4.9.28
+  - KERNEL=4.4.68
   - KERNEL=4.1.39
-  - KERNEL=3.18.50
-  - KERNEL=3.12.73
   - KERNEL=3.10.105
   - TESTSUITE=1 LIBS=-ljemalloc
 
-- 
2.11.1

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

[ovs-dev] [PATCH] ofproto-dpif-xlate: Fix typos in comment.

[Ben Pfaff]

Signed-off-by: Ben Pfaff 
---
 ofproto/ofproto-dpif-xlate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index b308f21de100..39fed7e0b303 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -4623,7 +4623,7 @@ xlate_output_trunc_action(struct xlate_ctx *ctx,
 if (xport == NULL || xport->odp_port == ODPP_NONE) {
 /* Since truncate happens at its following output action, if
  * the output port is a patch port, the behavior is somehow
- * unpredicable. For simpilicity, disallow this case. */
+ * unpredictable.  For simplicity, disallow this case. */
 ofputil_port_to_string(port, name, sizeof name);
 xlate_report_error(ctx, "output_trunc does not support "
"patch port %s", name);
-- 
2.10.2

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

[ovs-dev] [PATCH 1/2] ofproto-dpif-xlate: Fix typos in comment.

[Ben Pfaff]

Signed-off-by: Ben Pfaff 
---
 ofproto/ofproto-dpif-xlate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index b308f21de100..39fed7e0b303 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -4623,7 +4623,7 @@ xlate_output_trunc_action(struct xlate_ctx *ctx,
 if (xport == NULL || xport->odp_port == ODPP_NONE) {
 /* Since truncate happens at its following output action, if
  * the output port is a patch port, the behavior is somehow
- * unpredicable. For simpilicity, disallow this case. */
+ * unpredictable.  For simplicity, disallow this case. */
 ofputil_port_to_string(port, name, sizeof name);
 xlate_report_error(ctx, "output_trunc does not support "
"patch port %s", name);
-- 
2.10.2

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

Re: [ovs-dev] [PATCH] travis: Update kernel build targets.

[Greg Rose]

On Thu, 2017-05-18 at 13:17 -0700, Joe Stringer wrote:
> 3.18 and 3.12 have been EOLed, 4.11 is new, and there are some minor
> revisions to other kernels. Update the list.
> 
> Signed-off-by: Joe Stringer 

Thanks!

Acked-by: Greg Rose 

> ---
>  .travis.yml | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 3a7387373ed7..36cd5cf6a7d9 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -25,17 +25,16 @@ sudo: false
>  
>  env:
>- OPTS="--disable-ssl"
> -  - TESTSUITE=1 KERNEL=3.16.39
> +  - TESTSUITE=1 KERNEL=3.16.43
>- TESTSUITE=1 OPTS="--enable-shared"
>- BUILD_ENV="-m32" OPTS="--disable-ssl"
> -  - KERNEL=3.16.39 DPDK=1
> -  - KERNEL=3.16.39 DPDK=1 OPTS="--enable-shared"
> -  - KERNEL=4.10.12
> -  - KERNEL=4.9.24
> -  - KERNEL=4.4.63
> +  - KERNEL=3.16.43 DPDK=1
> +  - KERNEL=3.16.43 DPDK=1 OPTS="--enable-shared"
> +  - KERNEL=4.11.1
> +  - KERNEL=4.10.16
> +  - KERNEL=4.9.28
> +  - KERNEL=4.4.68
>- KERNEL=4.1.39
> -  - KERNEL=3.18.50
> -  - KERNEL=3.12.73
>- KERNEL=3.10.105
>- TESTSUITE=1 LIBS=-ljemalloc
>  



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

Re: [ovs-dev] [PATCH 1/2] ofproto-dpif-xlate: Fix typos in comment.

[Aaron Conole]

Ben Pfaff  writes:

> Signed-off-by: Ben Pfaff 
> ---

Acked-by: Aaron Conole 

I'll be installing and playing with 2/2.

Really pumped about this series! :)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Ben Pfaff]

On Thu, May 18, 2017 at 06:09:21PM +, Darrell Ball wrote:
> 
> 
> On 4/4/17, 5:47 PM, "Darrell Ball"  wrote:
> 
> 
> 
> On 4/4/17, 3:09 AM, "Lal, PrzemyslawX"  wrote:
> 
> On 04/04/2017 06:14, Darrell Ball wrote:
> 
> >
> > On 4/3/17, 5:27 AM, "ovs-dev-boun...@openvswitch.org on behalf of 
> Przemyslaw Lal"  przemyslawx@intel.com> wrote:
> >
> >  In current implementation port_id is used as an ifindex for 
> all netdev-dpdk
> >  interfaces.
> >  
> >  For physical DPDK interfaces using port_id as ifindex causes 
> that '0' is set as
> >  ifindex for 'dpdk0' interface, '1' for 'dpdk1' and so on. For 
> the DPDK vHost
> >  interfaces ifindexes are not even assigned (0 is used by 
> default) due to the
> >  fact that vHost ports don't use port_id field from the DPDK 
> library.
> >  
> >  This causes multiple negative side-effects. First of all 0 is 
> an invalid
> >  ifindex value. The other issue is possible overlapping of 
> 'dpdkX' interfaces
> >  ifindex values with the ifindexes of kernel space interfaces 
> which may cause
> >  problems in any external tools that use those values. Neither 
> 'dpdk0', nor any
> >  DPDK vHost interfaces are visible in sFlow collector tools, as 
> all interfaces
> >  with ifindexes smaller than 1 are ignored.
> >  
> >  Proposed solution to these issues is to calculate a hash of 
> interface's name
> >  and use calculated value as an ifindex. This way interfaces 
> keep their
> >  ifindexes during OVS-DPDK restarts, ports re-initialization 
> events, etc., show
> >  up in sFlow collectors and meet RFC 2863 specification 
> regarding re-using
> >  ifindex values by the same virtual interfaces and maximum 
> ifindex value.
> >  
> >  Signed-off-by: Przemyslaw Lal 
> >  ---
> >   lib/netdev-dpdk.c | 6 +-
> >   1 file changed, 5 insertions(+), 1 deletion(-)
> >  
> >  diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> >  index ddc651b..687b0a5 100644
> >  --- a/lib/netdev-dpdk.c
> >  +++ b/lib/netdev-dpdk.c
> >  @@ -2215,7 +2215,11 @@ netdev_dpdk_get_ifindex(const struct 
> netdev *netdev)
> >   int ifindex;
> >   
> >   ovs_mutex_lock(&dev->mutex);
> >  -ifindex = dev->port_id;
> >  +/* Calculate hash from the netdev name. Ensure that 
> ifindex is a 24-bit
> >  + * postive integer to meet RFC 2863 recommendations.
> >  + */
> >  +uint32_t h = hash_string(netdev->name, 0);
> >  +ifindex = (int)(h % 0xfe + 1);
> >
> >
> > If user configuration was supported, enforcing uniqueness would be 
> the
> > responsibility of the user.
> 
> This was already discussed on this mailing list and outcome was that 
> while hash is not perfect, it is the best solution for now.
> Also, please keep in mind that names of the physical DPDK devices and 
> dpdkvhostuser interfaces are configurable, so user can still enforce
> uniqueness.
> 
> I know uniqueness could be enforced by trial and error of name selection.
> I saw the comment
>  “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.”
> 
> If others are fine, then so am I.
> 
> The uniqueness issue is understood and there is a workaround capability to
> address it.
> 
> Let us just fold the patch in, since the patch has been out for long enough to
> receive feedback.
> 
> Acked by: Darrell Ball 

Thanks Przemyslaw and Darrell.  I applied this to master.  I simplified
the code since the cast to int was a no-op (it does the same thing as
the conversion implied by the assignment:

--8<--cut here-->8--

From: Przemyslaw Lal 
Date: Mon, 3 Apr 2017 13:27:47 +0100
Subject: [PATCH] netdev-dpdk: fix ifindex assignment for DPDK ports

In current implementation port_id is used as an ifindex for all netdev-dpdk
interfaces.

For physical DPDK interfaces using port_id as ifindex causes that '0' is set as
ifindex for 'dpdk0' interface, '1' for 'dpdk1' and so on. For the DPDK vHost
interfaces ifindexes are not even assigned (0 is used by default) due to the
fact that vHost ports don't use port_id field from the DPDK library.

This causes multiple negative side-effects. First of all 0 is an invalid
ifindex value. The other issue is possible overlapping of 'dpdkX' interfaces
ifindex values with the ifindexes of kernel space interfaces which may cause

Re: [ovs-dev] [PATCH] dpif-netdev/netdev-dpdk: Fix line lengths.

[Ben Pfaff]

On Fri, May 05, 2017 at 11:52:05AM +0100, Kevin Traynor wrote:
> Fix line lengths to be <= 79 as per coding style and so that checkpatch
> will not show up existing warnings on these files.
> 
> Signed-off-by: Kevin Traynor 

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

Re: [ovs-dev] [PATCH] rhel-systemd: start vswitchd after udev

[Ben Pfaff]

On Sat, May 13, 2017 at 11:08:13AM -0400, Aaron Conole wrote:
> Aaron Conole writes:
> > It's possible to race with the udev service, such that dpdk ports are
> > not finished being bound until after ovs-vswitchd has been started.
> > This means that attempts to use the port will fail.  While it is
> > possible to work around this for some NICs using port hotplug, not all
> > port types are supported (for instance vfio), and it requires manual
> > intervention.
> >
> > Fixes: 36af136b690c ("rhel-systemd: Delay shutting down the services")
> > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1397299
> > Suggested-by: Flavio Leitner 
> > Signed-off-by: Aaron Conole 
> > ---
> >  rhel/usr_lib_systemd_system_ovs-vswitchd.service | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Ping?  Should I rebase / resend this?  I'm not sure if it still applies
> to the tree.

It still applies fine but I'm not comfortable reviewing it myself.  Is
Flavio the right one to review it or should someone else?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/2] ofproto-dpif-xlate: Fix typos in comment.

[Ben Pfaff]

On Thu, May 18, 2017 at 04:41:21PM -0400, Aaron Conole wrote:
> Ben Pfaff  writes:
> 
> > Signed-off-by: Ben Pfaff 
> > ---
> 
> Acked-by: Aaron Conole 

Thanks!  I applied this to master.

> I'll be installing and playing with 2/2.
> 
> Really pumped about this series! :)

Glad to hear it!  I have some more ideas for followups, but this is a
good place to start.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC v0 0/4] rhel/fedora: non-root OvS out of the box

[Ben Pfaff]

On Sun, Apr 23, 2017 at 10:21:10AM -0400, Aaron Conole wrote:
> This series attempts to introduce the ability to start and use
> Open vSwitch 'out of the box' as a non-root user.  It does this by
> modifying the service files to pass the recently introduced --ovs-user
> argument around, and by making some minor tweaks to the passwd, group,
> and filesystem information.
> 
> The more controversial changes are:
> 
> * This adds another config file (/etc/sysconfig/openvswitch-pre) to the system
> * The dpdk support directly modifies /dev/hugepages with a call to chmod
> * A new user 'openvswitch', and up to two new groups 'openvswitch', and
>   'hugetlbfs' are created
> 
> This is presented as RFC (v0, since it will likely need changes) for
> initial feedback.
> 
> Aaron Conole (4):
>   rhel: allow arbitrary user:group
>   fedora: dynamically allocate ovs user
>   fedora: Also include the db lockfile
>   fedora: allow dpdk to also run as non-root user

I guess that we are waiting for Flavio to look at this?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC v0 0/4] rhel/fedora: non-root OvS out of the box

[Aaron Conole]

Ben Pfaff  writes:

> On Sun, Apr 23, 2017 at 10:21:10AM -0400, Aaron Conole wrote:
>> This series attempts to introduce the ability to start and use
>> Open vSwitch 'out of the box' as a non-root user.  It does this by
>> modifying the service files to pass the recently introduced --ovs-user
>> argument around, and by making some minor tweaks to the passwd, group,
>> and filesystem information.
>> 
>> The more controversial changes are:
>> 
>> * This adds another config file (/etc/sysconfig/openvswitch-pre) to the 
>> system
>> * The dpdk support directly modifies /dev/hugepages with a call to chmod
>> * A new user 'openvswitch', and up to two new groups 'openvswitch', and
>>   'hugetlbfs' are created
>> 
>> This is presented as RFC (v0, since it will likely need changes) for
>> initial feedback.
>> 
>> Aaron Conole (4):
>>   rhel: allow arbitrary user:group
>>   fedora: dynamically allocate ovs user
>>   fedora: Also include the db lockfile
>>   fedora: allow dpdk to also run as non-root user
>
> I guess that we are waiting for Flavio to look at this?

I think so.  I'm planning on rebasing this because I think some things
in the spec files have changed, and I think Timothy R. is also doing
some change, and his is less "intrusive".
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/5] dpif-netdev: Skip EMC lookup when EMC is disabled.

[Ben Pfaff]

Thanks Bhanuprakash, Kevin, Darrell.  I applied this patch to master.

On Wed, May 17, 2017 at 02:49:53AM +, Darrell Ball wrote:
> I found 4-5% throughput improvement when emc is disabled and it is a simple 
> change
> Thanks for adding this.
> 
> Acked-by: Darrell Ball dlu...@gmail.com
> 
> 
> 
> On 4/13/17, 11:30 AM, "ovs-dev-boun...@openvswitch.org on behalf of 
> Bodireddy, Bhanuprakash"  bhanuprakash.bodire...@intel.com> wrote:
> 
> >On 04/13/2017 07:11 PM, Kevin Traynor wrote:
> >> On 03/12/2017 05:33 PM, Bhanuprakash Bodireddy wrote:
> >>> Conditional EMC insert patch gives the flexibility to configure the
> >>> probability of flow insertion in to EMC. This also allows an option
> >>> to entirely disable EMC by setting 'emc-insert-inv-prob=0' which can
> >>> be useful at large number of parallel flows.
> >>>
> >>> This patch skips EMC lookup when EMC is disabled. This is useful to
> >>> avoid wasting CPU cycles and also improve performance considerably.
> >>>
> >>
> >> LGTM. How much does this improve performance?
> 
> I found  significant performance improvement when testing with few 
> hundred streams.  I remember the improvement was  ~800kpps  with smaller 
> packets. This is for the reason that emc_lookup() invokes expensive memcmp() 
> to compare the netdev_flow_key in EMC and it takes up significant cycles. 
> Longer the 'key', worse the performance.  
> 
> >Ack for the series,
> >Acked-by: Kevin Traynor 
> 
> Thanks kevin for the review and Acks.
> 
> Regards,
> Bhanuprakash. 
> ___
> dev mailing list
> d...@openvswitch.org
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=0nx_fadlj6m2KxOZGCsMJYGW9jUMnpXfb-sE5Aesw54&s=IeltQjLxliaHPElGHcd0mWdY7hRUJqbAEspM8CMkyco&e=
>  
> 
> 
> ___
> 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] rhel-systemd: start vswitchd after udev

[Aaron Conole]

Ben Pfaff  writes:

> On Sat, May 13, 2017 at 11:08:13AM -0400, Aaron Conole wrote:
>> Aaron Conole writes:
>> > It's possible to race with the udev service, such that dpdk ports are
>> > not finished being bound until after ovs-vswitchd has been started.
>> > This means that attempts to use the port will fail.  While it is
>> > possible to work around this for some NICs using port hotplug, not all
>> > port types are supported (for instance vfio), and it requires manual
>> > intervention.
>> >
>> > Fixes: 36af136b690c ("rhel-systemd: Delay shutting down the services")
>> > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1397299
>> > Suggested-by: Flavio Leitner 
>> > Signed-off-by: Aaron Conole 
>> > ---
>> >  rhel/usr_lib_systemd_system_ovs-vswitchd.service | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> Ping?  Should I rebase / resend this?  I'm not sure if it still applies
>> to the tree.
>
> It still applies fine but I'm not comfortable reviewing it myself.  Is
> Flavio the right one to review it or should someone else?

Flavio had actually suggested it.  I'm CC'ing the tester.  Maybe we can
at least get a Tested-by tag.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 2/5] dpif-netdev: Reorder elements in dp_netdev structure.

[Ben Pfaff]

On Sun, Mar 12, 2017 at 05:33:25PM +, Bhanuprakash Bodireddy wrote:
> 'emc_insert_min' variable is made to align on a 64-byte boundary and this
> introduces a 24 byte hole.
> 
> This patch moves the emc_insert_min member variable slightly higher in
> the order to remove the hole and thus saves a cache line with the new
> ordering.
> 
> Signed-off-by: Bhanuprakash Bodireddy 
> CC: Ciara Loftus 
> CC: Georg Schmuecking 

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

Re: [ovs-dev] [PATCH 3/5] Documentation: Update DPDK doc EMC conditional insert section.

[Ben Pfaff]

On Sun, Mar 12, 2017 at 05:33:26PM +, Bhanuprakash Bodireddy wrote:
> Update the documentation with the information on the megaflow hits
> observed with the default 'emc-insert-inv-prob' value. Also add the
> recommended setting for achieving higher forwarding performance.
> 
> Signed-off-by: Bhanuprakash Bodireddy 
> CC: Ciara Loftus 
> CC: Georg Schmuecking 

Thanks for updating the documentation!  I applied this to master.

(However, I think it's better if we can make the switch self-tuning
rather than requiring the user to understand traffic patterns and then
tune it by hand.  I hope that we can improve that later--and then delete
the tuning documentation.)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] dpif-netdev: Fix comments for dp_netdev_pmd_thread struct.

[Ben Pfaff]

On Mon, May 15, 2017 at 04:57:00PM +0100, Bhanuprakash Bodireddy wrote:
> The sorted subtable ranking patch introduced a classifier instance per
> ingress port with its subtables ranked on the frequency of hits. The PMD
> thread can have more classifier instances now and solely depends on the
> number of ingress ports currently handled by the pmd thread.
> 
> Fixes: 3453b4d62a98 ("dpif-netdev: dpcls per in_port with sorted
> subtables")
> Signed-off-by: Bhanuprakash Bodireddy 
> Signed-off-by: Darrell Ball 

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

Re: [ovs-dev] [PATCH] netdev-dpdk: add support for rx_multicast_packets counter

[Ben Pfaff]

Usually I wait for someone who knows DPDK better to review DPDK patches,
but I agree that this one is trivial.  I applied it to master.  Thank
you for your contribution!

On Tue, May 16, 2017 at 07:50:00AM +, Szczerbik, PrzemyslawX wrote:
> Hi,
> 
> Any comments on this change? It's really trivial patch, which has been 
> sitting in patchwork for some time now.
> Is there anything that I can do to expedite the review process?
> 
> Kind regards,
> Przemek
> 
> > -Original Message-
> > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > boun...@openvswitch.org] On Behalf Of Przemyslaw Szczerbik
> > Sent: Friday, April 28, 2017 10:52 AM
> > To: d...@openvswitch.org
> > Subject: [ovs-dev] [PATCH] netdev-dpdk: add support for rx_multicast_packets
> > counter
> > 
> > This patch enables already implemented ifInMulticastPkts counter in sFlow 
> > for
> > DPDK interfaces. Metric is retrieved from DPDK by using extended statistic 
> > API
> > and stored in 'multicast' member of netdev_stats structure, which represents
> > number of incoming packets that were addressed to a multicast address.
> > 
> > Signed-off-by: Przemyslaw Szczerbik 
> > ---
> >  lib/netdev-dpdk.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> > index ddc651b..2de9d26 100644
> > --- a/lib/netdev-dpdk.c
> > +++ b/lib/netdev-dpdk.c
> > @@ -118,6 +118,7 @@ BUILD_ASSERT_DECL((MAX_NB_MBUF /
> > ROUND_DOWN_POW2(MAX_NB_MBUF/MIN_NB_MBUF))
> >  #define XSTAT_TX_1024_TO_1522_PACKETS"tx_size_1024_to_1522_packets"
> >  #define XSTAT_TX_1523_TO_MAX_PACKETS "tx_size_1523_to_max_packets"
> > 
> > +#define XSTAT_RX_MULTICAST_PACKETS   "rx_multicast_packets"
> >  #define XSTAT_TX_MULTICAST_PACKETS   "tx_multicast_packets"
> >  #define XSTAT_RX_BROADCAST_PACKETS   "rx_broadcast_packets"
> >  #define XSTAT_TX_BROADCAST_PACKETS   "tx_broadcast_packets"
> > @@ -1996,6 +1997,8 @@ netdev_dpdk_convert_xstats(struct netdev_stats
> > *stats,
> >  stats->tx_1024_to_1522_packets = xstats[i].value;
> >  } else if (strcmp(XSTAT_TX_1523_TO_MAX_PACKETS, names[i].name) == 
> > 0) {
> >  stats->tx_1523_to_max_packets = xstats[i].value;
> > +} else if (strcmp(XSTAT_RX_MULTICAST_PACKETS, names[i].name) == 0) 
> > {
> > +stats->multicast = xstats[i].value;
> >  } else if (strcmp(XSTAT_TX_MULTICAST_PACKETS, names[i].name) == 0) 
> > {
> >  stats->tx_multicast_packets = xstats[i].value;
> >  } else if (strcmp(XSTAT_RX_BROADCAST_PACKETS, names[i].name) == 0) 
> > {
> > --
> > 1.9.3
> > 
> > --
> > Intel Research and Development Ireland Limited
> > Registered in Ireland
> > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> > Registered Number: 308263
> > 
> > 
> > This e-mail and any attachments may contain confidential material for the 
> > sole
> > use of the intended recipient(s). Any review or distribution by others is
> > strictly prohibited. If you are not the intended recipient, please contact 
> > the
> > sender and delete all copies.
> > 
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> --
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
> 
> 
> This e-mail and any attachments may contain confidential material for the sole
> use of the intended recipient(s). Any review or distribution by others is
> strictly prohibited. If you are not the intended recipient, please contact the
> sender and delete all copies.
> 
> ___
> 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] rhel-systemd: start vswitchd after udev

[Ben Pfaff]

On Thu, May 18, 2017 at 05:11:03PM -0400, Aaron Conole wrote:
> Ben Pfaff  writes:
> 
> > On Sat, May 13, 2017 at 11:08:13AM -0400, Aaron Conole wrote:
> >> Aaron Conole writes:
> >> > It's possible to race with the udev service, such that dpdk ports are
> >> > not finished being bound until after ovs-vswitchd has been started.
> >> > This means that attempts to use the port will fail.  While it is
> >> > possible to work around this for some NICs using port hotplug, not all
> >> > port types are supported (for instance vfio), and it requires manual
> >> > intervention.
> >> >
> >> > Fixes: 36af136b690c ("rhel-systemd: Delay shutting down the services")
> >> > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1397299
> >> > Suggested-by: Flavio Leitner 
> >> > Signed-off-by: Aaron Conole 
> >> > ---
> >> >  rhel/usr_lib_systemd_system_ovs-vswitchd.service | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> Ping?  Should I rebase / resend this?  I'm not sure if it still applies
> >> to the tree.
> >
> > It still applies fine but I'm not comfortable reviewing it myself.  Is
> > Flavio the right one to review it or should someone else?
> 
> Flavio had actually suggested it.  I'm CC'ing the tester.  Maybe we can
> at least get a Tested-by tag.

I didn't realize there was a tester.  I guess that I should have looked
at the bugzilla URL.

If Maxim tested it successfully, we don't really need him to give us the
Tested-by, we can add it ourselves.  (But now that we've asked, we might
as well get an answer.)

Thanks,

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

Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: Fix typos in comment.

[Greg Rose]

On Thu, 2017-05-18 at 13:20 -0700, Ben Pfaff wrote:
> Signed-off-by: Ben Pfaff 
> ---
>  ofproto/ofproto-dpif-xlate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> index b308f21de100..39fed7e0b303 100644
> --- a/ofproto/ofproto-dpif-xlate.c
> +++ b/ofproto/ofproto-dpif-xlate.c
> @@ -4623,7 +4623,7 @@ xlate_output_trunc_action(struct xlate_ctx *ctx,
>  if (xport == NULL || xport->odp_port == ODPP_NONE) {
>  /* Since truncate happens at its following output action, if
>   * the output port is a patch port, the behavior is somehow
> - * unpredicable. For simpilicity, disallow this case. */
> + * unpredictable.  For simplicity, disallow this case. */
>  ofputil_port_to_string(port, name, sizeof name);
>  xlate_report_error(ctx, "output_trunc does not support "
> "patch port %s", name);

'unpredicable' isn't a word but maybe it should be...

LGTM

Acked-by: Greg Rose 


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

Re: [ovs-dev] [RFC v0 0/4] rhel/fedora: non-root OvS out of the box

[Ben Pfaff]

On Thu, May 18, 2017 at 05:09:04PM -0400, Aaron Conole wrote:
> Ben Pfaff  writes:
> 
> > On Sun, Apr 23, 2017 at 10:21:10AM -0400, Aaron Conole wrote:
> >> This series attempts to introduce the ability to start and use
> >> Open vSwitch 'out of the box' as a non-root user.  It does this by
> >> modifying the service files to pass the recently introduced --ovs-user
> >> argument around, and by making some minor tweaks to the passwd, group,
> >> and filesystem information.
> >> 
> >> The more controversial changes are:
> >> 
> >> * This adds another config file (/etc/sysconfig/openvswitch-pre) to the 
> >> system
> >> * The dpdk support directly modifies /dev/hugepages with a call to chmod
> >> * A new user 'openvswitch', and up to two new groups 'openvswitch', and
> >>   'hugetlbfs' are created
> >> 
> >> This is presented as RFC (v0, since it will likely need changes) for
> >> initial feedback.
> >> 
> >> Aaron Conole (4):
> >>   rhel: allow arbitrary user:group
> >>   fedora: dynamically allocate ovs user
> >>   fedora: Also include the db lockfile
> >>   fedora: allow dpdk to also run as non-root user
> >
> > I guess that we are waiting for Flavio to look at this?
> 
> I think so.  I'm planning on rebasing this because I think some things
> in the spec files have changed, and I think Timothy R. is also doing
> some change, and his is less "intrusive".

OK.

I've marked these "superseded" in patchwork, in anticipation of a
repost.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Cover letters (was Re: [PATCH 0/7] Add OVS DPDK keep-alive functionality)

[Aaron Conole]

Stephen Finucane  writes:

> On Tue, 2017-05-02 at 12:21 -0400, Aaron Conole wrote:
>> Ben Pfaff  writes:
>> 
>> > On Mon, May 01, 2017 at 04:45:56PM -0400, Aaron Conole wrote:
>> > > Ben Pfaff  writes:
>> > > ...
>> > > > I think it'd be even better to include measurements in one of
>> > > > the commit messages, because those are available in the
>> > > > repository after the patches are applied.  It's harder to find
>> > > > cover letters because they're only on the mailing list.
>> > > 
>> > > One thing that other projects do to keep the cover letters is to
>> > > create a branch, apply all the patches from the series, and then
>> > > create a merge commit, with the commit message as the cover
>> > > letter.  It can make the history a bit messier, but means that
>> > > the cover letter is retained, and makes 'git bisect' work quite a
>> > > bit better (because bisect knows how to skip merged trees
>> > > appropriately).  It could be worth doing, because it can help to
>> > > explain an overall motivation for a series when walking the tree
>> > > with git annotations.
>> > 
>> > I wouldn't object to that, for well-organized series.
>> > 
>> > Is there a way to automate applying a branch like this from
>> > email?  Or is it better to do them as pull requests (whether via
>> > email or Github)?
>> 
>> I think patchwork provides access to the cover letter somehow.  I've
>> CC'd Stephen because he has a bit of experience with PW, and may be
>> able to comment on whether or not I'm just crazy.

Sorry for the late response.

> Patchwork 2.0 will. We're finishing up the release at the moment (RC
> this week. Final release some time later this month), but it'll allow
> downloading of entire series and displaying of cover letters. One of
> the Patchwork contributors has a sample instance up to browse [1].
>
> You should also check out 'git-pw' [2] (which I think Aaron has
> contributed patches to?). This relies on Patchwork 2.0, but it'll make
> downloading and applying a series as easy as:
>
>   git-pw series apply {seriesID}
>
> for a whole series, or:
>
>   git-pw patch apply {patchID}
>
> for a patch with its dependencies.
>
> I'll be sure to ping the list as soon as the 2.0 is released and the
> ozlabs instance bumped, which should be (fingers crossed) any week now.

Cool!  I look forward to it.  I checked out the patchwork-2.0 instance,
and was happy to see that it's possible to grab the 0/X cover letter.
That means we could implement something where we grab the series, and
use the cover letter at the merge message.  I'll find out whether there
can be a happy script / incantation to do that once ozlabs instance is
upgraded.

> Stephen
>
> [1] https://py3.patchwork.dja.id.au/project/lkml/list/
> [2] https://github.com/stephenfin/git-pw
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v4] OVN localport type support

[Ben Pfaff]

On Wed, May 10, 2017 at 08:35:45AM +, Daniel Alvarez wrote:
> This patch introduces a new type of OVN ports called "localport".
> These ports will be present in every hypervisor and may have the
> same IP/MAC addresses. They are not bound to any chassis and traffic
> to these ports will never go through a tunnel.
> 
> Its main use case is the OpenStack metadata API support which relies
> on a local agent running on every hypervisor and serving metadata to
> VM's locally. This service is described in detail at [0].
> 
> An example to illustrate the purpose of this patch:
> 
> - One logical switch sw0 with 2 ports (p1, p2) and 1 localport (lp)
> - Two hypervisors: HV1 and HV2
> - p1 in HV1 (OVS port with external-id:iface-id="p1")
> - p2 in HV2 (OVS port with external-id:iface-id="p2")
> - lp in both hypevisors (OVS port with external-id:iface-id="lp")
> - p1 should be able to reach p2 and viceversa
> - lp on HV1 should be able to reach p1 but not p2
> - lp on HV2 should be able to reach p2 but not p1
> 
> Explicit drop rules are inserted in table 32 with priority 150
> in order to prevent traffic originated at a localport to go over
> a tunnel.
> 
> [0] https://review.openstack.org/#/c/452811/
> 
> Signed-off-by: Daniel Alvarez 

Thanks for working on this!

This seems reasonable, but I'm torn about one aspect of it.  I'm not
sure whether my concern is a kind of premature optimization or not, so
let me just describe it and we can discuss.

This adds code that iterates over every local lport (suppose there are N
of them), which is nested inside a function that is executed for every
port relevant to the local hypervisor (suppose there are M of them).
That's O(N*M) time.  But the inner loop is only doing something useful
for localport logical ports, and normally there would only be 1 or so of
those; at any rate a constant number.  So in theory this could run in
O(M) time.

I see at least two ways to fix the problem, if it's a problem, but I
don't know whether it's worth fixing.  Daniel?  Russell?  (Others?)

Thanks,

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

Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: Fix typos in comment.

[Ben Pfaff]

On Thu, May 18, 2017 at 02:52:57PM -0700, Greg Rose wrote:
> On Thu, 2017-05-18 at 13:20 -0700, Ben Pfaff wrote:
> > Signed-off-by: Ben Pfaff 
> > ---
> >  ofproto/ofproto-dpif-xlate.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> > index b308f21de100..39fed7e0b303 100644
> > --- a/ofproto/ofproto-dpif-xlate.c
> > +++ b/ofproto/ofproto-dpif-xlate.c
> > @@ -4623,7 +4623,7 @@ xlate_output_trunc_action(struct xlate_ctx *ctx,
> >  if (xport == NULL || xport->odp_port == ODPP_NONE) {
> >  /* Since truncate happens at its following output action, 
> > if
> >   * the output port is a patch port, the behavior is somehow
> > - * unpredicable. For simpilicity, disallow this case. */
> > + * unpredictable.  For simplicity, disallow this case. */
> >  ofputil_port_to_string(port, name, sizeof name);
> >  xlate_report_error(ctx, "output_trunc does not support "
> > "patch port %s", name);
> 
> 'unpredicable' isn't a word but maybe it should be...
> 
> LGTM
> 
> Acked-by: Greg Rose 

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

Re: [ovs-dev] [PATCH 2/2] sparse: Avoid warnings compiling stream-ssl.c.

[Ben Pfaff]

Thanks for the thoughtful review.  I applied this to master.

On Wed, May 10, 2017 at 12:08:29AM +, Darrell Ball wrote:
> I don’t see the Sparse complaint
> 
> I am using
> 
> dball@ubuntu:~/ovs$ openssl version
> OpenSSL 1.0.2g  1 Mar 2016
> dball@ubuntu:~/ovs$ uname -a
> Linux ubuntu 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> 
> The line number quoted in the commit message here
> “/usr/include/openssl/e_os2.h:275:12: this was the original definition”
> makes no sense for me
> 
> That being said, I cannot see a problem with the proposed change
> and since we don’t understand the Sparse complaint, we can either
> ignore it or spend more time in the slim hope we can understand it
> and it turns out to be useful.
> 
> I think it is better to ignore it
> 
> Acked-by: Darrell Ball 
> 
> 
> 
> On 5/5/17, 9:39 PM, "ovs-dev-boun...@openvswitch.org on behalf of Ben Pfaff" 
>  wrote:
> 
> This change avoids the following "sparse" warnings:
> 
> /usr/include/inttypes.h:105:10: warning: preprocessor token PRIu64 
> redefined
> /usr/include/openssl/e_os2.h:275:12: this was the original definition
> 
> With this change, the build is again "sparse" clean.
> 
> I did not look into the details of this particular issue.  However, the
> upshot is that including  before any OpenSSL header avoids the
> warning and the opposite order provokes it.
> 
> Signed-off-by: Ben Pfaff 
> ---
>  lib/dhparams.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/dhparams.h b/lib/dhparams.h
> index 54f9c5fbc01b..9bf03e51ed7e 100644
> --- a/lib/dhparams.h
> +++ b/lib/dhparams.h
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2008 Nicira, Inc.
> + * Copyright (c) 2008, 2017 Nicira, Inc.
>   *
>   * Licensed under the Apache License, Version 2.0 (the "License");
>   * you may not use this file except in compliance with the License.
> @@ -17,6 +17,7 @@
>  #ifndef DHPARAMS_H
>  #define DHPARAMS_H 1
>  
> +#include 
>  #include 
>  
>  DH *get_dh1024(void);
> -- 
> 2.10.2
> 
> ___
> dev mailing list
> d...@openvswitch.org
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=8bO30Qvgkz6yoS5Af-9gGrNcJcPgq-_wwIOJF8ynpdU&s=pf3zcGbDebqT24IX4YIPYGjLKoe6cNT04fIUw89Z5WU&e=
>  
> 
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] docs: Improve formatting for daemon options in a few manpages.

[Ben Pfaff]

On Tue, May 09, 2017 at 01:44:34PM -0700, Andy Zhou wrote:
> On Mon, May 8, 2017 at 7:43 AM, Ben Pfaff  wrote:
> > daemon.man is meant to have a heading above it, but in a few manpages its
> > text was running directly into the previous documentation because this had
> > been overlooked.
> >
> > By adding .PP to daemon.man, we make this problem less severe if the
> > heading is similarly omitted in future manpages, since at least it will
> > then have its own paragraph instead of running into the previous one.
> >
> > Signed-off-by: Ben Pfaff 
> Acked-by: Andy Zhou 

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

Re: [ovs-dev] [PATCH 1/2] ovs-ctl: Add option to delete transient ports only on boot.

[Ben Pfaff]

On Fri, May 05, 2017 at 08:34:13PM +0200, Timothy Redaelli wrote:
> The first time after boot, when openvswitch is started by using
> --delete-transient-ports-on-boot ovs-ctl option, all transient ports will be
> removed.
> 
> Signed-off-by: Timothy Redaelli 
> ---
>  utilities/ovs-ctl.in | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
> index 575ffa03..c3130fa3 100755
> --- a/utilities/ovs-ctl.in
> +++ b/utilities/ovs-ctl.in
> @@ -189,6 +189,11 @@ do_start_ovsdb () {
>  if test X"$DELETE_TRANSIENT_PORTS" = Xyes; then
>  del_transient_ports
>  fi
> +if test X"$DELETE_TRANSIENT_PORTS_ON_BOOT" = Xyes && \
> +! test -f "$rundir/deleted_transient_ports"; then
> +del_transient_ports
> +: > "$rundir/deleted_transient_ports"
> +fi
>  fi
>  }
>  

Hmm.

The Xenserver initscript, in xenserver/etc_init.d_openvswitch,
implements something a little like this by hand:

if test ! -e /var/run/openvswitch.booted; then
touch /var/run/openvswitch.booted
set "$@" --delete-bridges
fi

I don't know whether that's a strong precedent that the caller should
implement this kind of logic.  But, if it's not, then I'd request that
this new option be documented in the ovs-ctl usage message and manpage.

Thanks,

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

Re: [ovs-dev] [PATCH] travis: Update kernel build targets.

[Joe Stringer]

On 18 May 2017 at 13:33, Greg Rose  wrote:
> On Thu, 2017-05-18 at 13:17 -0700, Joe Stringer wrote:
>> 3.18 and 3.12 have been EOLed, 4.11 is new, and there are some minor
>> revisions to other kernels. Update the list.
>>
>> Signed-off-by: Joe Stringer 
>
> Thanks!
>
> Acked-by: Greg Rose 

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

Re: [ovs-dev] [PATCH v5 0/7] create tunnel devices using rtnetlink interface

[Greg Rose]

On Thu, 2017-05-18 at 16:10 -0400, Eric Garver wrote:
> This series adds support for the creation of tunnels using the rtnetlink
> interface. This will open the possibility for new features and flags on those
> vports without the need to change vport compatibility code.
> 
> Support for STT and LISP have not been added because these are not upstream 
> yet,
> so we don't know how the interface will be like upstream. And there are no
> features in the current drivers right now we could make use of.
> 
> Note: This work originally started by Thadeu Lima de Souza Cascardo.
> 
> Note: There is a known failure for GENEVE tunnels using rtnetlink on newer
> kernels. This is being addressed with a separate kernel fix. The fallback to
> compat will work however.

I've applied these patches for testing and review and I get these errors
when I run make check on a 4.12-rc1 kernel:
 783: tunnel-push-pop.at:3 tunnel_push_pop - action
 784: tunnel-push-pop.at:191 tunnel_push_pop - packet_out
 785: tunnel-push-pop.at:229 tunnel_push_pop - underlay bridge match
 786: tunnel-push-pop-ipv6.at:3 tunnel_push_pop_ipv6 - action

Are these the known failures?  Was there something in the compat that
needs fixing?  I'm sort of new to this so please excuse any obvious
ignorance showing.

I've downloaded the 4.9.23 kernel and will try against that next.

Thanks,

- Greg

> 
> Testing:
>   - kernel 4.9.22, in-tree datapath
> - rtnetlink successfully creates devices
>   - kernel 4.2.8, in-tree datapath
> - rtnetlink is tried, but fails due to no COLLECT_METADATA support
> - genetlink successfully creates devices
>   - kernel 4.2.8, out-of-tree datapath
> - rtnetlink is not tried
> - genetlink successfully creates devices
>   - Create a native VXLAN interface with incorrect config, run VXLAN
> check-kernel test. Old device is replaced by OVS created one.
> 
> v5:
>   - Make dpif_netlink_rtnl_port_create() easier to follow.
>   - Reword some patch descriptions
> 
> v4:
>   - If device exists, verify and potentially delete/re-add. This handles the
> case where OVS may be killed.
>   - Further commonize rtnetlink code; create, verify, delete
>   - Incorporate Joe's style changes from last review
> 
> v3:
>   - commonzie code to get port data to verify port
>   - eliminate dpif_netlink_rtnl_vxlan_destroy() and alike
>   - minor changes for coding style guidelines
>   - add ACKs from previous reviews
> 
> Eric Garver (6):
>   dpif-netlink: Refactor code to create compat ports
>   dpif-netlink: Support rtnetlink port creation.
>   dpif-netlink-rtnl: Support VXLAN creation
>   dpif-netlink-rtnl: Support GRE creation
>   dpif-netlink-rtnl: Support GENEVE creation
>   dpif-netlink: Probe for out-of-tree tunnels, decides used interface
> 
> Thadeu Lima de Souza Cascardo (1):
>   netdev: get device type from vport prefix if it uses one
> 
>  NEWS|   3 +
>  lib/automake.mk |   3 +
>  lib/dpif-netlink-rtnl.c | 467 
> 
>  lib/dpif-netlink-rtnl.h |  54 ++
>  lib/dpif-netlink.c  | 210 ++
>  lib/dpif-netlink.h  |   2 +
>  lib/netdev.c|  26 ++-
>  7 files changed, 691 insertions(+), 74 deletions(-)
>  create mode 100644 lib/dpif-netlink-rtnl.c
>  create mode 100644 lib/dpif-netlink-rtnl.h
> 



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

Re: [ovs-dev] [PATCH v3 1/1] dpif-netdev: The pmd-*-show commands will show info in core order

[Ben Pfaff]

On Tue, May 09, 2017 at 09:08:54AM +0200, Eelco Chaudron wrote:
> The "ovs-appctl dpif-netdev/pmd-rxq-show" and "ovs-appctl
> dpif-netdev/pmd-stats-show" commands show their output per core_id,
> sorted on the hash location. My OCD was kicking in when using these
> commands, hence this change to display them in natural core_id order.
> 
> In addition I had to change a test case that would fail if the cores
> where not in order in the hash list. This is due to OVS assigning
> queues to cores based on the order in the hash list. The test case now
> checks if any core has the set of queues in the given order.
> 
> Manually tested this on my setup, and ran clang-analyze.
> 
> Signed-off-by: Eelco Chaudron 

Thanks a lot!  Little things like this eventually add up to make the UI
nicer.  I applied this to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] rhel: Fix openvswitch.spec install.

[Joe Stringer]

This is the equivalent change of 2f4f43bfddfd ("rhel: fix the fedora
spec") for the regular openvswitch.spec. From that patch:

When commit d0c961a99f57 ("lib/automake.mk: don't install runtime
directories") landed, it broke RPM based builds since the requisite
directories were no longer available.  This commit adds those
directories back when making RPMs so that the packagemanager can see
them.

Fixes: d0c961a99f57 ("lib/automake.mk: don't install runtime directories")
Signed-off-by: Joe Stringer 
---
 rhel/openvswitch.spec.in | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/rhel/openvswitch.spec.in b/rhel/openvswitch.spec.in
index 31a535c9f50c..412f3cd9dd21 100644
--- a/rhel/openvswitch.spec.in
+++ b/rhel/openvswitch.spec.in
@@ -107,7 +107,9 @@ rm \
 (cd "$RPM_BUILD_ROOT" && rm -rf usr/%{_lib}/*.la)
 (cd "$RPM_BUILD_ROOT" && rm -rf usr/include)
 
-install -d -m 755 $RPM_BUILD_ROOT/var/lib/openvswitch
+install -d -m 0755 $RPM_BUILD_ROOT%{_rundir}/openvswitch
+install -d -m 0755 $RPM_BUILD_ROOT%{_localstatedir}/log/openvswitch
+install -d -m 0755 $RPM_BUILD_ROOT/var/lib/openvswitch
 
 copy_headers() {
 src=$1
-- 
2.11.1

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

Re: [ovs-dev] [PATCH v2 1/5] rstp: Init a recursive mutex for rstp.

[Ben Pfaff]

On Wed, May 10, 2017 at 04:15:02AM -0700, nickcooper-zhangtonghao wrote:
> * This patch will be used for next patch. The 'rstp/show' command,
> which uses the mutex, calls functions which also use the mutex.
> We should init it as a recursive mutex.
> 
> * Some rstp tests of OvS, which run with ovstest, does not run rstp_init
> in the bridge_init. We should call rstp_init when creating the rstp
> and stp also do that, otherwise tests fail.
> 
> * This patch remove the rstp_mutex in header file and make it static
> in c file because we only use it in lib/rstp.c
> 
> Signed-off-by: nickcooper-zhangtonghao 

Thanks for working on the rstp code!

This patch causes a huge number of build failures with Clang, like this:

In file included from ../lib/rstp.c:32:
../lib/rstp.h:135:18: error: use of undeclared identifier 'rstp_mutex'
../include/openvswitch/compiler.h:136:57: note: expanded from macro 
'OVS_EXCLUDED'

I think that's the only reason that rstp_mutex is global.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] rhel: Fix openvswitch.spec install.

[Greg Rose]

On Thu, 2017-05-18 at 15:44 -0700, Joe Stringer wrote:
> This is the equivalent change of 2f4f43bfddfd ("rhel: fix the fedora
> spec") for the regular openvswitch.spec. From that patch:
> 
> When commit d0c961a99f57 ("lib/automake.mk: don't install runtime
> directories") landed, it broke RPM based builds since the requisite
> directories were no longer available.  This commit adds those
> directories back when making RPMs so that the packagemanager can see
> them.
> 
> Fixes: d0c961a99f57 ("lib/automake.mk: don't install runtime directories")
> Signed-off-by: Joe Stringer 

Thanks for fixing this!

Acked-by: Greg Rose 

> ---
>  rhel/openvswitch.spec.in | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/rhel/openvswitch.spec.in b/rhel/openvswitch.spec.in
> index 31a535c9f50c..412f3cd9dd21 100644
> --- a/rhel/openvswitch.spec.in
> +++ b/rhel/openvswitch.spec.in
> @@ -107,7 +107,9 @@ rm \
>  (cd "$RPM_BUILD_ROOT" && rm -rf usr/%{_lib}/*.la)
>  (cd "$RPM_BUILD_ROOT" && rm -rf usr/include)
>  
> -install -d -m 755 $RPM_BUILD_ROOT/var/lib/openvswitch
> +install -d -m 0755 $RPM_BUILD_ROOT%{_rundir}/openvswitch
> +install -d -m 0755 $RPM_BUILD_ROOT%{_localstatedir}/log/openvswitch
> +install -d -m 0755 $RPM_BUILD_ROOT/var/lib/openvswitch
>  
>  copy_headers() {
>  src=$1



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

Re: [ovs-dev] [RFC 1/2] doc: Reduce duplication in 'man_pages'

[Ben Pfaff]

On Wed, May 10, 2017 at 09:32:18PM -0400, Stephen Finucane wrote:
> All these entries are going to be roughly the same, with only two key
> differences. Clarify things by focusing on those differences.
> 
> Signed-off-by: Stephen Finucane 

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

Re: [ovs-dev] [PATCH v5 0/7] create tunnel devices using rtnetlink interface

[Joe Stringer]

On 18 May 2017 at 15:35, Greg Rose  wrote:
> On Thu, 2017-05-18 at 16:10 -0400, Eric Garver wrote:
>> This series adds support for the creation of tunnels using the rtnetlink
>> interface. This will open the possibility for new features and flags on those
>> vports without the need to change vport compatibility code.
>>
>> Support for STT and LISP have not been added because these are not upstream 
>> yet,
>> so we don't know how the interface will be like upstream. And there are no
>> features in the current drivers right now we could make use of.
>>
>> Note: This work originally started by Thadeu Lima de Souza Cascardo.
>>
>> Note: There is a known failure for GENEVE tunnels using rtnetlink on newer
>> kernels. This is being addressed with a separate kernel fix. The fallback to
>> compat will work however.
>
> I've applied these patches for testing and review and I get these errors
> when I run make check on a 4.12-rc1 kernel:
>  783: tunnel-push-pop.at:3 tunnel_push_pop - action
>  784: tunnel-push-pop.at:191 tunnel_push_pop - packet_out
>  785: tunnel-push-pop.at:229 tunnel_push_pop - underlay bridge match
>  786: tunnel-push-pop-ipv6.at:3 tunnel_push_pop_ipv6 - action
>
> Are these the known failures?  Was there something in the compat that
> needs fixing?  I'm sort of new to this so please excuse any obvious
> ignorance showing.
>
> I've downloaded the 4.9.23 kernel and will try against that next.

Hmm, I've tried it on my dev box with kernel 4.9.11 and I don't see
any failures.

If these reliably fail, could you post the testsuite.log?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] rhel: Fix openvswitch.spec install.

[Joe Stringer]

On 18 May 2017 at 15:48, Greg Rose  wrote:
> On Thu, 2017-05-18 at 15:44 -0700, Joe Stringer wrote:
>> This is the equivalent change of 2f4f43bfddfd ("rhel: fix the fedora
>> spec") for the regular openvswitch.spec. From that patch:
>>
>> When commit d0c961a99f57 ("lib/automake.mk: don't install runtime
>> directories") landed, it broke RPM based builds since the requisite
>> directories were no longer available.  This commit adds those
>> directories back when making RPMs so that the packagemanager can see
>> them.
>>
>> Fixes: d0c961a99f57 ("lib/automake.mk: don't install runtime directories")
>> Signed-off-by: Joe Stringer 
>
> Thanks for fixing this!
>
> Acked-by: Greg Rose 

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

Re: [ovs-dev] [RFC 2/2] doc: Convert ovs-vswitchd to rST

[Ben Pfaff]

Bravo.  This must have been a lot of work.

More comments follow...

On Wed, May 10, 2017 at 09:32:19PM -0400, Stephen Finucane wrote:
> This is the largest man page by some distance. There are a couple of
> changes needed to make this work:
> 
> - Combining italics and bold without spaces (i.e. hello-world
>   ) and nesting italics and bold (i.e. hello-world)
>   is not supported by rST. Where present, this has been removed.
> 
> - Duplicated opts are not possible. Where before we would have had a
>   list like so:
> 
> -vPATTERN:destination:pattern
>   Description
> 
> -vFACILITY:facility
>   Description
> 
>We now have:
> 
>  -v 
> 
>PATTERN::
>  Description
> 
>FACILITY:
>  Description
> 
>   This is necessary if we want to make best use of the Sphinx indexing.

I'm not too aware of Sphinx indexing.  When I type "Sphinx indexing"
into Google, it tells me about a search engine named Sphinx, which I
don't think is what you mean.  Can you point to something about it?

If the indexing is just a matter of being able to jump to the definition
of -v from somewhere else, I wonder whether it matters whether both
definitions are indexed?  I think that both definitions would be right
next to each other in this case.

There's a bigger problem with the above transformation, though: -v takes
an optional argument, which means that only accepts an argument if the
argument is mashed up against it.  If you write "-v ..." with a space,
it's not an argument, it's "-v" followed by a non-option argument.

> - TODO
> 
> Signed-off-by: Stephen Finucane 

> - There's a big loss of formatting for subcommands. While I don't think
>   the bit of loss in the option descriptions is _that_ big a deal, the
>   subcommands are longer and could benefit from the formatting more. I
>   could probably fix it in Sphinx internally for Sphinx 1.6, but that'd
>   take a year or two to propagate to distros.

I don't understand the issue yet.  What happens if we just use RST that
produces the desired formatting?  (Is this about indexing again?)

> - I'm not sure if there's a way to use this kind of macro:
> 
> \*(DX\fBadd\-dp \fIdp\fR [\fInetdev\fR[\fB,\fIoption\fR]...]
> 
>   which is called like so:
> 
> .ds DX \fBdpctl/\fR
> .de DO
> \\$2 \\$1 \\$3
> 
>   and yields:
> 
> dpctl/add-dp dp [netdev[,option]...]
> 
>   This will probably result in some duplication, else a _lot_ of 'inc'
>   files

We could always just document these commands in only one place, e.g. the
ovs-dpctl manpage, and then refer to that manpage from ovs-vswitchd
manpage with a little extra explanation, e.g. "You can use ovs-dpctl
commands via ovs-appctl: instead of 'ovs-dpctl show', type 'ovs-appctl
dpctl/show'."

> - I'm not sure how we should pass in autoconf (?) variables like
>   @RUNDIR@. Could we do this in Python or something?

I haven't done the right research on this yet.

> - Some other stuff that I've forgotten
> 
> In any case though, it should go folks a rough idea of what a larger man
> page in rST/Sphinx will actually look like.

I notice that in PDF builds, long lines in examples get cut off at the
right margin instead of line-wrapping, which is unfortunate.

This needs the following to avoid a build error:

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 3c75d906afec..a7109f8e2f79 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -91,6 +91,23 @@ DOC_SOURCE = \
Documentation/internals/contributing/documentation-style.rst \
Documentation/internals/contributing/libopenvswitch-abi.rst \
Documentation/internals/contributing/submitting-patches.rst \
+   Documentation/ref/common.inc \
+   Documentation/ref/coverage-unixctl.inc \
+   Documentation/ref/daemon.inc \
+   Documentation/ref/dpctl.inc \
+   Documentation/ref/memory-unixctl.inc \
+   Documentation/ref/ofproto-dpif-unixctl.inc \
+   Documentation/ref/ofproto-tnl-unixctl.inc \
+   Documentation/ref/ofproto-unixctl.inc \
+   Documentation/ref/ovs-vswitchd.8.rst \
+   Documentation/ref/remote-active.inc \
+   Documentation/ref/remote-passive.inc \
+   Documentation/ref/service.inc \
+   Documentation/ref/ssl-bootstrap.inc \
+   Documentation/ref/ssl.inc \
+   Documentation/ref/unixctl.inc \
+   Documentation/ref/vlog-unixctl.inc \
+   Documentation/ref/vlog.inc \
Documentation/requirements.txt \
$(addprefix Documentation/ref/,$(RST_MANPAGES))
 FLAKE8_PYFILES += Documentation/conf.py
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Fwd: [PATCH] bfd: Fix signs in ovs-appctl bfd/show Detect Time, Next Tx Time, Last TX Time

[Andy Zhou]

On Thu, May 18, 2017 at 6:39 AM, Gabor Szucs  wrote:
> Hi,
> This is a fix for ovs-appctl bfd/show printout that looks partly incorrect.
>
> ovs-appctl bfd/show command printout
> shows negative time lag from now for upcoming events:
> Detect Time: now -2632ms
> Next TX Time: now -800ms
> and positive time lag from now for past event:
> Last TX Time: now +150ms
>
> The fix negates the signs.
>
> Signed-off-by: Gábor Szűcs 
> Co-authored-by: Csaba Ihllye 
> Signed-off-by: Csaba Ihllye 

Thanks for sending the patch. Pushed to master.

The patch itself seems to be corrupted, may be it was sent with git send-email?
Since it is simple enough I just fixed it up locally before pushing.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] OVS bond interface OFPP_NORMAL and Openflow

[Piyush Agarwal]

Hi,
>From the FAQ:

Q: It looks like each of the interfaces in my bonded port shows up
   as an individual OpenFlow port.  Is that right?

A: Yes, Open vSwitch makes individual bond interfaces visible as
   OpenFlow ports, rather than the bond as a whole.  The interfaces
   are treated together as a bond for only a few purposes:

   - *Sending a packet to the OFPP_NORMAL port.  (When an OpenFlow*
* controller is not configured, this happens implicitly to*
* every packet.)*

   - The "autopath" Nicira extension action.  However, "autopath"
 is deprecated and scheduled for removal in February 2013.

   - Mirrors configured for output to a bonded port.

I have some questions based on this. This is what I am trying to achieve: I
have a two-interface bond port in OVS that I'd like balance-slb
load-balancing.
Let's say my OVS bridge is:

$ sudo ovs-vsctl show
bdb92ad6-3dc3-40c0-be03-714c88d1ac27
Bridge "testbr0"
Port "bond0"
Interface "veth1"
Interface "veth2"
Port "testbr0"
Interface "testbr0"
type: internal
Port "veth10"
Interface "veth10"
ovs_version: "2.5.0"


$ sudo ovs-ofctl -OOpenflow13 show testbr0
OFPT_FEATURES_REPLY (OF1.3) (xid=0x2): dpid:769ca595b645
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS GROUP_STATS QUEUE_STATS
OFPST_PORT_DESC reply (OF1.3) (xid=0x3):
 *1(veth1)*: addr:ae:c8:18:c7:8f:3e
 config: 0
 state:  0
 current:10GB-FD COPPER
 speed: 1 Mbps now, 0 Mbps max
 *2(veth2)*: addr:d2:26:71:c0:c3:a5
 config: 0
 state:  0
 current:10GB-FD COPPER
 speed: 1 Mbps now, 0 Mbps max
 *10(veth10)*: addr:ae:fd:60:a7:51:2c
 config: 0
 state:  0
 current:10GB-FD COPPER
 speed: 1 Mbps now, 0 Mbps max
 LOCAL(testbr0): addr:76:9c:a5:95:b6:45
 config: PORT_DOWN
 state:  LINK_DOWN
 speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (OF1.3) (xid=0x5): frags=normal miss_send_len=0

Sure enough the bond did not get an OF port number, but the member
interfaces did. What I want to do is this: for packets coming from veth10,
I want that traffic to be load-balanced across bond0 (comprised of veth1
and veth2).

1) Given the bond port gets no openflow port number, this looks like
something I can't do with an openflow controller at all. Right?

2) If I am to use the "normal" non-openflow pipeline,  it seems like the
flow that specifies action as OFPP_NORMAL has to be the last flow? Said
another way, I cannot match certain packets (coming on veth10) and set the
action to be OFPP_NORMAL, can I?

Are there are any guides/blog posts that help explain how to use
OFPP_NORMAL action, I couldn't find any practical example of this.

Thank you in advance for your input.

-- 
Piyush Agarwal
Life can only be understood backwards; but it must be lived forwards.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] Debian: Install libraries in Multi-Arch format

[Ben Warren via dev]

From: Ben Warren 

The Debian 'Multi-Arch' feature moves all library files (*.a, *.so) to
an architecture-specific directory.  This allows libraries for multiple
architectures to co-exist on a host and simplifies cross-compilation.

For example, issuing the following command:

apt-get install openvswitch-dev:amd64 openvswitch-dev:mips64el

will place libraries as follows:

$ find /usr/lib/ -name libopenvswitch*
/usr/lib/mips64el-linux-gnuabi64/pkgconfig/libopenvswitch.pc
/usr/lib/mips64el-linux-gnuabi64/libopenvswitch.a
/usr/lib/mips64el-linux-gnuabi64/libopenvswitch.so
/usr/lib/x86_64-linux-gnu/pkgconfig/libopenvswitch.pc
/usr/lib/x86_64-linux-gnu/libopenvswitch.a
/usr/lib/x86_64-linux-gnu/libopenvswitch.so

Signed-off-by: Ben Warren 
---
 debian/compat | 2 +-
 debian/control| 8 +---
 debian/openvswitch-common.install | 2 +-
 debian/openvswitch-dev.install| 6 +++---
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/debian/compat b/debian/compat
index 45a4fb7..ec63514 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-8
+9
diff --git a/debian/control b/debian/control
index 0b75f2b..b8b14bc 100644
--- a/debian/control
+++ b/debian/control
@@ -56,6 +56,7 @@ Description: Open vSwitch datapath module source - DKMS 
version
 
 Package: openvswitch-common
 Architecture: linux-any
+Multi-Arch: foreign
 Depends: openssl,
  python (>= 2.7),
  python-six,
@@ -285,9 +286,10 @@ Description: Open vSwitch VTEP utilities
 
 Package: openvswitch-dev
 Architecture: linux-any
-Depends:
- openvswitch-common (>= ${binary:Version}),
- ${misc:Depends}
+Multi-Arch: same
+Depends: openvswitch-common (= ${binary:Version}),
+ ${misc:Depends},
+ ${shlibs:Depends}
 Description: Open vSwitch development package
  Open vSwitch is a production quality, multilayer, software-based, Ethernet
  virtual switch. It is designed to enable massive network automation through
diff --git a/debian/openvswitch-common.install 
b/debian/openvswitch-common.install
index ebb7d5c..aa41204 100644
--- a/debian/openvswitch-common.install
+++ b/debian/openvswitch-common.install
@@ -9,4 +9,4 @@ usr/sbin/ovs-bugtool
 usr/share/openvswitch/bugtool-plugins
 usr/share/openvswitch/scripts/ovs-bugtool-*
 usr/share/openvswitch/scripts/ovs-lib
-usr/lib/lib*.so.*
+usr/lib/*/lib*.so.*
diff --git a/debian/openvswitch-dev.install b/debian/openvswitch-dev.install
index 11791e4..ca3d22c 100644
--- a/debian/openvswitch-dev.install
+++ b/debian/openvswitch-dev.install
@@ -1,6 +1,6 @@
-usr/lib/lib*.so
-usr/lib/lib*.a
-usr/lib/pkgconfig
+usr/lib/*/lib*.so
+usr/lib/*/lib*.a
+usr/lib/*/pkgconfig
 include/*.h usr/include/openvswitch
 include/openflow/*.h usr/include/openvswitch/openflow
 include/openvswitch/*.h usr/include/openvswitch/openvswitch
-- 
2.6.4

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

Re: [ovs-dev] [PATCH v5 0/7] create tunnel devices using rtnetlink interface

[Eric Garver]

On Thu, May 18, 2017 at 03:35:34PM -0700, Greg Rose wrote:
> On Thu, 2017-05-18 at 16:10 -0400, Eric Garver wrote:
> > This series adds support for the creation of tunnels using the rtnetlink
> > interface. This will open the possibility for new features and flags on 
> > those
> > vports without the need to change vport compatibility code.
> > 
> > Support for STT and LISP have not been added because these are not upstream 
> > yet,
> > so we don't know how the interface will be like upstream. And there are no
> > features in the current drivers right now we could make use of.
> > 
> > Note: This work originally started by Thadeu Lima de Souza Cascardo.
> > 
> > Note: There is a known failure for GENEVE tunnels using rtnetlink on newer
> > kernels. This is being addressed with a separate kernel fix. The fallback to
> > compat will work however.
> 
> I've applied these patches for testing and review and I get these errors
> when I run make check on a 4.12-rc1 kernel:
>  783: tunnel-push-pop.at:3 tunnel_push_pop - action
>  784: tunnel-push-pop.at:191 tunnel_push_pop - packet_out
>  785: tunnel-push-pop.at:229 tunnel_push_pop - underlay bridge match
>  786: tunnel-push-pop-ipv6.at:3 tunnel_push_pop_ipv6 - action
> 
> Are these the known failures?  Was there something in the compat that
> needs fixing?  I'm sort of new to this so please excuse any obvious
> ignorance showing.

Not known. Some of the tests aren't the most reliable. I usually run
with RECHECK=yes.

Here are the travis-ci results for this series (no failures):

   https://travis-ci.org/erig0/ovs/builds/233759266

> 
> I've downloaded the 4.9.23 kernel and will try against that next.

Thanks for testing!

> 
> Thanks,
> 
> - Greg
> 
> > 
> > Testing:
> >   - kernel 4.9.22, in-tree datapath
> > - rtnetlink successfully creates devices
> >   - kernel 4.2.8, in-tree datapath
> > - rtnetlink is tried, but fails due to no COLLECT_METADATA support
> > - genetlink successfully creates devices
> >   - kernel 4.2.8, out-of-tree datapath
> > - rtnetlink is not tried
> > - genetlink successfully creates devices
> >   - Create a native VXLAN interface with incorrect config, run VXLAN
> > check-kernel test. Old device is replaced by OVS created one.
> > 
> > v5:
> >   - Make dpif_netlink_rtnl_port_create() easier to follow.
> >   - Reword some patch descriptions
> > 
> > v4:
> >   - If device exists, verify and potentially delete/re-add. This handles the
> > case where OVS may be killed.
> >   - Further commonize rtnetlink code; create, verify, delete
> >   - Incorporate Joe's style changes from last review
> > 
> > v3:
> >   - commonzie code to get port data to verify port
> >   - eliminate dpif_netlink_rtnl_vxlan_destroy() and alike
> >   - minor changes for coding style guidelines
> >   - add ACKs from previous reviews
> > 
> > Eric Garver (6):
> >   dpif-netlink: Refactor code to create compat ports
> >   dpif-netlink: Support rtnetlink port creation.
> >   dpif-netlink-rtnl: Support VXLAN creation
> >   dpif-netlink-rtnl: Support GRE creation
> >   dpif-netlink-rtnl: Support GENEVE creation
> >   dpif-netlink: Probe for out-of-tree tunnels, decides used interface
> > 
> > Thadeu Lima de Souza Cascardo (1):
> >   netdev: get device type from vport prefix if it uses one
> > 
> >  NEWS|   3 +
> >  lib/automake.mk |   3 +
> >  lib/dpif-netlink-rtnl.c | 467 
> > 
> >  lib/dpif-netlink-rtnl.h |  54 ++
> >  lib/dpif-netlink.c  | 210 ++
> >  lib/dpif-netlink.h  |   2 +
> >  lib/netdev.c|  26 ++-
> >  7 files changed, 691 insertions(+), 74 deletions(-)
> >  create mode 100644 lib/dpif-netlink-rtnl.c
> >  create mode 100644 lib/dpif-netlink-rtnl.h
> > 
> 
> 
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] TMB REWARD

[Telekom Malaysia Berhad]

Telekom Malaysia Berhad
Level 51, North Wing, Menara TM,
Jalan Pantai Baru, 50672,
Kuala Lumpur,
WP Kuala Lumpur,
Malaysia.


Hadiah Bonus Tahun Baru.

Pihak Telekom Malaysia @Program Kemenangan yang telah diadakan pada 15 April 
2017 di mana alamat email anda yang disertakan beraama Tiket Kemenangan 
nombor 2 - 4 - 
16-37 - 89 - 40 -85 dengan siri nombor 2268/02 telah memenangi loteri 
kategori hadiah kedua khas keluarga Telekom Malaysia.Untuk menuntut hadiah 
kemenangan ini anda dikehendaki menghubungi melalui e mail Bahagian Tuntutan 
untuk tujuan pemerosesan dan pembayaran hadiah wang tunai kepada anda.

Di sepanjang program Khas Keluarga Telekom yang telah diadakan di Ibupejabat 
di Kuala Lumpur sejumlah Rm270,000.00 (Ringgit Malaysia : Dua Ratus Tujuh 
Puluh Ribu) telah dianugerahkan kepada anda oleh Telekom Malaysia Berhad 
kepada anda dan keluarga anda sempena sambutsn Hari Raya 2017 ini.

Program ini turut dibiayai bersama oleh Toyota Malaysia dan Tenaga Nasional 
sebagai pakej istimewa Telekom 2017 dan anda perlu memahami bahawa e mail ini 
adalah 100% sah dan diiktiraf kerana program ini kebiasaannya diadakan sekali 
dalam masa lima tahun.

Sila hubungi agen kami untuk menuntut hadiah ini :

EN SHAFIE BIN HASSAN
Pengarah Bahagian Tuntutan
E-mail: onlinetmbcla...@outlook.my

Untuk tujuan pemerosesan sila hubungi agen kami dengan maklumat-maklumat 
berikut :
1) Nama Penuh:
2). Umur:
3). Pekerjaan:
4). Telefon:
5). Negeri/Bandar:

Perlu diingatkan bahawa hadiah akhir tahun Telekom Malaysia Berhad 2017 ini 
adalah diberikan khas kepada anda dan keluarga anda dan anda hendaklah 
membuat tunttan ini 
sebelum 31 Mei 2017.

Terima kasih.

Mrs Nadia binti Rafik
Pengurus Eksekutif
Anugerah Telekom Malaysia
Ibupejabat telekom Malaysia.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

[ovs-dev] 回复:Re: [PATCH] Supporting ovn-northd service HA depend on OVNDB-HA

[高正伟]

Thanks Numan


I think that supporting  OVNDB and ovn-northd HA  depend on one pacemaker is an 
idea,   In case of thinking OVN-HA,  user will not individually care about 
OVNDB or ovn-northd HA.


Thanks.



在 2017-05-18 20:53:22，"Numan Siddique"  写道：





On Wed, May 17, 2017 at 9:15 PM, Ben Pfaff  wrote:
From: Zhengwei Gao 

As ovn-northd servcie  parse network element between ovnnb_db and
ovnsb_db, it ensures ovn-northd service connecting to ovnnb_db and
ovnsb_db. OVNDB-HA was supported with pacemaker, ovn-northd service
will be failover fllowing OVNDB-HA.
---
This was posted as a github pull request:
https://github.com/openvswitch/ovs/pull/176

 ovn/utilities/ovndb-servers.ocf | 4 
 1 file changed, 4 insertions(+)

diff --git a/ovn/utilities/ovndb-servers.ocf b/ovn/utilities/ovndb-servers.ocf
index 908cb3c17d84..40c55411e828 100755
--- a/ovn/utilities/ovndb-servers.ocf
+++ b/ovn/utilities/ovndb-servers.ocf
@@ -122,8 +122,12 @@ ovsdb_server_notify() {
 # the right thing at startup
 ocf_log debug "ovndb_server: $host_name is the master"
 ${CRM_ATTR_REPL_INFO} -v "$host_name"
+# Startup ovn-northd service
+${OVN_CTL} start_northd

 else
+# Stop ovn-northd service
+${OVN_CTL} stop_northd
 # Synchronize with the new master
 ocf_log debug "ovndb_server: Connecting to the new master 
${OCF_RESKEY_CRM_meta_notify_promote_uname}"
 ${OVN_CTL} demote_ovnnb --db-nb-sync-from-addr=${MASTER_IP} \



I tried this patch and it works.
In the case of OpenStack and Tripleo, puppet is used to create and manage the 
pacemaker resources for OVN [1] and it also starts ovn-northd as a pacemaker 
service with colocation constraint set to the virtual ip created for the OVN DB 
servers.


I think it makes more sense to start ovn-northd based on a flag (like 
START_NORTHD) so that the user or the configuration systems can chose.


Thanks
Numan






[1] - 
https://review.openstack.org/#/c/372274/10/manifests/profile/pacemaker/ovn_northd.pp
 
--
2.10.2

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

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

Re: [ovs-dev] [PATCH v5 0/7] create tunnel devices using rtnetlink interface

[Greg Rose]

On Thu, 2017-05-18 at 15:53 -0700, Joe Stringer wrote:
> On 18 May 2017 at 15:35, Greg Rose  wrote:
> > On Thu, 2017-05-18 at 16:10 -0400, Eric Garver wrote:
> >> This series adds support for the creation of tunnels using the rtnetlink
> >> interface. This will open the possibility for new features and flags on 
> >> those
> >> vports without the need to change vport compatibility code.
> >>
> >> Support for STT and LISP have not been added because these are not 
> >> upstream yet,
> >> so we don't know how the interface will be like upstream. And there are no
> >> features in the current drivers right now we could make use of.
> >>
> >> Note: This work originally started by Thadeu Lima de Souza Cascardo.
> >>
> >> Note: There is a known failure for GENEVE tunnels using rtnetlink on newer
> >> kernels. This is being addressed with a separate kernel fix. The fallback 
> >> to
> >> compat will work however.
> >
> > I've applied these patches for testing and review and I get these errors
> > when I run make check on a 4.12-rc1 kernel:
> >  783: tunnel-push-pop.at:3 tunnel_push_pop - action
> >  784: tunnel-push-pop.at:191 tunnel_push_pop - packet_out
> >  785: tunnel-push-pop.at:229 tunnel_push_pop - underlay bridge match
> >  786: tunnel-push-pop-ipv6.at:3 tunnel_push_pop_ipv6 - action
> >
> > Are these the known failures?  Was there something in the compat that
> > needs fixing?  I'm sort of new to this so please excuse any obvious
> > ignorance showing.
> >
> > I've downloaded the 4.9.23 kernel and will try against that next.
> 
> Hmm, I've tried it on my dev box with kernel 4.9.11 and I don't see
> any failures.
> 
> If these reliably fail, could you post the testsuite.log?

It's the 4.12-rc1 kernel.  He mentions known failures on newer kernels.

- Greg

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

Re: [ovs-dev] OVS bond interface OFPP_NORMAL and Openflow

[Ben Pfaff]

On Thu, May 18, 2017 at 04:24:18PM -0700, Piyush Agarwal wrote:
> Hi,
> From the FAQ:
> 
> Q: It looks like each of the interfaces in my bonded port shows up
>as an individual OpenFlow port.  Is that right?
> 
> A: Yes, Open vSwitch makes individual bond interfaces visible as
>OpenFlow ports, rather than the bond as a whole.  The interfaces
>are treated together as a bond for only a few purposes:
> 
>- *Sending a packet to the OFPP_NORMAL port.  (When an OpenFlow*
> * controller is not configured, this happens implicitly to*
> * every packet.)*
> 
>- The "autopath" Nicira extension action.  However, "autopath"
>  is deprecated and scheduled for removal in February 2013.
> 
>- Mirrors configured for output to a bonded port.
> 
> I have some questions based on this. This is what I am trying to achieve: I
> have a two-interface bond port in OVS that I'd like balance-slb
> load-balancing.
> Let's say my OVS bridge is:
> 
> $ sudo ovs-vsctl show
> bdb92ad6-3dc3-40c0-be03-714c88d1ac27
> Bridge "testbr0"
> Port "bond0"
> Interface "veth1"
> Interface "veth2"
> Port "testbr0"
> Interface "testbr0"
> type: internal
> Port "veth10"
> Interface "veth10"
> ovs_version: "2.5.0"
> 
> 
> $ sudo ovs-ofctl -OOpenflow13 show testbr0
> OFPT_FEATURES_REPLY (OF1.3) (xid=0x2): dpid:769ca595b645
> n_tables:254, n_buffers:256
> capabilities: FLOW_STATS TABLE_STATS PORT_STATS GROUP_STATS QUEUE_STATS
> OFPST_PORT_DESC reply (OF1.3) (xid=0x3):
>  *1(veth1)*: addr:ae:c8:18:c7:8f:3e
>  config: 0
>  state:  0
>  current:10GB-FD COPPER
>  speed: 1 Mbps now, 0 Mbps max
>  *2(veth2)*: addr:d2:26:71:c0:c3:a5
>  config: 0
>  state:  0
>  current:10GB-FD COPPER
>  speed: 1 Mbps now, 0 Mbps max
>  *10(veth10)*: addr:ae:fd:60:a7:51:2c
>  config: 0
>  state:  0
>  current:10GB-FD COPPER
>  speed: 1 Mbps now, 0 Mbps max
>  LOCAL(testbr0): addr:76:9c:a5:95:b6:45
>  config: PORT_DOWN
>  state:  LINK_DOWN
>  speed: 0 Mbps now, 0 Mbps max
> OFPT_GET_CONFIG_REPLY (OF1.3) (xid=0x5): frags=normal miss_send_len=0
> 
> Sure enough the bond did not get an OF port number, but the member
> interfaces did. What I want to do is this: for packets coming from veth10,
> I want that traffic to be load-balanced across bond0 (comprised of veth1
> and veth2).
> 
> 1) Given the bond port gets no openflow port number, this looks like
> something I can't do with an openflow controller at all. Right?

An OpenFlow controller can output a packet to "NORMAL", which honors
bond configuration.  With this port setup, that's likely to do what you
want.

> 2) If I am to use the "normal" non-openflow pipeline,  it seems like the
> flow that specifies action as OFPP_NORMAL has to be the last flow? Said
> another way, I cannot match certain packets (coming on veth10) and set the
> action to be OFPP_NORMAL, can I?

I don't know what the "last flow" is.

You can use "NORMAL" as the action for any packets you like.

> Are there are any guides/blog posts that help explain how to use
> OFPP_NORMAL action, I couldn't find any practical example of this.

Well, suppose you want to switch TCP and ARP packets coming in veth10,
balancing them across veth1 and veth2, and drop all the other packets
that come in on veth10.  You could use a flow table like this:

priority=50, in_port=10, tcp, actions=normal
priority=50, in_port=10, arp, actions=normal
priority=40, in_port=10, actions=drop

You'd probably also want a flow to handle packets coming in on the other
ports, too:
priority=0, actions=normal
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ofproto-dpif-ipfix: add support for per-flow TCP counters

[Ben Pfaff]

On Thu, May 11, 2017 at 11:13:27AM +0100, Przemyslaw Szczerbik wrote:
> This patch implements support for per-flow TCP IPFIX counters. It's based on 
> RFC
> 5102, section 5.10.
> 
> Signed-off-by: Przemyslaw Szczerbik 

Thanks for working on IPFIX!

I suggest folding in an update to NEWS to mention this new feature,
e.g.:

diff --git a/NEWS b/NEWS
index 7a2b185bbd84..ab2faec02e57 100644
--- a/NEWS
+++ b/NEWS
@@ -10,7 +10,9 @@ Post-v2.7.0
Log level can be changed in a usual OVS way using
'ovs-appctl vlog' commands for 'dpdk' module. Lower bound
still can be configured via extra arguments for DPDK EAL.
-   - IPFIX now provides additional counters for totals since startup.
+   - IPFIX now provides additional counters:
+ * Total counters since metering process startup.
+ * Per-flow TCP flag counters.
- New support for multiple VLANs (802.1ad or "QinQ"), including a new
  "dot1q-tunnel" port VLAN mode.
- In ovn-vsctl and vtep-ctl, record UUIDs in commands may now be

However, I am worried about this feature.  I suspect that it does not
report correct statistics.  It infers that, if a flow's tcp_flags
contains a given flag, then that flag has been seen on every packet.
But this is incorrect: in fact, it only means that the flag has been
seen on at least one packet.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v6 1/5] userspace: Switching of L3 packets in L2 pipeline

[Ben Pfaff]

On Fri, May 12, 2017 at 11:07:38AM +, Zoltán Balogh wrote:
> From: Jan Scheurich 
> 
> Ports have a new layer3 attribute if they send/receive L3 packets.
> 
> The packet_type included in structs dp_packet and flow is considered in
> ofproto-dpif. The classical L2 match fields (dl_src, dl_dst, dl_type, and
> vlan_tci, vlan_vid, vlan_pcp) now have Ethernet as pre-requisite.
> 
> A dummy ethernet header is pushed to L3 packets received from L3 ports
> before the the pipeline processing starts. The ethernet header is popped
> before sending a packet to a L3 port.
> 
> For datapath ports that can receive L2 or L3 packets, the packet_type
> becomes part of the flow key for datapath flows and is handled
> appropriately in dpif-netdev.
> 
> In the 'else' branch in flow_put_on_pmd() function, the additional check
> flow_equal(&match.flow, &netdev_flow->flow) was removed, as a) the dpcls
> lookup is sufficient to uniquely identify a flow and b) it caused false
> negatives because the flow in netdev->flow may not properly masked.
> 
> In dpif_netdev_flow_put() we now use the same method for constructing the
> netdev_flow_key as the one used when adding the flow to the dplcs to make sure
> these always match. The function netdev_flow_key_from_flow() used so far was
> not only inefficient but sometimes caused mismatches and subsequent flow
> update failures.
> 
> Signed-off-by: Lorand Jakab 
> Signed-off-by: Simon Horman 
> Signed-off-by: Jiri Benc 
> Signed-off-by: Yi Yang 
> Signed-off-by: Jan Scheurich 
> Co-authored-by: Zoltan Balogh 

Hi Zoltan, thanks for sending v6.

I suggest folding in the incremental appended to this message.  It
changes "packet_type=(0,0x0)" into just "packet_type=(0,0)", which looks
more natural to me, and corrects a few minor style points.

More importantly, I'm getting a test failure.  The relevant bits are:

785. tunnel-push-pop.at:229: testing tunnel_push_pop - underlay bridge 
match ...
...
../../tests/tunnel-push-pop.at:264: ovs-appctl ofproto/trace ovs-dummy 
'in_port(2),eth_type(0x0800),ipv4(src=1.1.3.88,dst=1.1.3.112,proto=17,tos=0,ttl=64,frag=no),udp(src=51283,dst=4789)'
stdout:
Flow: 
udp,in_port=LOCAL,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=1.1.3.88,nw_dst=1.1.3.112,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=51283,tp_dst=4789

bridge("int-br")

 0. priority 32768
output:3
 -> output to native tunnel
 -> tunneling to 1.1.2.92 via br0
 -> tunneling from aa:55:aa:55:00:00 1.1.2.88 to f8:bc:12:44:34:b6 
1.1.2.92

Final flow: 
udp,in_port=LOCAL,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=1.1.3.88,nw_dst=1.1.3.112,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=51283,tp_dst=4789
Megaflow: recirc_id=0,ip,in_port=LOCAL,nw_ecn=0,nw_frag=no
Datapath actions: 
push_eth(src=00:00:00:00:00:00,dst=00:00:00:00:00:00),tnl_push(tnl_port(3),header(size=42,type=3,eth(dst=f8:bc:12:44:34:b6,src=aa:55:aa:55:00:00,dl_type=0x0800),ipv4(src=1.1.2.88,dst=1.1.2.92,proto=47,tos=0,ttl=64,frag=0x4000),gre((flags=0x2000,proto=0x6558),key=0x1c8)),out_port(100))
../../tests/tunnel-push-pop.at:265: tail -1 stdout
--- -   2017-05-18 20:54:02.253568043 -0700
+++ /home/blp/nicira/ovs/_build/tests/testsuite.dir/at-groups/785/stdout
2017-05-18 20:54:02.249243540 -0700
@@ -1,2 +1,2 @@
-Datapath actions: 
tnl_push(tnl_port(3),header(size=42,type=3,eth(dst=f8:bc:12:44:34:b6,src=aa:55:aa:55:00:00,dl_type=0x0800),ipv4(src=1.1.2.88,dst=1.1.2.92,proto=47,tos=0,ttl=64,frag=0x4000),gre((flags=0x2000,proto=0x6558),key=0x1c8)),out_port(100))
+Datapath actions: 
push_eth(src=00:00:00:00:00:00,dst=00:00:00:00:00:00),tnl_push(tnl_port(3),header(size=42,type=3,eth(dst=f8:bc:12:44:34:b6,src=aa:55:aa:55:00:00,dl_type=0x0800),ipv4(src=1.1.2.88,dst=1.1.2.92,proto=47,tos=0,ttl=64,frag=0x4000),gre((flags=0x2000,proto=0x6558),key=0x1c8)),out_port(100))


--8<--cut here-->8--

diff --git a/lib/match.c b/lib/match.c
index 4855c74a4401..6b7bb9bd476a 100644
--- a/lib/match.c
+++ b/lib/match.c
@@ -1258,11 +1258,11 @@ match_format(const struct match *match, struct ds *s, 
int priority)
 ds_put_format(s, "packet_type=(%u,*),",
   pt_ns(f->packet_type));
 } else if (pt_ns_type_be(wc->masks.packet_type) == OVS_BE16_MAX) {
-ds_put_format(s, "packet_type=(%u,0x%"PRIx16"),",
+ds_put_format(s, "packet_type=(%u,%#"PRIx16"),",
   pt_ns(f->packet_type),
   pt_ns_type(f->packet_type));
-} else{
-ds_put_format(s, "packet_type=(%u,0x%"PRIx16"/0x%"PRIx16"),",
+} else {
+ds_put_format(s, "packet_type=(%u,%#"PRIx16"/%#"PRIx16"),",
   pt_ns(f->packet_type),
   pt_ns_type(f->packet_type),
   pt_ns_type(wc->masks.packet_type));
di

[ovs-dev] [PATCH] Fix flake8 check

[Terry Wilson]

Stop occluding the previous definition of filename.

Signed-off-by: Terry Wilson 
---
 Documentation/conf.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index d70ee6b..62531dd 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -121,6 +121,6 @@ _man_pages = [
 
 # Generate list of (path, name, description, [author, ...], section)
 man_pages = [
-('ref/%s' % filename, filename.split('.', 1)[0],
- description, [author], filename.split('.', 1)[1])
-for filename, description in _man_pages]
+('ref/%s' % fname, fname.split('.', 1)[0],
+ description, [author], fname.split('.', 1)[1])
+for fname, description in _man_pages]
-- 
1.8.3.1

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

Re: [ovs-dev] [PATCH v6 2/5] userspace: L3 tunnel support for GRE and LISP

[Ben Pfaff]

On Fri, May 12, 2017 at 11:07:40AM +, Zoltán Balogh wrote:
> From: Jan Scheurich 
> 
> Add a boolean "layer3" configuration option for tunnel vports.
> The layer3 option defaults to false for all ports except LISP.
> GRE ports accept both true and false for "layer3".
> 
> A tunnel vport configured with layer3=true receives L3 packets.
> which are then converted to Ethernet packets by pushing a dummy
> Ethernet heder at the ingress of the OpenFlow pipeline. The
> Ethernet header of a packet is stripped before sending to a
> layer3 tunnel vport.
> 
> Presently a single GRE vport cannot carry both L2 and L3 packets.
> But it is possible to create two GRE vports representing the same
> GRE tunel, one with layer3=false, the other with layer3=true.
> L2 packet from the tunnel are received on the first vport, L3
> packets on the second. The controller must send packets to the
> layer3 GRE vport to tunnel them without their Ethernet header.
> 
> Units tests have been added to check the L3 tunnel handling.
> 
> LISP tunnels are not yet supported by the netdev userspace datapath.
> 
> Signed-off-by: Simon Horman 
> Signed-off-by: Jiri Benc 
> Signed-off-by: Yi Yang 
> Signed-off-by: Jan Scheurich 
> Co-authored-by: Zoltan Balogh 

Thank you for the revision!  I've had a few user inquiries lately about
L3 tunnels, so I think that this feature will be welcomed.

There are a few minor white space errors:

WARNING: Line has non-spaces leading whitespace
#357 FILE: vswitchd/vswitch.xml:2396:
header present.

WARNING: Line has non-spaces leading whitespace
#358 FILE: vswitchd/vswitch.xml:2397:
  

I think that parse_gre_header() should perhaps be pickier about the
Ethertypes it accepts, since values below 0x600 are not valid
Ethertypes and sometimes they are used for special purposes, for example
OpenFlow uses 0x5ff to mean that the frame lacks an Ethertype.

I recommend adding an item to NEWS to mention this new user-visible
feature.

Ideally, some new documentation would explain how layer 2 and 3 packets
interact.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] coding-style: Fix typo.

[Ben Pfaff]

Signed-off-by: Ben Pfaff 
---
 Documentation/internals/contributing/coding-style.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/internals/contributing/coding-style.rst 
b/Documentation/internals/contributing/coding-style.rst
index 4694b2363775..666e887b1b68 100644
--- a/Documentation/internals/contributing/coding-style.rst
+++ b/Documentation/internals/contributing/coding-style.rst
@@ -210,7 +210,7 @@ accept and ignore a null pointer argument. Code that calls 
such a function
 null-pointer check. We find that this usually makes code easier to read.
 
 Functions in ``.c`` files should not normally be marked ``inline``, because it
-does not usually help code generation and it does suppress compilers warnings
+does not usually help code generation and it does suppress compiler warnings
 about unused functions. (Functions defined in .h usually should be marked
 inline.)
 
-- 
2.10.2

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

Re: [ovs-dev] [PATCH v6 3/5] dpif-netlink: Don't send PACKET_TYPE to kernel

[Ben Pfaff]

On Fri, May 12, 2017 at 11:07:42AM +, Zoltán Balogh wrote:
> The kernel datapath does not support the packet_type match field.
> Instead it encodes the packet type implictly by the presence or absence of
> the Ethernet attribute in the flow key and mask.
> 
> This patch filters the PACKET_TYPE attribute out of netlink flow key and
> mask to be sent to the kernel datapath.
> 
> Signed-off-by: Zoltan Balogh 

Thank you for v6!

checkpatch has a few complaints:

ERROR: Inappropriate spacing in pointer declaration
#10 FILE: b/lib/dpif-netlink.c:2921:
nl_msg_put_exclude_packet_type(struct ofpbuf* buf, uint16_t type,

WARNING: Line length is >79-characters long
#15 FILE: b/lib/dpif-netlink.c:2926:
  
OVS_KEY_ATTR_PACKET_TYPE);

WARNING: Line length is >79-characters long
#18 FILE: b/lib/dpif-netlink.c:2929:
ovs_assert(NLA_ALIGN(packet_type->nla_len) == NLA_HDRLEN + 
sizeof(uint32_t));

The commit message is clear, but it's less obvious in the code what's
going on.  I suggest that some version of the commit message explanation
be put at the top of nl_msg_put_exclude_packet_type()

The name nl_msg_put_exclude_packet_type() makes it sound like the
function should be in netlink.c, not in dpif-netlink.c.  I suggest
adjusting the name to avoid the nl_msg_ prefix.

nl_msg_put_exclude_packet_type() uses the expression NLA_HDRLEN +
sizeof(uint32_t) a couple of times.  I suggest NL_A_U32_SIZE instead.

In:
+size_t first_chunk_size =
+(size_t)((uint8_t *)packet_type - (uint8_t *)data);
the cast is unneeded, because an initializer implicitly converts its
expression to the type of the initialized object.

nl_msg_put_exclude_packet_type() should not be declared "inline",
because coding-style.rst says:

Functions in ``.c`` files should not normally be marked ``inline``,
because it does not usually help code generation and it does
suppress compilers warnings about unused functions. (Functions
defined in .h usually should be marked inline.)

It looks like this patch fixes a bug that was introduced by the first
patch in the series.  If that's true, then this patch should be folded
into patch 1, so that "git bisect" later does not land in a buggy commit
accidentally.

Thanks,

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

Re: [ovs-dev] [PATCH v6 4/5] ofproto-dpif-xlate: refactor compose_output_action__

[Ben Pfaff]

On Fri, May 12, 2017 at 11:07:43AM +, Zoltán Balogh wrote:
> From: Jan Scheurich 
> 
> The very long function compose_output_action__() has been re-factored to make
> the different cases for output to patch-port, native tunnel port, kernel 
> tunnel
> port, recirculation, or termination of a native tunnel at output to LOCAL port
> clearer. Larger, self-contained blocks have been split out into separate
> functions.
> 
> Signed-off-by: Jan Scheurich 
> Co-authored-by: Zoltan Balogh 
> 
> Conflicts:
>   ofproto/ofproto-dpif-xlate.c

I'm happy with this, it's a nice refactoring, although one wonders
whether it can be taken even farther.

I folded in the following incremental and applied this to master.

--8<--cut here-->8--

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 59ef77bf998a..f71a9db0a6b3 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -3303,11 +3303,9 @@ check_output_prerequisites(struct xlate_ctx *ctx,
 return true;
 }
 
-static inline bool
-terminate_native_tunnel(struct xlate_ctx *ctx,
-ofp_port_t ofp_port,
-struct flow *flow,
-struct flow_wildcards *wc,
+static bool
+terminate_native_tunnel(struct xlate_ctx *ctx, ofp_port_t ofp_port,
+struct flow *flow, struct flow_wildcards *wc,
 odp_port_t *tnl_port)
 {
 *tnl_port = ODPP_NONE;
@@ -3319,7 +3317,7 @@ terminate_native_tunnel(struct xlate_ctx *ctx,
 *tnl_port = tnl_port_map_lookup(flow, wc);
 }
 
-return (*tnl_port != ODPP_NONE);
+return *tnl_port != ODPP_NONE;
 }
 
 static void
@@ -3535,12 +3533,11 @@ compose_output_action__(struct xlate_ctx *ctx, 
ofp_port_t ofp_port,
 }
 
 if (out_port != ODPP_NONE) {
-
 /* Commit accumulated flow updates before output. */
 xlate_commit_actions(ctx);
 
 if (xr) {
-/* Recirculate the packet */
+/* Recirculate the packet. */
 struct ovs_action_hash *act_hash;
 
 /* Hash action. */
@@ -3553,7 +3550,6 @@ compose_output_action__(struct xlate_ctx *ctx, ofp_port_t 
ofp_port,
 /* Recirc action. */
 nl_msg_put_u32(ctx->odp_actions, OVS_ACTION_ATTR_RECIRC,
xr->recirc_id);
-
 } else if (is_native_tunnel) {
 /* Output to native tunnel port. */
 build_tunnel_send(ctx, xport, flow, odp_port);
@@ -3562,8 +3558,7 @@ compose_output_action__(struct xlate_ctx *ctx, ofp_port_t 
ofp_port,
 } else if (terminate_native_tunnel(ctx, ofp_port, flow, wc,
&odp_tnl_port)) {
 /* Intercept packet to be received on native tunnel port. */
-nl_msg_put_odp_port(ctx->odp_actions,
-OVS_ACTION_ATTR_TUNNEL_POP,
+nl_msg_put_odp_port(ctx->odp_actions, OVS_ACTION_ATTR_TUNNEL_POP,
 odp_tnl_port);
 
 } else {
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v6 5/5] userspace: add vxlan gpe support to vport

[Ben Pfaff]

On Fri, May 12, 2017 at 11:07:46AM +, Zoltán Balogh wrote:
> From: Georg Schmuecking 
> 
> This patch is based on the "datapath: enable vxlangpe creation in compat mode"
> from Yi Yang. It introduces an extension option "gpe" to the vxlan port in the
> netdev-dpdk datapath. Furthermore it introduces a new protocol header file
> vxlangpe.h in which the vxlan gpe protocoll is described. In the vxlan 
> specific
> methods the different packet are introduced and handled.
> 
> Added VXLAN GPE tunnel push test.
> 
> Signed-off-by: Yi Yang 
> Signed-off-by: Georg Schmuecking 

checkpatch says:

ERROR: Inappropriate bracing around statement
#138 FILE: lib/netdev-native-tnl.c:519:
if (gpe->oam_flag)

WARNING: Line has non-spaces leading whitespace
#153 FILE: lib/netdev-native-tnl.c:534:
}

WARNING: Line length is >79-characters long
#188 FILE: lib/netdev-native-tnl.c:578:
put_16aligned_be32(&vxh->vx_vni, 
htonl(ntohll(params->flow->tunnel.tun_id) << 8));

WARNING: Line length is >79-characters long
#206 FILE: lib/netdev-native-tnl.c:596:
put_16aligned_be32(&vxh->vx_vni, 
htonl(ntohll(params->flow->tunnel.tun_id) << 8));

In netdev_vxlan_pop_header(), I don't see anything that verifies that
the packet is long enough when GPE is present.

The formatting of the switch statements look different from the usual
OVS style, which is like this:

switch (gpe->next_protocol) {
case VXLAN_GPE_NP_IPV4:
next_pt = PT_IPV4;
break;
case VXLAN_GPE_NP_IPV6:
next_pt = PT_IPV6;
break;
case VXLAN_GPE_NP_ETHERNET:
next_pt = PT_ETH;
break;
default:
goto err;
}

I suspect that struct vxlanhdr_gpe should use ovs_16aligned_be32 for the
vx_vni member.

I doubt that these #defines are a good idea, in vxlangpe.h:

#define u8 uint8_t
#define u32 uint8_t
#define __be32 ovs_be32

struct vxlanhdr in lib/packets.h is pretty different in philosophy from
struct vxlanhdr_gpe in vxlangpe.h.  I'd suggest making the new structure
more like the existing one; OVS doesn't really use bit-fields much and
in my experience they do not make code much easier to deal with.

The new struct vxlan_metadata doesn't seem to be used anywhere and I
wonder whether it should be included.

Thanks,

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

Re: [ovs-dev] [PATCH v6 5/5] userspace: add vxlan gpe support to vport

[Yang, Yi Y]

Ben, vxlangpe.h is from Linux kernel header file, so style is Linux but not 
ovs, keeping these intact is to make sure there are same pieces in both 
userspace and kernel, so code is also almost same. We'll change it to ovs style 
per your comments. Zoltan, please let me know if you need any help from me.

-Original Message-
From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] 
On Behalf Of Ben Pfaff
Sent: Friday, May 19, 2017 12:54 PM
To: Zoltán Balogh 
Cc: 'd...@openvswitch.org' 
Subject: Re: [ovs-dev] [PATCH v6 5/5] userspace: add vxlan gpe support to vport

On Fri, May 12, 2017 at 11:07:46AM +, Zoltán Balogh wrote:
> From: Georg Schmuecking 
> 
> This patch is based on the "datapath: enable vxlangpe creation in compat mode"
> from Yi Yang. It introduces an extension option "gpe" to the vxlan 
> port in the netdev-dpdk datapath. Furthermore it introduces a new 
> protocol header file vxlangpe.h in which the vxlan gpe protocoll is 
> described. In the vxlan specific methods the different packet are introduced 
> and handled.
> 
> Added VXLAN GPE tunnel push test.
> 
> Signed-off-by: Yi Yang 
> Signed-off-by: Georg Schmuecking 

checkpatch says:

ERROR: Inappropriate bracing around statement
#138 FILE: lib/netdev-native-tnl.c:519:
if (gpe->oam_flag)

WARNING: Line has non-spaces leading whitespace
#153 FILE: lib/netdev-native-tnl.c:534:
}

WARNING: Line length is >79-characters long
#188 FILE: lib/netdev-native-tnl.c:578:
put_16aligned_be32(&vxh->vx_vni, 
htonl(ntohll(params->flow->tunnel.tun_id) << 8));

WARNING: Line length is >79-characters long
#206 FILE: lib/netdev-native-tnl.c:596:
put_16aligned_be32(&vxh->vx_vni, 
htonl(ntohll(params->flow->tunnel.tun_id) << 8));

In netdev_vxlan_pop_header(), I don't see anything that verifies that the 
packet is long enough when GPE is present.

The formatting of the switch statements look different from the usual OVS 
style, which is like this:

switch (gpe->next_protocol) {
case VXLAN_GPE_NP_IPV4:
next_pt = PT_IPV4;
break;
case VXLAN_GPE_NP_IPV6:
next_pt = PT_IPV6;
break;
case VXLAN_GPE_NP_ETHERNET:
next_pt = PT_ETH;
break;
default:
goto err;
}

I suspect that struct vxlanhdr_gpe should use ovs_16aligned_be32 for the vx_vni 
member.

I doubt that these #defines are a good idea, in vxlangpe.h:

#define u8 uint8_t
#define u32 uint8_t
#define __be32 ovs_be32

struct vxlanhdr in lib/packets.h is pretty different in philosophy from struct 
vxlanhdr_gpe in vxlangpe.h.  I'd suggest making the new structure more like the 
existing one; OVS doesn't really use bit-fields much and in my experience they 
do not make code much easier to deal with.

The new struct vxlan_metadata doesn't seem to be used anywhere and I wonder 
whether it should be included.

Thanks,

Ben.
___
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] Fix flake8 check

[Numan Siddique]

On Fri, May 19, 2017 at 9:39 AM, Terry Wilson  wrote:

> Stop occluding the previous definition of filename.
>
> Signed-off-by: Terry Wilson 
>

Acked-by: Numan Siddique 



> ---
>  Documentation/conf.py | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index d70ee6b..62531dd 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -121,6 +121,6 @@ _man_pages = [
>
>  # Generate list of (path, name, description, [author, ...], section)
>  man_pages = [
> -('ref/%s' % filename, filename.split('.', 1)[0],
> - description, [author], filename.split('.', 1)[1])
> -for filename, description in _man_pages]
> +('ref/%s' % fname, fname.split('.', 1)[0],
> + description, [author], fname.split('.', 1)[1])
> +for fname, description in _man_pages]
> --
> 1.8.3.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev