[ovs-dev] [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to support variable length

[Yang, Yi Y]

Noticed, please check the reply for that one.

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

I gave a more detailed explanation later:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/337164.html

On Wed, Aug 09, 2017 at 07:52:38PM +0000, Yang, Yi Y wrote:
> 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:blp at ovn.org]
> Sent: Thursday, August 10, 2017 2:01 AM
> To: Yang, Yi Y <yi.y.yang at intel.com>
> Cc: dev at 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.yang at 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.