[ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

Jiannan Ouyang ouyangj at fb.com
Fri Jul 14 01:38:37 UTC 2017


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



More information about the dev mailing list