Ben, no matter it is MD type 1 or MD type 2, we use the same netlink attribute 
OVS_ACTION_ATTR_ENCAP_NSH to transfer these data, another netlink attribute 
OVS_KEY_ATTR_NSH is for struct ovs_key_nsh. So I can't catch your point, can 
you explain it more?

-----Original Message-----
From: Ben Pfaff [mailto:b...@ovn.org] 
Sent: Thursday, August 10, 2017 2:01 AM
To: Yang, Yi Y <yi.y.y...@intel.com>
Cc: d...@openvswitch.org
Subject: Re: [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to support 
variable length

On Wed, Aug 09, 2017 at 07:45:13PM +0800, Yi Yang wrote:
> In order to adapt to MD type 1 and MD type 2 at the same time and 
> avoid breaking Linux kernel uAPI later, we change struct 
> ovs_action_encap_nsh to the below format.
> 
> struct ovs_action_encap_nsh {
>     uint8_t flags;
>     uint8_t mdtype;
>     uint8_t mdlen;
>     uint8_t np;
>     __be32 path_hdr;
>     uint8_t metadata[];
> };
> 
> struct ovs_action_encap_nsh will be allocated dynamically when it is 
> used.
> 
> The following patch will change encap_nsh and decap_nsh into push_nsh 
> and pop_nsh, respectively, Linux kernel guys prefer
> push_* and pop_*.
> 
> Signed-off-by: Yi Yang <yi.y.y...@intel.com>

This is an unusual format for a Netlink attribute.  More commonly, one would 
put variable-length data into an attribute of its own, which allows that data 
to be handled using the regular Netlink means.  Then the mdlen and metadata 
members could be removed, since they would be part of the additional attribute, 
and one might expect the mdtype member to be removed as well since each type of 
metadata would be in a different attribute type.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to