On 13 July 2017 at 18:38, Jiannan Ouyang <ouya...@fb.com> wrote: > Hi Joe, > >> It's neat to see new tunnel implementations being introduced, and also >> quite cool that it doesn't require significant code changes to OVS to >> make this happen. Thanks for looking into this :-) > > Thanks :) > >> I mentioned on the netdev thread that we should work towards using the >> rtnetlink interface for using the latest kernel devices, eventually >> everything should switch over to that configuration path. >>ยท >> Do you expect that users will upgrade to the latest kernel to get GTP >> support? This is certainly the easier method from a >> development/support perspective. If this is the case, then I don't >> think we should need many (if any?) changes to the datapath/ directory >> in OVS. In this case patch #1 could be replaced with a little bit of >> extra code that pipes the device configuration through >> lib/dpif-netlink-rtnl.[ch]. > > I agree with your suggestion. > > For code deployment, let's assume uses will upgrade to the latest kernel. > Nowadays, does OVS tend to have a duplicated tunnel implementation? I noticed > there are some duplicated tunnel implementation for OVS datapath and the > "upstream" implementation. What's the plan here?
The code in the OVS tree helps to backport functionality to older kernels. For example, we currently allow building the OVS tree version of the module against kernel 3.10, but this kernel didn't have support for geneve tunnels. So, the compat code provides this functionality for those older kernels. Depending on the kernel version, how isolated the feature is, and how important that feature is to users, we may attempt to provide an implementation of a particular feature in the OVS tree so that users can use this module with whichever kernel they like, or we may just request that users upgrade their kernel to get the newer functionality. Typically the implementation in the OVS tree is based on the latest code that is available in the Linux tree at the time that the feature is introduced. Ideally the code directly under ovs/datapath/ is identical to upstream linux/net/openvswitch/ code, then the ovs/datapath/compat fleshes out all of the APIs necessary to build and use that functionality on the older kernel. It's always easier to ask users to upgrade and not provide an implementation in the OVS tree - it's a lot of work to support a backport. That's the background of my question. For what it's worth, there's some examples about the features supported on various platforms in Documentation/faq/releases.rst, and it would be good if your patch could update this as well. >> I have a broad question with this overall model - Does it assume that >> the OpenFlow controller is responsible for handling the GTP-C traffic? >> Then it just programs OVS to match on that GTP-C traffic and forward >> to the controller? Subsequently, whatever PDP contexts and so on that >> the controller's GTP-C implementation needs to create, it just sets up >> equivalent flows for this purpose? > > What you said are right, except that the patches are about GTP-U (userplane > GTP). We expect the OpenFlow controller to handle GTP-U traffics and create > flows for each PDP context. OK, so I think this is coming back to me. The kernel implementation will split out the GTP-C traffic and send it to an independent socket, where your GTP daemon can process the messages. So, the GTP-C traffic never hits OVS userspace. Does that sound right? _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
