Noticed, please check the reply for that one.

-----Original Message-----
From: Ben Pfaff [mailto:[email protected]] 
Sent: Thursday, August 10, 2017 4:04 AM
To: Yang, Yi Y <[email protected]>
Cc: [email protected]
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:[email protected]]
> Sent: Thursday, August 10, 2017 2:01 AM
> To: Yang, Yi Y <[email protected]>
> Cc: [email protected]
> 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 <[email protected]>
> 
> 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
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to