Re: [ovs-dev] [PATCH 4.4-only] openvswitch: clear sender cpu before forwarding packets
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
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.
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.
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.
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.
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.
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
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.
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.
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
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.
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.
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
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
[ 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
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
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.
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.
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
[ 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
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
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.
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
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
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
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
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
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.
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.
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.
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.
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.
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
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.
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
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.
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
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
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.
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
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.
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.
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.
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
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
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.
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
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)
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
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.
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.
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.
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.
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.
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
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
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.
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.
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.
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'
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
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.
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
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
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
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
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
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 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
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
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
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
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
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
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.
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
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__
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
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
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
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