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

[Joe Stringer]

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 ;))