[ovs-dev] [PATCH 3/3] datapath-windows: Removed always true condition in VXLAN

Jesse Gross jesse at kernel.org
Fri Apr 15 18:18:57 UTC 2016


On Fri, Apr 15, 2016 at 10:56 AM, Nithin Raju <nithin at vmware.com> wrote:
> -----Original Message-----
> From: Jesse Gross <jesse at kernel.org>
> Date: Friday, April 15, 2016 at 10:40 AM
> To: Nithin Raju <nithin at vmware.com>
> Cc: Paul Boca <pboca at cloudbasesolutions.com>, "dev at openvswitch.org"
> <dev at openvswitch.org>
> Subject: Re: [ovs-dev] [PATCH 3/3] datapath-windows: Removed always true
> condition in VXLAN
>
>>On Fri, Apr 15, 2016 at 10:27 AM, Nithin Raju <nithin at vmware.com> wrote:
>>> Paul,
>>> If you are sure that tunKey->tunnelId will always be set, it would be a
>>> good idea to mark .optional as FALSE in definition of
>>> nlFlowTunnelKeyPolicy.
>>
>>For tunnels in general, the key won't always be present. (GRE is an
>>example of where the key is optional in the protocol itself and this
>>is reflected in what would be received from netlink.)
>>
>>In the specific case of VXLAN, though, it is true that the instance ID
>>bit must always be set.
>
> Thanks for the input.
>
> That calls for more checks while adding the port and perhaps an ASSERT
> during VXLAN encap to make sure there¹s a valid Tunnel ID.

I think it's a bit heavyweight to have an assertion here - the kernel
should be able to deal with userspace that is buggy or malicious in a
graceful manner. If userspace doesn't provide a value for the tunnel
ID for protocols that require one, then it seems like the cleanest
thing to do is just fill in zero. (This is what Linux does.) I believe
that's what the original patch does, so it seems fine to me as is.



More information about the dev mailing list