[ovs-dev] [PATCH 0/7] userspace: Support for L3 tunneling
Jarno Rajahalme
jarno at ovn.org
Fri Feb 3 23:28:10 UTC 2017
Thanks for this contribution, Jan & al!
I’ll start reviewing these right away. Please find my comment addressing your concern below,
> On Feb 3, 2017, at 2:37 AM, Jan Scheurich <jan.scheurich at ericsson.com> wrote:
>
> This patch set is part of an initiative to deal with non-Ethernet packets in OVS for advanced use cases like L3 tunneling or NSH. The initiative is centering on the new OpenFlow concepts of "Packet type-aware pipeline" (PTAP) and "Generic encap/decap actions" (EXT-382). The overall design is documented in
> https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8
>
> This patch series implements the user-space parts of the support for L3 tunnels connected to the legacy Ethernet-only pipeline in OVS.
>
> In large parts it is an adaptation of the earlier work on L3 tunneling by Lorand Jakab, Simon Horman, Jiri Benc and Yi Yang, adapted to the new design for packet type aware pipelines as prototyped by Jean Tourrilhes.
>
> It supersedes user-space patches 9-11 of the most recent patch set submitted by Yi Yang (https://mail.openvswitch.org/pipermail/ovs-dev/2016-December/326865.html). The remaining user-space parts of that series (VXLAN-GPE) will be superseded by further patches in the context of this initiative.
>
> Key changes are the introduction of explicit packet_type fields in the dp_packet and flow structs, as well as a simpler handling of L3 tunnels limited to the ofproto layer.
>
> userspace: Add packet_type in dp_packet and flow
> userspace: Support for push_eth and pop_eth actions
> userspace: Switching of L3 packets in L2 pipeline
> ofproto-dpif-upcall: Intialize dump-seq of new flow to zero
> userspace: L3 tunnel support for GRE and LISP
> dpif-netlink: Don't send PACKET_TYPE to kernel
> ofproto-dpif-xlate: refactor compose_output_action__
>
> For native L3 tunneling with the user-space datapath these patches are complete. To apply L3 tunneling to the kernel datapath, they are dependent on the following other contributions:
>
> * [PATCH net-next v13 0/8] openvswitch: support for layer 3 encapsulated packets
> https://mail.openvswitch.org/pipermail/ovs-dev/2016-November/324943.html
> The net-next patch has been accepted
> * [RFC PATCH v4 0/6] create tunnel devices using rtnetlink interface
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327749.html
> * Another user-space patch to send the "layer3" option down via rtnetlink interface
> * Backports of the kernel datapath patches to the OVS tree module:
> Patches 01-08 of patch series [PATCH v2 00/17] port Jiri Benc's L3 patchset to ovs
> https://mail.openvswitch.org/pipermail/ovs-dev/2016-December/326865.html
> * A compatibility mechanism to send down "layer3" option to the backported kernel module to support older kernels.
>
> To ease the progress with the implementation of the subsequent user-space patches for the PTAP, EXT-382 and NSH and avoid the pain of frequent re-basing of these large patch series, we would like to request exemption for merging the present patch series before the kernel datapath pieces are all in place.
>
In general it is fine to add functionality to the userspace datapath even if no kernel equivalent exists. Then, should kernel equivalent become available, we typically have a choice between maintaining compatibility with different datapath implementations of a same feature, or changing the userspace datapath implementation to closely match the kernel so that one kind of translation can serve both datapaths. What we do not want is to accept changes to the OVS tree kernel module before a feature is upstreamed, as that could lead to an OVS release being made with one kind of ABI and then a later upstream kernel datapath having a different ABI, where in the worst case specific opcode values for actions, key fields, etc. might have different semantics, resulting into maintenance difficulties. As we do not have an ABI for the userspace datapath these concerns typically do not apply.
Jarno
> build-aux/extract-ofp-fields | 1 +
> datapath/linux/compat/include/linux/openvswitch.h | 19 +
> include/openflow/openflow-common.h | 9 +
> include/openvswitch/flow.h | 30 +-
> include/openvswitch/match.h | 1 +
> include/openvswitch/meta-flow.h | 15 +-
> include/openvswitch/ofp-print.h | 9 +-
> lib/dp-packet.c | 4 +
> lib/dp-packet.h | 37 +-
> lib/dpif-netdev.c | 62 ++--
> lib/dpif-netlink.c | 55 ++-
> lib/dpif.c | 8 +-
> lib/flow.c | 100 +++--
> lib/flow.h | 9 +
> lib/match.c | 21 +-
> lib/meta-flow.c | 2 +
> lib/netdev-bsd.c | 1 +
> lib/netdev-dummy.c | 5 +
> lib/netdev-linux.c | 4 +-
> lib/netdev-native-tnl.c | 27 +-
> lib/netdev-vport.c | 22 +-
> lib/netdev.h | 1 +
> lib/nx-match.c | 2 +-
> lib/odp-execute.c | 19 +
> lib/odp-util.c | 231 ++++++++++--
> lib/odp-util.h | 15 +-
> lib/ofp-print.c | 28 +-
> lib/ofp-util.c | 2 +-
> lib/packets.c | 45 +++
> lib/packets.h | 5 +-
> lib/pcap-file.c | 4 +-
> ofproto/ofproto-dpif-rid.h | 2 +-
> ofproto/ofproto-dpif-sflow.c | 8 +
> ofproto/ofproto-dpif-upcall.c | 6 +-
> ofproto/ofproto-dpif-xlate.c | 461 ++++++++++++++----------
> ofproto/ofproto-dpif.c | 6 +-
> ofproto/tunnel.c | 15 +-
> tests/test-flows.c | 2 +-
> tests/tunnel-push-pop-ipv6.at | 25 +-
> tests/tunnel-push-pop.at | 45 ++-
> tests/tunnel.at | 28 +-
> vswitchd/vswitch.xml | 13 +
> 42 files changed, 1008 insertions(+), 396 deletions(-)
>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
More information about the dev
mailing list