On Tue, Oct 6, 2015 at 11:45 AM, Jiri Benc <jb...@redhat.com> wrote: > On Tue, 6 Oct 2015 11:28:08 -0700, Pravin Shelar wrote: >> What do you have in mind? I do not see way to fix this issue in vport-*.c. > > It seems to me that e.g. the code you have in vxlan_egress_tun_info in > drivers/net/vxlan.c can be put into vxlan_get_egress_tun_info in > net/openvswitch/vport-vxlan.c. vport->dev is guaranteed to be vxlan, > and the current code accesses netdev_priv(dev) as struct vxlan_dev > anyway. > > This would of course not work if we created lwtunnel interface from the > ovs user space. But that's not going to happen with kernel 4.3, we'll > need a way to query datapath for features it supports for this to work
This issue exist for lwtunnel based devices, for vport based tunnels there is no bug. > - there's currently no useful way to determine whether the kernel > supports metadata based vxlan or not. I'm working on a patch to query > the datapath for the supported features but that's for net-next. Thus > I think we're safe. > We should be able to use lwtunnel devices on 4.3. How about using tunnel device parameters to detect lwtunnel support. For example in case of vxlan tunnel IFLA_VXLAN_COLLECT_METADATA flags can confirm lwtunnel support. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
