[ovs-dev] [PATCH v2 1/7] nsh: datapath support for network service headers

Pritesh Kothari (pritkoth) pritkoth at cisco.com
Fri Mar 7 22:15:43 UTC 2014


On Mar 7, 2014, at 12:51 PM, Pravin Shelar <pshelar at nicira.com> wrote:

> On Fri, Mar 7, 2014 at 11:52 AM, Pritesh Kothari (pritkoth)
> <pritkoth at 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


More information about the dev mailing list