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

Jarno Rajahalme jrajahalme at nicira.com
Wed Oct 2 02:11:50 UTC 2013


> On Oct 1, 2013, at 6:36 PM, "Pritesh Kothari (pritkoth)" <pritkoth at cisco.com> wrote:

> 
>> Also, the usual treatment of reserved bits is ignore on reception, rather than
>> dropping.
> 
> hmm. i didn't quite get what you are saying here, vxlan_vni and svc_path both use upper 24bits
> and their detection seems same to me here: 
> 
> vxlan.c:118: if (vxh->vx_flags != htonl(VXLAN_FLAGS) || (vxh->vx_vni & htonl(0xff))) {
> 
> or if (unlikely(nsh->b.svc_path & htonl(NSH_M_NSI))) { // NSH_M_NSI ==> 0x000000ff which is same as 0xff above?
> am i missing something here?
> 

I did not check if the NSH spec tells to reject packets with reserved bits set, but if it did, that would not be too forward compatible. I'm not stating anything about vxlan here.

>> 
>>> +            pr_warn("invalid NSH service path=%#x\n",
>>> +                    ntohl(nsh->b.svc_path));
>>> +            goto drop;
>>> +        }
>>> +
>>> +        nsp = nsh->b.svc_path | htonl(nsh->b.svc_idx);
>>> +    }
>>> +
>> ...
>>> 
>>> --- a/include/linux/openvswitch.h
>>> +++ b/include/linux/openvswitch.h
>>> @@ -304,6 +304,7 @@ enum ovs_tunnel_key_attr {
>>>    OVS_TUNNEL_KEY_ATTR_TTL,        /* u8 Tunnel IP TTL. */
>>>    OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT,    /* No argument, set DF. */
>>>    OVS_TUNNEL_KEY_ATTR_CSUM,        /* No argument. CSUM packet. */
>>> +    OVS_TUNNEL_KEY_ATTR_NSP,        /* be32 NSH service path */
>> 
>> Should state here that only lowest 24 bits are used.
> 
> yep will mention it, its actually upper 24 bits.
> 

Check once more, as it seems to me that the value from the attr is shifted left, so it is the lowest 24 bits of the attr that are used...


  Jarno




More information about the dev mailing list