[ovs-dev] [RFC PATCH v1] docs: Add release feature roadmap.
Stephen Finucane
stephen at that.guru
Thu Sep 28 15:34:24 UTC 2017
On Wed, 2017-09-13 at 22:04 +0100, Ian Stokes wrote:
> Add a document to outline the roadmap of features contributors are targeting
> for upcoming OVS releases.
>
> Signed-off-by: Ian Stokes <ian.stokes at intel.com>
> ---
> Documentation/automake.mk | 1 +
> Documentation/faq/index.rst | 1 +
> Documentation/faq/release_feature_roadmap.rst | 350
> +++++++++++++++++++++++++
> 3 files changed, 352 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/faq/release_feature_roadmap.rst
>
> diff --git a/Documentation/automake.mk b/Documentation/automake.mk
> index 24fe63d..3e16873 100644
> --- a/Documentation/automake.mk
> +++ b/Documentation/automake.mk
> @@ -75,6 +75,7 @@ DOC_SOURCE = \
> Documentation/faq/terminology.rst \
> Documentation/faq/vlan.rst \
> Documentation/faq/vxlan.rst \
> + Documentation/faq/release_feature_roadmap.rst \
Looks like you've some extra whitespace here than shouldn't be here.
> Documentation/internals/index.rst \
> Documentation/internals/authors.rst \
> Documentation/internals/bugs.rst \
> diff --git a/Documentation/faq/index.rst b/Documentation/faq/index.rst
> index 334b828..e865f57 100644
> --- a/Documentation/faq/index.rst
> +++ b/Documentation/faq/index.rst
> @@ -41,3 +41,4 @@ Open vSwitch FAQ
> terminology
> vlan
> vxlan
> + release_feature_roadmap
> diff --git a/Documentation/faq/release_feature_roadmap.rst
> b/Documentation/faq/release_feature_roadmap.rst
> new file mode 100644
> index 0000000..40388f6
> --- /dev/null
> +++ b/Documentation/faq/release_feature_roadmap.rst
> @@ -0,0 +1,350 @@
> +..
> + Licensed under the Apache License, Version 2.0 (the "License"); you
> may
Ditto (before "Licensed")
> + 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.
> +
> +=======================
> +Release Feature Roadmap
> +=======================
> +
> +This document provides a feature roadmap for upcoming OVS releases.
> +
> +A few issues to note:
> +
> +* The aim of the roadmap is to provide visibility across the community
> + regarding which features contributors are targeting in the upcoming
> release.
> +* A feature listed on the roadmap is not guaranteed to be upstreamed in the
> + targeted release and a release will not be delayed in order to accommodate
> + features listed in the roadmap.
> +* It is not mandatory to include planned features in the roadmap although it
> + is encouraged. Features not listed but that are submitted will still be
> + reviewed as per usual for a release.
> +
> +------------------------------
> +Adding Features to the Roadmap
> +------------------------------
nit: overlines aren't necessary, and we don't use them for anything deeper than
the top-level header. Could you drop it here?
> +
> +When adding a feature to the roadmap a user should be aware of the required
> +fields and expected values as detailed below:
> +
> +* **Contributor**: The name of the person/company contributing the feature.
> +* **Feature Name**: The name of the feature being contributed.
> +* **Description**: A brief description of the feature being contributed.
> +
> +-----------------------
> +OVS 2.9 feature Roadmap
> +-----------------------
> +
> ++--------------------------------------------------------------------------+
> +| **OVS 2.9 Feature Roadmap** +
> ++--------------------------------------------------------------------------+
> +| |
> ++--------------------------------------------------------------------------+
> +| **Contributor**: *Intel* |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Keepalive |
> ++--------------------------------------------------------------------------+
> +| **Description**: Keepalive feature is aimed at achieving Fastpath Service|
> +| Assurance in OVS-DPDK deployments. It adds support for monitoring the |
> +| packet processing threads by dispatching heartbeats at regular intervals |
> +| and the status is updated periodically in OVSDB. In case of heartbeat |
> +| misses the failure is detected and reported to higher level fault |
> +| management systems/frameworks. The status can be monitored from OpenStack|
> +| Ceilometer service. |
> ++--------------------------------------------------------------------------+
This is good, but the whole thing would be a heck of a lot easier to read/write
if you used the 'list-table' directive. For example:
- * Contributor
* Feature Name
* Description
- * Intel
* Keepalive
* The keepalive feature is aimed...
Alternatively, you could use a definition list with terms under it like so:
Keepalive
:Contributor: Intel
The keepalive feature is aimed...
Either way, try to avoid anything that involves this kind of spacing because
it's really nasty to maintain.
> +| **Feature Name**: vHost PMD |
> ++--------------------------------------------------------------------------+
> +| **Description**: The vHost PMD brings vHost User ports under control of |
> +| DPDKs librte_ether library and in doing so DPDKs librte_vhost library |
> +| will no longer be directly referenced in OVS. Potential benefits include |
> +| shared code among port types in netdev-dpdk and smoother upgrades between|
> +| DPDK versions in OVS. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Multi-segment Mbuf |
> ++--------------------------------------------------------------------------+
> +| **Description**: Support for jumbo frames was added to netdev-dpdk in |
> +| v2.6.0. In that implementation, a jumbo frame is stored within a |
> +| single-segment mbuf. That mode will remain the default, but an option |
> +| will now be added to allow a jumbo frame to be stored within a |
> +| multi-segment mbuf. This reduces the requirement for large, contiguous |
> +| blocks of memory, and may be useful in deployments with limited memory. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Connection Tracker performance |
> ++--------------------------------------------------------------------------+
> +| **Description**: The Connection Tracker is a feature to manage stateful |
> +| connections and implement security Firewalls. This allows a better |
> +| protection against attacks and helps in load balancing. The counterpart |
> +| is a significant impact on the overall performance. This work is aimed at|
> +| analyzing possible bottlenecks – also considering the latest protocol |
> +| implementations - to improve the Connection Tracker performance. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: IPsec |
> ++--------------------------------------------------------------------------+
> +| **Description**: This feature looks to introduce IPsec into OVS with |
> +| DPDK. IPsec would function in transport mode and would be used in |
> +| conjunction with existing encapsulation methods (initially VxLAN) to |
> +| create a new interface type vxlanipsec. The DPDK cryptodev framework |
> +| will be used to handle cipher/digest operations as part of the |
> +| encap/decap actions in accordance with a security association. The |
> +| cryptodev devices supported would be limited to virtual crypto devices |
> +| such as the AESN-MB vdev. As such cipher and digest algorithms supported|
> +| would be limited to the capabilities of the vdev. In terms of Security |
> +| Association generation for IPsec policies, the feature will allow a user |
> +| to specify security associations via command line options for the |
> +| interface. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Zero copy |
> ++--------------------------------------------------------------------------+
> +| **Description**: Support for enabling DPDKs dequeue zero copy feature |
> +| on vHost User ports which removes the costly memcpy operation from guest |
> +| to host when enabled. Detailed information in the DPDK documentation: |
> +| http://dpdk.org/doc/guides/prog_guide/vhost_lib.html#vhost-api-overviewew
> |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: DPDK 17.05.2 and 17.11 |
> ++--------------------------------------------------------------------------+
> +| **Description**: DPDK 17.05.2 is the latest stable release of DPDK, and |
> +| includes numerous bug-fixes and stability updates. DPDK 17.11 will |
> +| include numerous new features, such as Generic Segmentation Offload (GSO)|
> +| and extended vHost PMD port ID enablement. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Upcall performance |
> ++--------------------------------------------------------------------------+
> +| **Description**: The first packet in every flow that is handled by OVS is|
> +| an upcall to the exception path. This is a performance bottleneck for |
> +| some use cases. Analysis and improvements to the performance of this code|
> +| path will be investigated. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Service Assurance : ipfix |
> ++--------------------------------------------------------------------------+
> +| **Description**: Virtual switching reporting of flow telemetry via IPFix.|
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Extended NIC Stats |
> ++--------------------------------------------------------------------------+
> +| **Description**: Expose low level driver statistics registers to the user|
> +| through the Extended NIC statistics API in DPDK for physical interfaces. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: QoS: Prioritizing latency sensitive traffic |
> ++--------------------------------------------------------------------------+
> +| **Description**: Provide a method to request ingress scheduling on |
> +| interfaces. Will include an implemtation of same for DPDK physical ports.|
> +| This allows specific packet types to be forwarded to their destination |
> +| port ahead of other packets and/or be less likely to be dropped in an |
> +| overloaded situation. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: NAT extended counters with sFlow |
> ++--------------------------------------------------------------------------+
> +| **Description**: Monitoring NAT flow telemetry via sFlow. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Megaflow cache lookup improvement (cuckoo distributor) |
> ++--------------------------------------------------------------------------+
> +| **Description**: The Datapath Classifier tuple space search can become a |
> +| performance bottleneck for a large number of subtables. This feature |
> +| presents the idea of the two-layer hierarchical lookup, where a low |
> +| overhead first level of indirection (called cuckoo distributor (CD)) is |
> +| accessed first to indicate with high probability which subtable the key |
> +| belongs to. CD improves the already existing Subtable Ranking when |
> +| traffic has high entropy and is adaptively turned off when it finds the |
> +| traffic mostly hit one subtable. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: NSH |
> ++--------------------------------------------------------------------------+
> +| **Description**: Network Service Header to enable service function |
> +| chaining. This is experimental in OVS 2.8, but will likely see full |
> +| support in 2.9. Currently the NSH RFC is still in draft. |
> ++--------------------------------------------------------------------------+
> +| |
> ++--------------------------------------------------------------------------+
> +| **Contributor**: *VMware* |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: OVSDB RAFT |
> ++--------------------------------------------------------------------------+
> +| **Description**: Add RAFT support to ovsdb-server to allow for greater |
> +| fail-over and scale-out of OVSDB. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: OVN Incremental update |
> ++--------------------------------------------------------------------------+
> +| **Description**: Don't require complete recalculation of all OVN state |
> +| when a minor change is made. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: DNS for controller names |
> ++--------------------------------------------------------------------------+
> +| **Description**: Currently, a controller can only be specified with an IP|
> +| address. Add support for DNS names. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Debian packaging |
> ++--------------------------------------------------------------------------+
> +| **Description**: Break the Debian packaging out of the main OVS repo. |
> +| This will make packaging easier on Debian. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Don't slow-path controller actions |
> ++--------------------------------------------------------------------------+
> +| **Description**: Currently, a controller action slow-paths all the |
> +| actions related to the flow. Make it so that actions that can be |
> +| executed in the datapath are executed there, with the controller action |
> +| implemented as a "userspace" action. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: OpenFlow 1.5-1.6 |
> ++--------------------------------------------------------------------------+
> +| **Description**: Improve support for the latest versions of OpenFlow. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Kernel meters |
> ++--------------------------------------------------------------------------+
> +| **Description**: Implement rate-limiting meters in the kernel. This will |
> +| be useful for on-the-wire traffic as well as the userspace/kernel channel|
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: ERSPAN |
> ++--------------------------------------------------------------------------+
> +| **Description**: Support ERSPAN in OVS. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: OVN IPsec |
> ++--------------------------------------------------------------------------+
> +| **Description**: Allow using encrypted tunnels in OVN. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: DPDK feature gaps for OVN gateway |
> ++--------------------------------------------------------------------------+
> +| **Description**: Identify features missing from the DPDK implementation |
> +| that would prevent it from being an OVN gateway. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: OVN ACL logging improvements |
> ++--------------------------------------------------------------------------+
> +| **Description**: Currently, we only log ACL events in ovn-controller.log.|
> +| Based on user-feedback, we may want to improve this. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Librarification |
> ++--------------------------------------------------------------------------+
> +| **Description**: Make parts of OVS more usable as a library. For example,|
> +| if we break OVN out as a separate project, it will have dependencies on |
> +| OVSDB. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Userspace fragmentation |
> ++--------------------------------------------------------------------------+
> +| **Description**: Add support for reassembling IP fragments in conntrack |
> +| for the userspace datapath. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: BPF |
> ++--------------------------------------------------------------------------+
> +| **Description**: Implement the datapath using BPF. The first target will |
> +| be Linux. Ideally, we could use a single BPF datapath on all supported |
> +| platforms. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: P4 |
> ++--------------------------------------------------------------------------+
> +| **Description**: Use P4 to define matches and actions instead of C. |
> ++--------------------------------------------------------------------------+
> +| |
> ++--------------------------------------------------------------------------+
> +| **Contributor**: *Red Hat* |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: OVN Live Migration |
> ++--------------------------------------------------------------------------+
> +| **Description**: Improve behavior of OVN when using VM live migration. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: OVN - IPv6 router solicitation |
> ++--------------------------------------------------------------------------+
> +| **Description**: Support OVN logical routers responding to router |
> +| solicitation requests (patches under review already) |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: OVN - IPv6 router advertisements |
> ++--------------------------------------------------------------------------+
> +| **Description**: Support periodic router advertisements being sent for |
> +| OVN logical routers. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: OVN - IPv6 dynamic neighbor discovery |
> ++--------------------------------------------------------------------------+
> +| **Description**: OVN logical routers need to be able to perform dynamic |
> +| neighbor discovery, similar to dynamic ARP support done for IPv4. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: OVN - IPv6 Load Balancer |
> ++--------------------------------------------------------------------------+
> +| **Description**: OVN currently only supports IPv4 addressing for load |
> +| balancers. Enhance load balancers to be IPv6-capable as well. |
> ++--------------------------------------------------------------------------+
> +| |
> ++--------------------------------------------------------------------------+
> +| **Contributor**: *ZTE* |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: OVN support TAAS |
> ++--------------------------------------------------------------------------+
> +| **Description**: Taas was designed to provide tenants and service |
> +| providers a means of monitoring the traffic flowing in their Neutron |
> +| provisioned virtual networks. Taas has been implemented in ovs, this work|
> +| will enable it in OVN. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: OVN support ECMP |
> ++--------------------------------------------------------------------------+
> +| **Description**: ECMP may be used in NFV, this work will implement it in |
> +| OVN. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: OpenFlow 1.5 |
> ++--------------------------------------------------------------------------+
> +| **Description**: Support for the versions of OpenFlow 1.5. |
> ++--------------------------------------------------------------------------+
> +| |
> ++--------------------------------------------------------------------------+
> +| **Contributor**: *Ericsson* |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: User-space tunneling improvements |
> ++--------------------------------------------------------------------------+
> +| **Description**: Improve the user-space tunnel handling with respect to |
> +| robustness and flexibility. Add better tools to detect and trouble-shoot |
> +| problems with tunnel connectivity. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Detailed PMD performance statistics |
> ++--------------------------------------------------------------------------+
> +| **Description**: Collect and display a wealth of PMD runtime statistics |
> +| for analysis of performance and to support trouble-shooting of |
> +| packet-drop bursts caused by events happening on sub-millisecond scale. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Improved packet drop statistics |
> ++--------------------------------------------------------------------------+
> +| **Description**: Allow trouble-shooters and operators to quickly monitor |
> +| the amount of packets dropped in OVS, split up for the various drop |
> +| reasons |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Upcall rate limiting |
> ++--------------------------------------------------------------------------+
> +| **Description**: Protect PMDs from uncontrolled slow-down through mass |
> +| upcalls by rate-limiting them (better drop some first packets than many |
> +| packets belonging to established flows). Can be considered a first step |
> +| towards the more ambitious "Upcall Performance" feature driven by Intel. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Separate PMD isolation from Rx queue pinning |
> ++--------------------------------------------------------------------------+
> +| **Description**: Make it possible to pin individual heavy Rx queues |
> +| without having to add dedicated PMDs or pin all other queues as well. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: dp_hash based select group |
> ++--------------------------------------------------------------------------+
> +| **Description**: Introduce a default select group mechanism parameter per|
> +| bridge to make the dp-hash based select group available to OF 1.3 |
> +| controllers. This is needed for scalable load balancing (e.g. for ECMP) |
> +| in OVS as the current default select group implementation requires one |
> +| upcall per connection to be load-balanced, which limits the connection |
> +| setup rate OVS can sustain. |
> ++--------------------------------------------------------------------------+
> +| **Feature Name**: Auto distribution of Rx queues to balance load of PMDs |
> ++--------------------------------------------------------------------------+
> +| **Description**: Monitor PMD load imbalance and trigger a load-based |
> +| re-distribution of Rx-queues over PMDs when individual PMDs are |
> +| overloaded and cause packet drop that can be avoided by a better balanced|
> +| distribution. This work build on Kevin Traynor's patch set currently on |
> +| the mailing list. |
> ++--------------------------------------------------------------------------+
Can't speak to any of the content, but it looks wonderful ;)
Stephen
More information about the dev
mailing list