On Mar 7, 2014, at 12:51 PM, Pravin Shelar <pshe...@nicira.com> wrote:
> On Fri, Mar 7, 2014 at 11:52 AM, Pritesh Kothari (pritkoth) > <pritk...@cisco.com> wrote: >> Hi Pravin, >> >>>> >>>> if (type > OVS_TUNNEL_KEY_ATTR_MAX) { >>>> @@ -388,11 +390,16 @@ static int ipv4_tun_from_nlattr(const struct nlattr >>>> *attr, >>>> case OVS_TUNNEL_KEY_ATTR_CSUM: >>>> tun_flags |= TUNNEL_CSUM; >>>> break; >>>> + case OVS_TUNNEL_KEY_ATTR_NSP: >>>> + nsp = htonl(be32_to_cpu(nla_get_be32(a)) << 8); >>>> + tun_flags |= TUNNEL_NSP; >>>> + break; >>>> default: >>>> return -EINVAL; >>>> } >>>> } >>>> >>> I have not looked at entire patch but just noticed this. If you only >>> going to support NSP over vxlan only we should check if this packet is >>> for vxlan or add support of NSP for all tunneling protocols. >> >> yes actually the check does exists, here is the snippet from around line 445 >> of the patch: >> > Can you copy paste that code snippet? I could not find it. > > What I meant was, If NSP is set for tunnel then check if output > actions sends packet to vxlan. I am not sure if i get your question correctly, but from what i get, you mean to say that we should steer the packet to vxlan port if nsp is set right? I don’t think the patch works that way, its actually the other way round, i.e if we find a vxlan packet over a specific port (IANA assigned udp port 6633 [1]) only then we decide to push nsh header over it with a specific nsp set in that nsh header. [1] https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6633 Regards, Pritesh _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev