On Fri, Apr 15, 2016 at 10:56 AM, Nithin Raju <[email protected]> wrote: > -----Original Message----- > From: Jesse Gross <[email protected]> > Date: Friday, April 15, 2016 at 10:40 AM > To: Nithin Raju <[email protected]> > Cc: Paul Boca <[email protected]>, "[email protected]" > <[email protected]> > 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 <[email protected]> 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. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
