On Wed, Jun 15, 2016 at 10:12 PM, Nithin Raju <nit...@vmware.com> wrote:
>>>>diff --git a/datapath-windows/ovsext/Geneve.c
>>>>b/datapath-windows/ovsext/Geneve.c
>>>>new file mode 100644
>>>>index 0000000..8190a15
>>>>--- /dev/null
>>>>+++ b/datapath-windows/ovsext/Geneve.c
>>[...]
>>>>+ geneveHdr = (GeneveHdr *)((PCHAR)udpHdr + sizeof *udpHdr);
>>>>+ if (geneveHdr->protocol != htons(ETH_P_TEB)) {
>>>>+ status = STATUS_NDIS_INVALID_PACKET;
>>>>+ goto dropNbl;
>>>>+ }
>>>>+ tunKey->flags = OVS_TNL_F_KEY;
>>>>+ if (geneveHdr->oam) {
>>>>+ tunKey->flags |= OVS_TNL_F_OAM;
>>>>+ }
>>>
>>> VXLAN code has been recently updated to set OVS_TNL_F_KEY conditionally.
>>> Can you pls. udpate Geneve code as well?
>>
>>The key is always present in the Geneve header, so I'm not sure what
>>it would be conditional on.
>
> What should be the behavior if the VNI is 0? Is the packet considered a
> valid packet?
VNI of 0 is fine, there's no special meaning attached to it.
OVS_TNL_F_KEY should still be set in this case. (This is true of VXLAN
as well to be consistent with other datapath implementation. Any
policy decisions about this would be made in userspace.)
>>> Also, who takes care of validating if we can handle all of the critical
>>> options? Are the critical options part of the flow key?
>>
>>Userspace handles critical vs. non-critical options. The datapath just
>>needs to faithfully report what was received.
>
> Thanks for the info. I am assuming that ALL the options are part of the
> flow key - regardless of whether they are critical or not. So, once
> userspace sets up the flow in the datapath, any subsequent packet with the
> same Geneve header + options will match the flow.
Yes - just a dumb memcpy from the packet header to the flow key. If
this contains critical options which are unknown (and only userspace
knows which options are known) then userspace will install a drop
flow.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
