On Tue, Mar 14, 2017 at 01:01:02PM -0700, Joe Stringer wrote: > On 16 February 2017 at 14:25, Eric Garver <[email protected]> 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] ?
That rename is fine with me. I left it next to dpif-netlink because I think of it as an extension of that interface. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
