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? > 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. Thanks -Jiannan _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev