[ovs-dev] [PATCH RFC v5 0/8] create tunnel devices using rtnetlink interface
Joe Stringer
joe at ovn.org
Tue Mar 14 20:01:02 UTC 2017
On 16 February 2017 at 14:25, Eric Garver <e at erig.me> 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.
>
> Testing:
> - kernel 4.9.3, 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
>
> v2:
>
> We are able to set the MTU to UINT16_MAX since it is not restricted by the
> driver during newlink.
>
> v3:
>
> Prefer to get type from vport before checking if device is opened. Also, disable
> IFLA_VXLAN_LEARNING as it's not enabled on compat vports as well.
>
> v4:
> - Probe for ovs_geneve on init, this indicates out-of-tree datapath
> - If exists, only try genetlink/compat
> - else, try rtnetlink and fallback to genetlink/compat
> - Read back and verify devices created with rtnetlink
> - checkpatch fixes
>
> v5:
> - Move rtnetlink code to a new file lib/dpif-rtnetlink.c. This is for
> creating/destroying linux tunnel devices.
> - Move probe patch to after GENEVE, so it doesn't break build.
> - Add NEWS item
> - Split patch 2 into two parts (patch 2 and 3 in this series)
>
> Eric Garver (7):
> dpif-netlink: break up code that creates compat ports
> dpif-netlink: code to create/destroy tunnel ports via rtnetlink
> dpif-netlink: add VXLAN creation support
> dpif-netlink: add GRE creation support
> dpif-netlink: add GENEVE creation support
> dpif-netlink: Probe for out-of-tree datapath.
> NEWS: Add item for creating tunnels via rtnetlink
>
> 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.c | 199 +++++++++++++-------
> lib/dpif-netlink.h | 2 +
> lib/dpif-rtnetlink.c | 515 +++++++++++++++++++++++++++++++++++++++++++++++++++
> lib/dpif-rtnetlink.h | 53 ++++++
> lib/netdev.c | 26 ++-
I had suggested something like lib/netdev-lwt.[ch], but perhaps it has
more to do with the dpif-netlink in the actual code. At the risk of
bikeshedding..
lib/dpif-provider.h defines the API that the lib/dpif-foo.[ch]
implementations implement. For example, dpif-netlink provides a DPIF
implementation based on netlink. dpif-netdev provides a DPIF
implementation based on top of net devices. Adding another,
dpif-rtnetlink.[ch] suggests it's a full datapath implementation, now
based on tnetlink, rather than some extra port handling pieces for
dpif-netlink. Maybe this would be more obvious if it were something
like dpif-netlink-rtnl.[ch] ?
(I'll try to get to the real review now ;))
More information about the dev
mailing list