Yep, so there's definitely some arguments there and particularly if you're coming from an OVS-centric perspective then the logic follows. However, OVS doesn't operate as an island. My point is that the Linux kernel already has generic UDP tunnel common code which is shared between various tunnel device implementations (which are also used elsewhere in the kernel). This works with the generic OVS netdev device type which the latest OVS userspace code can now configure through rtnetlink. I'd expect that no further changes to OVS kernel API should be necessary to be able to use this infrastructure for new tunnel types; it just requires that the new tunnels implemented in kernel are taught about metadata_dst --- which, again, can be useful for other kernel users. There are nice things about this proposal, but until there are patches and a discussion in the upstream netdev community, we can't assume that this is the path forward for all datapaths.
On 6 July 2017 at 18:31, Yang, Yi Y <[email protected]> wrote: > Joe, thank you for your clarification, it will significantly reduce ovs > tunnel implementation dependency on Linux kernel if we just use udp tunnel in > kernel, anyway userspace tunnel implementations are also some duplicates of > kernel tunnel implementations less or more:-) > > I think it will simplify ovs tunnel implementation and maintenance if we use > generic encap & decap framework to do tunnel encap & decap and move such > processing into OpenFlow pipeline. > > -----Original Message----- > From: Joe Stringer [mailto:[email protected]] > Sent: Thursday, July 6, 2017 10:25 PM > To: Yang, Yi Y <[email protected]> > Cc: Wieger IJntema <[email protected]>; [email protected] > Subject: Re: [ovs-dev] GTP support to OVS upstream > > On 5 July 2017 at 03:54, Yang, Yi Y <[email protected]> wrote: >> I remember OpenFlow 1.6 spec (not finalized) proposes to use OpenFlow >> actions to do GTP-u encapsulation and decapsulation, current OvS tunnel >> implementation can't support the third kind of use case (don't encap & >> decap, just parse, match and forward), MEC (ETSI Molibe/Multi-access Edge >> Computing) the third kind of use case. >> >> I'm wondering if it is feasible to implement a generic UDP tunnel in OvS, >> let Openflow do encap /decap/parse&match, now ovs master has fully supported >> L3 tunnel port and PTAP(Packet type aware pipeline), we have posted out >> generic encap & decap actions implementation, once ovs officially merges >> them, ovs can support generic encap & decap action, we can base on them to >> implement GTP-u encap & decap, then it will be better if we can implement a >> generic UDP tunnel, ovs can add UDP tunnel ports with different UDP port to >> handle different tunnel protocol, I think this will be the best way to >> handle the aforementioned three kinds of use cases. > > When it comes to the OVS userspace datapath, this seems like it maps pretty > well to how things are already being done. When it comes to kernel APIs > though there's a bunch of considerations around minimizing code duplication > with the rest of the code, restricting scope/size creep of the module, and > expectations of how long the API is supported. I think further discussion is > necessary in that space to determine whether the OVS kernel module should > really follow this model or not. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
