[ovs-dev] [PATCH] VxLAN-gpe implementation

[Jiri Benc]

On Mon, 6 Jun 2016 14:22:58 -0700, Jesse Gross wrote:
> On Sat, Jun 4, 2016 at 6:39 AM, Yi Yang <yi.y.yang at intel.com> wrote:
> [...]
> >  datapath/vport-netdev.c                           |   3 +-
> >  datapath/vport-vxlan.c                            |  17 ++-
> 
> These changes aren't upstream yet. Please do that before backporting them here.
> 
> However, the changes to vport-vxlan.c are modifying compatibility code
> that shouldn't be extended further. Instead, just use the existing
> VXLAN netlink interfaces that have already been created to enable
> these features.
> 
> There is also a number of other patches to the OVS kernel module/VXLAN
> that have not been backported. Pravin started doing this work but it
> hasn't been applied yet. In general, I think it makes sense to
> backport patches in order so that the diffs of the patches match those
> of upstream.
> 
> Finally, I have a question about receive side offloading with
> VXLAN-gpe. This is primarily an upstream issue but is present in the
> code being backported here as well. The VXLAN code sets up receive
> offloads for all ports regardless of whether they are classic VXLAN or
> L2/L3 GPE and expects NICs to parse the packets. I don't think this is
> safe because there are a number of NICs out there that predate the
> existence of GPE and therefore won't do this parsing correctly. I
> think that it is necessary to disable receive offloading for
> non-Ethernet VXLAN-GPE unless the offloading interface is extended.

Coincidentally, I was talking about this with Hannes a few days ago.
I'm adding him to CC.

I guess you're referring to ndo_add_vxlan_port, right? I agree that
this interface needs changes, especially considering that we know
whether the UDP port belongs to VXLAN or VXLAN-GPE. But from my
understanding of how drivers use this callback, the worst thing that
could happen is suboptimal generation of rx hashes and thus steering
the packets to a different receive queue than in the optimal case.
Surely something to fix but it seems it won't cause much functional
troubles with the current code?

 Jiri