[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